Behavioral Style Combinational Design with VHDL IAY 0600 Digital Systems Design Alexander Sudnitson Tallinn University of Technology

Dataflow style half-adder description library ieee; use ieee.std_logic_1164. all; entity half_adder is port (a, b : in std_logic; sum, carry_out : out std_logic); end half_adder; architecture data_flow of half_adder is begin sum <= a xor b ; -- concurrent signal assignment carry_out <= a and b ; -- concurrent signal assignment end data_flow; Signal assignment statement placed in the statement part of an architecture is a concurrent statement.

Behavioral style half-adder coding entity half_adder is port (a, b : in std_logic; sum, carry: out std_logic); end half_adder; architecture behavior of half_adder is begin ha: process (a, b) if a = ‘1’ then sum <= not b ; carry <= b ; --sequential signal assignments else sum <= b ; carry <= ‘0’ ; end if; end process ha ; end behavior ; We can have different architectures associated with the same entity declaration, creating different design entities.

Behavioral style features A behavioral style architecture uses algorithms in the form of sequential programs. These sequential programs are called processes. The statement part of a behavioral style architecture consists of one or more processes. Each process statement is, in its entirety, a concurrent statement. Process communicate with each other, and with other concurrent statements, using signals. Statements inside a process are sequential statements. They are executed in sequence and their order is critical to their effect. Sequential control statements select between alternative statement execution paths.

Process communication (full adder example) In this example, three processes are communicating, using signals (s1, s2, s3), to implement a full adder. Process communication using signals is similar to the way components in a structural description communicate (are connected).

Full adder in behavioral style library ieee; use ieee.std_logic_1164. all; entity full_adder is port (a, b, carry_in : in std_logic; sum, carry_out : out std_logic); end full_adder; architecture processes of full_adder is signal s1, s2, s3 : std_logic; -- Signals to interconnect begin -- Each process is a concurrent statement ha1: process (a, b) -- ha1 process begin if a = ' 1 ' then s1 <= not b ; s2 <= b ; else s1 <= b ; s2 <= 0 ; end if; end process ha1;

Full adder in behavioral style (cont) ha2: process (s1, carry_in) -- ha2 process begin if s1 = ' 1 ' then sum <= not carry_in ; s3 <= carry_in ; else sum <= carry_in ; s3 <= ' 0 ' ; end if; end process ha2 ; or1: process (s3, s2) -- or1 process if ( s3 = ' 1 ' ) or ( s2 = ' 1 ' ) then carry_out = ' 1 ' ; else carry_out = ' 0 ' ; end process or1 ; end processes

Process statement A process statement is a concurrent statement that itself is comprised of sequential statements. No signals can be declared in a process. A process with a sensitivity list must not contain any wait statements. A process without a sensitivity list must contain at least one wait statement, or its simulation will never end. A process can be viewed as an infinite loop whose execution is repeatedly suspended and resumed.

Process statement and combinational logic Processes statements can be used to describe combinational or sequential systems. Two requirements for a process to synthesize to a combinational system are: The process’s sensitivity list must contain all signals read in the process. A signal or variable assigned a value in a process must be assigned a value in all possible executions of the process.

Parity Detector Example (non-)Synthesizing loops

Parity detector example (dataflow description) Output oddp is asserted when the number of 1s in the input vector is odd, otherwise it is unasserted. library ieee; use ieee.std_logic_1164. all ; entity parity is port (din : in std_logic_vector (3 downto 0) ; oddp : out std_logic -- aserted for odd parity) ; end parity ; architecture dataflow of parity is begin oddp <= din (3) xor din (2) xor din (1) xor din (0) ; end dataflow ;

Simulation of dataflow style parity detrector The testbench sequences through all possible binary input combinations. Input vector din is diplayed as both a composite signal, whose value is expressed in hexadecimal, and in terms of its separate elements.

Behavioral parity detector (failed) description Architecture for parity detector written using a loop statement and a signal: architecture bihav_sig of parity is signal odd : std_logic ; begin po : pocess (din) odd <= ' 0 ' ; for index in 3 downto 0 loop odd <= odd xor din (index) ; end loop ; end process ; oddp <= odd ; end behav_sig ;

Behavioral parity detector (failed) description Architecture for parity detector written using a loop statement and a signal: architecture bihav_sig of parity is signal odd : std_logic ; begin po : pocess (din) odd <= ' 0 ' ; for index in 3 downto 0 loop odd <= odd xor din (index) ; end loop ; end process ; oddp <= odd ; end behav_sig ;

Simulation of previous parity detector description Waveforms from simulation of parity detector written using a loop and a signal. The simulation resulted in oddp always having the value ‘ U ’.

