Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search

Messages from 35300

Article: 35300
Subject: Re: sensitivity list
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Fri, 28 Sep 2001 13:43:31 +1000
Links: << >>  << T >>  << A >>
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
Subject: Re: Using EABs in Leonardo Spectrum with Flex10K
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Fri, 28 Sep 2001 13:51:52 +1000
Links: << >>  << T >>  << A >>
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
(removed)


Article: 35303
Subject: Meta-stability
From: Manjunathan <manjunathan_s1@yahoo.com>
Date: Thu, 27 Sep 2001 23:23:47 -0700
Links: << >>  << T >>  << A >>
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: 35304
Subject: Re: how to dublicate logic?
From: Jens-Christian Lache <lache@tu-harburg.de_removeTheUnderscore>
Date: Fri, 28 Sep 2001 09:29:07 +0200
Links: << >>  << T >>  << A >>
Andy 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
Subject: Global Clock to Pad constraint
From: "Noddy" <g9731642@campus.ru.ac.za>
Date: Fri, 28 Sep 2001 09:32:48 +0200
Links: << >>  << T >>  << A >>
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
adrian




Article: 35306
Subject: Re: Programming flash connected to CPLD via JTAG
From: Matthias Fuchs <matthias.fuchs@esd-electronics.com>
Date: Fri, 28 Sep 2001 09:55:19 +0200
Links: << >>  << T >>  << A >>
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 ?

Matthias

Article: 35307
Subject: Re: Programming flash connected to CPLD via JTAG
From: "Wolfgang Loewer" <wolfgang.loewer@elca.de>
Date: Fri, 28 Sep 2001 10:32:35 +0200
Links: << >>  << T >>  << A >>
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 ?
>
> Matthias



Article: 35308
Subject: Re: sensitivity list
From: Jonathan Bromley <Jonathan.Bromley@doulos.com>
Date: Fri, 28 Sep 2001 12:05:28 +0100
Links: << >>  << T >>  << A >>
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: 35309
Subject: Re: Meta-stability
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 28 Sep 2001 14:58:02 +0100
Links: << >>  << T >>  << A >>


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,
> 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
Subject: Re: Spartan-IIE?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Fri, 28 Sep 2001 08:01:44 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Meta-stability
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Fri, 28 Sep 2001 08:04:02 -0700
Links: << >>  << T >>  << A >>



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,
> Manjunathan




Article: 35312
Subject: Re: how to dublicate logic?
From: John_H <johnhandwork@mail.com>
Date: Fri, 28 Sep 2001 16:15:12 GMT
Links: << >>  << T >>  << A >>
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
Subject: Active-HDL back annotated simulation and PC memory usage
From: "Atkins, Kate" <Kate.Atkins@siraeo.co.uk>
Date: Fri, 28 Sep 2001 17:19:17 +0100
Links: << >>  << T >>  << A >>
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


Article: 35314
Subject: Re: how to dublicate logic?
From: Jens-Christian Lache <lache@tu-harburg.de_removeTheUnderscore>
Date: Fri, 28 Sep 2001 18:35:08 +0200
Links: << >>  << T >>  << A >>
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
Subject: Re: Meta-stability
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Fri, 28 Sep 2001 09:37:03 -0700
Links: << >>  << T >>  << A >>
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 Treseler

Article: 35316
Subject: Re: Spartan-IIE?
From: Philip Freidin <philip@fliptronics.com>
Date: Fri, 28 Sep 2001 17:03:59 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Using EABs in Leonardo Spectrum with Flex10K
From: "Aldo Romani" <romani@free.mail.it>
Date: Fri, 28 Sep 2001 19:21:26 +0200
Links: << >>  << T >>  << A >>
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
Subject: Re: how to dublicate logic?
From: Ray Andraka <ray@andraka.com>
Date: Fri, 28 Sep 2001 17:29:31 GMT
Links: << >>  << T >>  << A >>

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
Subject: Re: Meta-stability
From: Philip Freidin <philip@fliptronics.com>
Date: Fri, 28 Sep 2001 17:30:06 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Active-HDL back annotated simulation and PC memory usage
From: Ray Andraka <ray@andraka.com>
Date: Fri, 28 Sep 2001 17:33:34 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Meta-stability
From: Ray Andraka <ray@andraka.com>
Date: Fri, 28 Sep 2001 17:37:18 GMT
Links: << >>  << T >>  << A >>
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: 35322
Subject: Re: Spartan-IIE?
From: "Tim" <tim@rockylogic.com.nospam.com>
Date: Fri, 28 Sep 2001 19:15:07 +0100
Links: << >>  << T >>  << A >>
Any guidance on S2E packages?





Article: 35323
Subject: Re: Meta-stability
From: Brian Philofsky <brian.philofsky@xilinx.com>
Date: Fri, 28 Sep 2001 12:50:42 -0600
Links: << >>  << T >>  << A >>




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: 35324
Subject: Re: Meta-stability
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Fri, 28 Sep 2001 12:03:28 -0700
Links: << >>  << T >>  << A >>
Brian,

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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search