In reply to dave_59:
This assumes all the external IPs have NO delays, even a #1.
That’s correct, we assume no delays between the signal and the clock. Typically this assumption holds well except with behavioral models where we might want to emulate some sort of real behavior.
Also this code needs to be in a timescale so that $realtime always returns an integer; otherwise the modulo operator will not work.
I guess I could change $realtime to $time without necessarily losing much. Our timescale is 1ps/1ps due to constraints in some of the models we are using, so I guess that in that case $realtime is guaranteed to be an integer since it’s scaled to the timescale and there’s no possibility to have an event in the fs range (please correct if I’m wrong).
You can use always @(signal iff (!$isunknown(signal) ) to get rid of X transitions.
that’s the construct I was looking for, indeed I got bitten by the X transitions already! Thanks.
A much better approach is using a formal CDC checking tool. With little or no stimulus at all, a CDC can trace all the domain crossings exhaustively.
I fully agree that a CDC flow would immediately highlight these issues, yet I consider it complementary rather a replacement and the reasons are two:
- CDC flow typically is put in place at top level and come much later in the picture. Running CDC cycles when the system is far from being mature is way too time consuming and when designers are head down in the implementation are not necessarily thinking/working on SDCs.
- you still have the case of VIP ↔ TB ↔ DUT interfaces where you can’t assume your VIP/TB is holding its promise to provide a synchronous signal. Too many debugging cycles are plagued by assumptions that turn out to be false.
I haven’t seen much literature on these types of checks and maybe it’s worth questioning whether they are really needed, but so far I haven’t been offered a clear solution on how to address at least my second point above, that’s why I’m following the white rabbit!