CODEWITHSUNDEEP
variablessignalsvhdl
erwindenboer
erwindenboer

Reputation: 171

Why won't a signal be updated instantly in process statement? VHDL

In VHDL, you need to use a variable in a process statement for it to be updated instantaneously. The use of a signal can be done, but it won't be updated immediately. Repeating my question from above: Why won't a signal be updated instantly in process statement?

Upvotes: 1

Views: 1942

Answers (2)

Jim Lewis
Jim Lewis

Reputation: 3973

The short answer is the VHDL execution model. The VHDL execution model does a simulation cycle in two separate steps: Update and then Execution. A limited perspective (there are many details that I have abstracted away) of the a simulation cycle is:

  • During the update phase all signals that will be updated during a simulation cycle are.
  • When signals are updated and change, processes that are sensitive to a signal changing are marked for execution.
  • Execute statements and processes that were marked for execution until they encounter either a wait statement or loop back to the process sensitivity list (and the process has one).

Your question is why do this? It guarantees that every compliant VHDL simulator executes the same code with exactly the same number of simulation cycles and produces the exact same result.

To understand why it would be problematic if signals updated instantaneously, consider the following code:

proc1 : process(Clk)
begin
  if rising_edge(Clk) then
    Reg1 <= A ;
  end if ; 
end process ; 

proc2 : process(Clk)
begin
  if rising_edge(Clk) then
    Reg2 <= Reg1 ; 
  end if ; 
end process ;

In the above code, if signals updated instantaneously like variables, and the processes ran in the order proc1 then proc2, then in the simulator we would see 1 flip-flop for A to be received by Reg2. OTOH, if the processes ran in the order proc2 then proc1, then in the simulator we would see 2 flip-flops for A to be received by Reg2.

This is also why shared variables of an ordinary type in VHDL were only introduced temporarily in 1993 and removed in 2000 when a more appropriate feature was able to be introduced (shared variables of a protected type).

Upvotes: 2

DomasAquinas
DomasAquinas

Reputation: 331

Because a signal is designed to behave like a physically implemented value in the hardware, it only updates in response to determined stimuli and according to the progression of time.

In VHDL, this is reflected in that a signal assignment statement does not itself update the value of a signal. Rather, it schedules a transaction to occur on that signal that, when the appointed time comes, will trigger an event on the signal to change its value (if the assignment is to a changed value).

The default scheduling for a transaction is after a delta-delay in simulation, i.e. a simulation time instant just after all concurrently executing processes at that time complete. So if I'm operating in a clocked process and I update a signal value in a process triggered by rising_edge(clk), the new value won't be accessible within that current run of the process but will update just after the rising edge of the clock, when the process is complete.

This difference exists because VHDL is a hardware description language, not a programming language. Designs therefore must take into account the realities of hardware operation - the progression of time, the need for causal stimuli, &c. Thus in a good VHDL design, any value meant to persist through time will be defined as a signal so that the design takes into account that it ought to behave like a section of hardware. Within a process, a variable can provide an intermediate value for use in a combinatorial calculation - the synthesizer will determine whatever logic is necessary to accomplish that job, but the variable as a language element is a tool for calculations, not a way to define persistent values. Of course, variable abuse is possible and does exist... :^)

Upvotes: 1

Related Questions