FPGARelated.com
Forums
   Forums    More Forums    comp.arch.fpga  

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

Started by Unknown ●August 22, 2007
Summary A user seeks a method to initialize all signals in a VHDL design to a known state for simulation because the RTL code lacks resets or initializers, causing widespread 'X' (unknown) values.

A user seeks a method to initialize all signals in a VHDL design to a known state for simulation because the RTL code lacks resets or initializers, causing widespread 'X' (unknown) values. While the design works in physical FPGA hardware where signals have default power-up states, the simulation remains stuck in an uninitialized state.

The discussion concludes that while the best practice is to add resets or initializers to the RTL, workarounds include using simulator-specific Tcl scripts to force values or performing gate-level simulations where vendor-specific primitives might have defined initial states.

  • Using a Tcl script with 'find signals' and 'force -deposit' can initialize signals in ModelSim without permanently overriding their values.
  • Simulating the gate-level netlist may solve the issue if the FPGA vendor's primitives include default power-up states.
  • Modifying the std_logic_1164 package to treat 'U' as '0' is a theoretical but complex and potentially slow solution.
  • The lack of resets or initializers is highlighted as a poor design practice that creates a disconnect between hardware behavior and simulation accuracy.
  • Randomized two-state simulation is suggested as a more robust way to detect initialization bugs compared to pessimistic multi-valued logic.
VHDLSimulationModelSimFPGA Initialization
Hi,

           I have a VHDL design which has no reset, within the design
are statements that rely on the last know state of a signal i.e sig_a
<= not sig_a,  sig_a has not had an initial value declared in the
signal region, hence it's value is X, there are numerous occurrences
of this within the design. The design has been place and routed and
works ok on the board as in the real world all signals have a default
value. I can not change the RTL code, I therefore need to force all
signals in the design to a known state, I understand that force only
works on 1 signal at a time. Does anybody know how to force all nets,
or have any better ideas than using force?

Thanks

Jon
Reply by Andy ●August 22, 20072007-08-22
On Aug 22, 9:45 am, witten...@googlemail.com wrote:

> Hi,
>
>            I have a VHDL design which has no reset, within the design
> are statements that rely on the last know state of a signal i.e sig_a
> <= not sig_a,  sig_a has not had an initial value declared in the
> signal region, hence it's value is X, there are numerous occurrences
> of this within the design. The design has been place and routed and
> works ok on the board as in the real world all signals have a default
> value. I can not change the RTL code, I therefore need to force all
> signals in the design to a known state, I understand that force only
> works on 1 signal at a time. Does anybody know how to force all nets,
> or have any better ideas than using force?
>
> Thanks
>
> Jon


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
Reply by Mike Treseler ●August 22, 20072007-08-22
wittenjon@googlemail.com wrote:


>            I have a VHDL design which has no reset, within the design
> are statements that rely on the last know state of a signal i.e sig_a
> <= not sig_a,  sig_a has not had an initial value declared in the
> signal region, hence it's value is X, there are numerous occurrences
> of this within the design. The design has been place and routed and
> works ok on the board as in the real world all signals have a default
> value.


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


> I can not change the RTL code, I therefore need to force all
> signals in the design to a known state, I understand that force only
> works on 1 signal at a time. Does anybody know how to force all nets,
> or have any better ideas than using force?


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

         -- Mike Treseler
Reply by Jonathan Bromley ●August 22, 20072007-08-22
On Wed, 22 Aug 2007 09:19:08 -0700, 
Andy <jonesandy@comcast.net> wrote:


>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.


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 :-)
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.
Reply by Jonathan Bromley ●August 22, 20072007-08-22
On Wed, 22 Aug 2007 07:45:52 -0700, wittenjon@googlemail.com wrote:


