simulation differences in modelsim

[koyel.aphy]

I have designed a unit that I am testing in modelsim. I did that in
two ways, first forcing the inputs from the object pull down menu of
the vsim window and clicking on the run command and second by writing
a test bench. However, I find that in the first case the inputs need
to arrive two clock pulses after the reset goes high as is also true
logically in my design whereas in the test bench, the outputs get the
correct values if the input enters one clock pulse after the reset
goes high else if it enters two clock pulses after the reset goes high
as in the first case then the last data sample is not written and the
output takes on the previous value. If I try to input data one clock
pulse after reset goes high in the first case as in the second case
then the last sample overwrites the previous last before the previous
last is out, which is also true logically.What is the problem with the
test bench?

This is a part of the test bench that reads the data depending on the
reset2 signal that has to be set high after one clock pulse, the reset
goes high else that causes problem as mentioned above. This is just a
signal I have used to control reading operation in the test bench.

readfile ROCESS
file inp1:TEXT open READ_MODE is "inp1.txt";
file inp2:TEXT open READ_MODE is "inp2.txt";
VARIABLE inline1,inline2 : LINE;
variable dat_var : std_logic_vector (11 DownTo 0);
variable add_var : std_logic_vector (2 DownTo 0);
BEGIN

WAIT UNTIL (clock1 = '1' AND clock1'EVENT);
IF (NOT ENDFILE(inp1)) and reset2 = '1' then -----reading data
READLINE(inp1, inline1);
READ(inline1, dat_var);
datain1 <= dat_var;
count_read <= count_read+1;

END IF;
IF (NOT ENDFILE(inp2)) and reset2 = '1' THEN --------reading address

READLINE(inp2, inline2);
READ(inline2, add_var);
write_add <= add_var;
count_read <= count_read+1;
END IF;
end process readfile;

 

[koyel.aphy]

On Sun, 15 Jun 2008 06:27:59 -0700 (PDT), wrote:

[...]

What is the problem with the test bench?

It was a little hard to follow the details of your description -
it's always difficult to describe timing behaviour in words -
but I suspect the problem is that you are applying stimulus
exactly at the moment of the active clock edge. Although this
is probably OK in a zero-delay RTL simulation, it gives no
hold time for the inputs and it is usually very confusing to
try to interpret the results.  

It is far better to set up the input stimulus so that it gives
reasonable setup and hold time relative to the clock edge.  One
useful technique is to apply the stimulus on inactive clock
edges, and to sample both the stimulus and the DUT's outputs
exactly at the moment of the clock edge when you are sure that
the DUT has not yet had a chance to react to the clock.

This is a part of the test bench [...]

It looks basically OK, apart from the stimulus timing problem
I already described.  Also, the testbench will not stop
automatically when your stimulus file is exhausted;  it
is probably a good idea to do something about that.  For example,
just before the end of your process:

  assert (NOT ENDFILE(inp1)) or (NOT ENDFILE(inp2))
    report "Input data exhausted - NORMAL SIMULATION STOP"
    severity FAILURE;

HTH
--
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
(e-mail address removed)://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Thank you very much for this useful information. Indeed if I give the
inputs at the falling edge then it has to wait two clock pulses after
the reset is high. The delay is maintained correctly as I have done in
my design.

cheers

 

[jtw]

Alternatively, force the clock(s) to stop. The simulation will stop when
there are no more scheduled transactions.

JTW

On Sun, 15 Jun 2008 06:27:59 -0700 (PDT), wrote:

[...]

What is the problem with the test bench?

It was a little hard to follow the details of your description -
it's always difficult to describe timing behaviour in words -
but I suspect the problem is that you are applying stimulus
exactly at the moment of the active clock edge. Although this
is probably OK in a zero-delay RTL simulation, it gives no
hold time for the inputs and it is usually very confusing to
try to interpret the results.

It is far better to set up the input stimulus so that it gives
reasonable setup and hold time relative to the clock edge. One
useful technique is to apply the stimulus on inactive clock
edges, and to sample both the stimulus and the DUT's outputs
exactly at the moment of the clock edge when you are sure that
the DUT has not yet had a chance to react to the clock.

This is a part of the test bench [...]

It looks basically OK, apart from the stimulus timing problem
I already described. Also, the testbench will not stop
automatically when your stimulus file is exhausted; it
is probably a good idea to do something about that. For example,
just before the end of your process:

assert (NOT ENDFILE(inp1)) or (NOT ENDFILE(inp2))
report "Input data exhausted - NORMAL SIMULATION STOP"
severity FAILURE;

HTH
--
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
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Tricky]