XOR function in STD logic -- truth table for "xor" function CONSTANT xor_table : stdlogic_table := ( -- ---------------------------------------------------- -- | U X 0 1 Z W L H - | | ( 'U', 'U', 'U', 'U', 'U', 'U', 'U', 'U', 'U' ), -- | U | ( 'U', 'X', 'X', 'X', 'X', 'X', 'X', 'X', 'X' ), -- | X | ( 'U', 'X', '0', '1', 'X', 'X', '0', '1', 'X' ), -- | 0 | ( 'U', 'X', '1', '0', 'X', 'X', '1', '0', 'X' ), -- | 1 | ( 'U', 'X', 'X', 'X', 'X', 'X', 'X', 'X', 'X' ), -- | Z | ( 'U', 'X', 'X', 'X', 'X', 'X', 'X', 'X', 'X' ), -- | W | ( 'U', 'X', '0', '1', 'X', 'X', '0', '1', 'X' ), -- | L | ( 'U', 'X', '1', '0', 'X', 'X', '1', '0', 'X' ), -- | H | ( 'U', 'X', 'X', 'X', 'X', 'X', 'X', 'X', 'X' ) -- | - | );

How a RTL synthesizer synthesizes a loop The synthesizer unrolls the loop to create the sequence of statements that corresponds to the complete execution of the loop. One copy of the sequence of statements inside the loop is created for each loop iteration. In each copy, the loop parameter is replaced by its value for that loop iteration. The loop is replaced by the statements created by unrolling the loop (behavior is not changing). for index in 3 downto 0 loop odd <= odd xor din (index) ; end loop ; odd <= '0' ; odd <= '0' ; odd <= odd xor din (3) ; odd <= odd xor din (2) ; odd <= odd xor din (1) ; odd <= odd xor din (0) ;

How a RTL synthesizer synthesizes a loop Since odd is a signal, the assignment of a value to it does not take affect until the process suspends. As a result, only the last assignment to odd before the process suspends is meaningful. odd <= odd xor din (0) ; Accordingly, the synthesizer synthesizes next logic:

Explanation of simulation result From last assignment statement < odd <= odd xor din (0); > it is clear why the simulation resulted in oddp always having the value ‘ U ’. At initialization, odd is given the value ‘ U ’. After the process suspends odd is assigned ‘ U ’ xor din (0), which evaluates to ‘ U ’ (look the next slide). Thus the process always computes the value ‘ U ’ for odd (that is assigned than to oddp).

Signals versus Variables Signals in an architecture: Retain their values between executions of a process. The assigned value takes effect at the update phase of the next simulation cycle. The signal’s value is not changed during the current simulation cycle. Variables in an architecture Retain their values between executions of the process in which they are declared. When a variable assignment statement is executed, the variable takes its new value immediately. Statements in the process that follow the variable assignment statement see its new value.

Solution of the problem We need each assignment to odd to take immediately. Thus, we need to use variable to store the value of odd. Look the next slide: the design description is modified by replacing the signal declaration for in the declarative part of the architecture body with a variable declaration for odd in the declarative part of the process. The Sequence of sequential assignments made to variable odd: odd := ' 0 ' ; odd := odd xor din (3) ; odd .= odd xor din (2) ; odd := odd xor din (1) ; odd := odd xor din (0) ; Since assignments take effect immediately, the algorithm work as desired

Using variables Architecture for parity detctor written using a loop and variable: architecture bihav_var of parity is begin po : pocess (din) variable odd : std_logic; -- declare a variable odd := ' 0 ' ; for index in 3 downto 0 loop odd := odd xor din (index) ; end loop ; oddp <= odd ; end process ; end behav_var ; default value

Synthesis of processes Logic resulting from synthesis using the architecture written with a loop and variable odd := ' 0 ' ; odd := xor din (3) ; odd .= xor din (2) ; odd := xor din (1) ; odd := xor din (0) ;

Loops that cannot be synthesized To synthesize a loop, a RTL synthesizer must unroll the loop. This requires that the number of loop iterations be known during synthesis. Thus a for loop with constant bounds can be synthesized. If a variable were used in specifying the loops range bounds (nonconstant bounds), the synthesizer could not statically determine the number of loop iterations. Also a synthesizer cannot statically determine the number of loop iterations of a while loop, since completion of a while loop is dependent on data generated during the loop’s execution. Synthesis tools vary but generally a loop can be synthesized so long as the number of iterations is known to the synthesis tool. (While loops are supported by some logic synthesis tools, with certain restrictions).

Avoiding latches To ensure that the logic synthesized from a process is combinational, all signals and vatiables assigned a value in the process must be assigned a value each time the process executes. If this requirement is not met, latches may be inferred. To insure this requirement is met it might be helpful to assign a default value at the beginning of the process to each signal or variable that is assigned values later in the process.