Simulating Power-Up

SystemVerilog
1

If the DUV uses 4-state types then, when simulation is started, those values are initially at X until (typically) reset is asserted. This can be likened to a real device powering up where flip-flop outputs have random values. However, the DUV I am currently testing has non-resettable flip-flops as well as SRAM memory, and I would like to recreate that fresh power-up one gets at the start of simulation. Is there a (reasonably convenient) way, during a simulation run, to force the DUV so that all its logic returns to X values?

My apologies if this question is geared more towards Questa than SystemVerilog.

2

In reply to sbellock:

You can think that closing the simulator is conceptually similar to turning the power off. If you don’t turn the power off and reset during a simulation, then the flip-flops would still keep their values.

Why don’t you just start multiple simulations? Once you reset, you’re anyway starting from (basically) scratch.

3

In reply to Tudor Timi:

Hi Tudor. Yes, multiple simulation sessions are the way I will do it if there are no other convenient options. My initial resistance to multiple simulations stems from two issues: 1) it elevates the test flow from the SV code up to the Python code that is executing the test, and 2) the DUV contains non-volatile memory whose contents need to be preserved between power-ups. I would need to communicate this, and other information, to the next simulation run through files.

So yeah, not impossible, but it would be nice if there was something like:

duv duv_i (.*);

initial
begin
    force duv_i = 'X;
end
4

In reply to sbellock:

You could try using the power-aware simulation capabilities of your tool (i.e. UPF) to model power off. This costs extra money (because it needs an extra license) and requires you to write a UPF file. Otherwise you’re going to have to force each and every one of your registers “by hand”.

5

In reply to Tudor Timi:

Great suggestion! I was under the mistaken impression that UPF and PA simulation was more for gate level designs but it looks like, for what I want it to do, it works just fine at the RTL level. The UPF file was easy to write and its impact on my testbench is minimal. I just needed to add

import UPF::*;

and use the supply_off and supply_on tasks.