about x-prapagation of double flop during gate simulation

[childs72]

Hi, we are seeing gate level simulation (with sdf annotation) that shows "x" after double-flop stage. I suggested that x-prapagation of double flop is not handled properly by the simulation.

However my friend beg to differ as he claimed he seen gate level (with sdf annotation) simulation where "x" that appears after single-flop design became stable data after changing the design to double-flop.

(the double-flop & single-flop I mentioned above are for 1-bit signal synchronization purpose)

I hope anyone may share his/her experience on this issue. Thanks!

 

[yanshangzhao]

It's possible to see x even if you use two FF. You should think yousefl as a simulator, when timing violation happens, a register's value is x. Then x will prapagation to second FF then some part of circuit. So you can always see x in asynchronous circuit simulation no matter how many FF you use. But in real digital circuit, almost all the mid-state will be stable after two FF. If you are sure two FF is acceptable(most time it's ok), you can add that path in a no-timing-check list. Then simulator won't do timing check in that path. x state will disappear.

 

[sharath666]

When running with VCS we usually disable the notifiers on the first flop of a 2 flop synchronizer to avoid X propagation.

 

[childs72]

Thanks guys. Finally I am able to confirmed with my friend that what he saw before (where x-propagation is gone after double-flop implementation) is simulated with notifier turned OFF. So everything makes sense now

 

[dick_freebird]

I would caution you that, particularly at high clock
frequencies, metastable output of the first FF can
extend past the opposite clock edge (if you get the
timing exactly wrong - SPICE will show this) and the
probability of a double FF failing to clean the logical
state is thus nonzero. It may get you from a 1%-of-
the-time problem to a 0.01%-of-the-time problem.
Neither one is going to be any fun to deal with, and
the latter may get more customers "pregnant" before
it surfaces as a field failure (and the sparse, intermittent
ones are the most fun to chase). And they'll be looking
for who put it in, for child support - bet on it.

If all you want is a clean report, fine. But I don't
think killing notifiers gets you to design robustness
certainty. Seems more like a cheat to me. Like how
some people assert resets in the core of a design
with no electrical connection to do so in reality.
Bad form, bad chip, and then another engineer decides
to try their hand at selling real estate instead.

Engineers make lousy realtors. Even lousy engineers.

"x" is telling you that you have stepped off from safe
ground. You should do your best to take the warning
at face value and falsify it cleanly if you are able, or
fix the design if you're not.

 

[childs72]

Hi,

While the current approach is estimated to work fine with my design (which is running at less than 100MHz), I am really interested to understand how to properly sync the data at high frequency.

So far I only aware of double-flop technique to sync single bit data to safely avoid metastable signal at output of 2nd flop by reducing the chance of seeing metastable data at 2nd flop output to near-to-0-possibility). Other techniques that I heard of are using FIFO for bus, or by using protocol handshake, I do not think they have advantage over double-flop when comes to sync single bit data at high frequency). I am still pretty new in RTL designing so much of RTL design stuffs I learned are through reading only. Thanks.