Alternatively, force the clock(s) to stop. The simulation will stop when
there are no more scheduled transactions.

JTW

[...]
What is the problem with the test bench?

It was a little hard to follow the details of your description -
it's always difficult to describe timing behaviour in words -
but I suspect the problem is that you are applying stimulus
exactly at the moment of the active clock edge. Although this
is probably OK in a zero-delay RTL simulation, it gives no
hold time for the inputs and it is usually very confusing to
try to interpret the results.

It is far better to set up the input stimulus so that it gives
reasonable setup and hold time relative to the clock edge. One
useful technique is to apply the stimulus on inactive clock
edges, and to sample both the stimulus and the DUT's outputs
exactly at the moment of the clock edge when you are sure that
the DUT has not yet had a chance to react to the clock.

This is a part of the test bench [...]

It looks basically OK, apart from the stimulus timing problem
I already described. Also, the testbench will not stop
automatically when your stimulus file is exhausted; it
is probably a good idea to do something about that. For example,
just before the end of your process:

assert (NOT ENDFILE(inp1)) or (NOT ENDFILE(inp2))
report "Input data exhausted - NORMAL SIMULATION STOP"
severity FAILURE;

HTH

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

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

I like to use an "ENDSIM" master control signal that turns the clock
off, which is controlled by either all stimulus and outputs complete,
or'd with another control called "KILLSIM", which basically acts as a
timeout on the testbench, which can help to show when the design is
stuck and prevent modelsim from running forever.

clk_proc : process
variable end_time : time;
begin
while not ENDSIM loop
if clk /= '0' then
clk <= '0';
else
clk <= '1';
end if;

if NOW >= TIMEOUT*CLK_PERIOD then
KILLSIM <= true;
end if;

wait for CLK_PERIOD/2;
end loop;

if KILLSIM then
report "Simulation Timed Out after " & integer'image(TIMEOUT) & "
clock cycles."
severity warning;

else
end_time := NOW;

report "Simulation ended successfully after " &
time'image(end_time)
severity note;

end if;

wait;
end process;

ENDSIM <= KILLSIM
or (and_reduce(endsim_ip & endsim_op) = '1');

 

[HT-Lab]

Alternatively, force the clock(s) to stop. The simulation will stop when
there are no more scheduled transactions.

In the current Modelsim and I believe ActiveHDL you can use the new standard
VHDL env package subprogram STOP/FINISH, example:

library std;
use std.env.all;

-- 0 prints nothing
-- 1 prints simulation time and location
-- 2 prints simulation time, location, and statistics about
-- the memory and CPU times used in simulation

STOP(1);

Which will result in a clean simulation stop:

# ** Note: stop
# Time: 360 ns Iteration: 0 Instance: /test_tb

Hans.
www.ht-lab.com

 

[Andy]

Alternatively, force the clock(s) to stop. The simulation will stop when
there are no more scheduled transactions.

So long as you don't have behavioral models in your testbench that
schedule events on their own!

I had a wait until... for... statement that scheduled an event for
the timeout. The simulation kept going until that timeout event, even
though the condition had been true and the wait statement had
triggered long before. Of course with no events between when the clock
stopped and the timeout, simulation time advanced very rapidly!

Andy

 

[koyel.aphy]

I generally force the simulation to stop by using break key. I have a
signal called output enable that remains high only during the valid
output data so even if the simulation runs for more time than it
should, I do not get the outputs beyond the valid data. However, I
have encountered one strange behaviour that when I simulate the test
bench, it stops after reading 98 inputs whereas it should read
all(2048 in my case) and then when I click the run all command from
the simulator window, it works normally and gives the result. This is
true for both modelsim and ISE simulator. Can you explain why this is
happenning? If I have a smaller design of the same unit that reads 16
lines then I do not encounter this problem.