Non-Determinism In C and RTL Models

ICCAD 2006 – Ira Chayut, Verification Architect

© 2006 NVIDIA Corporation Slide 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

© 2006 NVIDIA Corporation Slide 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?”

© 2006 NVIDIA Corporation Slide 4

A Typical Verification Example

Stimulus is applied to the C model and the DUT. The outputs are then compared.

© 2006 NVIDIA Corporation Slide 5

Causes of Mismatches

Errors in: DUTC modelstimuluschecker codecompiler or simulator

Differences in the way models handle time

© 2006 NVIDIA Corporation Slide 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

© 2006 NVIDIA Corporation Slide 7

Causes of Non-Determinism

Independence between C model and DUT

Architectural vagueness

Efficiency

Points of arbitration (including memories and caches)

© 2006 NVIDIA Corporation Slide 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

© 2006 NVIDIA Corporation Slide 9

Non-Determinism Work-Arounds

Hints from DUT

Cycle-accurate C models

Smart checkers

Don’t verify non-deterministic cases

© 2006 NVIDIA Corporation Slide 10

Non-Determinism Example

MUX selects stimulus until:

FIFO full, orTimer reaches time-out

C model does not have concept of time –RTL sees time-outs that C model does not

!=

© 2006 NVIDIA Corporation Slide 11

Hints from DUT

DUT simulation:

provides hints to untimed C model

gates the C model

weakens the independent check by C model

==

© 2006 NVIDIA Corporation Slide 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

© 2006 NVIDIA Corporation Slide 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

© 2006 NVIDIA Corporation Slide 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

© 2006 NVIDIA Corporation Slide 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 checkersCycle-accurate C modelsDUT hintsValidate DUT or silicon