Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
Announcements
All support for Intel NUC 7 - 13 systems has transitioned to ASUS. Read latest update.
16497 Discussions

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

JOHI
New Contributor II
1,400 Views

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.

0 Kudos
1 Solution
Tricky
New Contributor II
570 Views
  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?

 

 

View solution in original post

0 Kudos
3 Replies
JOHI
New Contributor II
570 Views

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?

 

 

0 Kudos
Tricky
New Contributor II
571 Views
  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?

 

 

0 Kudos
JOHI
New Contributor II
570 Views

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.

0 Kudos
Reply