# Two VHDL process statements reading the same signal and one modifying it

Lets say we have two process statements in VHDL both reacting on the same clock edge.

Beside the clock we also have for example the reset signal. I know that only one process can modify the reset signal otherwise we get multiple drivers error.

Now lets assume one of the processes is modifying the signal and the other one is reading it. Which will evaluate first. Or in otherwords will the signal change be triggered in both processes and the code will work as expected ?

To clarify here is the VHDL code.

-- First process
process (clk, reset)
begin
if rising_edge(clk) and reset= '1' then
-- do work
end if;
end process;

-- Second process
process (clk)
begin
if rising_edge(clk) then
case reset is
when '1' => reset <= '0';
when '0' => reset <= '1';
end case;
end if;
end process;


The code is hypotetical and totaly irrelevant. But will the first process execute on every other clock or not.

Based on a test this will happen. But can I assume this will always happen or not.

There are a number of nuances that come into play here.

1. VHDL simulation is divided into a signal update phase and a run phase. The signal update phase always finishes before the run phase starts.
2. Signal assignments get evaluated during a run phase, but never update until the next signal update phase. If there is no delay placed on the signal, the signal will be scheduled to update on the next delta cycle (zero in wall clock time, but is there for ordering). If there is an after with a time value greater than 0 ns, then the signal will be scheduled to update on the first execution of the simulation time = current time + after time value.

Hence, your reset signal will update one delta cycle after clock. The "do work" portion of your process will see reset exactly one clock cycle after the clock cycle on which it was set. The VHDL simulation model is rock solid stable, so there will not be any uncertainty about how this particular process runs (like suggested by @MaximGi).

In a hardware design, you have put a flip-flop on reset and then fed that signal to other pieces of your design.

From a synthesis portability perspective, I caution you against putting any other logic in the same if condition as the clock. I would instead recommend re-writing your process as the following. Note your process is correct for simulation, it is just that some of the synthesis tools are fussy.

-- First process
process (clk)
begin
if rising_edge(clk) then
if reset= '1' then
-- do work
end if ;
end if;
end process;


Also there is no need for reset on this sensitivity list since rising_edge(Clk) will only be true on the exact delta cycle in which clock changes. You only need reset on a sensitivity list when you use asynchronous reset.

Processes work in parallel in vhdl. So if you happen to materially (pressing the button) set reset to '1', it will be set to '0' by process 2 at the next rising edge and the chance that the 'do work' instructions in process 1 are executed are totally random, you should not use this design, it is unstable. I guess the chance will be higher that process 1 executes first since it's triggered by both clock and reset while process 1 is triggered only by clock. However, I still suggest you change your design and put the "reset's reset" instructions in the same process for stability.

• What you say is not true for VHDL as it has a stable execution model. OTOH, you might be confused if you have used Verilog as it does have numerous races conditions (while VHDL only has a few and this is not one of them). Hence, there is no cause for concern here. Think like a synthesis tool, draw the picture for each process, and then connect them together. See my longer response below. – Jim Lewis Feb 19 '16 at 18:15
• You're probably right, then I'm sorry if I misled anyone. But I still would not implement this materially while it's possible to make it single process and less questionable. – MaximGi Feb 20 '16 at 14:35
• One simple rule in VHDL: Every signal assignment in a clocked process (such as above) always creates a flip-flop. No need to worry about whether it is one process or many. And definitely never anything questionable about it. In fact, historically we coded in many processes due to synthesis tool limitations at the time. – Jim Lewis Feb 20 '16 at 15:47
• going further, even in your single process approach, there are still separate processes in separate entities and these are no different than having multiple processes in a single entity. Hence, for any design of any size, you will indeed use more than one process - hence, thank goodness there is nothing questionable about it. :) – Jim Lewis Feb 20 '16 at 15:50