VHDL testbench hard question: How to force values into internal IP signals? (eg: simulation of SEE, Single Event Effect)

[ruifernandomarques]

Hello! Literally my first post here. Here goes:

I'm a 8y verilogger, who's re-starting in VHDL, and with System Verilog there's a way to create a "sequence of events" where I force values of the internal IP "signals" (they are called "registers" in verilog).

One might say that this is bad practice, but then I'd welcome an alternative to simulate SEEs (Single Event Effects, related to Radiation Environments, which literally change the value of internal random bits), or even time constraint violation due to temperature / voltage level fluctuation, etc.

Other classic answer is to create an external interface for "debug"/"test"/"fault injection" mode but, creating these "debug"/"test"/"fault injection" interfaces to interact via external interface heightens the projects % and enlarges the used area where more SEEs may occur.

I am also aware I can force signals through a ".do" script file. That's not what I'm looking for either.

Within the VHDL testbench, create a sequence of events equal to:

1. -> run QuestaSim/ModelSim for 1ms
2. -> manually force value on the waveform tab
3. -> run 1ps
4. -> noForce the same signal.
5. -> run -all

(all this without having to manually start and stop the simulation multiple times and force and release signals on the waveform tab multiple times)

eg ( improvised / not VHDL testbenching ) :

-- the following lines should be within testbench file​

process
begin​

wait 1ms ; -- wait for 1 ms before creating a SEE on the LSB of a counter (internal IP signal of "i_myPLL" VHDL)​

force -freeze i_myPLL.counter(0) = '0' ; -- i_myPLL is the instantiation of a "myPLL" VHDL block, that has "counter" as an internal std_logic_vector​

wait 2ns ; -- wait for 2 ns before "releasing" the "counter" value​

release i_myPLL.counter(0) ; -- from this point onwards, the std_logic_vector "counter" is only dependent on the "i_myPLL" internal logic​

wait ; -- simulation continues with no forced signals​

end​

-- end of example​

Is there such a thing in VHDL testbenching, or is it something strictly to System Verilog?

Thank you for the help!

 

[dick_freebird]

I have only used SPICE type simulators to do SEE
simulations, as I'm an "analog guy".

However I have seen and largely ignored some
of the "big digital" players presenting methods
of injecting faults on the fly. They have their
"methodologies" (that's Dorkish for methods).
You might be able to find clues in IEEE NSREC
papers, and wherever server-farm-reliability
interested digital types hang out. Look for stuff
from Boeing solid state, Vanderbilt, BAE Systems,
Aeroflex/Cobham (these are among the most
radiation-effects-publication-happy, many
others do not publish).

The interesting problem is less the mechanics
of flipping a gate's state (transient for combo logic,
transient or persistent for latches & FFs) than the
challenge of getting one at a time, in turn, with
location logged, at varying timepoints (as response
for a given "victim" is also data state dependent).

Fault simulators are a good adjunct to functional,
they can show you circuit blocks where an error
accrued, may not be observed. I believe some
approaches use "fault-ish" approaches for efficiency
rather than trying to scan the whole part per transistor
per vector for sensitivities.

SPICE work can be useful up front, to determine
(for example) whether classes of gates are SET-
immune, latches / FFs SEU & SET immune, in
which case they could be ignored for analysis
(greatly reducing run times for "shotgun" functional
analyses). I worked in one technology where simple
6X min W sufficed to make logic SET immune and
DFFs unupsettable. But that's old obsolete stuff,
now. Still a low level assessment of what you've
got could be high-leverage.

 

[ads-ee]

There is a feature in Modelsim/Questa call signal spy that will allow accessing internal VHDL nodes. I don't know if it will allow you to do so from a SV testbench.

If you are using VHDL 2008 (i think that is the version) it allows access through the hierarchy like Verilog/SV does.

 

[TrickyDicky]

I'm not sure how useful fault injection would be to pure rtl. If you're looking for fault injection in a real circuit you'll want to be simulating the netlist. Rtl (particularly vhdl) will use enumerated types for state machines that will be encoded by the synthesisor.

What application are you looking at? Fault injection is not something I've ever done, but I'm in commercial space.

Vhdl has external names that allow access throughout the hierarchy, along with new reserved word force to override the current value.

 

[ruifernandomarques]

If you are using VHDL 2008 (i think that is the version) it allows access through the hierarchy like Verilog/SV does.

Can you give me an example or references?
I've been looking on-line for it, and I haven't found anything apart from what stated on the original post - force signals through the ".do" file, etc. which don't fill my purpose.
Do you know what VHDL testbench "command" can be used to write onto internal HDL Block registers/signals?

