simulator reset, not hardware reset

[danmc91]

Hello,

I'm trying to do some verilog sims of a circuit where the source is
schematics. I have a verilog netlister which will netlist out the
design down to calling primitives from a standard cell library. I
have a library.v file with verilog modules for all of the standard
cells (logic gates, flip-flops, etc).

The problem I'm having is how to deal with simple things like a
flip-flop configured as a divide by 2. The actual flip-flop does not
have a reset pin and so when the simulation starts, the output of the
flip-flop is an 'x' (as it should be) but of course it never resolves
because its output just feeds back to its input via an inverter. In
the real hardware, I could care less which state the thing starts in.

To make matters worse, there are actually quite a number of circuits
which are similar to this divide by 2. In other words they are
circuits with flip-flops which

a) don't have reset pins
b) don't care at all what state the thing comes up in because some
number of clock cycles later, all previous state has been flushed.

So my question, is if there is a way to tell verilog-XL for example to
initialize all registers which are an 'x' to 0 (or 1, I don't really
care) without having to explicitly list each and every one of them?

I don't really have the option of getting the library.v file modified
to put initial blocks inside of all flip-flops and latches that don't
have reset pins.

Thanks
-Dan

 

[danmc91]

I guess I can try to hack together something which walks through the
design and produces those force/release lines. Whats somewhat painful
is there are quite a number of flip-flops like this in the design.

Thanks for the suggestion.

-Dan

 

[Mike Treseler]

danmc91 wrote:

I guess I can try to hack together something which walks through the
design and produces those force/release lines. Whats somewhat painful
is there are quite a number of flip-flops like this in the design.

I would write clean RTL code from the
schematics and sim that.

-- Mike Treseler

 

[Art Stamness]

Another simple, yet terribly inneficient method is to write a tree
walker in PLI code that will initialize your regs in your design
hierarchy.

This is generally a bad thing to do, and I usually don't recomment it
for a few reasons :

- Combinational code that uses 'reg' construct get initialized ( which
isn't very realistic )
- Acc access enabled on entire desgins can slow things down ( only
matters if simulation performance is imporant ).
- You end up with only testing a single reset configurations, i.e.
reset all flops to 0, there could be latent bugs with different ( and
realistic ) startup conditions of flops.

For example code of a acc_routine that given the name of a module,
prints out all the nets within it, look at IEEE-1364-2001 22.4.3. The
function is "display_net_names". From this you can get a sense of how
the acc system works, and with a little more work you can figure out
how to make it start at the top of the tree, find every "reg"
construct, set it to a value, and then walk down to any submodules, and
do the same there.

Or to make it even more simple, just change your library! Put an ifdef
for simulation only, and put an "initial begin q = $random()" within
it. This will get you able to test it, but has the problem that the
order of evaluation of all the initial begins is non-deterministic, so
you might not be able to reproduce a failing case. But will allow you
to use the same netlist for synthesis, and simulation, provided the
correct defines are set.

Hope that helps.

-Art

 

[danmc91]

thanks. I'll look into this.

Part of my problems stem from the fact that I'm not doing any synthesis
at all here. I've built a circuit via schematics and the lowest cells
are from a standard cell library. All I'm using verilog for is to more
fully exercise this block than is possible via a SPICE-like simulation.

What I guess I can do is copy out the library file to a private
location (the master is controlled by a third party whom I have no
control over) and make the initialization modification. It does seem
somewhat strange to me that this isn't a very common problem. Of
course if I were writing verilog to drive a synthesis tool, I wouldn't
be directly instantiating flip-flop cells, but rather I'd be writing
code which a synthesis tool would turn into a flip-flop and it would be
easy for me to include proper initialization in my code.

I will try to read up on the PLI stuff, that sounds like a useful thing
I should really get around to learning anyway.

-Dan

 

[gtwrek@yahoo.com]

I'll add one more reason to Art's list as to why this is generally a
"bad thing to do".

It very likely won't work.

I did something very similar to what Art suggests, in an attempt
to "demeta" (as we called it) a gate level simulation. I wrote a
fairly simple PLI routine that stepped through the entire design,
and found any reg with an "X". It then forced that memory
to a RANDOM value (or zero, depending on how we configured).

The task could be called at any time.

The problem was there were too many special cases.
One big one - some registers are used as notifiers for timing
checks. These registers are usually not initialized - are X,
and are just used in notifiers for a change from X->X,
indicating a timing error. When the notifier changes,
a timing violation occurs, causing the model to force an X.

So my fancy pli task found these notifiers as X, forced them
to a value - triggereing a change, which triggers a (false)
timing error, causing an X somewhere else...

Other special cases include how to handle UDPs usually
found in library models.

In the end, I never got anywhere with this method.
Good learning exercise for PLI programming however!

This is why I advocate a smart reset strategy. Even if the reset's
not required in the final design, for simulation reason, reset
everything.

Good luck to the OP - you've got work ahead of you!

 

[Mike Treseler]

danmc91 wrote:

I don't really have the option of getting the library.v file modified
to put initial blocks inside of all flip-flops and latches that don't
have reset pins.

You'll have to change something, if you want to get a sim working.

-- Mike Treseler

 

[Chris Briggs]

One option is to use force from your testbench to drive a 0 or 1 into
the flop's input for a cycle, then use release to let it go.

e.g.,
initial begin
force tb.dut.mod.flop.d = 1'b0;
@(posedge tb.dut.mod.flop.clk) #1;
release tb.dut.mod.flop.d;
end

-cb