simulation differences in modelsim

Discussion in 'VHDL' started by koyel.aphy@gmail.com, Jun 15, 2008.

  1. Guest

    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 :pROCESS
    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;
    , Jun 15, 2008
    #1
    1. Advertising

  2. Guest

    On Jun 16, 10:25 pm, Jonathan Bromley <>
    wrote:
    > 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
    > ://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
    , Jun 17, 2008
    #2
    1. Advertising

  3. jtw Guest

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

    JTW

    "Jonathan Bromley" <> wrote in message
    news:...
    > 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
    >
    > http://www.MYCOMPANY.com
    >
    > The contents of this message may contain personal views which
    > are not the views of Doulos Ltd., unless specifically stated.
    jtw, Jun 18, 2008
    #3
  4. Tricky Guest

    On 18 Jun, 05:16, "jtw" <wrightjt @hotmail.invalid> wrote:
    > Alternatively, force the clock(s) to stop. The simulation will stop when
    > there are no more scheduled transactions.
    >
    > JTW
    >
    > "Jonathan Bromley" <> wrote in message
    >
    > news:...
    >
    > > 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
    > >
    > >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');
    Tricky, Jun 18, 2008
    #4
  5. HT-Lab Guest

    "jtw" <wrightjt @hotmail.invalid> wrote in message
    news:XZ%5k.1918$...
    > 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
    HT-Lab, Jun 18, 2008
    #5
  6. Andy Guest

    On Jun 17, 11:16 pm, "jtw" <wrightjt @hotmail.invalid> wrote:
    > 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
    Andy, Jun 19, 2008
    #6
  7. Guest

    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.
    , Jun 19, 2008
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Manfred Balik

    VHDL Simulation in ModelSim

    Manfred Balik, Jul 15, 2003, in forum: VHDL
    Replies:
    0
    Views:
    1,723
    Manfred Balik
    Jul 15, 2003
  2. Ouadid
    Replies:
    7
    Views:
    10,191
    Jim Wu
    Dec 18, 2003
  3. The Eclectic Electric
    Replies:
    4
    Views:
    2,130
    Rincewind
    Sep 11, 2005
  4. Home_Job_opportunity
    Replies:
    0
    Views:
    480
    Home_Job_opportunity
    Jan 8, 2009
  5. Home_Job_opportunity
    Replies:
    0
    Views:
    564
    Home_Job_opportunity
    Jan 14, 2009
Loading...

Share This Page