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
In simulation, B<=A, then Y<=old B, with a 'delta' delay. In real hardware, A is connected to B which is connected to Y with wires. Because B is altered within the process statement, it doesn't need to be included in the sensitivity list, to be acted upon. However, i could be wrong... yaohan wrote: > > hi, > I have a problem which I feel difficult to explain. > > library ieee; > use ieee.std_logic_1164.all; > > entity test is > port( > A: in integer range 0 to 127; > Y: out integer range 0 to 127 > ); > end test; > > architecture test_bev of test is > signal B: integer range 0 to 127; > begin > process (A) --process A > begin > B <= A; > Y <= B; > end if; > end process; > end test_bev; > > As for my understanding, the process A will only execute when change on > signal A. So Let say, I only change the value A for once, this value should > be assigned to B; Mean while Y is assigned with OLD B value. As long as no > change on signal A, this process will be suspended, i.e Y == value of OLD B. > > However, when I simulate using MAX+PLUS II, the results show that Y is > update to A input values after short delay. As if the sensitivity list does > not have any effect .. ( Or may be the compiler has included all the signal > into sensivity list ...).. -- ___ ___ / /\ / /\ / /__\ Russell Shaw, B.Eng, M.Eng(Research) / /\/\ /__/ / Victoria, Australia, Down-Under /__/\/\/ \ \ / http://home.iprimus.com.au/rjshaw \ \/\/ \__\/ \__\/Article: 35301
You should download version 'd' of leonardo. My designs crashed version 'a' due to compiler bugs. Aldo Romani wrote: > > Hello to the newsgroup, > maybe some of you may help me. > > I'm a newbie in FPGA programming, so I apologize from now if I am going to ask > silly questions. > > I have some VHDL code I have to synthesize on Altera Flex10K devices. I use > Leonardo Spectrum, version v20001a2.75. -- ___ ___ / /\ / /\ / /__\ Russell Shaw, B.Eng, M.Eng(Research) / /\/\ /__/ / Victoria, Australia, Down-Under /__/\/\/ \ \ / http://home.iprimus.com.au/rjshaw \ \/\/ \__\/ \__\/Article: 35302
Hello Everybody,
I have a doubt in transfering a signal from one clock(clka) to another(clkb).
Below I have explained in detail.
I have registered the signal three times, in clockB domain, after that i have used this signal.
since, there is a chance of meta stablility in the flipflop one, to avoid this i have registered again two times more.
But when i implemented this desgin, and simulated the deign with SDF in MODEL-TECH.
here the flip flop one, goes to meta stability, and this unknown value propagates
to second and the third one also,
my question is that does this design works in real time? even though it fails during simulation ?
can u give me a suggestion to avoid metastability?
how to prevent the propagation of the unknown?
my code is like this,
library IEEE;
use IEEE.std_logic_1164.all;
entity check_meta_stability is
port (
clk1: in STD_LOGIC;
clk2: in STD_LOGIC;
reset1: in STD_LOGIC;
reset2: in STD_LOGIC;
o: out STD_LOGIC
);
end check_meta_stability ;
architecture check_meta_stability_arch of check_meta_stability is
signal s1,s2,s3 : std_logic;
begin
process (clk1,reset1)
begin
if reset1='1' then
s1 <= '0' ;
elsif clk1='1' and clk1'event then
s1 <= not s1 ;
end if ;
end process ;
process (clk2,reset2)
begin
if reset2='1' then
s2 <= '0' ;
s3 <= '0' ;
o <= '0' ;
elsif clk2='1' and clk2'event then
s2 <= s1 ;
s3 <= s2 ;
o <= s3 ;
end if ;
end process ;
end check_meta_stability_arch;
Thanks in Advance,
Have a Great Day,
Regards,
Manjunathan
Article: 35304Andy Peters wrote: > Which synthesis tool? > > Synplify has no problem duplicating signals like you need, and the P+R > tools do not seem to merge them back... > > --a > > Jens-Christian Lache wrote: > > > > John_H wrote: > > > > > Please let us know > > > 1) synthesis tool, > > > 2) coding language > > > > > > Jens-Christian Lache wrote: > > > > > > > Hi! > > > > To reduce the fanout of a tristate signal leading to 64 iobs I > > > > tried dublicate this signal. How do I tell > > > > the synthesis tool now not to remove my dublicated logic? > > > > ( I tried to use a BUFG as well, but that didn't work at all) > > > > thanks for your help, > > > > -jc- > > > > Hi! > > 1) foundation 3.1i > > 2) vhdl > > > > In the "Libraries Guide 3.3.06i -- Online" under Design Elements, > > BUF is a comment about this problem: > > > > .. the buffer is preserved by attaching an X (explicit) attribute to > > both the input and output nets of the BUF." > > > > I tried it, but it didn't work. > > > > This is the code: > > http://d6.design.chalmers.se/jctmp/jctmp/specache.vhd > > > > I would like to tell the synthesis tool a max fanout for the > > > > readBuffer0Pipeline1: FDCE FF and to have > > it generate several nets with smaller fan out > > automatically. > > > > Thanks a lot!!!!!!!!!!!!! > > > > -jc- The synthesis tool is synopsys fpga express. I could now make it work with dublicating ff instead of inserting BUFs. But thats not really what I wanted. -jc-Article: 35305
Could someone please explain to me how the Clock to Pad constraint works. I thought I understood, as I have constraints on all my inputs and outputs, but I put a global clock to pad constraint on my clock signal, and now nothing makes sense to me. I have a clock signal period of 41.67 ns (24 MHz), with a Clock to Pad constraint of 11ns. Does this sound reasonable? thanks adrianArticle: 35306
Hi Mike, "Mike R." wrote: > The only big disadvantage of SRAM fpgas is: > there is no single chip solution.You always need a configuration memory on > startup. I know that ! > The ideal configuration memory is available from XILINX: > The XC18V00 series of jtag in system programmable fpga proms - see > http://www.xilinx.com/partinfo/ds026.pdf > They work well, but are difficult to get and expensive. I know. The price is why I want to use a flash/pld combination instead of a serial PROM. > > There is often a byte or word wide flash memory in the system which could be > used for the fpga configuration. > You can built your own cpld prom loader with a jtag interface, but you must > use a separate jtag chain for the cpld and the prom loader. This leads to my question: Why do I need separate jtag chains ? My idea is to use the PLDs JTAG interface to access the PLD pins. I think this is called boundary scan, isn't it ? Is this possible ? > The jtag interface is well documented and simple, but the spi interface > needs less logic to implement. You're right, but I only want a single interface. Any idea ? MatthiasArticle: 35307
Matthias, I know about a company who successfully used JAM/STAPL to do what you described. JAM/STAPL is an interpreted language with byte code or ASCII versions. If you use ASCII it's an easy to understand language that you can use to control your CPLD pins through the JTAG port. There's also a so called JAM/STAPL player available, compiled for various platforms together with drivers e.g. for Windows NT/2000 as well as C source code. The JAM/STAPL player reads in your JAM file and drives the JTAG port through your own interface or the Altera Byte- or Bitblaster. Go to http://www.jamisp.com/ for more information on JAM STAPL - Wolfgang http://www.elca.de "Matthias Fuchs" <matthias.fuchs@esd-electronics.com> schrieb im Newsbeitrag news:3BB2E378.38B42639@esd-electronics.com... > Hi, > > I am looking for an application note on how to program a flash that is > connected to the pins of a small PLD (XC9500). > Later the PLD/flash combination should boot an FPGA. But first I need a > way to programm the flash through the JTAG interface of the PLD. Is this > possible ? Is there some software available to do this ? I think it > should be somthing like a scriptable JTAG tool set.... > > Everything I found are app notes that describe the booting of the fpga > though the PLD/flash combination but noone cares about programming the > flash for the first time :-) > > Any ideas or experiences ? > > MatthiasArticle: 35308
In article <3BB38030.6F93CBCF@gmx.de>, Falk Brunner
<Falk.Brunner@gmx.de> writes
>Jonathan Bromley schrieb:
>> There are plenty
>> of situations in test benches where I really NEED to control what's
>> going on by means of a sensitivity list.
>
>Hmm. Can you explain this more detail or give a simple example? I dont
>get it at all.
Often, when pushing data around a big complicated testbench, it's
convenient to use a toggling "strobe" signal (typically a BIT or
BOOLEAN) to indicate that a new data value is available. If you
use just the rising edge of the strobe, you then must go through
a tedious four-phase handshake, just as you would do in hardware.
But in a testbench there's no need for that; you can simply toggle
the strobe and use either edge to indicate that some event has
happened. So, you end up writing code like this:
process (Toggling_Strobe)
begin
Some_Signal <= New_Value;
Delayed_Strobe <= Toggling_Strobe;
Toggling_Acknowledge <= NOT Toggling_Acknowledge;
end process;
Impossible to infer the right sensitivity list from the code!
Hint: What would happen if a tool automatically put
Toggling_Acknowledge into the sensitivity list? :-)
NB: In practice it's usually more convenient, in testbenches,
to use a process without a sensitivity list. Then, you are
permitted to put any sort of wait statements inside it. So
I would more likely write this:
process
begin
wait on Toggling_Strobe;
Some_Signal <= New_Value;
wait for Some_Delay;
Delayed_Strobe <= Toggling_Strobe;
Toggling_Acknowledge <= NOT Toggling_Acknowledge;
end process;
It's not the world's most brilliant example, but I hope it gives
a flavour of the kind of thing I mean.
>I dont have much expirience with VHDL testbenches
Go for it! It can revolutionise your life! Read Janick Bergeron's
fantastic book on verification techniques, "Writing Test Benches".
--
Jonathan Bromley
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223 Email: jonathan.bromley@doulos.com
Fax: +44 1425 471573 Web: http://www.doulos.com
**********************************
** Developing design know-how **
**********************************
This e-mail and any attachments are confidential and Doulos Ltd. reserves
all rights of privilege in respect thereof. It is intended for the use of
the addressee only. If you are not the intended recipient please delete it
from your system, any use, disclosure, or copying of this document is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 35309Manjunathan wrote: > Hello Everybody, > I have a doubt in transfering a signal from one clock(clka) to another(clkb). > Below I have explained in detail. > > I have registered the signal three times, in clockB domain, after that i have used this signal. > > since, there is a chance of meta stablility in the flipflop one, to avoid this i have registered again two times more. > > But when i implemented this desgin, and simulated the deign with SDF in MODEL-TECH. > > here the flip flop one, goes to meta stability, and this unknown value propagates > to second and the third one also, > > my question is that does this design works in real time? even though it fails during simulation ? > > can u give me a suggestion to avoid metastability? > > how to prevent the propagation of the unknown? > > my code is like this, > > library IEEE; > use IEEE.std_logic_1164.all; > > entity check_meta_stability is > port ( > clk1: in STD_LOGIC; > clk2: in STD_LOGIC; > reset1: in STD_LOGIC; > reset2: in STD_LOGIC; > o: out STD_LOGIC > ); > end check_meta_stability ; > > architecture check_meta_stability_arch of check_meta_stability is > > signal s1,s2,s3 : std_logic; > begin > > process (clk1,reset1) > > begin > > if reset1='1' then > s1 <= '0' ; > elsif clk1='1' and clk1'event then > s1 <= not s1 ; > > end if ; > > end process ; > > > process (clk2,reset2) > > begin > > if reset2='1' then > s2 <= '0' ; > s3 <= '0' ; > o <= '0' ; > elsif clk2='1' and clk2'event then > > s2 <= s1 ; > s3 <= s2 ; > o <= s3 ; > > end if ; > > end process ; > end check_meta_stability_arch; > > > > Thanks in Advance, > > Have a Great Day, > > Regards, > Manjunathan This is a classic question that comes up on this NG periodically. Search the archives at http://www.fpga-faq.com Giving due thanks to Phillip Friedin for hosting it.Article: 35310
Eric, I know. I just couldn't resist. We are (mostly) engineers on this newsgroup, and it must be like fingernails on a chalk board to anyone in marketing or sales that reads this stuff. Since I am an engineer who occasionally has to visit the "dark side" (marketing) I am perhaps a little more sensitive to their feelings. Austin Eric Smith wrote: > I wrote about Spartan II-E: > > Is it just a cheaper Virtex-E > > Austin Lesea <austin.lesea@xilinx.com> writes: > > Less expensive, or cost reduced, or low cost specific application > > targeted, or ASIC/ASSP replacement device I believe are the politically > > correct descriptors. > > Sorry, I should have been more precise and said "less expensive". I > was only using "cheap" in the sense of inexpensive, without any intended > negative connotation.Article: 35311
There is no way to avoid metastability, (when dealing with synchronous events) There are only ways to deal with its effects. Maybe I could sell a bumper sticker: "Metastability Happens!" Austin Manjunathan wrote: > Hello Everybody, > I have a doubt in transfering a signal from one clock(clka) to another(clkb). > Below I have explained in detail. > > I have registered the signal three times, in clockB domain, after that i have used this signal. > > since, there is a chance of meta stablility in the flipflop one, to avoid this i have registered again two times more. > > But when i implemented this desgin, and simulated the deign with SDF in MODEL-TECH. > > here the flip flop one, goes to meta stability, and this unknown value propagates > to second and the third one also, > > my question is that does this design works in real time? even though it fails during simulation ? > > can u give me a suggestion to avoid metastability? > > how to prevent the propagation of the unknown? > > my code is like this, > > library IEEE; > use IEEE.std_logic_1164.all; > > entity check_meta_stability is > port ( > clk1: in STD_LOGIC; > clk2: in STD_LOGIC; > reset1: in STD_LOGIC; > reset2: in STD_LOGIC; > o: out STD_LOGIC > ); > end check_meta_stability ; > > architecture check_meta_stability_arch of check_meta_stability is > > signal s1,s2,s3 : std_logic; > begin > > process (clk1,reset1) > > begin > > if reset1='1' then > s1 <= '0' ; > elsif clk1='1' and clk1'event then > s1 <= not s1 ; > > end if ; > > end process ; > > > process (clk2,reset2) > > begin > > if reset2='1' then > s2 <= '0' ; > s3 <= '0' ; > o <= '0' ; > elsif clk2='1' and clk2'event then > > s2 <= s1 ; > s3 <= s2 ; > o <= s3 ; > > end if ; > > end process ; > end check_meta_stability_arch; > > > > Thanks in Advance, > > Have a Great Day, > > Regards, > ManjunathanArticle: 35312
Using Foundation, you're targeting Xilinx. In the Virtex style devices (I'm not familiar enough with the 4k series), replicating ffs is what you *want* to do as long as your IOB configuration isn't too strange. I can't pack a latch and a register together in the same IOB, but I can get registers with different clock enables (same clock) and resets to pack in the same IOB easily. If you have a tristate register controlling a large number of IOBs, it's often easy to meet timing by feeding the tristate register's LUT output to a tristate register in *every* IOB cell; that's where the replication really helps out. Adding BUFs may help to distribute signals nicely in ASICs but the applicability to FPGAs is really limited. Xilinx did a good job, in my opinion, getting all the registers packed in the IOB. I'm hoping my next Altera design will see tristate registers at the pad as well :-) Jens-Christian Lache wrote: > I could now make it work with dublicating ff instead of > inserting BUFs. But thats not really what I wanted.Article: 35313
Hi Has anybody else noted Active-HDL (VHDL) using huge amounts of memory when doing post place and route simulation with timing info (SDF)? Specifically it is an Actel RT14100, clocked at <4MHz. When simulation time gets to 600ms memory usage is about 600MByte and as this is into virtual memory for my machine simulation slows to less than snails pace. Static timing analysis says "no worries" but project manager wants more proof :-( Any useful advice appreciated. Thanks in advance KateArticle: 35314
John_H wrote: > Using Foundation, you're targeting Xilinx. In the Virtex style devices (I'm > not familiar enough with the 4k series), replicating ffs is what you *want* > to do as long as your IOB configuration isn't too strange. I can't pack a > latch and a register together in the same IOB, but I can get registers with > different clock enables (same clock) and resets to pack in the same IOB > easily. > > If you have a tristate register controlling a large number of IOBs, it's > often easy to meet timing by feeding the tristate register's LUT output to a > tristate register in *every* IOB cell; that's where the replication really > helps out. > > Adding BUFs may help to distribute signals nicely in ASICs but the > applicability to FPGAs is really limited. Xilinx did a good job, in my > opinion, getting all the registers packed in the IOB. I'm hoping my next > Altera design will see tristate registers at the pad as well :-) > > Jens-Christian Lache wrote: > > > I could now make it work with dublicating ff instead of > > inserting BUFs. But thats not really what I wanted. Thanks a lot for your answer. I will think about it. The "Library guide" from Xilinx says that the BUFs are no good for s.th. else than exactly this purpose of decreasing the fanout of a device. So it should be possible somehow. (Sorry that I'am so persistant, I have a new problem where my signal doesn't come from a FF but a LUT.) I was looking for something like a shell variable MAXFANOUT=20 or a switch for the synthesis tool or a global attribute that dublicates my logic on it own using BUFs. I now that synplify does this job. Or I want to attach an attribute to a signal to have it preserved. Anyway, I could finally break through the 100MHz boarder of my SDRAM design. I have a CAS latency of 3 and then every 10ns a 64bit word from the BlockRAM. Since I am using two internal banks of each 4 BlockRAMS, I have to multiplex between them. This leads to the high fanout signal. I actually wrote to the support line of xilinx in europe, but they didn't answer yet. Thank you a lot for your help, John, you answered a question of mine the other day as well. Thats kind! Nice WE, -jc-Article: 35315
Manjunathan wrote: > I have a doubt in transfering a signal > from one clock(clka) to another(clkb). > Below I have explained in detail. > > I have registered the signal three times, > in clockB domain, after that i have used this signal. ... > here the flip flop one, goes to meta stability, > and this unknown value propagates > to second and the third one also, > > my question is that does this design works in real time? > even though it fails during simulation ? Yes. Because a synchronizer processes signals that do not meet setup/hold requirements 'U' outputs can result and propagate in simulation. > can u give me a suggestion to avoid metastability? I think you are on the right path. Two or more flops per synchronizer is standard practice. > how to prevent the propagation of the unknown? My tack is to just trust the synchronizer and phase the testbench clocks or data to allow a functional simulation of everything else to run without 'U's. --Mike TreselerArticle: 35316
On Fri, 28 Sep 2001 08:01:44 -0700, Austin Lesea <austin.lesea@xilinx.com> wrote: >Eric, > >I know. I just couldn't resist. We are (mostly) engineers on this >newsgroup, and it must be like fingernails on a chalk board to anyone in >marketing or sales that reads this stuff. > >Since I am an engineer who occasionally has to visit the "dark side" >(marketing) I am perhaps a little more sensitive to their feelings. > >Austin Resist Austin, Resist ... Let the Force guide you.Article: 35317
May this affect the missing synthesis into EAB? Leonardo Spectrum calls them 'Memory Bits', and I can't get to use them at all. Any design, including memories, uses them at 0%. Anybody has any suggestion? I'm quite desperate... Thanks for your answer, Aldo "Russell Shaw" <rjshaw@iprimus.com.au> ha scritto nel messaggio news:3BB3F3D8.F67A166E@iprimus.com.au... > You should download version 'd' of leonardo. My designs crashed version > 'a' due to compiler bugs. > > Aldo Romani wrote: > > > > Hello to the newsgroup, > > maybe some of you may help me. > > > > I'm a newbie in FPGA programming, so I apologize from now if I am going to ask > > silly questions. > > > > I have some VHDL code I have to synthesize on Altera Flex10K devices. I use > > Leonardo Spectrum, version v20001a2.75. > > > -- > ___ ___ > / /\ / /\ > / /__\ Russell Shaw, B.Eng, M.Eng(Research) / /\/\ > /__/ / Victoria, Australia, Down-Under /__/\/\/ > \ \ / http://home.iprimus.com.au/rjshaw \ \/\/ > \__\/ \__\/ > >Article: 35318
Rather than multiplexing between block RAMs arrange them in bit slice fashion. I
am guessing since you have 64 bit words and say you are using 4 BRAMs per bank,
that each bank is 256x64. If you arrange both banks to share the same BRAM, so
that you have 8 512x8 dual port BRAMs, then you eliminate all muxing (8 bits of
both banks per BRAM), replacing it with address instead. The only thing that gets
more difficult in this case is putting in initial values.
Jens-Christian Lache wrote:
>
> Since I am using two internal banks of each 4 BlockRAMS,
> I have to multiplex between them. This leads to the high
> fanout signal.
>
>
> I actually wrote to the support line of xilinx in europe,
> but they didn't answer yet. Thank you a lot for your help,
> John, you answered a question of mine the other day as well.
> Thats kind!
>
> Nice WE,
> -jc-
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 35319
Hi Manjunathan,
Your approach to minimizing the probability of metastability in your
system is the correct approach, and a 3 stage synchronizer is about
as much as anyone is likely to use. There are several articles that
Xilinx has published in their data books and XCELL magazine that
give details of the probability calculations, and the raw data for the
components that is needed to do the calculations. Unfortunately,
the data for components only covers older technology. On the
bright side, all the current components are almost certainly better
in terms of probability of going metastable, and probable duration
to resolution.
There is also a FAQ that covers this at:
http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm
which may give more insight. It was written by an engineer that has
been teaching about this stuff for over 20 years, and he seems to
understand the topic. (Thanks Rick for the pointer, and Austin for
pointing out that you can't eliminate the problem, but you can make
it very rare.)
But now, on to your question.
As it turns out, you are not simulating metastability. I know of no
digital simulator that can simulate metastability. What you are simulating
is a setup/hold violation. Your flip-flop model is taking the violation,
and setting the Q output to X. This then propagates through your simulation,
which is what you are seeing. There is no probability calculation going on,
which is why your simulation is probably showing the problem propagating
through the 3rd flip-flop all the time. Depending on your clock rate, etc,
the reality is it might propagate once in every 10^-20 times or maybe 10^-50
it depends on many things, but is far more rare than your simulation is
showing. You can't fix your simulation to show the correct rate, because it
is so rare, you would be simulating for ever before you saw a metastability.
The correct analysis is to do the calculations.
As for your simulation, once you have done your calculations, and confirmed
that the 3 stage synchronizer reduces the probability of metastability
sufficently, you should proceed with simulation, as if the metastabilities do
not come out of the third flip flop. You can then check the rest of your design.
So in answer to your question:
"my question is that does this design works in real time? even though
it fails during simulation ?"
is "yes", provided you don't have other logic errors.
You also asked "how to prevent the propagation of the unknown?"
As for making the simulation make more sense, what you need to do
is any of
a) adjust clkA so that in simulation you dont get the setup/hold violations
or
b) Figure out how to disable setup/hold checks for just the first FF of your
synchronizer
or
c) edit the SDF for just the first FF, and set the setup and hold times to
really small values, like 1 pS
or
d) Add an AND gate after the first FF (only in the simulation version of the
design) and drive the other input of the AND gate directly from the test
bench. Run your simulation, see when the setup/hold violation occur,
and adjust the test bench to mask these by blocking them at the AND
gate.
I think I will add the above to the FAQ.
Philip Freidin
On Thu, 27 Sep 2001 23:23:47 -0700, Manjunathan <manjunathan_s1@yahoo.com>
wrote:
>Hello Everybody,
> I have a doubt in transfering a signal from one clock(clka) to another(clkb).
> Below I have explained in detail.
>
>I have registered the signal three times, in clockB domain, after that i have used this signal.
>
>since, there is a chance of meta stablility in the flipflop one, to avoid this i have registered again two times more.
>
>But when i implemented this desgin, and simulated the deign with SDF in MODEL-TECH.
>
>here the flip flop one, goes to meta stability, and this unknown value propagates
>to second and the third one also,
>
>my question is that does this design works in real time? even though it fails during simulation ?
>
>can u give me a suggestion to avoid metastability?
>
>how to prevent the propagation of the unknown?
>
>my code is like this,
>
>library IEEE;
>use IEEE.std_logic_1164.all;
>
>entity check_meta_stability is
> port (
> clk1: in STD_LOGIC;
> clk2: in STD_LOGIC;
> reset1: in STD_LOGIC;
> reset2: in STD_LOGIC;
> o: out STD_LOGIC
> );
>end check_meta_stability ;
>
>architecture check_meta_stability_arch of check_meta_stability is
>
>signal s1,s2,s3 : std_logic;
>begin
>
> process (clk1,reset1)
>
> begin
>
> if reset1='1' then
> s1 <= '0' ;
> elsif clk1='1' and clk1'event then
> s1 <= not s1 ;
>
> end if ;
>
> end process ;
>
>
> process (clk2,reset2)
>
> begin
>
> if reset2='1' then
> s2 <= '0' ;
> s3 <= '0' ;
> o <= '0' ;
> elsif clk2='1' and clk2'event then
>
> s2 <= s1 ;
> s3 <= s2 ;
> o <= s3 ;
>
> end if ;
>
> end process ;
>end check_meta_stability_arch;
>
>
>
>Thanks in Advance,
>
>Have a Great Day,
>
>Regards,
>Manjunathan
Philip Freidin
Fliptronics
Article: 35320
A thorough static timing analysis is much more proof than a timing
simulation. Timing simulation only covers one timing case, typically
everything at worst case (slowest) delay. It is extroardinarily easy to put
in a set of test vectors that won't trip up a timing simulation on a design
that is not meeting timing. If you have just one clock, the static timing
is pretty much a no-brainer. More than one clock, then you have to be
careful about your constraints to make sure the right constraints apply to
the right signals. As a first cut, set all your clocks to a period
constraint set at your fastest clock. If that meets timing you are done.
"Atkins, Kate" wrote:
> Hi
>
> Has anybody else noted Active-HDL (VHDL) using huge amounts of memory
> when doing post place and route simulation with timing info (SDF)?
>
> Specifically it is an Actel RT14100, clocked at <4MHz. When simulation
> time gets to 600ms memory usage is about 600MByte and as this is into
> virtual memory for my machine simulation slows to less than snails pace.
>
> Static timing analysis says "no worries" but project manager wants more
> proof :-(
>
> Any useful advice appreciated.
>
> Thanks in advance
>
> Kate
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 35321
Yep, your tact is pretty much the only way to simulate it. Set up the
inputs to make sure they don't violate setup-hold, then trust that the
FF's will settle out metastability in the real system. simulators
simulate metastability with a 'X', even though in real circuits that 'X'
is resolved downstream as either a '1' or a '0'. The simulator won't
resolve the 'X'.
Mike Treseler wrote:
>
> I think you are on the right path.
> Two or more flops per synchronizer is
> standard practice.
>
> > how to prevent the propagation of the unknown?
>
> My tack is to just trust the synchronizer
> and phase the testbench clocks or data
> to allow a functional simulation of
> everything else to run without 'U's.
>
> --Mike Treseler
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 35322Any guidance on S2E packages?Article: 35323
Hello Manjunathan,
I first want to say that Philip and Ray have provided great information on metastability and thank them for that. This
does seem to be a reoccurring topic on this newsgroup and a source of confusion for many. I will try to add to what they
have said to see if I can add some further clarification and suggestions to this subject.
First off in the physical realm, for most practical purposes, a two stage synchronizer would suffice for most as the
chances of one register having a metastable resolution time the exact amount of time that it would take for the next
register to have another metastable event occur is pretty slim. However since registers are pretty much for free in most
FPGA architectures and if the added latency is not an issue, the third stage will push you closer to the impossibility of
metastability ever effecting your circuit however that possibility will always exist. One thing I can suggest is to put a
tighter timing constraint on the second and third stages of your synchronizing registers. By reducing the traveling time
for signals in between the registers, you increase the settling time for the registers and since most metastable events
settle fairly quickly, you further reduce the chance of having metastability on the second or third register stage in your
synchronizer.
Now on the simulation side of things, as mentioned there are no simulation models from any vendor (that I am aware of) that
can accurately simulate metastability. To build such a model that will accurately predict the settling times for registers
will to say the least be extremely difficult. So most vendors take the easy way out and output an 'X' symbolizing "we do
not know what the output will be (1, 0 or something in between) for now but will resolve on the next clock cycle if another
violation does not occur." As you could see, this can halt most simulations at that point and make functional verification
of the design with timing not work. If your intent is to see exactly what your circuit will do if a metastable event
occurs in the simulator, that currently is not possible. If however you want to verify the functionality of your circuit
and do not want a setup/hold violation to halt your simulation, there are way to do this other than what has already been
mentioned. In other words, you do not have to modify your stimulus or design to avoid setup violations in order to
simulate as this does not always make sense (perhaps you are crossing clock domains where the clocking frequencies do not
allow this for example). If you are targeting the Xilinx architectures, there is a switch in the VHDL netlister, ngd2vhdl,
called -xon. If you specify the -xon switch to the false, then the simulation model produced will not go to 'X' when a
setup or hold violation occurs and instead will keep its previous value. Now the thing to realize here is that the value
may have very well changed in real silicon depending on when in the setup/hold window the violation occurred so this result
has to be analyzed with caution however it does allow the simulation to continue without requiring you to modify your
stimulus or design. For you Verilog people out there, the equivalent to this is to run the simulation with the
"+no_notifier " option when invoking the simulation. Now I do not suggest to use these switches to get around timing
violations from synchronous elements as it is far better to fix the timing problems than ignore them however in situations
where you know you have an asynchronous path, still wish to simulate the design without setup violations stopping you and
you realize that the output form the violated register may not be entirely accurate in that situation, then this is a
useful to know.
Hopefully this information will add further clarification,
-- Brian
Philip Freidin wrote:
> Hi Manjunathan,
>
> Your approach to minimizing the probability of metastability in your
> system is the correct approach, and a 3 stage synchronizer is about
> as much as anyone is likely to use. There are several articles that
> Xilinx has published in their data books and XCELL magazine that
> give details of the probability calculations, and the raw data for the
> components that is needed to do the calculations. Unfortunately,
> the data for components only covers older technology. On the
> bright side, all the current components are almost certainly better
> in terms of probability of going metastable, and probable duration
> to resolution.
>
> There is also a FAQ that covers this at:
>
> http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm
>
> which may give more insight. It was written by an engineer that has
> been teaching about this stuff for over 20 years, and he seems to
> understand the topic. (Thanks Rick for the pointer, and Austin for
> pointing out that you can't eliminate the problem, but you can make
> it very rare.)
>
> But now, on to your question.
>
> As it turns out, you are not simulating metastability. I know of no
> digital simulator that can simulate metastability. What you are simulating
> is a setup/hold violation. Your flip-flop model is taking the violation,
> and setting the Q output to X. This then propagates through your simulation,
> which is what you are seeing. There is no probability calculation going on,
> which is why your simulation is probably showing the problem propagating
> through the 3rd flip-flop all the time. Depending on your clock rate, etc,
> the reality is it might propagate once in every 10^-20 times or maybe 10^-50
> it depends on many things, but is far more rare than your simulation is
> showing. You can't fix your simulation to show the correct rate, because it
> is so rare, you would be simulating for ever before you saw a metastability.
>
> The correct analysis is to do the calculations.
>
> As for your simulation, once you have done your calculations, and confirmed
> that the 3 stage synchronizer reduces the probability of metastability
> sufficently, you should proceed with simulation, as if the metastabilities do
> not come out of the third flip flop. You can then check the rest of your design.
>
> So in answer to your question:
>
> "my question is that does this design works in real time? even though
> it fails during simulation ?"
>
> is "yes", provided you don't have other logic errors.
>
> You also asked "how to prevent the propagation of the unknown?"
>
> As for making the simulation make more sense, what you need to do
> is any of
>
> a) adjust clkA so that in simulation you dont get the setup/hold violations
>
> or
>
> b) Figure out how to disable setup/hold checks for just the first FF of your
> synchronizer
>
> or
>
> c) edit the SDF for just the first FF, and set the setup and hold times to
> really small values, like 1 pS
>
> or
>
> d) Add an AND gate after the first FF (only in the simulation version of the
> design) and drive the other input of the AND gate directly from the test
> bench. Run your simulation, see when the setup/hold violation occur,
> and adjust the test bench to mask these by blocking them at the AND
> gate.
>
> I think I will add the above to the FAQ.
>
> Philip Freidin
>
> On Thu, 27 Sep 2001 23:23:47 -0700, Manjunathan <manjunathan_s1@yahoo.com>
> wrote:
> >Hello Everybody,
> > I have a doubt in transfering a signal from one clock(clka) to another(clkb).
> > Below I have explained in detail.
> >
> >I have registered the signal three times, in clockB domain, after that i have used this signal.
> >
> >since, there is a chance of meta stablility in the flipflop one, to avoid this i have registered again two times more.
> >
> >But when i implemented this desgin, and simulated the deign with SDF in MODEL-TECH.
> >
> >here the flip flop one, goes to meta stability, and this unknown value propagates
> >to second and the third one also,
> >
> >my question is that does this design works in real time? even though it fails during simulation ?
> >
> >can u give me a suggestion to avoid metastability?
> >
> >how to prevent the propagation of the unknown?
> >
> >my code is like this,
> >
> >library IEEE;
> >use IEEE.std_logic_1164.all;
> >
> >entity check_meta_stability is
> > port (
> > clk1: in STD_LOGIC;
> > clk2: in STD_LOGIC;
> > reset1: in STD_LOGIC;
> > reset2: in STD_LOGIC;
> > o: out STD_LOGIC
> > );
> >end check_meta_stability ;
> >
> >architecture check_meta_stability_arch of check_meta_stability is
> >
> >signal s1,s2,s3 : std_logic;
> >begin
> >
> > process (clk1,reset1)
> >
> > begin
> >
> > if reset1='1' then
> > s1 <= '0' ;
> > elsif clk1='1' and clk1'event then
> > s1 <= not s1 ;
> >
> > end if ;
> >
> > end process ;
> >
> >
> > process (clk2,reset2)
> >
> > begin
> >
> > if reset2='1' then
> > s2 <= '0' ;
> > s3 <= '0' ;
> > o <= '0' ;
> > elsif clk2='1' and clk2'event then
> >
> > s2 <= s1 ;
> > s3 <= s2 ;
> > o <= s3 ;
> >
> > end if ;
> >
> > end process ;
> >end check_meta_stability_arch;
> >
> >
> >
> >Thanks in Advance,
> >
> >Have a Great Day,
> >
> >Regards,
> >Manjunathan
>
> Philip Freidin
> Fliptronics
Article: 35324Brian, You correctly point out that it will still occur. A system I worked on would once every three months, jump 1 microsecond in phase. Now this was a synchronization system, and it was traced to a metastability problem with a three register synchronizer. We could reduce the probability of occurrence, but we could never eliminate it. Rather than solve it in hardware (impossible), we decided to implement a Kalman filter algorithm in software. If the incoming data indicated a change larger than expected, we threw the data away, rather than act on it. This took the system performance to the level desired, and no further problems were ever reported. Sometimes it is far simpler to fix the problem further down the line, where it can be fixed. To use an example from Peter Alfke, the keyboard we type on is a perfect example of metastability. Sometimes, the key is registered incorrectly, or not at all. As long as it appears to be no worse than your normal spelling, or missed key, you never notice or care. There is no need to make the perfect metastability free keyboard. Austin Brian Philofsky wrote: > Hello Manjunathan, > > I first want to say that Philip and Ray have provided great information on metastability and thank them for that. This > does seem to be a reoccurring topic on this newsgroup and a source of confusion for many. I will try to add to what they > have said to see if I can add some further clarification and suggestions to this subject. > > First off in the physical realm, for most practical purposes, a two stage synchronizer would suffice for most as the > chances of one register having a metastable resolution time the exact amount of time that it would take for the next > register to have another metastable event occur is pretty slim. However since registers are pretty much for free in most > FPGA architectures and if the added latency is not an issue, the third stage will push you closer to the impossibility of > metastability ever effecting your circuit however that possibility will always exist. One thing I can suggest is to put a > tighter timing constraint on the second and third stages of your synchronizing registers. By reducing the traveling time > for signals in between the registers, you increase the settling time for the registers and since most metastable events > settle fairly quickly, you further reduce the chance of having metastability on the second or third register stage in your > synchronizer. > > Now on the simulation side of things, as mentioned there are no simulation models from any vendor (that I am aware of) that > can accurately simulate metastability. To build such a model that will accurately predict the settling times for registers > will to say the least be extremely difficult. So most vendors take the easy way out and output an 'X' symbolizing "we do > not know what the output will be (1, 0 or something in between) for now but will resolve on the next clock cycle if another > violation does not occur." As you could see, this can halt most simulations at that point and make functional verification > of the design with timing not work. If your intent is to see exactly what your circuit will do if a metastable event > occurs in the simulator, that currently is not possible. If however you want to verify the functionality of your circuit > and do not want a setup/hold violation to halt your simulation, there are way to do this other than what has already been > mentioned. In other words, you do not have to modify your stimulus or design to avoid setup violations in order to > simulate as this does not always make sense (perhaps you are crossing clock domains where the clocking frequencies do not > allow this for example). If you are targeting the Xilinx architectures, there is a switch in the VHDL netlister, ngd2vhdl, > called -xon. If you specify the -xon switch to the false, then the simulation model produced will not go to 'X' when a > setup or hold violation occurs and instead will keep its previous value. Now the thing to realize here is that the value > may have very well changed in real silicon depending on when in the setup/hold window the violation occurred so this result > has to be analyzed with caution however it does allow the simulation to continue without requiring you to modify your > stimulus or design. For you Verilog people out there, the equivalent to this is to run the simulation with the > "+no_notifier " option when invoking the simulation. Now I do not suggest to use these switches to get around timing > violations from synchronous elements as it is far better to fix the timing problems than ignore them however in situations > where you know you have an asynchronous path, still wish to simulate the design without setup violations stopping you and > you realize that the output form the violated register may not be entirely accurate in that situation, then this is a > useful to know. > > Hopefully this information will add further clarification, > > -- Brian > > Philip Freidin wrote: > > > Hi Manjunathan, > > > > Your approach to minimizing the probability of metastability in your > > system is the correct approach, and a 3 stage synchronizer is about > > as much as anyone is likely to use. There are several articles that > > Xilinx has published in their data books and XCELL magazine that > > give details of the probability calculations, and the raw data for the > > components that is needed to do the calculations. Unfortunately, > > the data for components only covers older technology. On the > > bright side, all the current components are almost certainly better > > in terms of probability of going metastable, and probable duration > > to resolution. > > > > There is also a FAQ that covers this at: > > > > http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm > > > > which may give more insight. It was written by an engineer that has > > been teaching about this stuff for over 20 years, and he seems to > > understand the topic. (Thanks Rick for the pointer, and Austin for > > pointing out that you can't eliminate the problem, but you can make > > it very rare.) > > > > But now, on to your question. > > > > As it turns out, you are not simulating metastability. I know of no > > digital simulator that can simulate metastability. What you are simulating > > is a setup/hold violation. Your flip-flop model is taking the violation, > > and setting the Q output to X. This then propagates through your simulation, > > which is what you are seeing. There is no probability calculation going on, > > which is why your simulation is probably showing the problem propagating > > through the 3rd flip-flop all the time. Depending on your clock rate, etc, > > the reality is it might propagate once in every 10^-20 times or maybe 10^-50 > > it depends on many things, but is far more rare than your simulation is > > showing. You can't fix your simulation to show the correct rate, because it > > is so rare, you would be simulating for ever before you saw a metastability. > > > > The correct analysis is to do the calculations. > > > > As for your simulation, once you have done your calculations, and confirmed > > that the 3 stage synchronizer reduces the probability of metastability > > sufficently, you should proceed with simulation, as if the metastabilities do > > not come out of the third flip flop. You can then check the rest of your design. > > > > So in answer to your question: > > > > "my question is that does this design works in real time? even though > > it fails during simulation ?" > > > > is "yes", provided you don't have other logic errors. > > > > You also asked "how to prevent the propagation of the unknown?" > > > > As for making the simulation make more sense, what you need to do > > is any of > > > > a) adjust clkA so that in simulation you dont get the setup/hold violations > > > > or > > > > b) Figure out how to disable setup/hold checks for just the first FF of your > > synchronizer > > > > or > > > > c) edit the SDF for just the first FF, and set the setup and hold times to > > really small values, like 1 pS > > > > or > > > > d) Add an AND gate after the first FF (only in the simulation version of the > > design) and drive the other input of the AND gate directly from the test > > bench. Run your simulation, see when the setup/hold violation occur, > > and adjust the test bench to mask these by blocking them at the AND > > gate. > > > > I think I will add the above to the FAQ. > > > > Philip Freidin > > > > On Thu, 27 Sep 2001 23:23:47 -0700, Manjunathan <manjunathan_s1@yahoo.com> > > wrote: > > >Hello Everybody, > > > I have a doubt in transfering a signal from one clock(clka) to another(clkb). > > > Below I have explained in detail. > > > > > >I have registered the signal three times, in clockB domain, after that i have used this signal. > > > > > >since, there is a chance of meta stablility in the flipflop one, to avoid this i have registered again two times more. > > > > > >But when i implemented this desgin, and simulated the deign with SDF in MODEL-TECH. > > > > > >here the flip flop one, goes to meta stability, and this unknown value propagates > > >to second and the third one also, > > > > > >my question is that does this design works in real time? even though it fails during simulation ? > > > > > >can u give me a suggestion to avoid metastability? > > > > > >how to prevent the propagation of the unknown? > > > > > >my code is like this, > > > > > >library IEEE; > > >use IEEE.std_logic_1164.all; > > > > > >entity check_meta_stability is > > > port ( > > > clk1: in STD_LOGIC; > > > clk2: in STD_LOGIC; > > > reset1: in STD_LOGIC; > > > reset2: in STD_LOGIC; > > > o: out STD_LOGIC > > > ); > > >end check_meta_stability ; > > > > > >architecture check_meta_stability_arch of check_meta_stability is > > > > > >signal s1,s2,s3 : std_logic; > > >begin > > > > > > process (clk1,reset1) > > > > > > begin > > > > > > if reset1='1' then > > > s1 <= '0' ; > > > elsif clk1='1' and clk1'event then > > > s1 <= not s1 ; > > > > > > end if ; > > > > > > end process ; > > > > > > > > > process (clk2,reset2) > > > > > > begin > > > > > > if reset2='1' then > > > s2 <= '0' ; > > > s3 <= '0' ; > > > o <= '0' ; > > > elsif clk2='1' and clk2'event then > > > > > > s2 <= s1 ; > > > s3 <= s2 ; > > > o <= s3 ; > > > > > > end if ; > > > > > > end process ; > > >end check_meta_stability_arch; > > > > > > > > > > > >Thanks in Advance, > > > > > >Have a Great Day, > > > > > >Regards, > > >Manjunathan > > > > Philip Freidin > > Fliptronics
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