btw, Thank you all for your feedback.

 

[TrickyDicky]

external names takes this format:

---

Code VHDL - [expand]
1
<<signal path.subpath.some_signal : std_logic>> <= '1';

---

The "box" chars <<>> specify and external name. Ususally, people will create an alias to make their RSI less bad when assinging it several times

---

Code VHDL - [expand]
1
2
3
4
5
alias internal_sig is <<signal path.subpath.some_signal : std_logic>>;
....
internal_sig <= '1';
wait for 10 ns;
internal_sig <= '0';

---

 

[ruifernandomarques]

I'm not sure how useful fault injection would be to pure rtl. If you're looking for fault injection in a real circuit you'll want to be simulating the netlist. Rtl (particularly vhdl) will use enumerated types for state machines that will be encoded by the synthesisor.

What application are you looking at? Fault injection is not something I've ever done, but I'm in commercial space.

Vhdl has external names that allow access throughout the hierarchy, along with new reserved word force to override the current value.

I have multiple situations that would take great advantage on this matter, but I can give you some specific cases:

1. FSM / Control Flow SEE: Finite State Machines are coded as "one-hot-encoding": if the FSM has N states, the number of bits for the FSM is N, and 1 and only 1 bit is active for each state. Whenever a SEE randomly change a bit from the FSM, if the FSM was enumerated, the FSM would have an unpredictable "jump" to another state (or undefined state). With "one-hot-encoding", since FSM valid states have 1 and only 1 active bit, whenever 2 bits, or 0 (zero) bits are active (due to radiation SEE), the FSM is taken to a "SEE detection State", and can "properly" reset/reboot/recover.
   1. How can one test this if not by forcing an internal register/signal to get the FSM to a "non one-hot-encoded" State? There's no logic INTO that "non one-hot-encoded" State (nor should), but clearly there's logic OUT OF that state.
2. Data Flow SEE: Another case is when you have ADC's (or actually any other other type of input) connected "into" your FPGA, and want to test how robust is your ADC samples into your system. For Telecommunications, it's common to test your reception chain for SNR (Signal to Noise Ratio). If SEEs occur, the SNR will degrade a lot (that's not actually SNR, but the samples that you read are in "worst shape" due to the SEEs), and quite often, you want to know, how many SEEs your reception chain is able to withstand before you lose / don't identify an incoming communication. This can be simulated "more less" by inputting SEEs samples coming from the ADC, but if you have multiple digital filters within the Reception chain (which you usually have), again, I don't see how can you change random internal bits from your FPGA on that reception chain.
3. There's much more, but I think it's easy to understand the added value by stating the SEE events on Control Flow chains, and Data Flow chains.

I'm not sure if commercial space reaches the century of van Allen, but I believe if someone is working for the space industry, you are probably facing one of these three situations:

1. Your products don't fly through high radiation, so the chances of a SEE are small (even smaller for a "critical SEE"), so you may discard them
2. Your products fly through high radiation, so your FPGAs are either Radiation Tolerant or Radiation Hardened which may solve the problem
3. Your products fly through high radiation, but SEEs need to be taken into account even with Radiation Tolerant or Hardened FPGAs, and some methodologies are a must: One-Hot-Encoded FSM, Triple Modular Redundancy, etc.
4. Obviously, the time of the mission, and the criticality of System Failure, etc. should be weighted.

There's value in having a way of forcing internal registers/signals of an IP HDL Block, in VHDL testbench environment.

( Thank you all for your replies. )

 

[ruifernandomarques]

external names takes this format:

---

Code VHDL - [expand]
1
<<signal path.subpath.some_signal : std_logic>> <= '1';

---

The "box" chars <<>> specify and external name. Ususally, people will create an alias to make their RSI less bad when assinging it several times

---

Code VHDL - [expand]
1
2
3
4
5
alias internal_sig is <<signal path.subpath.some_signal : std_logic>>;
....
internal_sig <= '1';
wait for 10 ns;
internal_sig <= '0';

---

Thank you, I'll try it.

 

[TrickyDicky]

By Commercial space, I meant commercial products with no concern with radiation hardening.
Im sure it would be a problem for space or even some aircraft applications.

Also, be aware, that the external signal names are only available in VHDL 2008, and generally will only work if the signal you're trying to get at is also in VHDL. Cross language support for external names (and Verilogs heirarcical names) will be tool dependent and likely not as good as you'd like.

 

[std_match]

You should use the "force" and "release" keywords in VHDL-2008.
If you just assign '1' or '0' you will get 'X' in the simulation because the normal driver is still there.