FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 04-02-2004, 09:30 PM
Brian Philofsky
Guest
 
Posts: n/a
Default Re: Metastablility



I felt I should chime into this thread as I am responsible for the
Xilinx simulation models and at the same time I have a history of
metastability testing with Peter (the expert in metastability) to draw
from. I have put some thought into the very subject of being able to
simulate metastability in a timing simulation and there are a few issues
that are not very easy to overcome that needs to be addressed to ever
make this a reality. First off, as Peter mentioned, the actual time
that any measurable metastable event would happen is a tiny time slice
out of the setup/hold window. The modeled setup and hold window for
timing analysis is artificially much bigger than what is really seen in
the silicon due to uncertainties not only in the actual size of the
window but also in the routing delays for the data and clock paths to
the FF. To model metastability delays anywhere in the setup/hold window
would be a very pessimistic way to look at the problem and you can not
guess where in the window it could really happen, in the beginning,
middle or end of the window. The second issue is how to determine how
long the FF goes metastable. We could use the statistical probabilities
and random numbers to calculate resolution times but it would not
necessarily show reality (it shows probability) which would be the goal
of doing this and at the same time it would significantly slow down an
already slow timing simulation since random numbers will need to be
generated and applied to a probability equation at every FF to make this
happen. This would make the FF elements more complicated and most
likely add confusion to the interpreting the model (why does it go X for
2 ns this time but 200 ps the next run?). Finally, when a setup/hold
violation happens, the simulation value goes to X to indicate it does
not know the end value. This is partially due to metastability but more
due to the fact that during the violation, the value may have changed or
not and that is not known. Producing X's in the model is the only way
for the simulator to tell you that it am driving a value but it does not
know what it is and because of this, there is no easy way to distinguish
between being in a metastable state and simply not knowing the FF
toggled or not. Without being able to represent this, there is no easy
way to model that the FF is in a metastable state for some time after
the violation and then goes to a "good value" later but we are not sure
which value it is.

So does this mean that all circuits that have asynchronous interfaces
are doomed. No. What this means is that you must use good design
practices in lieu of good simulation models to combat the effects of
metastability. Really, metastability is only a big problem in two
scenarios, if you have a metastable FF feeding many other FFs, or you
are trying to collect multiple signals (a bus) through an asynchronous
interface. The best way to alleviate bused data signals crossing clock
domains is to use an asynchronous FIFO which will safely collect and
transfer the data from one clock domain to the other. For the case of
control and other singe bit signals that must cross clock domains, you
need to double register the data so that the metastable register will
only feed one other FF that has a fairly short data path to give maximum
settling time. Since the suject is about simulating, for timing
simulation with Xilinx devices, you should put the attribute
ASYNC_REG=TRUE so that the synchronizing FF will not go to X when a
timing violation occurs but instead keep its last value so that you can
still perform a timing simulation of the interface. Properly designing
for metastability lessens the need for accurate simulation models to
model metastability. Both of these techniques are well documented all
over the Xilinx web site.

Hopefully this adds some more insight to this subject. It would be very
interesting to have models that show this behavior but the reality is it
is not likely to happen any time soon.


-- Brian


Muthu wrote:
> Hi,
>
> Is it possible to simulate Metastability? Not in the functional
> simulation. But in Gate level Netlist simulation.
>
> Regards,
> Muthu


Reply With Quote
  #2 (permalink)  
Old 04-03-2004, 12:33 AM
glen herrmannsfeldt
Guest
 
Posts: n/a
Default Re: Metastablility

Brian Philofsky wrote:


> I felt I should chime into this thread as I am responsible for the
> Xilinx simulation models and at the same time I have a history of
> metastability testing with Peter (the expert in metastability) to draw
> from. I have put some thought into the very subject of being able to
> simulate metastability in a timing simulation and there are a few issues
> that are not very easy to overcome that needs to be addressed to ever
> make this a reality. First off, as Peter mentioned, the actual time
> that any measurable metastable event would happen is a tiny time slice
> out of the setup/hold window.


(big snip)

Say one build a flip-flop out of CLB logic, maybe just to use
to demonstrate metastability. Would that have a significantly
wider window and/or longer resolution time?

-- glen

Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Metastablility john jakson FPGA 0 04-01-2004 12:58 AM


All times are GMT +1. The time now is 11:30 PM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved