Non-Determinism In C and RTL Models

1. Non-Determinism In C and RTL Models ICCAD 2006 – Ira Chayut, Verification Architect

2. “C Models” in a Variety of Languages • “C Model” == “Reference Model” • Reference Model could be in C, C++, Perl, Python, Java, Verilog, SystemVerilog, SystemC, emulation, silicon rendition of the Device Under Test (DUT), etc. • The DUT can be any implementation, this presentation assumes a Verilog RTL DUT

3. Validation vs. Verification • Validation: answers the question: “Does the model produce the correct output?” • Verification: answers the question: “Does the DUT behavior match that of the reference model?”

4. A Typical Verification Example Stimulus is applied to the C model and the DUT. The outputs are then compared.

5. Causes of Mismatches • Errors in: • DUT • C model • stimulus • checker code • compiler or simulator • Differences in the way models handle time

6. Determinism / Non-Determinism • According to Wikipedia: In a deterministic system, every action, or cause, produces a reaction, or effect, and every reaction, in turn, becomes the cause of subsequent reactions. The totality of these cascading events can theoretically show exactly how the system will exist at any moment in time. • Thus, a non-deterministic system is one where knowing the state of a model and the stimulus, we cannot precisely know the next state and output • At Nvidia – the term “non-determinism” is used for situations where the C model cannot predict the DUT’s behavior

7. Causes of Non-Determinism • Independence between C model and DUT • Architectural vagueness • Efficiency • Points of arbitration (including memories and caches)

8. Time and Non-Determinism • Timed-events are the largest cause of non-determinism, including: • Memory accesses • Cache fills/hits/misses • Time-outs • Multiple clock domains • Clock jitter in silicon

9. Non-Determinism Work-Arounds • Hints from DUT • Cycle-accurate C models • Smart checkers • Don’t verify non-deterministic cases

10. Non-Determinism Example • MUX selects stimulus until: • FIFO full, or • Timer reaches time-out • C model does not have concept of time –RTL sees time-outs that C model does not !=

11. Hints from DUT • DUT simulation: • provides hints to untimed C model • gates the C model • weakens the independent check by C model ==

12. Cycle-Accurate C Model • Slows C model runs • Slows C model development • Problem modeling jitter between async clock domains • Weakens the independent check of C model

13. Smart Checkers • Match out-of-order transactions • Ignore don’t care bits • Recognize acceptable extra transactions • Score-board transactions to catch spurious transactions • Statistical analysis needed sometimes

14. Don’t Verify Non-Deterministic Cases • Some cases too difficult to test • Verify later-stage results • Validate DUT • Validate in silicon • Avoid non-deterministic designs

15. Conclusions • C model and DUT behavior may vary for some stimulus, but both behaviors are correct • Time-based behavior is especially problematic • When non-determinism cannot be avoided: • Smart checkers • Cycle-accurate C models • DUT hints • Validate DUT or silicon