Three chips, three escapes (illustrative). One booted only on some boards, because a register without reset started random and the RTL simulation had quietly initialised it to zero. One corrupted data once a day, because a signal crossed between two clocks without a synchroniser, and simulation, which has no metastability, never failed. One hung after waking from sleep, because the simulator had kept a powered-down block alive and holding its state. Each was correct in RTL simulation.
Which bugs does ordinary RTL simulation miss, and what finds them?
The obvious assumption is that a thorough RTL simulation covers reset, clocking and power along with everything else, since they are all in the RTL. But plain RTL simulation is an idealised model: registers can start as zero or X depending on the simulator and settings, every clock crossing behaves perfectly, and power is never actually removed. Each idealisation hides a whole class of real failures.
Class | What goes wrong in silicon | Why plain RTL simulation misses it | What finds it |
|---|---|---|---|
Reset | Wrong reset values; flops without reset start random; reset released in the wrong order | Uninitialised state may simulate as 0 or as X that is masked by optimistic logic | Reset-value checks, X-propagation analysis, reset-order tests |
Clock-domain crossing | Metastability, lost or duplicated pulses, incoherent multi-bit data | Simulation has no metastability and fixed clock ratios | Structural CDC analysis, protocol checks on crossings, randomised clock ratios |
Power | State lost on power-down, missing isolation, wrong retention, failed wake | Without power-aware simulation, blocks are never powered down | Power-aware simulation with the power intent, power-state coverage |
Reset: read every register after reset and compare with the specification; check that no X reaches outputs; test reset in the middle of traffic and in different orders across domains.
Clock crossings: run structural CDC analysis on the netlist or RTL, not simulation alone; check the protocol of every handshake crossing; vary clock ratios in simulation.
Power: simulate with the power intent applied so domains really lose state; cover every power-state transition, including wake with work pending.
Class | Primary method | Where the detail lives |
|---|---|---|
Reset | Register reset checks, X-propagation and formal reset analysis | Formal and RTL courses |
Clock-domain crossing | Structural CDC and RDC analysis plus targeted simulation | CDC and RDC course |
Power | Power-aware simulation, power-state coverage | Low-power verification course |
DCRouter has one reset bug and three low-power bugs. The reset bug, port 3 disabled after reset (BUG_17), is visible to any test that reads CTRL or sends on port 3. The power bugs need tests that let DCRouter go idle and sleep: losing an output's lock when it sleeps mid-packet (BUG_20), failing to wake from port 3 (BUG_21), and dropping credit returns while asleep (BUG_22). A test that keeps traffic flowing never sleeps, and never sees any of them. (DCRouter has a single clock, so it has no crossing bugs; the CDC and RDC course covers those.)
It powers up in a random state; the simulator may have started it at 0 or masked an X, hiding behaviour that depends on its initial value.
The low-power bugs (BUG_20, BUG_21, BUG_22): DCRouter only sleeps after 8 idle cycles.
Plain RTL simulation idealises reset, clocks and power, hiding whole classes of bugs.
Reset needs value and X checks, crossings need structural CDC analysis, power needs power-aware simulation.
Name each idealisation in the plan and the method that covers it.