>Hi,
>
>           I have a VHDL design which has no reset, within the design
>are statements that rely on the last know state of a signal i.e sig_a
><= not sig_a,  sig_a has not had an initial value declared in the
>signal region, hence it's value is X, there are numerous occurrences
>of this within the design. The design has been place and routed and
>works ok on the board as in the real world all signals have a default
>value. I can not change the RTL code, I therefore need to force all
>signals in the design to a known state, I understand that force only
>works on 1 signal at a time. Does anybody know how to force all nets,
>or have any better ideas than using force?


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.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.
Reply by Andy ●August 22, 20072007-08-22
On Aug 22, 12:20 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

> On Wed, 22 Aug 2007 09:19:08 -0700,
>
> Andy <jonesa...@comcast.net> wrote:
> >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.
>
> 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 :-)
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.


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
Reply by fpgabuilder ●August 23, 20072007-08-23
On Aug 22, 10:34 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

> On Wed, 22 Aug 2007 07:45:52 -0700, witten...@googlemail.com wrote:
> >Hi,
>
> >           I have a VHDL design which has no reset, within the design
> >are statements that rely on the last know state of a signal i.e sig_a
> ><= not sig_a,  sig_a has not had an initial value declared in the
> >signal region, hence it's value is X, there are numerous occurrences
> >of this within the design. The design has been place and routed and
> >works ok on the board as in the real world all signals have a default
> >value. I can not change the RTL code, I therefore need to force all
> >signals in the design to a known state, I understand that force only
> >works on 1 signal at a time. Does anybody know how to force all nets,
> >or have any better ideas than using force?
>
> 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.
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.


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.
Reply by diogratia ●August 23, 20072007-08-23
On Aug 23, 5:20 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

> On Wed, 22 Aug 2007 09:19:08 -0700,
>
> Andy <jonesa...@comcast.net> wrote:
> >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.
>
> 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 :-)
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.


On Aug 23, 5:20 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

> On Wed, 22 Aug 2007 09:19:08 -0700,
>
> Andy <jonesa...@comcast.net> wrote:
> >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.
>
> 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 :-)
> --
> Jonathan Bromley, Consultant



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.
Reply by Jonathan Bromley ●August 23, 20072007-08-23
On Thu, 23 Aug 2007 04:08:27 -0700, 
diogratia <diogratia@gmail.com> wrote:


>It's possible to modify std_logic_1164 as you say, it's not all that
>hard, just a bunch of tables. 


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


>It's not what you actually should be doing,


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.


>What you are actually after


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.


> 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.


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 <= '0';
   else
     ff <= '1';

Note that this example reliably treats X, U etc as equivalent
to 0 in simulation. (A similar loophole exists in Verilog.)
Consequently, a functional bug that appears only if the FF
initializes to '1' would not be uncovered by this sim.
On the other hand, if the FF were initialised to a randomized 
0/1 value, the bug could be detected in functional RTL simulation.


>  The generated
>net list model in VHDL should take care of modeling the actual
>intialization found in the device.


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.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.
Reply by Andy ●August 23, 20072007-08-23
On Aug 23, 6:44 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

> On Thu, 23 Aug 2007 04:08:27 -0700,
>
> diogratia <diogra...@gmail.com> wrote:
> >It's possible to modify std_logic_1164 as you say, it's not all that
> >hard, just a bunch of tables.
>
> Sure.  The challenges are twofold: making sure that the changes
> don't break existing behavioural code, and introducing power-up
> randomization (see below).
>
> >It's not what you actually should be doing,
>
> 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.
>
> >What you are actually after
>
> 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.
>
> > 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.
>
> 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 <= '0';
>    else
>      ff <= '1';
>
> Note that this example reliably treats X, U etc as equivalent
> to 0 in simulation. (A similar loophole exists in Verilog.)
> Consequently, a functional bug that appears only if the FF
> initializes to '1' would not be uncovered by this sim.
> On the other hand, if the FF were initialised to a randomized
> 0/1 value, the bug could be detected in functional RTL simulation.
>
> >  The generated
> >net list model in VHDL should take care of modeling the actual
> >intialization found in the device.
>
> 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.
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.


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