Breaking News
Wrapping One's Brain Around Metastability
11/20/2013

< Previous   Image 3 of 5      Next >

Transition on input doesn't cause any problems.
Transition on input doesnít cause any problems.

< Previous   Image 3 of 5      Next >

Return to Article

View Comments: Oldest First | Newest First | Threaded View
jpbi0
User Rank
Rookie
about the load
jpbi0   11/20/2013 1:03:29 PM
NO RATINGS
1 saves
Two important points.

1) Inserting any logic between the two sync flops will delay the signal and thus push the settling edge closer to clock edge #2.

Note that DfT is a likely culprit of adding logic. The two flops form a shift register and thus the 2nd flop does not need a scan mux on it's input. However it requires attention of the designer to make sure that the 2nd flop is NOT replaced by a scan flop by the automated scan insertion tool.

2) It is important to note that the output of the first flop (op_1) can only be used to go to the input of the 2nd flop. The recovery time is strongly correlated to the RC time of that wire, so adding ANY load will increase the recovery time and thus the chance (MTBF) that the 2nd flop will go meta-stable. Ideally these two flops will be back to back (abutting) in the layout and thus the important wire (op_1) will be very short and have an extremely small RC. Adding anything else will easily increase the wire length by a factor 10.

Best solution is to make a sync module that does not expose the output of the 1st flop. I recommend adding an '_m' postfix to the name of the output of the 1st flop to indicate that it can go meta-stable.

 

lroee
User Rank
Rookie
I made this mistake long ago
lroee   12/18/2013 9:38:18 PM
NO RATINGS

I ran into this using TTL D FFs to sync an encoder output back in the early 70's. The encoder transitions were async to the system clock and the output of the single stage sync circuit was used directly by an edge triggered up down counter.

Needless to say the counter would gain counts one way or the other. I finally placed a small cap on the output of the D FFs and the problem went away. After thinking about it some more, I double synced the inputs as you describe. I like this better than caps. The duration of the metastable glitches was of the order of the prop delay of the FF.

Unfortunately the temporary "magic cap" fix does not work very well with an FPGA.

I'm not even sure the term metastable existed at that point in time. We all assumed that a D FF would either set or not. Eventually manufacturers started to point out the issue of what might happen if the timing was violated.


Radio
NEXT UPCOMING BROADCAST
EE Times Senior Technical Editor Martin Rowe will interview EMC engineer Kenneth Wyatt.
Top Comments of the Week
Like Us on Facebook

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Times on Twitter
EE Times Twitter Feed
Flash Poll