force statement execution in verilog

HI

We are forcing some wires in a design from our testbench. We read some
information from a file and force the wires depending on the data in
the file. When we have multiple force assignment within one simulation
delta using the same variable on the right hand side, the last value
seems to get applied to all the forces. I have created a small testcase
to show this. If you look at the simulation result it shows that the
initial assignments are ok, but when we went to the next simulation
time, all the values were overwritten by the last value. Looks like the
forces were initially executed but then reexecuted again when the
simulation time moved.

Has anyone else experinenced this? Is this the expected behavior of
verilog force statements? Or is this a bug in the simulator?

Thanks.

-Dipu


-------------verilog code-----------------
module temp(
);

wire [7:0] test1;
reg [7:0] test2;
reg [7:0] test3;
reg [7:0] dataval;

initial begin
force test1 = 0;
force test2 = 0;
force test3 = 0;
$display (" time %0t : test1 =%0d, test2=%0d, test3=%0d", $time,
test1, test2, test3 );
dataval = 8'd1;
force test1 = dataval;
$display (" time %0t : test1 =%0d, test2=%0d, test3=%0d", $time,
test1, test2, test3 );
dataval = 8'd2;
force test2 = dataval;
$display (" time %0t : test1 =%0d, test2=%0d, test3=%0d", $time,
test1, test2, test3 );
dataval = 8'd3;
force test3 = dataval;
$display (" time %0t : test1 =%0d, test2=%0d, test3=%0d", $time,
test1, test2, test3 );
#1;
$display (" time %0t : test1 =%0d, test2=%0d, test3=%0d", $time,
test1, test2, test3 );
#1;
end

endmodule
---------------------simulation result----------
time 0 : test1 =0, test2=0, test3=0
time 0 : test1 =1, test2=0, test3=0
time 0 : test1 =1, test2=2, test3=0
time 0 : test1 =1, test2=2, test3=3
time 1000 : test1 =3, test2=3, test3=3
-----------------------------------

 

When you say "force test1 = dataval;" that doesn't mean force test1 to
the value that dataval currently has and leave it there. It means to
continuously force test1 to the value that dataval has. If the value
of dataval changes later, then the value of test1 will change to track
it. It works like a continuous assignment, not like a procedural
assignment.

Note that this capability makes forces rather expensive in the
simulator, but has some definite uses. For example, if you want to
force a sequence of values onto test1, you don't have to use another
force statement for each value. You just force test1 to be dataval1,
then read a sequence of values into dataval1 and test1 will follow it.

 

Thanks a lot for the clarification. Is this behavior of FORCE described
in the Verilog LRM? I dont have that handy to check.

The main reason we are using force is to drive a value into some
internal signals ( wire or reg )from testbench during simulation. These
are mostly temporary drives while be are building up the design. Is
there another preferred approach to achieve the same result without
using force?

Thanks.

-Dipu

 

Yes, the behavior of force is described in 9.3.2, which is a subsection
of 9.3 Procedural Continuous Assignments.

Forces will probably do what you need, as long as you understand how
they work and use them accordingly. Depending on your tools, they may
be more expensive to simulate than some of the alternatives. If there
are no other drivers on these nets (because the forces are taking the
place of logic that is not present yet), you could use ordinary
continuous assignments from regs to the nets and then set the values of
the regs to control the net values. Unless you are using a lot of
forces and are seeing a high memory or speed cost, I wouldn't worry
about it.

Forces have the advantage that they work on both regs and nets, so you
don't have to worry about treating them differently. Historically,
forces only worked on nets and quasi-continuous assigns only worked on
regs. Forces were extended to work on regs mostly because of this
convenience factor.

 

Thanks again for the comments and the LRM reference. One reason we like
force is that it can apply to regs and wires, as you said. Also we can
override the output of a non-functioning section and test the rest of
the design. We have a work-around currently. In my example, we create
different variable corresponding to each signal we want to force and
load values into those variables from a file and do the force.

We have not looked into the impact of simulation time. Maybe one of
these days when we dont have to finish the design yesterday

-Dipu




sharp@cadence.com wrote:

Yes, the behavior of force is described in 9.3.2, which is a
subsection
of 9.3 Procedural Continuous Assignments.

Forces will probably do what you need, as long as you understand how
they work and use them accordingly. Depending on your tools, they
may
be more expensive to simulate than some of the alternatives. If
there
are no other drivers on these nets (because the forces are taking the
place of logic that is not present yet), you could use ordinary
continuous assignments from regs to the nets and then set the values
of
the regs to control the net values. Unless you are using a lot of
forces and are seeing a high memory or speed cost, I wouldn't worry
about it.

Forces have the advantage that they work on both regs and nets, so
you
don't have to worry about treating them differently. Historically,
forces only worked on nets and quasi-continuous assigns only worked
on
regs. Forces were extended to work on regs mostly because of this
convenience factor.