architecture A of E is begin P1 : process begin -- sequential statements end process P1; -- C2: concurrent statements P2 : process begin -- sequential statements end process P2; -- C1: concurrent statements end A;
An architecture can contain processes and concurrent statements which are all active in parallel. The connection of the parallel parts is established via signals and sensitivity lists. Concurrent statements can be interpreted as functionally equivalent processes with a sensitivity list containing all those values that are going to be read in this process. If, for example, the process P1 was triggered, e.g. by a clock edge, its statements are executed one after another. This way it is possible to execute parts of the code only after an active edge has occurred.
Let us assume that a couple of signals were modified. The changes will not take effect until the process execution has finished. According to the schematic, these updated values will trigger C1 and P1 which will trigger P1 and C2 in turn, and so on.
The execution of the statements continues until a stable state is reached, i.e. no events are generated any more.
architecture CONCURRENT of MULTIPLE is signal A, B, C, D : std_ulogic; signal Z : std_logic begin Z <= A and B; Z <= C and D; end CONCURRENT;
architecture SEQUENTIAL of MULTIPLE is signal Z, A, B, C, D : std_ulogic; begin process (A, B, C, D) begin Z <= A and B; Z <= C and D; end process; end SEQUENTIAL;
If the same two signal assignments appear in the VHDL code, once as concurrent statement in the architecture and once in a process, the result will differ substantially:
The signal update mechanism is essential for a VHDL simulator. Signals possess a past, a current and a future value within the simulators signal management functions. Signal assignments in a process always assign the value to the future value of the signal.
The future value is copied to the current value in the signal update phase after the process execution is finished i.e. the process is suspended.
Several process calls at one signal moment of the simulation are possible?
Several process calls at one single moment of the simulation are possible!
A simulation cycle always consists of a signal update and a process execution phase. Several of these so called delta cycles may have to be carried out in order to achieve a stable state of the system. The number of delta cycles has no effect on the time in the simulated time frame! It just affects the time that is necessary to carry out the simulation. The delta cycles are lined up orthogonally to the simulation time.
At the beginning, all signals are updated and a list of all processes that are triggered by the signal changes is created. All the processes of this list are executed one after another in delta cycle 1. When the execution is finished, the signal updates will be carried out and a new process list will be created. This continues until the process list remains empty, that means no further processes are triggered by the signal events. Now, statements which induce a real time step (’wait for …’, ’… after …’) are carried out and the simulation time advances for the specified amount of time.
library IEEE; use IEEE.Std_Logic_1164.all; entity DELTA is port (A, B : in std_ulogic; Y, Z : out std_ulogic); end DELTA;
architecture EXAMPLE of DELTA is signal X : std_ulogic; begin process (A, B, X) begin Y <= A; X <= B; Z <= X; end process; end EXAMPLE;
Let us assume that the value of signal B changes. In the example, the process is triggered by this event on B and is activated for the first time. The future value of X is given the current value of B. At the end of the process, the future value of X is transferred to its current value.
This change of value on X results in an event that calls the process for the second time. Now, the current value of X is written to the future value of Z (B and X remain the same). During the signal update phase only Z’s value changes which is not listed in the sensitivity list, i.e. the process will not be called again. The signals X and Z are set to the value from B this way. This example is for demonstrative purposes, only. The intermediate signal X conceals the functionality of the process and would not be used in practice. Generally, variables, which are not subject to the update mechanism, should be used instead.
process (A, B) begin if (A=B) then Z <= ‘1’; else Z <= ‘0’; end if; end process; | process begin if (A=B) then Z <= ‘1’; else Z <= ‘0’; end if; wait on A, B; end process; |
Basically, a process has to be considered as an endless loop.
The continuous process execution can be interrupted via wait statements. The use of a sensitivity list is equivalent to a WAIT ON-statement. If a sensitivity list is present, WAIT statements must not appear in the process.
postponed process begin Z <= ‘0’ ; -- wrong wait for 0 ns; Z <= ‘1’ ; -- wrong wait on A, B; -- wrong end process;
postponed process (A, B) begin if (A=B) then Z <= ‘1’ after 5 ns; else Z <= ‘0’ after 4 ns; end if; end process;
Postponed processes are always carried out in the last delta cycle.
This means that this process can access already stable signals at this point of simulation time.
In postponed processes, WAIT statements with 0 ns and signal assignments without delay are not permitted.
Please note that postponed processes can only be used in simulation, not in synthesis.