Forum Discussion

JOHI's avatar
JOHI
Icon for Contributor rankContributor
7 years ago
Solved

Sharing of signals over different processes in modelsim not working as expected ?

Hello,

For my test bench I have created a test bench with 3 separate processes.

The first process generates a clock.

The second process sets a signal " enable_clock" after reading a file with stimulae.

The third process waits for the flag "Enable_clock" to continue.

Although "Enable_clock" is set, the third process keeps on waiting on the line:

wait until enable_clock='1';

....

I verified this fact with breakpoints and with the "wave" display window: enable_clock is '1' but my process simulation is not moving forward.

Any help is appreciated.

Best Regards,

Johi.

  • Tricky's avatar
    Tricky
    7 years ago
    1. That is because enable_clock is set to '1' after the first falling edge of the clock, and it remains at '1'.

    The thrid process (main_data_gen) is waiting for enable_clock to toggle to '1' after the second clock. But it already at '1', and hence waits forever.

    Wait until is triggered by a 'event on the sensitivy list (the signals you are waiting for).

    the workaround is to do this:

    if enable_clock /= '1' then
  wait until enable_clock = '1';
end if;

    2. Now to comment on the code. Why are you manually waiting for edges on the clock? VHDL has the build in functions rising/falling_edge, so its usually much better to use those on the code, and is more readable. in addition, use loops to wait for a defined number of clocks:

    for i in 1 to 10 loop  -- wait for 10 clocks
  wait until rising_edge(clk);
end loop;

    or even better, in some tools package, define a procedure to wait for a specified number of clocks (its a pretty standard thing to want to do in any testbench:

    procedure wait_for_clks( constant n   :    integer;
                         signal   clk : in std_logic ) is
begin
  for i in 1 to n loop
    wait until rising_edge(clk);
  end loop;
end procedure;
 
.......
 
process
begin
  ......
  wait_for_clks(10, clk);
end process;

    3. Next, if you want a process to halt, putting wait until 0=1; will wait forever, but its a fairly nonsense piece of code. Why not simply write "wait", as a single wait will wait forever

    stim_proc : process
begin
  ....do something
  wait_for_clks(10, clk);
  .. do something else
  wait;    -- waits forever;
end process;

    4. For the PSD_data_table, why not set the values in an initialisation function, rather than assign them in a process?

3 Replies

  • JOHI's avatar
    JOHI
    Icon for Contributor rankContributor
    7 years ago

    Additional info:

    - If I add a sensitivity list:

    => Error: A wait statement is illegal for a process with a sensitivity list. (Modelsim)

    - If I remove sensitivity list:

    => Warning: Wait statement has no sensitivity list or time out clause; (Modelsim)

    workaround / solution I found:

    loop

    wait until CLOCK_50='1';

    wait until CLOCK_50='0';

    if ENABLE_CLOCK='1' then

    exit;

    end if;

    end loop;

    That my code cannot be compiled into hardware is obvious.

    But since we are in simulation, i would assume that:

    wait until CLOCK_50='1';

    wait until CLOCK_50='0';

    wait until ENABLE_CLOCK='1';

    would do the same trick.

    So I remain with the question what the proper way to share non clock signals over simulation processes in wait statements is?

  • Tricky's avatar
    Tricky
    Icon for Occasional Contributor rankOccasional Contributor
    7 years ago
    1. That is because enable_clock is set to '1' after the first falling edge of the clock, and it remains at '1'.

    The thrid process (main_data_gen) is waiting for enable_clock to toggle to '1' after the second clock. But it already at '1', and hence waits forever.

    Wait until is triggered by a 'event on the sensitivy list (the signals you are waiting for).

    the workaround is to do this:

    if enable_clock /= '1' then
  wait until enable_clock = '1';
end if;

    2. Now to comment on the code. Why are you manually waiting for edges on the clock? VHDL has the build in functions rising/falling_edge, so its usually much better to use those on the code, and is more readable. in addition, use loops to wait for a defined number of clocks:

    for i in 1 to 10 loop  -- wait for 10 clocks
  wait until rising_edge(clk);
end loop;

    or even better, in some tools package, define a procedure to wait for a specified number of clocks (its a pretty standard thing to want to do in any testbench:

    procedure wait_for_clks( constant n   :    integer;
                         signal   clk : in std_logic ) is
begin
  for i in 1 to n loop
    wait until rising_edge(clk);
  end loop;
end procedure;
 
.......
 
process
begin
  ......
  wait_for_clks(10, clk);
end process;

    3. Next, if you want a process to halt, putting wait until 0=1; will wait forever, but its a fairly nonsense piece of code. Why not simply write "wait", as a single wait will wait forever

    stim_proc : process
begin
  ....do something
  wait_for_clks(10, clk);
  .. do something else
  wait;    -- waits forever;
end process;

    4. For the PSD_data_table, why not set the values in an initialisation function, rather than assign them in a process?

  • JOHI's avatar
    JOHI
    Icon for Contributor rankContributor
    7 years ago

    Hello Tricky,

    High appreciation for you analysis: Following Your comments:

    1. AFIK, Vhdl does not support "wait until" statements & parameters in the process sensitivity list, so solving the issue using an explicit process sensitivity list is was a dead end.

    Your workaround for this property is very nice. I tried it; it works, this solution I would not have found myself. An alternative solution elaborating on and confirming your analysis: wait until (enable_clock and CLOCK_50) = '1' this also seems to work; "wait until" is evaluated each time "clock_50" changes.

    2. Your solution is better. I have a C++ background, my old habbit is not completely dead yet for code that does not end up in an FPGA. I modified my code in line with your remarks. I also see speed improvements during simulation.

    3. "Wait" was something I have been looking for but did not come across yet. Thanks.

    4. The values in the .mif are generated by an .xls script. They will also be used in a second FPGA (DE2-115) I use it as a wave generator for the main FPGA (DE10-STD). I generate a complex wave form that will finally come out of a rotating wheel in front of a PbS sensor. I could generate a .vhd the same way I generate the .Mif file of course but if you try nothing you learn nothing.

    Best regards,

    Johi.