Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
yes and no. Xilinx and Altera both have 'standard' libraries. They are VHDL, Verilog, schematic ..... you can guarantee them to be different as the underlying structure is different. Mostly they have their built-in's (pin definitions, LUTs block rams etc) but you can often find 74 series gates too. Xilinx has a rather nice core gen to build more complex functions.. some are free some cost. Mostly it depends on what you want from your library Simon "Simon Heinzle" <sheinzle@student.ethz.ch> wrote in message news:4344d45b@news1.ethz.ch... > Hi everybody, > > With ASICs, there are standard cell libraries in .lib file format for the > target process -- is there a comparable .lib file for the Xilinx FPGAs? > > Best regards, > Simon > >Article: 90176
> The warning talked about "3 NON-CLK pins" .. that's a dead giveaway for a > gated clock somewhere or using a signal which isn't a clock.... or using a > clock in a non-clock way. I would look at the circuit hard. > The clock divider has 2 outputs: a 50% duty cycle and a pulse at the last count of counter. I have connected 3 state machine to the pulse. Every machine and the other block are faliing edge sensitive. I have made the counter and the comparator with core generator. > You might find a good option is to use a couple of SLR16's as counters for > your SPI. each can replace a number of 'loads' with a single one. Seems a great idea, could you explain, please? > One solution is to duplicate the clock generator, the other is to ONLY use > the system clock. use a gate to latch the incoming data which is > generated > in parallel to the clock not from the clock. I will try it as soon as possible. Many and many thanks for your precious help. MarcoArticle: 90177
On Wed, 05 Oct 2005 21:31:02 -0700, austin <austin@xilinx.com> wrote:
>Oops,
Damn! I thought I had said enough, but apparently not.
>Looks like I read the 'english', and not the code.
Both are correct. Paul's circuit is a shift register (2 bits) and
it is logically indistinguishable from a shift register.
>Looks like it is registered once, and then sent to another FF. Both
>FF's are clocked on the rising edge, so it is not a metastability
>"filter"
Excuse me, this is a two stage synchronizer. Exactly.
>(which would clock the second FF on the falling edge) to reduce the
>probability of a metastable event
Which is NOT a two stage synchronizer. The "clock it on the falling edge"
circuit saves 1/2 a cycle in synchronizer latency, and makes
a major sacrifice in resolving time. This is not a good synchronizer.
Go read http://www.fpga-faq.org/FAQ_Pages/0017_Tell_me_about_metastables.htm
for more on this poor circuit.
>(they can not be prevented, but the statistics can be improved to where
>you just don't care).
Well I agree with this.
>That is a standard looking shift register. No issue with that.
Right. And assuming that it is clocked on the global clock net
(no reason not to assume this given Paul's posting) there are no
hold time issues that you seem to be worried about (probably because
it is written as a shift register (which can be problematic in ASICs)).
>The FPGA fabric is always slower than a global clock (except in some
>rare cases where things are really poorly placed due to other issues
>with poor or confusing or conflicting constraints), so there is no
>problem (like there could be in an ASIC) that the data might get to some
>FF's before the clock would (and an event is missed altogether).
>
>The tools should make a reasonably good placement to prevent problems.
>
>I have seen where folks used location constraints to be sure that the
>clock arrived at the MSB or last stage first, and then went against the
>flow of data towards the LSB or first stage to ensure that the clock
>would always get to the FF BEFORE the data coming to the FF could
>possibly change in ASIC standard cell flows. Not really needed in an
>FPGA: the fabric and clocks are supposed to be "correct by
>construction" so the engineer doesn't have to worry.
Agreed, but the issue being discussed in synchronizers.
>This whole thing also has nothing to do with metastability.
Oh yes it does! A two bit shift register is identical to a two
stage synchronizer.
>Austin
>> Paul Marciano wrote:
>>>
>>> Peter, rookie question: given the following synchronizer:
>>>
>>> module test(input clk, input in_sig, output reg out_sig);
>>> reg [1:0] ss;
>>>
>>> always @(posedge clk)
>>> begin
>>> out_sig <= ss[1];
>>> ss <= { ss[0], in_sig };
>>> end
>>> endmodule
>>>
>>>
>>> How, specifically, do I tell XST to locate ss[1] as close as possible
>>> to ss[0]?
>>>
>>>
>>> Regards,
>>> Paul.
>>>
Great! Now I've pissed of Peter and Austin. Did I mention I'm
not having a great week :-) :-)
Philip Freidin
Crusader for understanding metastability and how to minimize it.
===================
Philip Freidin
philip.freidin@fpga-faq.org
Host for WWW.FPGA-FAQ.ORG
Article: 90178"Marco" <marcotoschi@nospam.it> wrote in message news:di2neu$gk3$1@news.ngi.it... >> The warning talked about "3 NON-CLK pins" .. that's a dead giveaway for >> a >> gated clock somewhere or using a signal which isn't a clock.... or using >> a >> clock in a non-clock way. I would look at the circuit hard. >> > > The clock divider has 2 outputs: a 50% duty cycle and a pulse at the last > count of counter. > I have connected 3 state machine to the pulse. Every machine and the other > block are faliing > edge sensitive. > I have made the counter and the comparator with core generator. > > >> You might find a good option is to use a couple of SLR16's as counters >> for >> your SPI. each can replace a number of 'loads' with a single one. > > Seems a great idea, could you explain, please? > > > >> One solution is to duplicate the clock generator, the other is to ONLY >> use >> the system clock. use a gate to latch the incoming data which is >> generated >> in parallel to the clock not from the clock. > > I will try it as soon as possible. > > > Many and many thanks for your precious help. > Marco > I have finally found the trouble. I create a new thread to discuss on it. Many Thanks MarcoArticle: 90179
Hallo, I have made a clock divider (1 MHz) with a counter connected to system clock (50 MHz). This counter has a threshold which goes high on the last count. This pulse drives some blocks as a clock enable (the clock input of these blocks is connected to system clock). Every block is falling edge sensitive. The pulse drives also a FSM where every state send high/low 4 signals. In this way there is no gating clock, but now pulse signal has high load. I can't use DCM because of the too low out frequency. What could I do to reduce load and skew? The only way is to add a BUFG? Many Thanks in advance and sorry for my terrible english Marco ToschiArticle: 90180
Firstly thank you very much for your detailed answer. > > Is there ever scenario's where the area and switching overhead of a > > systolic array would warrant a less bandwidth efficient, more serial > > approach - or is that just plain ridulous to consider? > In fact only the serial solution has an area and switching overhead for > each computation. The systolic implementation only computes without > doing anything else. See below. I'm not too sure what you mean by this? Surely there is an area overhead for the systolic array versus a "serial"/single PE implementation? > > For example could you hope to trade less switching in the datapath for > > increased switching in the memory accesses but still make an overall > > reduction in switching? > > If your alogrithm dictates that you add two numbers, you can not save > the switching of the adder. But you might be able to save the memory access. Using your example of an adder, I have a algorithm where it is possible to avoid the addition completely if a certain condition occurs. With a systolic array the addition has to be completed, Thus my question, of whether a non- systolic implementation has major drawbacks. [snip] > If you have to perform the operations anyway it is allways more > efficient to perform them right away when the data is available compared > to sending intermediate results a long distance across chip or even off > chip. The later will slow down the process and consume a lot of power. I would totally agree with this point. > > However, this is the overall area/delay efficiency (computations per > time per area). If you have a fixed bandwidth goal perfect efficiency > doesn't help you much if you only have enough data available to utilize > the hardware only 1% of the time. In that case you go to a more serial > solution to save hardware. But the area/time/energy per computation > increases in that case. Thats a very helpful comparison. > > More complicated are problems were the systolic algorithm requires more > operations than the serial algorithm. In that case you need to tradeoff > the gains per computation of the systolic implementation vs. the > improved number of computations of the serial algorithm. I think this is my situation, so I'm going to try model the problem with C and evaluate the operations & cycles for both approaches. > > Kolja Sulimma Thank you again for your very enlightening response.Article: 90181
Hi,
we do not succeed in compiling our design using mixed voltage I/O macros
in ACTEL Designer 6.2 (SP2). To illustrate the problem, we have reduced it
to a simple 2-input AND gate . (If someone wants to try we have attached the
VHDL and the edif files below.)
The error message is :
Error: A mixed-voltage I/O macro is found in the design. This macro type is
not supported. When Vddp = 2.5V, use XX25LPXX macro. When Vddp = 3.3V, use
XX33XX I/O macro.
Please contact Actel Technical Support at 1-800-262-1060 or tech@actel.com
for more information.
According to the documentation, application notes and knowledge base on
the ACTEL website, we were lead to believe that the device apa-150 powered
with VDDp=3.3V is able to drive or receive both 2.5 and 3.3V compatible
signals (except for the 25LP macros).
Has anyone encountered this problem or know how to solve it ?
regards, J . Buytaert
CERN, Geneva
VHDL:
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_unsigned.all;
use IEEE.std_logic_arith.all;
use work.apa_comps.all;
entity test1 is
port( in1,in2 : in std_logic; out1 :out std_logic );
end;
architecture arch of test1 is
component ib25S port( Y : out std_logic; PAD : in
std_logic );
end component;
component ob33PH port( A : in std_logic; PAD : out
std_logic );
end component;
signal in1b, in2b, out1b : std_logic;
begin
out1b <= in1b and in2b ;
u1 : ib25s port map (in1b, in1 );
u2 : ib25s port map (in2b, in2 );
u3 : ob33ph port map (out1b, out1 );
end;
EDIF:
(edif test1
(edifVersion 2 0 0)
(edifLevel 0)
(keywordMap (keywordLevel 0))
(status
(written
(timeStamp 2005 10 6 11 51 34)
(author "Synplicity, Inc.")
(program "Synplify" (version "7.7.0, Build 054R"))
)
)
(library APA
(edifLevel 0)
(technology (numberDefinition ))
(cell GND (cellType GENERIC)
(property area (integer 0))
(view prim (viewType NETLIST)
(interface
(port Y (direction OUTPUT)
(property function (string "0"))
(property load (integer 0))
)
)
(property area (integer 0))
)
)
(cell PWR (cellType GENERIC)
(property area (integer 0))
(view prim (viewType NETLIST)
(interface
(port Y (direction OUTPUT)
(property function (string "1"))
(property load (integer 0))
)
)
(property area (integer 0))
)
)
(cell AND2 (cellType GENERIC)
(property area (integer 1))
(view prim (viewType NETLIST)
(interface
(port Y (direction OUTPUT)
(property function (string "A B"))
(property load (integer 0))
)
(port A (direction INPUT)
(property capacitance (integer 1))
(property load (integer 1))
)
(port B (direction INPUT)
(property capacitance (integer 1))
(property load (integer 1))
)
)
(property write_in_amethyst_lib (integer 1))
(property is_combinational (integer 1))
(property area (integer 1))
)
)
)
(library work
(edifLevel 0)
(technology (numberDefinition ))
(cell ib25S (cellType GENERIC)
(view syn_black_box (viewType NETLIST)
(interface
(port Y (direction OUTPUT))
(port PAD (direction INPUT))
)
)
)
(cell ob33PH (cellType GENERIC)
(view syn_black_box (viewType NETLIST)
(interface
(port A (direction INPUT))
(port PAD (direction OUTPUT))
)
)
)
(cell test1 (cellType GENERIC)
(view arch (viewType NETLIST)
(interface
(port in1 (direction INPUT))
(port in2 (direction INPUT))
(port out1 (direction OUTPUT))
)
(contents
(instance out1b (viewRef prim (cellRef AND2 (libraryRef
)
(instance u3 (viewRef syn_black_box (cellRef ob33PH))
)
(instance u2 (viewRef syn_black_box (cellRef ib25S))
)
(instance u1 (viewRef syn_black_box (cellRef ib25S))
)
(instance PWR_i (viewRef prim (cellRef PWR (libraryRef
)
(instance GND_i (viewRef prim (cellRef GND (libraryRef
)
(net in1 (joined
(portRef in1)
(portRef PAD (instanceRef u1))
))
(net in2 (joined
(portRef in2)
(portRef PAD (instanceRef u2))
))
(net out1 (joined
(portRef PAD (instanceRef u3))
(portRef out1)
))
(net (rename out1bZ0 "out1b") (joined
(portRef Y (instanceRef out1b))
(portRef A (instanceRef u3))
))
(net in1b (joined
(portRef Y (instanceRef u1))
(portRef A (instanceRef out1b))
))
(net in2b (joined
(portRef Y (instanceRef u2))
(portRef B (instanceRef out1b))
))
(net VCC (joined
(portRef Y (instanceRef PWR_i))
))
(net GND (joined
(portRef Y (instanceRef GND_i))
))
)
)
)
)
(design test1 (cellRef test1 (libraryRef work)))
)
Article: 90182I am doing some work targeted to StratixGX family for me RTL or gate delay simulation is a must. Can i do a post synthesis simulation in Modelsim for stratix GX Family using the synthesis output design.vho file from QuartusII. But this simulation should include gate delays specifically. as like in Xilinx I can do a pre Map simulation which gives gate delays. Please mail me on kedar.apte@patni.com Regards KedarArticle: 90183
First of all, thanks for the reply! Could these 'standard' libraries be used for timing analysis, e.g. for a core gen normally used for ASICs (to get a rough but more meaningful timing analysis than without any information)? Best regards, Simon "Simon Peacock" <simon$actrix.co.nz> wrote in message news:4344dc5b@news2.actrix.gen.nz... > yes and no. > > Xilinx and Altera both have 'standard' libraries. They are VHDL, Verilog, > schematic ..... you can guarantee them to be different as the underlying > structure is different. > > Mostly they have their built-in's (pin definitions, LUTs block rams etc) > but you can often find 74 series gates too. > Xilinx has a rather nice core gen to build more complex functions.. some > are > free some cost. Mostly it depends on what you want from your library > > Simon > > "Simon Heinzle" <sheinzle@student.ethz.ch> wrote in message > news:4344d45b@news1.ethz.ch... >> Hi everybody, >> >> With ASICs, there are standard cell libraries in .lib file format for the >> target process -- is there a comparable .lib file for the Xilinx FPGAs? >> >> Best regards, >> Simon >> >> > >Article: 90184
The APA devices can't have mixed voltage I/O. Table 1-3 on page 1-9 of the datasheet (5.0) clearly shows that with VDDP of 3.3V, then the input compatability & output drive are both 3.3V. To get around the problem you need to use external components to change the logic levels. Regards, Neill. J buytaert wrote: > Hi, > we do not succeed in compiling our design using mixed voltage I/O macros > in ACTEL Designer 6.2 (SP2). To illustrate the problem, we have reduced it > to a simple 2-input AND gate . (If someone wants to try we have attached the > VHDL and the edif files below.) > The error message is : > Error: A mixed-voltage I/O macro is found in the design. This macro type is > not supported. When Vddp = 2.5V, use XX25LPXX macro. When Vddp = 3.3V, use > XX33XX I/O macro. > > Please contact Actel Technical Support at 1-800-262-1060 or tech@actel.com > for more information. > > According to the documentation, application notes and knowledge base on > the ACTEL website, we were lead to believe that the device apa-150 powered > with VDDp=3.3V is able to drive or receive both 2.5 and 3.3V compatible > signals (except for the 25LP macros). > Has anyone encountered this problem or know how to solve it ? > > regards, J . Buytaert > CERN, Geneva >Article: 90185
"J buytaert" <jan.buytaert@cern.ch> schrieb im Newsbeitrag news:di2v3o$7m2$1@sunnews.cern.ch... > Hi, > we do not succeed in compiling our design using mixed voltage I/O macros > in ACTEL Designer 6.2 (SP2). To illustrate the problem, we have reduced it datasheet reading skills: PA+ DS, page 1-9 top righ corner table at any given vddp there is only 1 standard supported either 2.5 or 3.3 this also understandable as we there are know (ASFAIK) FPGAs available that would support 2.5 drive from 3.3V IO voltage. think of AP+ as a device with single IO bank, all IOs are using same IO voltage. for your application you most likely can safely use 3.3V io macros even when the other end is 2.5 drive AnttiArticle: 90186
Hello again. I have read all your postings about this and it was
interesting. I read the XAPP094 document and found a new idea how to solve
the problem.
As I wrote before, the input signal is synchronous to a 1.8 MHz clock and I
want to synchronize it to a 24 MHz clock.
After reading the XAPP094 I found a new way to qualify the signal to be
synchronous to 24 MHz. (se VHDL listing below).
How it works: The input signal is first sampled at the rising clock edge
(sample a) then again on falling clock edge (sample b). If the two samples
(a and b) are the same then I change the output signal on the next rising
edge to the value of a.
What do you all think about this solution?
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity qualify is
Port ( clk_24M : in std_logic;
d : in std_logic;
q : out std_logic);
end qualify;
architecture beh of qualify is
signal a, b : std_logic := '0';
begin
process(clk_24M)
begin
if rising_edge(clk_24M) then
a <= d;
end if;
end process;
process(clk_24M)
begin
if falling_edge(clk_24M) then
b <= d;
end if;
end process;
process(clk_24M)
begin
if rising_edge(clk_24M) then
if a = b then
q <= a;
end if;
end if;
end process;
end beh;
"Peter Alfke" <peter@xilinx.com> wrote in message
news:1128457315.762325.327300@o13g2000cwo.googlegroups.com...
> "Metastability" is a popular word to scare inexperienced designers.
>
> If you run a 1.8 MHz clock (even with a similar asynchronous data
> rate), your chance of having a 3 ns extra metastable delay is once per
> billion years (at 24 MHz it would be only 5 million years).
> For every additional ns of acceptable settling time, the
> mean-time-between-failure increases at least a million times. (see
> XAPP094 on the Xilinx website)
> The probability of your flip-flop failing during the life of this
> universe (even if you do nothing) with more than 10 ns of
> unaccounted-for delay is so minute it is practically zero.
> There are more important things to worry about, forget metastability...
> Peter Alfke, Xilinx Applications (who actually has created quantitative
> data about metastability)
>
Article: 90187My ISE7.1 says parallel cable drivers installed, but refuses to recognize my old cable III and tries using anon-existent multilink. Seems to be reading Prom & Virtex Id's, but can't start them after program. How do I get IMPACT to accept a Cable III ?Article: 90188
I have noticed that Synplify 8.1A seems to name things differently to 7.51A, so it might just be that you need to change the name in the DCF file. Marie wrote: > Good morning, > > I had a design wich was working fine in Libero 6.0 SP3 (Synplify > 7.51A). I made an upgrade to Libero 6.2 SP2 (Synplify 8.1A). > When I open the project the conversion works fine. > Without changing anything to the vhdl files or viewdraw schematic file > I redo the synthesis with Synplify. It seems to work without problem. > I then open Designer. I get the following error message: > Error: ERROR in SECTION GLOBAL_CLOCKS near line 17 :: > DCF#023: Invalid pin Z_1I478:PAD. Pin is Ignored > Warning: The constraint data (DCF) has unavailable net/pin references. > The invalid constraints will be removed. > I did not change anything to the clock pins! > I prevent Synplify to use automatically all clock pins (HCLK, CLKA and > CLKB) for all the clocks it finds in the design by adding two attribute > lines (syn_noclockbuf...) in the vhd file created by viewdraw. > And I use a CLKBUF in viewdraw to be allowed to set my clock signal on > the CLKA pin. > I am almost certain the problem comes from Synplify because if I do > exactly the same steps but without redoing the synthesis, that is > opening Designer directly after the conversion of the project then I > get not error during the layout. > Is there maybe an option in Synplify I have to change? > > Thank you very much, > > MarieArticle: 90189
Hi, you only need the .ise file in order to reuse your project,since the rest of files are automatically generated by the ISE environment,such as tcl scripts. The Xilinx Cores case is a bit more complex. You can regenerate your cores for the new project... you only have to check the paths contained in the .xco file and change it to your new project path, and then regenerate the core. Anyway, you can check all the files generated by Coregen in the [core_name]_readme.txt file created by Coregen in your working directory. "cyd" <cyd@spectrum.montana.edu> escribió en el mensaje news:1128539107.549495.182340@g43g2000cwa.googlegroups.com... > Anyone, > > I am looking for information concerning the neccissary files required > from a completed project to reuse in a new project. I write a top level > driver file in VHDL and often insert core generated processes. I run > into trouble when inserting the driver file into a new project when > core gen files were used. Specifically it is looking for a > wrapped_porcess (.xco ?). Question does ISE create a folder of > neccissary files of current project to be used in subsequent projects. > > Sincerley > > Cy Drollinger >Article: 90190
It seems to be a bit more suttle than that. In the data sheet mentioned is stated on page 1: "2.5 V/3.3 V Support with Individually Selectable Voltage and Slew Rate" You can see in the revision history of the of the application note of the I/O Features one can see that the 3.3/2.5 V I/O mixing was included in an earlier version of the application note. Moreover, the knowledge database describes how to implement it (which is what we tried and it doesn't work). http://www.actel.com/kb/article.aspx?id=KI25851 And the macro library guide http://www.actel.com/documents/pa_libguide.pdf states on e.g. page 62 which combinations of 2.5 and 3.3 V operation that is supported. Hence reading the documentation it is supported or at least has been supported. The question we have is if someone knows a workaround, if the feature has been supressed or knows why the Actel Designer compiler doen't accept something that is described in the library guide.Article: 90191
Philip Freidin wrote: >Oh yes it does! A two bit shift register is identical to a two >stage synchronizer. For most purposes. For physical floorplanning, it is not. If the UCF constrains two FFs to a clb, and the FFs are in a SRL16, then build will fail. For metastability, it is not. As I'm under the impression that SRL16s FFs are slower, I suspect that they are not as metastable hard. Peter or Austin, care to comment? If nothing else, there is not data on SRL16s, so I can't be sure how good or bad the solution is. This is also true of the BlockRAMs. I should have mentioned this above, but I unchecked the box (shift register extraction) so ISE didn't convert the FFs into a SRL16. Probably better do cover this in the code. Add this line to the Verilog: // synthesis attribute shreg_extract of ss is no; -- Phil Hays to reply solve: phil_hays at not(coldmail) dot com If not cold then hotArticle: 90192
Bill - Typical approach: clock the signal into a flip-flop with a 24 MHz clock, and give it most of a whole clock cycle to settle before applying it to the main circuit. Your approach: clock the signal into two flip-flops with the 24 MHz rising and falling edges, then apply the AND of the two flip-flop outputs to the main circuit. The problem with your approach is that the second flip-flop, the one clocked with the 24 MHz falling edge, has less than half as much time to settle (thanks to the AND gate delay) before being applied to the circuit. If the first flip-flop says HIGH and the second flip-flop says "I dunno," what happens to your circuit? Majority voting has often been proposed as a work-around for metastability. I've yet to see such a scheme that works. There's really only one way to reduce the probability that metastibility will upset your system: wait. Bob Perlman Cambrian Design Works On Thu, 6 Oct 2005 14:29:25 +0200, "Bill" <billbill@telia.se> wrote: >Hello again. I have read all your postings about this and it was >interesting. I read the XAPP094 document and found a new idea how to solve >the problem. > > > >As I wrote before, the input signal is synchronous to a 1.8 MHz clock and I >want to synchronize it to a 24 MHz clock. > > > >After reading the XAPP094 I found a new way to qualify the signal to be >synchronous to 24 MHz. (se VHDL listing below). > > > >How it works: The input signal is first sampled at the rising clock edge >(sample a) then again on falling clock edge (sample b). If the two samples >(a and b) are the same then I change the output signal on the next rising >edge to the value of a. > > > >What do you all think about this solution? > > > >library IEEE; >use IEEE.STD_LOGIC_1164.ALL; >use IEEE.STD_LOGIC_ARITH.ALL; >use IEEE.STD_LOGIC_UNSIGNED.ALL; > >entity qualify is > Port ( clk_24M : in std_logic; > d : in std_logic; > q : out std_logic); >end qualify; > >architecture beh of qualify is > signal a, b : std_logic := '0'; >begin > process(clk_24M) > begin > if rising_edge(clk_24M) then > a <= d; > end if; > end process; > > process(clk_24M) > begin > if falling_edge(clk_24M) then > b <= d; > end if; > end process; > > process(clk_24M) > begin > if rising_edge(clk_24M) then > if a = b then > q <= a; > end if; > end if; > end process; >end beh; > > > > > > >"Peter Alfke" <peter@xilinx.com> wrote in message >news:1128457315.762325.327300@o13g2000cwo.googlegroups.com... >> "Metastability" is a popular word to scare inexperienced designers. >> >> If you run a 1.8 MHz clock (even with a similar asynchronous data >> rate), your chance of having a 3 ns extra metastable delay is once per >> billion years (at 24 MHz it would be only 5 million years). >> For every additional ns of acceptable settling time, the >> mean-time-between-failure increases at least a million times. (see >> XAPP094 on the Xilinx website) >> The probability of your flip-flop failing during the life of this >> universe (even if you do nothing) with more than 10 ns of >> unaccounted-for delay is so minute it is practically zero. >> There are more important things to worry about, forget metastability... >> Peter Alfke, Xilinx Applications (who actually has created quantitative >> data about metastability) >> >Article: 90193
Phil,
I stand corrected,
Thanks.
It was late last night ...
Austin
Philip Freidin wrote:
> On Wed, 05 Oct 2005 21:31:02 -0700, austin <austin@xilinx.com> wrote:
>
>>Oops,
>
>
> Damn! I thought I had said enough, but apparently not.
>
>
>>Looks like I read the 'english', and not the code.
>
>
> Both are correct. Paul's circuit is a shift register (2 bits) and
> it is logically indistinguishable from a shift register.
>
>
>>Looks like it is registered once, and then sent to another FF. Both
>>FF's are clocked on the rising edge, so it is not a metastability
>>"filter"
>
>
> Excuse me, this is a two stage synchronizer. Exactly.
>
>
>>(which would clock the second FF on the falling edge) to reduce the
>>probability of a metastable event
>
>
> Which is NOT a two stage synchronizer. The "clock it on the falling edge"
> circuit saves 1/2 a cycle in synchronizer latency, and makes
> a major sacrifice in resolving time. This is not a good synchronizer.
>
> Go read http://www.fpga-faq.org/FAQ_Pages/0017_Tell_me_about_metastables.htm
>
> for more on this poor circuit.
>
>
>
>>(they can not be prevented, but the statistics can be improved to where
>>you just don't care).
>
>
> Well I agree with this.
>
>
>>That is a standard looking shift register. No issue with that.
>
>
> Right. And assuming that it is clocked on the global clock net
> (no reason not to assume this given Paul's posting) there are no
> hold time issues that you seem to be worried about (probably because
> it is written as a shift register (which can be problematic in ASICs)).
>
>
>>The FPGA fabric is always slower than a global clock (except in some
>>rare cases where things are really poorly placed due to other issues
>>with poor or confusing or conflicting constraints), so there is no
>>problem (like there could be in an ASIC) that the data might get to some
>>FF's before the clock would (and an event is missed altogether).
>>
>>The tools should make a reasonably good placement to prevent problems.
>>
>>I have seen where folks used location constraints to be sure that the
>>clock arrived at the MSB or last stage first, and then went against the
>>flow of data towards the LSB or first stage to ensure that the clock
>>would always get to the FF BEFORE the data coming to the FF could
>>possibly change in ASIC standard cell flows. Not really needed in an
>>FPGA: the fabric and clocks are supposed to be "correct by
>>construction" so the engineer doesn't have to worry.
>
>
> Agreed, but the issue being discussed in synchronizers.
>
>
>>This whole thing also has nothing to do with metastability.
>
>
> Oh yes it does! A two bit shift register is identical to a two
> stage synchronizer.
>
>
>>Austin
>
>
>
>>>Paul Marciano wrote:
>>>
>>>>Peter, rookie question: given the following synchronizer:
>>>>
>>>>module test(input clk, input in_sig, output reg out_sig);
>>>> reg [1:0] ss;
>>>>
>>>> always @(posedge clk)
>>>> begin
>>>> out_sig <= ss[1];
>>>> ss <= { ss[0], in_sig };
>>>> end
>>>>endmodule
>>>>
>>>>
>>>>How, specifically, do I tell XST to locate ss[1] as close as possible
>>>>to ss[0]?
>>>>
>>>>
>>>>Regards,
>>>>Paul.
>>>>
>
>
> Great! Now I've pissed of Peter and Austin. Did I mention I'm
> not having a great week :-) :-)
>
> Philip Freidin
> Crusader for understanding metastability and how to minimize it.
>
>
>
>
> ===================
> Philip Freidin
> philip.freidin@fpga-faq.org
> Host for WWW.FPGA-FAQ.ORG
Article: 90194Sylvain Munaut wrote: > I want to have a combinatorial block with 4 inputs : > - 2 vectors A and B > - 2 control signal 'passthru' & 'sel' > > that produces either A+B (if passthru=0), > A (if sel=0) or B (if sel=1). And all that in a > signle layer of logic. Jan Gray wrote about this a couple of times on www.fpgacpu.org. Apparently the mapper tries many (or even all) factorizations of your logic but it does not reorder the circuit. Therefore, if you have an adder followed by a mux you get two levels of logic. You need to write down a formulation were the adder follows the remining logic: result <= (A and (not sel or not passthrough)) + (B and (sel or not passtrough)); This is a function of four inputs plus carry-in that the mapping barely has a choice but to fit into one LUT plus carry logic. Acutally you are currently implementing three operations. You can squeeze in a fourth like subtraction or a bitwise logical operation. Kolja SulimmaArticle: 90195
OK, I see why you were confused now. I've had a quick look, and I actually have a copy of the app note which talks about mixed voltage I/O, but it doesn't really say much more than you already seem to know. Also after a quick check of the release notes for SP2, it seems this is where the problem is: Mixed mode I/O support has been removed from APA devices. As of SP2, use of any of these mixed mode I/Os is prohibited: OB25XX, IOB25XX, IOBL25XX, OTB25XX, OTBL25XX, or IB25XX. If any of these I/Os are detected in an existing ADB, an error message appears, and alternative non mixed-mode I/Os are suggested. So I guess the solution would be to uninstall SP2.Article: 90196
timotoole@gmail.com wrote: > Firstly thank you very much for your detailed answer. > >>>Is there ever scenario's where the area and switching overhead of a >>>systolic array would warrant a less bandwidth efficient, more serial >>>approach - or is that just plain ridulous to consider? >>In fact only the serial solution has an area and switching overhead for >>each computation. The systolic implementation only computes without >>doing anything else. See below. > > I'm not too sure what you mean by this? Surely there is an area > overhead for the systolic array versus a "serial"/single PE > implementation? That's not efficiency, that's cost. Cost increases. But for twice the area I get more than twice the speed for less than twice the power. So the computations per area and the computations per energy increase. That's what's called efficiency. This is the great thing about systolic algorithms. There are many parallel algorithms that are not systolic that get faster when adding more hardware but at diminishing efficieny. For some problems only logarithmic speedup is possible. > Using your example of an adder, I have a algorithm where it is possible > to avoid the addition completely if a certain condition occurs. With a > systolic array the addition has to be completed, Thus my question, of > whether a non- systolic implementation has major drawbacks. Do not forget the cost of checking the condition. Even in serial CPUs a branch is so expensive that doing a few extra operations can be more desirable testing whether thy can be skipped. [..] >>More complicated are problems were the systolic algorithm requires more >>operations than the serial algorithm. In that case you need to tradeoff >>the gains per computation of the systolic implementation vs. the >>improved number of computations of the serial algorithm. > > I think this is my situation, so I'm going to try model the problem > with C and evaluate the operations & cycles for both approaches. Also check what your performance requirement is. Expect the gain of an systolic algorithm compared to operating serially on externall memory to be huge. So if you waste 90% of the operations you are probably still faster. *Deliberatly oversimplifing here* But if a serial implementation meets your throughput target there is not much adding hardware for more speed and efficiency. You can try to run your C-model on a microblaze. This will be VERY inefficient, but maybe it is fast enough ;-) Kolja SulimmaArticle: 90197
Thank you for your reply. I do not find any .dcf file in my project directory. The .sdc constraint file seems empty. Could you tell me where I have to search? And when I will found this file which name should I change? Thank you very much, MarieArticle: 90198
Simon Heinzle wrote: > Hi everybody, > > With ASICs, there are standard cell libraries in .lib file format for the > target process -- is there a comparable .lib file for the Xilinx FPGAs? There are macro libraries but no standard cell libraries. Subject tree based mappers do not work well for FPGAs and the timing models used in ASIC flows don't either. Also, you do not need the geometrical information contained in the library because you do not move cells around or connect wires to them at specified locations. So there is no use for a standard cell library with FPGAs. FPGAs either use muxes as their basic elements (rare nowadays) in which case BDD-based synthesis is the natural approach. Or they use lookup tables that can implement any function with up to N inputs (predominant architecture). In that case listing all possible functions in a library isn't really helpful. Kolja SulimmaArticle: 90199
On Thu, 06 Oct 2005 08:05:57 -0700, Austin Lesea <austin@xilinx.com> wrote: >Phil, >I stand corrected, >Thanks. >It was late last night ... >Austin Well it turns out I needed to be corrected by Phil Hays. He is correct that if the shift register is mapped to an SRL16 then you can be in deep doo doo for constraints that expected FFs. While making corrections to late night typing, please note that in my posting, the following: >Both are correct. Paul's circuit is a shift register (2 bits) and >it is logically indistinguishable from a shift register. should be: "Both are correct. Paul's circuit is a shift register (2 bits) and it is logically indistinguishable from a two stage synchronizer." Since Phil Hays points out the mapping problem of a shift register being mapped to the "not as wonderful as real flip flops for building synchronizers" SRL16s, then the 2 stage synchronizer, which are indestinguishable from a 2 bit shift registers will also face this problem. In my code I avoid all this by directly instantiating the FFs, and then it is easy to attach placement constraints and timing constraints. In another posting by Phil Hays, he gives examples of such constraints >INST "ss_1" LOC = "CLB_R1C1.S0" ; >INST "ss_0" LOC = "CLB_R1C1.S0" ; > or >INST "ss_1" RLOC = "R0C0.S0" ; >INST "ss_0" RLOC = "R0C0.S0" ; > >INST "ss_1" TNM = "SYNC_FF"; >INST "ss_0" TNM = "SYNC_FF"; >TIMESPEC "TS_SYNCS" = FROM "SYNC_FF" TO "SYNC_FF" 2.5 ns; Depending on the synthesizer, these can fail if it renames the signals. Also these only work if they are at the top of the hierarchy. Finding their correct name when the FFs are inferred can be tricky, since changes elsewhere in your code can cause the names to change. I believe that instantiation is justified for the specific case of building synchronizers. Philip Freidin =================== Philip Freidin philip.freidin@fpga-faq.org Host for WWW.FPGA-FAQ.ORG
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z