Fault simulation

[Blebowski]

Hi,
just capturing an idea. @nickg as you are now working towards
Verilog implementation, it is likely that NVC will be able to parse a verilog
netlist soon (netlists usually contain only structural Verilog, so very small sub-set of the language).
It would be nice to try to simulate an input test pattern (e.g. in VCD or STIL),
and measure fault coverage obtained by such pattern.

[Blebowski]

Hi @nickg,

I was wondering if this is something you would be open to.

The goals of fault simulation typically are:

• Measure fault coverage of DUT / chip / device.
• Examine behavior of a device in environment where SEU (Single event upstets) may occur.

Having at least the first one would be a major thing in an open source tool.

• Measure DUTs fault coverage *

When an ASIC is being manufactured, having high fault coverage is important to get small amount of defective parts in the field. The fault coverage can be obtained from ATPG (for automated test patterns), or by fault-simulation.

During fault simulation, a tool simulates DUT two times:

• Gold simulation
• Faulty simulation

In the gold simulation, the simulator applies the stimuly (either test-bench around a DUT, or VCD input),
and:

• Records the DUTs outputs (in case of TB used as stimuli)
• Compares with VCDs output (in case of VCD based stimuli) -> Must match for VCD stimuli to be consistent.

Then in a faulty simulation, the simulator applies the same stimuli to DUTs input / inout pins, and compares
the output / inout pins with those of "gold simulation". If there is a mismatch somewhere, it means that the
fault was detected.

Then the simulator loops through all faults in the device, and fault-simulates each one of them. The
fault coverage is basically the amount of detected vs. undetected faults.

There are different fault models, the basic "stuck-at" fault model would be a good place to start.
Basically, the simulator assumes that the DUT is a gate-level netlist, and each input or output of
a PDK cell can contain stuck-at-0 and stuck-at-1 fault. The cell is typically recognized by being a module
defined under celldefine directive.

Obviously there are more elaborate options possible, but this simple approach would be a good place
to start.

[nickg]

I think this kind of tool would be best implemented on top of VHPI/VPI rather than coupling it to the main simulator. It could be bundled in the contrib/ directory if it's useful to a sufficient number of users.

[Blebowski]

Yeah, that is a good idea. I think the commercial tools use similar approach, e.g. waveform viewer communicates with simulator via VPI / VHPI to query the design hierarchy.

Looking at the VPI definition in System Verilog LRM, there is vpiCellInstance to figure out module is a cell.