Home    Bloggers    Messages    Webinars    Resources   
Tw  |  Fb  |  In  |  Rss
Adam Taylor

Ask Adam VHDL: Metastability, Part 1

Adam Taylor
Page 1 / 4   >   >>
Adam Taylor
Adam Taylor
7/9/2012 7:20:28 AM
User Rank
Blogger
Re: Metastability ......
I will be discussing FIFO's in one of my blogs soon relating to their use in the VGA display example I have been working on.

You might find the following link useful as it gives a good description of FIFO's and how they function

http://www.ti.com/lit/an/scaa042a/scaa042a.pdf

50%
50%
celine
celine
7/9/2012 5:42:19 AM
User Rank
Expert
Re: Metastability ......
"there is a part two coming up in the next few days. Is there anything else you would like me to address."

@Adam: multistage synchronizers are great to avoid metastabilties (and path delays mismatch as it has been said) from asynchronous independant signals or clock domain crossing signals but when it comes to buses I mainly use BRAM FIFOs. Once again I use them with some little pieces of knowledge about why it works but there still are some shadow corners like how the BRAM controller do the magic (I use the Xilinx Core Generator so I wasn't forced to answer this question to make it work). It would be great if you could write about it in the future.

50%
50%
Karl
Karl
6/21/2012 9:07:53 AM
User Rank
Guru
Re: Metastability when fast input is coming to slow clock domain
@skj:    A way of looking at this is that metastability in effect extends the propagation delay of reg#1 because of setup time violation, so yes there can be a setup or hold time viollation of reg#2.  That is the case when the synchronizer fails because of a finite probability that this will happen.  (both setup and hold times must be met)

In this example only setup can be violated for reg#1 because the input stays high, but for reg#2 either setup or hold may be depending on when reg#1 settles.

It should be more clear in Adam's MTBF calculations.

50%
50%
skj
skj
6/21/2012 6:06:30 AM
User Rank
Beginner
Re: Metastability when fast input is coming to slow clock domain
How does propogation delay compare to the hold time?

In the last diagram, @edge#2, OP_1 changes state from 0 to 1 after a "propagation delay". Could this causes a hold time violation at the input of register #2?

50%
50%
Karl
Karl
6/19/2012 2:04:21 PM
User Rank
Guru
Re: Metastability when fast input is coming to slow clock domain
@chunduru:  There are cases where only an occasional signal is sent to the slow domain and to make sure that it is sampled at least once the fast signal will have to be held for more than one clock period.

The cases of missed data because the slow clock cannot keep up can also occur as you observed.

Consider receiving data from a high speed serdes(which someone else mentioned previously) each time the shift register gets full, it must be emptied, so the "slow" clock can keep up because of the buffering in the shift reg.

When the fast data is being held to insuew that the slow clock can sample it, there is another detail to consider.  The data must be held for more than the slow clock period which means that it may get sampled more than once.  This leads to the slow logic generating a response(acknowledge) and the fast logic must remove the signal before another slow clock can occur.

 

 

50%
50%
chunduru
chunduru
6/19/2012 1:21:31 PM
User Rank
Beginner
Re: Metastability when fast input is coming to slow clock domain
@prabhul

I realized that the async data should be atleast as wide as clock signal of the recieving clock domain(as  Adam explained) .I believe the reason is that if asynchronous input frequency is higher than clock of recieving domain, then its a failure, because we are not capturing all the data because of our slow clock!!

Thanks

Chunduru

50%
50%
Adam Taylor
Adam Taylor
6/19/2012 4:34:41 AM
User Rank
Blogger
Re: Metastability when fast input is coming to slow clock domain
The MTBF Calculation takes into account the two frequencies i.e. the clock frequency and the asynchronous signal.

However it does not address the requirement that the fast asynchronous signal is of sufficent duration to be recovered correctly by the the slower clock domain that is down to the engineer to ensure correct data capture in that case as I mentioned in my reply above you need to make the fast signal atleast as wide as slow clock period.

50%
50%
Prabul Kanth P M
Prabul Kanth P M
6/19/2012 3:40:29 AM
User Rank
Beginner
Re: Metastability when fast input is coming to slow clock domain
@ ADAM: The same question i had in mind , glad that @chundru had brought it up.


Hope your next part gives a good insight to it.

50%
50%
Max Maxfield
Max Maxfield
6/18/2012 4:23:28 PM
User Rank
Blogger
Re: Metastability
@ab6vu: Don;t talk to me about management .... did you see my latest blog? http://bit.ly/LsA9Mi

50%
50%
ab6vu
ab6vu
6/18/2012 4:18:16 PM
User Rank
Guru
Re: Metastability
Max,

The products I described must have metastability:  it is unavoidable.  All we did was engineer it so that the statistics were 'acceptable.'

Ever try to explain that to management?  To an angry customer?

 

Hence why metastability is so misunderstood:  it will never 'go away' and it will never be 'fixed.'  It will always be present in anything that has to synchronize data moving between asynchronous systems.

All that one can do is reduce how often it happens....(or the consequences of it occurring).

Good idea to have written and agreed upon requirements!

100%
0%
Page 1 / 4   >   >>
More Blogs from Adam Taylor
Here we discover how to use the XADC (Xilinx Analog-to-Digital Convertor) in the Zynq All Programmable SoC to read the chip's internal temperature and voltage parameters and output them over an RS-232 link.
Now it's time to consider how we can implement and use the Xilinx Analog to Digital Convertor (XADC) within a Zynq All Programmable SoC-based system.
The Zynq All Programmable SoC comes equipped with programmable analog capabilities that can be used in a wide variety of applications, including defense, industrial, and automotive systems.
This is the blog we've all been waiting for – the point where we finally create our very first, standalone, "bare metal" Zynq application!
In the case of a real-world use model, we want to store our software program and configuration bitstream in nonvolatile memory and configure the device after the power comes on.
flash poll
follow us on twitter
follow Xilinx on twitter
like us on facebook
like Xilinx on facebook
All Programmable Planet     About Us     Contact Us     Help     Register     Twitter     Facebook     RSS