Need to force all signals in a design to a known value at start of simulation

You don't want to force nets, since then they cannot be overridden in simulation (unless you force and then release them).

You could just add initializers to the signal and variable declarations, but that means modifying the code, although it could be done with a script in most cases.

I don't suppose we need to tell you that having neither reset nor initializers is a bad design practice, even when it "works" in FPGA hardware.

This is one case where a two-state optimization on the simulator would be worth its weight in gold.

Andy

If it's working ok, why the interest in simulation? If it isn't working ok, you'll have to change the code anyway.

You could add a reset to the code for simulation and make a wrapper entity that ties reset to ground for synthesis.

-- Mike Treseler

I wonder.... I just wonder.... if anyone has created a replacement for std_logic_1164 that has all the same names and things in it, but rewrites the operator definitions so that 'U' gets treated as zero.... it would simulate dog-slow because the simulator's internal accelerations for std_logic_1164 would be bypassed, but it would be useful in ugly situations like this. You could even implement the operators as foreign language functions, making it possible for them to randomize the replacement value for 'U'...

And no, I'm not signing-up to do it. I don't have the time, and in any case I can't sell my soul for a second time now that I've learnt SystemVerilog :-)

Most simulators have a way to inquire about what signals exist in a given scope. You could incorporate that into a Tcl script. For example, in ModelSim try loading a simulation and then issuing the command

find signals -recursive *

So here's a script that forces all signals in your toplevel testbench to zero:

foreach sig [find signals *] { force $sig -deposit 0 }

Yuck.

That's scary; I was just thinking the same thing. I use numeric_bit conversion and logic functions in my bitwise integer functions. I wonder if simulators have accelerated operations for type bit/ bit_vector? You could just create a package that defines std_logic as a subtype of bit, and std_logic_vector as a subtype of bit_vector or numeric_bit.unsigned. So long as you don't use tri-states, etc. that might work pretty well, and likely be quicker than custom operators that remap 'u'; Initial values would get become '0' automatically. You'd have to re-create rising/falling_edge() if they had been used.

Once upon a time, I wrote a replacement package for an old MVL7/MVL9 package, that created named subtypes of SL & SLV to match their original type names. I can't remember how I handled bit literals though....

I've often thought they should go back and re-define bit as a subtype of std_logic in the language for just this purpose, especially now that std_logic1164 falls under the main 1076 standard.

Andy

Another thought... you mentioned that the code works on the fpga. Maybe you can try to simulate the gate-level netlist. Maybe the design is not too big and a gate-level simulation not be so bad to deal with.

It's possible to modify std_logic_1164 as you say, it's not all that hard, just a bunch of tables. It's not what you actually should be doing, it doesn't distinguish between uninitialized state holders (registers) and uninitialized inputs.

What you are actually after is getting closure between two different levels of abstraction, a behavioral model and a physical model with or without accurate timing. Being able to compare the two is the equivalent of running input stimulus for the physical model on a chip tester, a timed model where you may put delays on inputs, and may pick sample times on outputs for clock coherent comparison against the abstract model.

For purposes of doing closure in say VHDL, the physical model is done using a primitives library supplied by the FPGA vendor. The generated net list model in VHDL should take care of modeling the actual intialization found in the device. If your two models don't match results you should modify the more abstract one to match initialization after determining that all the difference are significant and that you shouldn't modify how synthesis is done instead. It may be possible to ignore some output based on how long it takes for uninitialized state to clear from providing deterministic input (if possible). The comparison doesn't commence until after so long, or ignores certain output vectors or parts until visible and correct state is propagated from input stimulus. The idea is to prove the logic operates and it works for targeted timing.

This creates an physical implementation dependent behavioral model, implying you should be able to modify it in an agile fashion when re- targeting the physical device. You have a good chance of finding common behavioral initialization for multiple target architectures, or you can modify the test bench (things like pull ups or pull downs on the PCB design) when you see dependencies based on availability of input buffers. Your likely to have to modify the input application times and output sample times in any event.

Sure. The challenges are twofold: making sure that the changes don't break existing behavioural code, and introducing power-up randomization (see below).

Maybe not; I have used assorted custom multi-valued logic arrangements in the past when I've needed to, but that's not the point at issue here.

just to set the record straight, *I'm* not after anything at all; the OP posed a slightly odd problem in which he's not able or willing to modify some original source code, even though that's what he really needs to do.

All this is true enough, but doesn't really answer the OP's (and many others') problem: There are designs for which the power-up state of a register is irrelevant. Modelling such power-up state as unknown is unnecessarily and wrongly pessimistic. There is a school of thought that argues in favour of doing 2-state simulation, with all registers initialized to randomized 0 or 1 values. Performing many successive simulations, with different randomized startup values, has in some situations been shown to be better at flushing out initialization bugs than a multi-valued logic simulation with its excessively pessimistic treatment of initialization unknowns; despite this, it can miss important initialization bugs for some perfectly reasonable kinds of RTL coding style:

if (ff = '1') then -- behavioural inverter model ff net list model in VHDL should take care of modeling the actual

As I suggest above, there doesn't necessarily have to be any such real initialization. Typical gate-level models will then continue to emit spuriously pessimistic X values. The usual culprits are simple clock dividers, power-up timeout counters and that sort of thing; but of course such elements can easily bring an entire design to its knees if they go on spitting out X values until the heat-death of the universe.

Whilst I agree with the general drift of your comments about RTL-to-gates simulation closure, I'm very far from convinced that it is a particularly helpful thing to do; I know ASIC people do it a lot, and need it to flush out certain kinds of implementation and synthesis problem, but it is not the only act in town.

While the OP has not stated it, I assume he is targeting an FPGA (this is an FPGA newsgroup). All FPGA synthesis tools (and FPGA's) I'm familiar with reliably default the initial value of all registers to '0' after configuration unless there is a reset (async or sync) to '1' in the code, or there is an explicit initialization in the declaration. Therefore, a two state logic system that by default initializes all signals to '0' would be functionally accurate for FPGA targets, tri-state logic notwithstanding.

However, this does not cover the problem with asynchronous release of the "default" reset after configuration. Therefore, it is possible that the first clock after the "default" reset will result in unexpected values in multiple bit registers (i.e. counters, state machines, buses, etc.). OTOH, since multi-state logic systems (like std_logic) will not reliably emulate this behavior, there is still no associated value of a multi-state logic system over a two-state system (tri-state circuitry notwithstanding) for RTL simulations.

The only way that I am aware of to reliably use the default initialization of registers in FPGAs, to the exclusion of explicit sync or async resets, is to not enable the clock until a sufficient time after the default reset has deasserted.

Andy