NonDeterminism 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 DUTs 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
• Dont 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 dont care bits
• Recognize acceptable extra transactions
• Score-board transactions to catch spurious
  transactions
• Statistical analysis needed sometimes

14
Dont 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