Response to Mentor CDC Whitepaper
There was a recent surge of discussions about asynchronous clock domain crossings and metastability handling in Verilab email: Two people asked Mark Litterick essentially the same question just hours apart, and then a day later Jason Sprott noticed a Mentor CDC Verification paper that referenced Mark’s “Pragmatic Simulation-Based Verification of Clock Domain Crossing Signals and Jitter using SystemVerilog Assertions,” paper (Best Paper at DVCon 2006).
One particular statement in the Mentor paper caught my eye: "this model can still generate false errors: the waveforms show that input sequence A, B, C, D, E, F can result in output sequence A, B, E, E, E, where two consecutive inputs, C and D, are skipped". And this statement bothered me: I had spent a long time figuring out Mark’s model some while back, and while it was not at all intuitive to me, I did convince myself that it could never generate a simulated output sequence that was impossible in real hardware. So if the Mentor paper was correct, then I had missed something about Mark’s model, and I’ll be honest, I didn’t relish going back and studying it again.
Obviously I was just going to have to find a mistake in the Mentor paper instead. And to my considerable relief, I did. In fact, I found two:
- The schematic (Fig 8, p.9) of Mark’s synchronizer model is missing a small but important feature.
- The waveform (Fig 9, p.9) of data signal values input to the model is a somewhat misleading representation of an async input.
In the Mentor paper, the select inputs to both muxes are simply "$random()". In Mark’s original model (Fig 11, p.5), the select input of the input mux is indeed just "$random()", but the select input of the output mux is "@(m2 or m3) $random()".
The result of the modified select term is to make the "A,B,E,E,E" behavior impossible except under specific conditions. But under the right conditions, it is indeed a possible behavior in hardware.
The waveform of the d input signal in Fig 9 of the Mentor paper gives a false impression that d is actually synchronous, rather than asynchronous, to the sampling clock clk. The stability of a transitioning async input cannot be inferred forward or backward from the sampling clock. If two consecutive samples are not equal, it is unknown when the transition occurred - it is only known that a transition occurred. So if the sampled values B, C, D, E in simulation were 0, 1, 1, 0, it is entirely possible for hardware to exhibit the output sequence 0, 0, 0, 0.
The fact that samples C and D were both 1 in simulation does not mean that d was stable for two complete clk periods, as implied in Fig 9: The 0->1 transition B->C could have occurred momentarily before the C sampling clock edge, and the 1->0 transition D->E could have occurred momentarily after the D sampling clock edge. And if both transitions violated the sampling setup/hold window, then the metastability could settle to the B value at the C clock edge, and the E value at the D clock edge.
