Verilator

I presume by fault you mean single-stuck-at modeling, as opposed to software fault injection?

I also presume you're doing this on a gate level netlist, and want to do all signals not just flops (say for soft error modeling)?

Also, out of curiosity, what are you getting out of this, verus using one of the algorithmic fault analysis techniques?

Anyhow...

The problem with "force" is you need to change the value of even combo nets; the existing "public" accessors let you read and write signals, but it won't override a combo net if it gets recomputed due to an upstream flop changing. Supporting a general "force" on all signals always would be extremely slow - probably 2x slower, so it needs to be optional.

However for your application you could imaging having Verilator when given a switch transform the netlist. Wherever signal "a" is used it is replaced with "a__resolver" and it adds "wire a__resolver = a__force_enable ? a__forced : a)". (This is for one bit, appropriate modification for vectors, memories, and flops.)

Or, on the driving side replace "a = ..." with "a = (a__force_enable ? a : ...)" where the force value can be kept in "a" since that bit won't change. This is faster than changing the reading side, since Verilator could be told to not schedule the force_enable variable, and there's almost always fewer writes than reads.

An additional complication if you want decent performance is to know that signal "a.b.c" and signal "a.d.c" are really the same signal, or inversions of each other, and so should share the same forcing net. Verilator does this already for toggle coverage analysis and for waveform tracing, though your application differs somewhat in what optimizations are legal vs. not so that faults aren't missed or mis-attributed.

Adding the "read mux" is easy-ish to write; if you want to proceed I can provide guidance as to what to change.

Hi Wilson. I aim to do this at RTL level as I need to select a test that not only gives good coverage, but also gives good fault coverage. I have a lot of tests to choose from so want to use Verilator on the RTL to pre-select a much smaller set of tests before (possibly), entertaining gate level sims.

I note that you mentioned altering the netlist to allow stuck-@ fault insertion, so I assume that you cannot use a Verilog force statement in Verilator?

I have used the trick of using toggle info to extract signal names before and was going to use it again as you suggested - it beats having to parse Verilog RTL.

Thanks for your prompt and useful reply.

Makes sense. No, there's no "force".