8 Register, Multiplexer and

Transcription

1 8 Register, Multiplexer and Three-State Inference HDL Compiler can infer Registers (latches and flip flops) Multiplexers Three state gates This chapter discusses methods of inferring different types of registers, multiplexers and three state devices in the following sections and subsection Register Inference Using Register Inference Describing Latches Describing Flip flops Additional Types of Register Inference Attributes Efficient Use of Registers

2 Multiplexers New VHDL Attribute New Variables for Multiplexer Inference Uses of Variables and Attributes New Inference Report Example of Multiplexer Inference and its Corresponding Inference Report Three State Inference Assigning the Value Z Latched Three State Variables Register Inference A register is a simple, one-bit memory device, either a flip-flop or a latch. A flip-flop is an edge-triggered memory device. A latch is a level-sensitive memory device. VHDL Compiler performs register inferencing using the wait and if statements. Use the wait statement to imply flip-flops in a synthesized circuit. VHDL Compiler creates flip-flops for all signals and some variables assigned values in a process with a wait statement. The if statement can be used to imply registers (flip-flops or latches) for signals and variables in the branches of the if statement.

3 Using Register Inference This section describes several elements needed to use the register inference capability of VHDL Compiler. Examples are provided of how to describe clocked signals and when to use wait or if statements. This section also describes recommended models for different types of inferred registers, as well as several restrictions on register inference capabilities. Use the wait and if statements to test for the rising or falling edge of a signal. The most common usages are process wait until (edge); process (sensitivity_list) if (edge)... Another form is process (sensitivity_list) if (...) then... elsif (...)... elsif (edge) then...

4 edge refers to an expression that tests for the positive or negative edge of a signal. The syntax of an edge expression is SIGNAL event and SIGNAL = 1 rising edge NOT SIGNAL stable and SIGNAL = 1 rising edge SIGNAL event and SIGNAL = 0 falling edge NOT SIGNAL stable and SIGNAL = 0 falling edge In a wait statement, edge can also be signal = 1 rising edge signal = 0 falling edge An edge expression must be the only condition of an if or an elsif. You can have only one edge expression in an if, and the if must not have an else clause. An edge expression cannot be part of another logical expression nor used as an argument. if (edge and RST = 1 ) Illegal usage; edge must be only condition Any_function(edge); Illegal usage; edge cannot be an argument if X > 5 then sequential_statement; elsif edge then sequential_statement; else sequential_statement; Illegal usage; do not use an else clause for not edge The lines above illustrate three incorrect uses. In the first group, the expression is part of a larger BOOLEAN expression. In the second group, the edge expression is used as an argument. In the third group, the edge expression is used as an intermediate condition.

5 wait vs. if Statements wait and if statements can sometimes be used interchangeably. The if statement is usually preferred, since it provides greater control over the inferred register s capabilities, as described in the next section. IEEE VHDL requires that a process with a wait statement cannot have a sensitivity list. An if edge statement in a process can occur anywhere in that process. The process sensitivity list must contain all signals read in the process, including the edge signal. In general, the following guidelines apply: Synchronous processes (processes that compute values only on clock edges) must be sensitive to the clock signal. Asynchronous processes (processes that compute values on clock edges and when asynchronous conditions are TRUE) must be sensitive to the clock signal (if any), and to inputs that affect asynchronous behavior. Recommended Use of Register Inference Capabilities The register inference capability can support coding styles other than those described here. However, for best results Restrict each process to a single type of memory-element inferencing: latch, latch with asynchronous set or reset, flip-flop, flip-flop with asynchronous reset, or flipflop with synchronous reset. Use the following templates LATCH: process(sensitivity_list) if LATCH_ENABLE then...

6 LATCH_ASYNC_SET:... attribute async_set_reset of SET : signal is true ;... process(sensitivity_list) if SET then Q <= 1 ; elsif LATCH_ENABLE then... FF: process(clk) if edge then... FF_ASYNC_RESET: process(reset, CLK) if RESET then Q <= 0 ; elsif edge then Q <=...; FF_SYNC_RESET: process(reset, CLK) if edge then if RESET then Q <= 0 ; else Q <=...; For examples of these templates see Describing Latches and Describing Flip-flops, later in this chapter.

7 Restrictions on Register Capabilities Do not use more than one if edge expression in a process. process(clk_a, CLK_B) if(clk_a event and CLK_A = 1 ) then A <= B; if(clk_b event and CLK_B = 1 ) then Illegal C <= B; Do not assign a value to a variable or signal on a FALSE branch of an if edge statement. To make such an assignment is equivalent to checking for the absence of a clock edge, which has no hardware counterpart. process(clk) if(clk event and CLK = 1 ) then SIG <= B; else SIG <= C; Illegal If a variable is assigned a value inside an edge construct, do not read that variable later in the same process. process(clk) variable EDGE_VAR, ANY_VAR: STD_LOGIC; if (CLK event and CLK = 1 ) then EDGE_SIGNAL <= X; EDGE_VAR := Y; ANY_VAR := EDGE_VAR; Legal ANY_VAR := EDGE_VAR; Illegal Do not use an edge expression as an operand. if not(clk event and CLK = 1 ) then Illegal

8 Delays in Registers Using delay specifications with values that are registered can cause the simulation to behave differently from the logic synthesized by VHDL Compiler. For example, the description in Example 8 1 contains delay information that causes Design Compiler to synthesize a circuit that behaves unexpectedly (i.e., post synthesis simulation results do not match pre synthesis simulation results). Example 8 1 Delays in Registers component flip_flop ( D, clock: in std_logic; Q: out std_logic;); end component; process ( A, C, D, clock ); signal B: std_logic; B <= A after 100ns; F1: flip_flop port map ( A, C, clock ), F2: flip_flop port map ( B, D, clock ); In Example 8 1, B changes 100 nanoseconds after A changes. If the clock period is less than 100 nanoseconds, output D is one or more clock cycles behind output C when the design is simulated. However, because VHDL Compiler ignores the delay information, A and B change values at the same time, and so do C and D. This behavior is not the same as in the post synthesis simulation. When using delay information in your designs, make sure that the delays do not affect registered values. In general, you can safely include delay information in your description if it does not change the value that gets clocked into a flip-flop.

9 Describing Latches VHDL Compiler infers latches from incompletely specified conditional expressions. For example, the following if statement infers a latch because there is no else clause: Example 8 2 Latch Inference process(gate, DATA) if (GATE = 1 ) then Q <= DATA; Figure 8 1 Latch Inference The inferred latch uses CLK as its clock and DATA as its data input, as shown in Example 8 2.

10 Automatic Latch Inferencing A signal or variable that is not driven under all conditions becomes a latched value. As shown in Example 8 3, TEMP becomes a latched value because it is assigned only when PHI is 1. Example 8 3 Automatically Inferred Latch if(phi = 1 ) then TEMP <= A; Figure 8 2 Automatically Inferred Latch To avoid having a latch inferred, assign a value to the signal under all conditions, as shown in Example 8 4. Example 8 4 Fully Specified Signal: No Latch Inference if (PHI = 1 ) then TEMP <= A; else TEMP <= 0 ; Figure 8 3 Fully Specified Signal: No Latch Inference

11 Restrictions on Latch Inference Capabilities You cannot read a conditionally assigned variable after the if statement in which it is assigned. A conditionally assigned variable is assigned a new value under some, but not all, conditions. That is, a variable must always have a value before it is read. signal X, Y: STD_LOGIC;... process variable VALUE: STD_LOGIC;; if (condition) then VALUE := X; Y <= VALUE; Illegal end; In simulation, latch inference occurs because signals and variables can hold state over time. A signal or variable holds its value until that value is reassigned. VHDL Compiler inserts a latch to duplicate this holding of state in hardware. Variables declared locally within a subprogram do not hold their value over time. Every time a subprogram is used, its variables are reinitialized. Therefore, VHDL Compiler does not infer latches for variables declared in subprograms. In Example 8 5 no latches are inferred.

12 Example 8 5 Function without Inferred Latch function MY_FUNC(DATA, GATE : STD_LOGIC) return STD_LOGIC is variable STATE: STD_LOGIC; if GATE then STATE := DATA; return STATE; end;... Q <= MY_FUNC(DATA, GATE); Figure 8 4 Function without Inferred Latch Example Design with Two-Phase Clocks The latch inference capability permits network structures such as two-phase systems to be described in a technology-independent manner. Example 8 6 shows a simple two-phase system with clocks PHI_1 and PHI_2. Example 8 6 Two Phase Clocks entity LATCH_VHDL is port(phi_1, PHI_2, A : in STD_LOGIC; t: out STD_LOGIC); end LATCH_VHDL; architecture EXAMPLE of LATCH_VHDL is signal TEMP, LOOP_BACK: STD_LOGIC; process(phi_1, A, LOOP_BACK) if(phi_1 = 1 ) then

13 TEMP <= A and LOOP_BACK; process(phi_2, TEMP) if(phi_2 = 1 ) then LOOP_BACK <= not TEMP; t <= LOOP_BACK; end EXAMPLE; Figure 8 5 Two Phase Clocks Design Compiler does not automatically infer dual-phase latches (devices with master and slave clocks). For these devices to be used, they must be instantiated as components. For more on how to do this, refer to Chapter 3, or to the HDL Coding Styles: Sequential Devices Application Note.

14 Describing Flip-flops Example 8 7 shows how an edge construct creates a flip-flop. Example 8 7 Inferred Flip-flop process(clk, DATA) if (CLK event and CLK = 1 ) then Q <= DATA; Figure 8 6 Inferred Flip-flop

15 Flip-flop with Asynchronous Reset Example 8 8 shows how to specify a flip-flop with an asynchronous reset. Example 8 8 Inferred Flip-flop with Asynchronous Reset process(reset_low, CLK, SYNC_DATA) if RESET_LOW = 0 then Q <= 0 ; elsif (CLK event and CLK = 1 ) then Q <= SYNC_DATA; Figure 8 7 Inferred Flip-flop with Asynchronous Reset Note how the flip-flop in Example 8 8 is connected. The D input of the flip-flop is connected to SYNC_DATA. If the reset condition is computable (see Computable Operands in Chapter 5), either the SET or CLEAR pin of the flip-flop is connected to the RESET_LOW signal, as shown in Example 8 8.

16 Example 8 9 shows an inferred flip-flop with an asynchronous reset, where the reset condition is not computable. If the reset condition (ANY_SIGNAL in Example 8 9) is not computable, SET is connected to (ANY_SIGNAL AND ASYNC_DATA) and CLEAR is connected to (ANY_SIGNAL AND NOT(ASYNC_DATA)), as shown in Example 8 9. Example 8 9 Inferred Flip-flop with Asynchronous Set or Clear process (CLK, ANY_SIGNAL, ASYNC_DATA, SYNC_DATA) if (ANY_SIGNAL) then Q <= ASYNC_DATA; elsif (CLK event and CLK = 1 ) then Q <= SYNC_DATA; Figure 8 8 Inferred Flip-flop with Asynchronous Set or Clear

17 Example Synchronous Design with Asynchronous Reset Example 8 10 describes a synchronous finite state machine with an asynchronous reset. Example 8 10 Synchronous Finite State Machine with Asynchronous Reset package MY_TYPES is type STATE_TYPE is (S0, S1, S2, S3); end MY_TYPES; use WORK.MY_TYPES.ALL; entity STATE_MACHINE is port(clk, INC, A, B: in STD_LOGIC; RESET: in BOOLEAN; t: out STD_LOGIC); end STATE_MACHINE; architecture EXAMPLE of STATE_MACHINE is signal CURRENT_STATE, NEXT_STATE: STATE_TYPE; SYNC: process(clk, RESET) if (RESET) then CURRENT_STATE <= S0; elsif (CLK event and CLK = 1 ) then CURRENT_STATE <= NEXT_STATE; end process SYNC; FSM: process(current_state, A, B) t <= A; Default assignment NEXT_STATE <= S0; Default assignment if (INC = 1 ) then case CURRENT_STATE is when S0 => NEXT_STATE <= S1; when S1 => NEXT_STATE <= S2; t <= B; when S2 => NEXT_STATE <= S3;

18 when S3 => null; end case; end process FSM; end EXAMPLE; Figure 8 9 Synchronous Finite State Machine with Asynchronous Reset B A CLK INC t RESET

19 Additional Types of Register Inference Attributes For examples of various type of latches and flip-flops that use the attributes and variables introduced in the following sections, see the HDL Coding Styles: Sequential Devices Application Note. This section discusses attributes used to assist register inference. The attributes are defined in the attributes package in the VHDL library called Synopsys. attribute async_set_reset : string; attribute sync_set_reset : string; attribute async_set_reset_local : string; attribute sync_set_reset_local : string; attribute async_set_reset_local_all : string; attribute sync_set_reset_local_all : string; attribute one_hot : string; attribute one_cold : string; async_set_reset async_set_reset is attached to single bit signals using the attribute construct. VHDL Compiler checks signals with the async_set_reset attribute set to true to determine whether they asynchronously set or reset a latch or flip flop in the entire design. The syntax of async_set_reset is attribute async_set_reset of signal_name,. : signal is true ; Latch with Asynchronous Set or Clear The asynchronous clear (or set) is inferred by driving the Q pin of your latch to 0 (1). Although VHDL Compiler does not require that the clear (or set) be the first condition in your conditional branch, it is best to write your VHDL in that manner.

20 Example 8 11 shows how to specify a latch with an asynchronous clear. Example 8 11 Inferred Latch with Asynchronous Clear attribute async_set_reset of clear : signal is true ; process(clear, gate, a) if (clear = 1 ) then q <= 0 ; elsif (gate = 1 ) then q <= a; Figure 8 10 Inferred Latch with Asynchronous Clear

21 sync_set_reset sync_set_reset is attached to single-bit signals using the attribute constructs. VHDL Compiler checks signals with the sync_set_reset attribute set to true to determine whether they synchronously set or reset a flip-flop in the entire design. The syntax of sync_set_reset is attribute sync_set_reset of signal_name,... : signal is true ; Flip-flop with Synchronous Reset Example 8 12 shows how to specify a flip-flop with a synchronous reset. Example 8 12 Inferred Flip flop with Synchronous Reset attribute sync_set_reset of RESET : signal is true ; process(reset, CLK) if (CLK event and CLK = 1 ) then if RESET = 1 then Q <= 0 ; else Q <= DATA_A; Figure 8 11 Inferred Flip-flop with Synchronous Reset

22 Note: Since the target technology library did not contain a synchronous reset flip flop, Design Compiler built the synchronous reset conditions using combinational logic. Flip Flop with Synchronous Set Example 8 13 shows how to specify a flip-flop with a synchronous set. Example 8 13 Inferred Flip Flop with Synchronous Set attribute sync_set_reset of SET : signal is true process (SET, CLK) if (CLK event and CLK = 1 ) then if SET = 1 then T <= 1 ; else T <= DATA_B; Figure 8 12 Inferred Flip Flop with Synchronous Set Note: Since the target technology library did not contain a synchronous set flip flop, Design Compiler built the synchronous set conditions using combinational logic.

23 async_set_reset_local async_set_reset_local is attached to the label of a process with a value of a double-quoted list of single-bit signals. Every signal in the list is treated as if it has the async_set_reset attribute attached in the specified process. The syntax of async_set_reset_local is attribute async_set_reset_local of process_label : label is signal_name,... ; Example 8 14 Asynchronous Set/Reset on a Single Block library IEEE; library synopsys; use IEEE.std_logic_1164.all; use synopsys.attributes.all; entity e_async_set_reset_local is port(reset, set, gate: in std_logic; y, t: out std_logic); end e_async_set_reset_local; architecture rtl of e_async_set_reset_local is attribute async_set_reset_local of direct_set_reset : label is reset, set ; direct_set_reset: process (reset, set) if (reset = 1 ) then y <= 0 ; asynchronous reset elsif (set = 1 ) then y <= 1 ; asynchronous set end process direct_set_reset;

24 gated_set_reset: process (gate, reset, set) if (gate = 1 ) then if (reset = 1 ) then t <= 0 ; gated data elsif (set = 1 ) then t <= 1 ; gated data end process gated_set_reset; end rtl; Figure 8 13 Asynchronous Set/Reset on a Single Block

25 sync_set_reset_local sync_set_reset_local is attached to the label of a process with a value of a double quoted list of single bit signals. Every signal in the list is treated as if it has the sync_set_reset attribute attached in the specified process. The syntax of sync_set_reset_local is attribute sync_set_reset_local of process_label : label is signal_name,... Example 8 15 Synchronous Set/Reset on a Single Block library IEEE; library synopsys; use IEEE.std_logic_1164.all; use synopsys.attributes.all; entity e_sync_set_reset_local is port(clk, reset, set, gate : in std_logic; y, t: out std_logic); end e_sync_set_reset_local; architecture rtl of e_sync_set_reset_local is attribute sync_set_reset_local of clocked_set_reset : label is reset, set ; clocked_set_reset: process (clk, reset, set) if (clk event and clk = 1 ) then if (reset = 1 ) then y <= 0 ; synchronous reset else y <= 1 ; synchronous set end process clocked_set_reset; gated_set_reset: process (clk, gate, reset, set) if (clk event and clk = 1 ) then if (gate = 1 ) then if (reset = 1 ) then t <= 0 ; gated reset elsif (set = 1 ) then

26 t <= 1 ; end process gated_set_reset; gated set end rtl; Figure 8 14 Synchronous Set/Reset on a Single Block set d2 z reset clk d1 y Note: Since the target technology library did not contain a synchronous set or a synchronous reset flip flop, Design Compiler built the synchronous set/reset conditions using combinational logic.

27 async_set_reset_local_all async_set_reset_local_all is attached to a process label. The attribute async_set_reset_local_all specifies that all the signals in the process are used to detect an asynchronous set or reset condition for inferred latches or flip-flops. The syntax of async_set_reset_local_all is attribute async_set_reset_local_all of process_label,... : label is true ; Example 8 16 Asynchronous Set/Reset on Part of a Design library IEEE; library synopsys; use IEEE.std_logic_1164.all; use synopsys.attributes.all; entity e_async_set_reset_local_all is port(reset, set, gate, gate2: in std_logic; y, t, w: out std_logic); end e_async_set_reset_local_all; architecture rtl of e_async_set_reset_local_all is attribute async_set_reset_local_all of direct_set_reset, direct_set_reset_too: label is true ; direct_set_reset: process (reset, set) if (reset = 1 ) then y <= 0 ; asynchronous reset elsif (set = 1 ) then y <= 1 ; asynchronous set end process direct_set_reset; direct_set_reset_too: process (gate, reset, set) if (gate = 1 ) then if (reset = 1 ) then t <= 0 ; asynchronous reset elsif (set = 1 ) then t <= 1 ; asynchronous set end process direct_set_reset_too;

28 gated_set_reset: process (gate2, reset, set) if (gate2 = 1 ) then if (reset = 1 ) then w <= 0 ; gated reset elsif (set = 1 ) then w <= 1 ; gated set end process gated_set_reset; end rtl; Figure 8 15 Asynchronous Set/Reset on Part of a Design

29 sync_set_reset_local_all sync_set_reset_local_all is attached to a process label. The attribute sync_set_reset_local_all specifies that all the signals in the process are used to detect a synchronous set or reset condition for inferred latches or flip flops. The syntax of sync_set_reset_local_all is attribute sync_set_reset_local_all of process_label,... : label is true ; Example 8 17 Synchronous Set/Reset on a Part of a Design library IEEE; library synopsys; use IEEE.std_logic_1164.all; use synopsys.attributes.all; entity e_sync_set_reset_local_all is port(clk, reset, set, gate, gate2: in std_logic; y, t, w: out std_logic); end e_sync_set_reset_local_all; architecture rtl of e_sync_set_reset_local_all is attribute sync_set_reset_local_all of clocked_set_reset, clocked_set_reset_too: label is true ; clocked_set_reset: process (clk, reset, set) if (clk event and clk = 1 ) then if (reset = 1 ) then y <= 0 ; synchronous reset elsif (set = 1 ) then y <= 1 ; synchronous set end process clocked_set_reset;

30 clocked_set_reset_too: process (clk, gate, reset, set) if (clk event and clk = 1 ) then if (gate = 1 ) then if (reset = 1 ) then t <= 0 ; synchronous reset elsif (set = 1 ) then t <= 1 ; synchronous set end process clocked_set_reset_too; gated_set_reset: process (gate2, reset, set) if (gate2 = 1 ) then if (reset = 1 ) then w <= 0 ; gated reset elsif (set = 1 ) then w <= 1 ; gated set end process gated_set_reset; end rtl;

31 Figure 8 16 Synchronous Set/Reset on a Part of a Design Note: Since the target technology library did not contain a synchronous set or a synchronous reset flip flop, Design Compiler built the synchronous set/reset conditions using combinational logic.

32 Note: To prevent D flip-flops with asynchronous set and reset signals from being implemented with priority encoded logic that would prioritize the set over the reset or vice versa, use the attributes one_hot and one_cold. (See the next section.) If these attributes are not used, priority encoded implementations may occur because the if... else construct in the HDL description specifies prioritization. The one_hot and one_cold attributes tell HDL Compiler that only one of the objects in the list is active at a time. If you are defining active high signals, use one_hot. For active low, use one_cold. Each attribute has two objects specified. one_hot The one_hot attribute takes one argument of a doublequoted list of signals separated by commas. This attribute indicates that the group of signals (set and reset) are one_hot, i.e., no more than one signal can have a Logic 1 value at any one time. Users are responsible to make sure that the group of signals are really one_hot. HDL Compiler does not produce any logic to check this assertion. The syntax of one_hot is attribute one_hot signal_name,... : label is true ; This attribute is only used for set and reset signals on sequential devices. For a general group of signals, do not use this attribute for specifying that only one signal is hot.

33 Example 8 18 Using one_hot for Set and Reset library IEEE; library synopsys; use IEEE.std_logic_1164.all; use synopsys.attributes.all; entity e_one_hot is port(reset, set, reset2, set2: in std_logic; y, t: out std_logic); attribute async_set_reset of reset, set : signal is true ; attribute async_set_reset of reset2, set2 : signal is true ; attribute one_hot of reset, set : signal is true ; end e_one_hot; architecture rtl of e_one_hot is direct_set_reset: process (reset, set ) if (reset = 1 ) then y <= 0 ; asynchronous reset by reset elsif (set = 1 ) then y <= 1 ; asynchronous set by set end process direct_set_reset; direct_set_reset_too: process (reset2, set2 ) if (reset2 = 1 ) then t <= 0 ; asynchronous reset by reset2 elsif (set2 = 1 ) then t <= 1 ; asynchronous set by ~reset2 set2 end process direct_set_reset_too; synopsys synthesis_off process (reset, set) assert not (reset= 1 and set= 1 ) report One hot violation severity Error; synopsys synthesis_on end rtl;

34 Figure 8 17 shows the schematic generated by the code in Example Figure 8 17 Using one_hot for Set and Reset

35 one_cold The one_cold attribute takes one argument of a doublequoted list of signals separated by commas. This attribute indicates that the group of signals (set and reset) is one_cold, i.e., no more than one signal can have a Logic 0 value at any one time. Users are responsible to make sure that the group of signals is really one_cold. VHDL Compiler does not produce any logic to check this assertion. The syntax of one_hot is attribute one_cold signal_name,... : label is true ; This attribute is only used for set and reset signals on sequential devices. For a general group of signals, do not use this attribute to specify that only one signal is cold. Example 8 19 Using one_cold for Set and Reset library IEEE; library synopsys; use IEEE.std_logic_1164.all; use synopsys.attributes.all; entity e_one_cold is port(reset, set, reset2, set2: in std_logic; y, t: out std_logic); attribute async_set_reset of reset, set : signal is true ; attribute async_set_reset of reset2, set2 : signal is true ; attribute one_cold of reset, set : signal is true ; end e_one_cold; architecture rtl of e_one_cold is direct_set_reset: process (reset, set ) if (reset = 0 ) then y <= 0 ; asynchronous reset by not reset elsif (set = 0 ) then y <= 1 ; asynchronous set by not set end process direct_set_reset;

36 direct_set_reset_too: process (reset2, set2 ) if (reset2 = 0 ) then t <= 0 ; asynchronous reset by not reset2 elsif (set2 = 0 ) then t <= 1 ; asynchronous set by (not reset2) (not set2) end process direct_set_reset_too; synopsys synthesis_off process (reset, set) assert not (reset= 0 and set= 0 ) report One cold violation severity Error; synopsys synthesis_on end rtl; Figure 8 18 Using one_cold for Set and Reset

37 dc_shell Variables for Latch or Flip-flop Inference The following dc_shell variables control latch or flip-flop inference. hdlin_ff_always_async_set_reset By default, hdlin_ff_always_async_set_reset is true. VHDL Compiler does not report an asynchronous set or reset condition of flip flops unless you set this variable to true. Since the default setting for this variable is true, VHDL Compiler automatically checks for set and reset conditions of flip flops. hdlin_ff_always_sync_set_reset For a design analyzed subsequently by VHDL Compiler, if hdlin_ff_always_sync_set_reset is true, every signal in the design is regarded as if it has the sync_set_reset attribute attached. The default setting of hdlin_ff_always_sync_set_reset is false. hdlin_latch_always_async_set_reset By default, hdlin_latch_always_async_set_reset is true. A false setting causes VHDL Compiler to interpret each control object of a latch as synchronous. If you want to asynchronously set or reset a latch, set this variable to true. Setting the variable to true is equivalent to specifying every object in the design as the object list for the async_set_reset directive. When true, for a design subsequently analyzed, every constant 0 loaded on a latch is used for asynchronous reset, and every constant 1 loaded on a latch is used for asynchronous set. VHDL Compiler does not limit checks for assignments to a constant 0 or constant 1 to a single process. That is, VHDL Compiler performs checking across processes.

38 hdlin_keep_feedback By default, hdlin_keep_feedback is false. A false setting causes VHDL Compiler to remove all flip-flop feedback loops. For example, feedback loops inferred from a statement such as Q=Q are removed. With the state feedback removed from a simple D flip-flop, it becomes a synchronous loaded flipflop. Set the hdlin_keep_feedback variable to true if you want to keep feedback loops. hdlin_keep_inv_feedback By default, hdlin_keep_inv_feedback is true. It should be set to false before HDL input if you want to infer toggle or JK flip flops. A false value causes VHDL Compiler to remove all inverted flip-flop feedback loops. For example, feedback loops inferred from a statement such as Q=Q are removed and synthesized as T flip-flops. Set the hdlin_keep_inv_feedback variable to true if you want to keep inverted feedback loops. hdlin_check_no_latch If hdlin_check_no_latch is set true and latches are inferred from a design, VHDL Compiler reports a design warning. The default setting of hdlin_check_no_latch is false. This is useful for verifying that a combinational design does not contain memory components. hdlin_report_inferred_modules Possible values for hdlin_report_inferred_modules are true, false, and verbose. When false, VHDL Compiler does not report information on inferred latches, flip-flops, or three-state gates. When true, a brief report is generated for these inferred devices.

39 When verbose, detailed information also is reported. These include the asynchronous set or reset, synchronous set or reset, and synchronous toggle conditions of each latch or flip-flop expressed in Boolean formulas. The default setting of hdlin_report_inferred_modules is true. Example 8 20 Bus Latch library IEEE; library synopsys; use IEEE.std_logic_1164.all; use synopsys.attributes.all; entity e_bus_latch is port(reset, set, gate: in std_logic; d: in std_logic_vector(1 downto 0); y: out std_logic_vector(1 downto 0)); attribute async_set_reset of reset, set : signal is true ; end e_bus_latch; architecture rtl of e_bus_latch is bus_assignment: process (reset, set, gate) if (reset = 1 ) then y <= 00 ; elsif (set = 1 ) then y <= 11 ; elsif (gate = 1 ) then y <= d; end process bus_assignment; end rtl; With hdlin_report_inferred_modules set to verbose, Example 8 20 generates the output shown in the table in Example In the table, AR stands for Asynchronous-Reset, AS stands for Asynchronous-Set, SR stands for Synchronous-Reset, SS stands for Synchronous-Set, and ST stands for Synchronous-Toggle.

40 Since latches do not have Synchronous-Reset/Set/Toggle, the SR, SS, and ST columns are marked (for N/A). The Y mark in the AR and AS columns indicates that the latches inferred use Asynchronous-Reset and Asynchronous-Set pins. The Bus column is marked Y to indicate y_reg is a bus latch. A table like this is generated when hdlin_report_inferred_modules is set to true or verbose. A detailed report like the one following the table is generated only when hdlin_report_inferred_modules is set to verbose. The report shows that all cells in the bus latch are asynchronously reset by the signal reset, and are asynchronously set by the signal set. The last line in the report, Async set and Async reset ==> Q: 0 indicates that when both reset and set are Logic 1, the output of the latch is Logic 0. If Design Compiler finds a latch cell in the target library that has the same property (i.e., output is Logic 0 when clear and preset are both active), the signal reset is connected directly to the clear pin and the signal set is connected directly to the preset pin. However, if no such latch is found in the target library, Design Compiler synthesizes an AND function (~reset and set) to prioritize reset over set and connect it to the preset pin, while the signal reset still connects directly to the clear pin. Example 8 21 Bus Latch Report Inferred memory devices in process in routine bus_latch line 11 in file bus_latch.vhd. ========================================================================== Register Name Type Width Bus AR AS SR SS ST ========================================================================== y_reg Latch 2 Y Y Y ========================================================================== y_reg (width 2)

41 Async reset: reset Async set: set Async set and Async reset ==> Q: 0 Latch with Asynchronous Set and Reset Example 8 22 demonstrates how to eliminate the prioritization in Example 8 20 by using the one_hot attribute. This attribute gives Design Compiler more freedom to choose a map for the latch. one_hot indicates a dont-care condition when both reset and set are Logic 1. Note the difference in the last lines of the detailed reports shown in Example 8 23 and Example Example 8 22 Bus Latch with one_hot library IEEE; library synopsys; use IEEE.std_logic_1164.all; use synopsys.attributes.all; entity e_bus_latch_with_one_hot is port(reset, set, gate: in std_logic; d: in std_logic_vector(1 downto 0); y: out std_logic_vector(1 downto 0)); attribute async_set_reset of reset, set : signal is true ; attribute one_hot of reset, set : signal is true ; end e_bus_latch_with_one_hot; architecture rtl of e_bus_latch_with_one_hot is

42 bus_with_one_hot: process (reset, set, gate) if (reset = 1 ) then y <= 00 ; elsif (set = 1 ) then y <= 11 ; elsif (gate = 1 ) then y <= d; end process bus_with_one_hot; synopsys synthesis_off process (reset, set) assert not (reset= 1 and set= 1 ) report One hot violation severity Error; synopsys synthesis_on end rtl; Example 8 23 Bus Latch with one_hot Report Inferred memory devices in process in routine bus_latch_with_one_hot line 12 in file bus_latch_with_one_hot.vhd. ========================================================================== Register Name Type Width Bus AR AS SR SS ST ========================================================================== y_reg Latch 2 Y Y Y ========================================================================== y_reg (width 2) Async reset: reset Async set: set Async set and Async reset ==> Q: X

43 Example 8 24 shows the VHDL for a bus flip-flop and the corresponding report table is shown in Example Example 8 24 Bus Flip-flop library IEEE; library synopsys; use IEEE.std_logic_1164.all; use synopsys.attributes.all; entity e_bus_flip_flop is port(clk, clear, preset, reset, set, gate: in std_logic; d: in std_logic_vector(1 downto 0); y: out std_logic_vector(1 downto 0)); attribute async_set_reset of clear, preset : signal is true ; attribute sync_set_reset of reset, set : signal is true ; attribute one_hot of clear, preset : signal is true ; end e_bus_flip_flop; architecture rtl of e_bus_flip_flop is bus_assignment: process (clk, clear, preset) if (clear = 1 ) then y <= 00 ; asynchronous reset elsif (preset = 1 ) then y <= 11 ; asynchronous set elsif (clk event and clk = 1 ) then if (reset = 1 ) then y <= 00 ; synchronous reset elsif (set = 1 ) then y <= 11 ; synchronous set elsif (gate = 1 ) then y <= d; end process bus_assignment; end rtl;

44 Example 8 25 Bus Flip-flop Report Inferred memory devices in process bus in routine bus_latch line 13 in file bus_latch.vhd. ========================================================================== Register Name Type Width Bus AR AS SR SS ST ========================================================================== y_reg Flip flop 2 Y Y Y Y Y N ========================================================================== y_reg (width 2) Async reset: clear Async set: preset Sync reset: reset Sync set: set Async set and Async reset ==> Q: X Sync set and Sync reset ==> Q: 0 Example 8 26 and Example 8 27 show the VHDL and detailed report produced when multiple-bit data do not infer a bus flip-flop. Example 8 26 Not Bus Flip-flop library IEEE; library synopsys; use IEEE.std_logic_1164.all; use synopsys.attributes.all; entity e_not_bus_flip_flop is port(clk, clear, preset : in std_logic; d: in std_logic_vector(0 to 1); y: out std_logic_vector(0 to 1)); attribute async_set_reset of clear, preset : signal is true ; end e_not_bus_flip_flop; architecture rtl of e_not_bus_flip_flop is not_bus: process (clk, clear, preset) if (clear = 1 ) then

45 y(0) <= 0 ; asynchronous reset for y(0), but not y(1) elsif (preset = 1 ) then y(1) <= 1 ; asynchronous set for y(1), but not y(0) y <= d; end process not_bus; end rtl; Example 8 27 Not Bus Flip-flop Report Inferred memory devices in process not_bus in routine not_bus_flip_flop line 12 in file not_bus_flip_flop.vhd. ========================================================================= Register Name Type Width Bus AR AS SR SS ST ========================================================================== y_reg Flip flop 2 N????? ========================================================================== y_reg_0 Async reset: clear y_reg_1 Async set: clear preset The Bus column in the table is marked N, since y[0] and y[1] do not share all control signals. The question marks (?) in other columns indicate the flip-flops inferred do not have similar asynchronous or synchronous controls. However, the detailed report following the table indicates which bit of y uses Asynchronous-Reset and which uses Asynchronous-Set. hdlin_reg_report_length hdlin_reg_report_length is an integer variable that indicates the length of the Boolean formulas reported by hdlin_report_inferred_modules when it is set to verbose. The default setting of hdlin_reg_report_length is 60.

46 Efficient Use of Registers HDL descriptions should build only as many flip-flops as a design requires. Example 8 28 shows a description where too many flip-flops are implied. Example 8 28 Circuit with Six Implied Registers library IEEE; use IEEE.std_logic_1164.all; use IEEE.std_logic_unsigned.all; entity ex8_13 is port ( clk, reset : in std_logic; and_bits, or_bits, xor_bits : out std_logic ); end ex8_13; architecture rtl of ex8_13 is process variable count : std_logic_vector (2 downto 0); wait until (clk event and clk = 1 ); if (reset = 1 ) then count := 000 ; else count := count + 1; and_bits <= count(2) and count(1) and count(0); or_bits <= count(2) or count(1) or count(0); xor_bits <= count(2) xor count(1) xor count(0); end rtl;

47 Figure 8 19 Circuit with Six Implied Registers AND_BITS CLOCK OR_BITS XOR_BITS RESET In Example 8 28, the outputs AND_BITS, OR_BITS, and XOR_BITS depend solely on the value of COUNT. Since COUNT is registered, the three outputs do not need to be registered. To avoid implying extra registers, assign the outputs from within a process that does not have a wait statement. Example 8 29 shows a description with two processes, one with a wait statement and one without. This description style lets you choose the signals that are registered and those that are not.

48 Example 8 29 Circuit with Three Implied Registers library IEEE; use IEEE.std_logic_1164.all; use IEEE.std_logic_unsigned.all; entity COUNT is port(clock, RESET: in std_logic; AND_BITS, OR_BITS, XOR_BITS : out std_logic); end COUNT; architecture RTL of COUNT is signal COUNT : UNSIGNED (2 downto 0); REG: process Registered logic wait until CLOCK event and CLOCK = 1 ; if (RESET = 1 ) then COUNT <= 000 ; else COUNT <= COUNT + 1; COMBIN: process(count) Combinational logic AND_BITS <= COUNT(2) and COUNT(1) and COUNT(0); OR_BITS <= COUNT(2) or COUNT(1) or COUNT(0); XOR_BITS <= COUNT(2) xor COUNT(1) xor COUNT(0); end RTL;

49 Figure 8 20 Circuit with Three Implied Registers RESET CLOCK The technique of separating combinational logic from registered or sequential logic is useful when describing finite state machines. See the following examples in Appendix A: Moore Machine Mealy Machine Count Zeros Sequential Version Soft Drink Machine Controller State Machine Version

50 Example Using Synchronous and Asynchronous Processes There may be occasions when you want to keep some of the values computed by a process in flip-flops, while allowing other values to change between clock edges. This can be done by splitting your algorithm between two processes, one with a wait statement and one without. Put the registered (synchronous) assignments into the wait process. Put the other (asynchronous) assignments in the other process. Use signals to communicate between the two processes. For example, suppose you want to build a design with the following characteristics: Inputs A_1, A_2, A_3 and A_4 change asynchronously. Output t is driven from one of A_1, A_2, A_3, or A_4. Input CONTROL is valid only on the positive edge of CLOCK. The value at the edge determines which of the four inputs is selected during the next clock cycle. Output t must always reflect changes in the value of the currently selected signal. The implementation of this design requires two processes. The wait statement process synchronizes the CONTROL value. The other process multiplexes the output based on the synchronized control. The signal SYNC_CONTROL communicates between the two processes. Example 8 30 shows the code and a schematic of one possible implementation. Example 8 30 Two Processes: One Synchronous, One Asynchronous entity SYNC_ASYNC is port (CLOCK: in STD_LOGIC; CONTROL: in INTEGER range 0 to 3; A: in BIT_VECTOR(0 to 3); t: out STD_LOGIC); end SYNC_ASYNC; architecture EXAMPLE of SYNC_ASYNC is

51 signal SYNC_CONTROL: INTEGER range 0 to 3; process wait until CLOCK event and CLOCK = 1 ; SYNC_CONTROL <= CONTROL; process (A, SYNC_CONTROL) t <= A(SYNC_CONTROL); end EXAMPLE; Figure 8 21 Two Processes: One Synchronous, One Asynchronous

52 Multiplexers Multiplexers or MUXes are widely used by hardware designers to implement conditional assignments to signals. In Version 3.4a, VHDL Compiler improves the way multiplexers are inferred. Users can embed an attribute in the VHDL, or use variables to tell VHDL Compiler that case statements in certain processes of the VHDL code should be inferred as generic multiplexer cells called MUX_OPs. Design Compiler then attempts to map MUX_OPs in the design to multiplexer cells in the target technology library. Similar to Synopsys DesignWare components, MUX_OPs are hierarchical cells whose implementation is determined by Design Compiler during compile. Note: In order to use the multiplexer inferencing feature, the target technology library must contain at least a 2 to 1 multiplexer. See the Optimizing Design chapter of The Design Compiler Family Reference Manual for additional information about how Design Compiler maps MUX_OPs to multiplexers in the target technology library. New HDL Attribute The new VHDL attribute is infer_mux. This attribute is set on an process in the VHDL description. It tells VHDL Compiler that case statement(s) in the specified process should be inferred as generic multiplexer cells (MUX_OPs). The level of control with the attribute is at the process level, not at the level of individual case statements.

53 New Variables for Multiplexer Inference There are three new hdlin variables in Version 3.4a that determine how and when generic multiplexers (MUX_OPs) are inferred by VHDL Compiler. They are hdlin_infer_mux This variable controls MUX_OP inferencing for all designs that are analyzed in the same dc_shell session, unless the variable is changed between design inputs. This variable can be set to default Infers MUX_OPs for case statements in processes that have the infer_mux attribute attached; this is the default value. none Does not infer MUX_OPs, regardless of the attributes set in the HDL. all Treats each case statement in the design as if the infer_mux attribute is attached to it. Note: Setting this variable to all will result in MUX_OPs being inferred for every case statement in your design. This may be undesirable and may negatively affect the quality of results because it may be more efficient to implement the MUX_OPs as random logic instead of a specialized multiplexer structure. Use this setting only if you want MUX_OPs inferred for every case statement in your design. hdlin_dont_infer_mux_for_resource_sharing This variable controls MUX_OP inferences when two or more synthetic operators drive the data inputs of the MUX_OP.

54 hdlin_mux_size_limit This variable sets the maximum size of a MUX_OP that VHDL Compiler can infer. For more information about these variables, see HDL Coding Styles: Multiplexers Application Note. New compile Variables The following compile variables are new in Version 3.4a, and are used to control the multiplexer logic generated by Design Compiler: compile_create_mux_op_hierarchy When true (the default), compile creates all MUX_OP implementations with their own level of hierarchy. When false, compile removes this level of hierarchy. compile_mux_no_boundary_optimization When false (the default), compile performs boundary optimization on all MUX_OP implementations. When true, compile does not perform these boundary optimizations. For more information about these variables, see the Optimizing Design chapter in The Design Compiler Family Reference Manual.

55 Uses of Variables and Attributes The variable applies to an entire design input, while the attribute controls case statements in a specified process in a design. For example, if there is an existing VHDL description written without using the infer_mux attribute, and the user wants to infer multiplexers for all the case statements in a design, the hdlin_infer_mux variable can be set as follows: dc_shell>hdlin_infer_mux = all As a result, each case statement in the design is interpreted as if the infer_mux attribute is attached to it. A user would add the attribute for tighter control over the case statements that are inferred as multiplexers. For more information on the recommended use of these attributes, see the HDL Coding Styles: Multiplexers Application Note. New inference Report An inference report is issued by VHDL Compiler during VHDL input using the elaborate or read commands. The first column of the report indicates the process that contains the case statement for which the MUX_OP is inferred. The line number of the case statement in the VHDL also appears in this column. The remaining columns indicate the number of inputs, outputs, and select lines on the inferred MUX_OP. Example 8 31 Inference Report for MUX_OP Statistics for MUX_OP =========================================================== block name/line Inputs Outputs # sel inputs =========================================================== proc1/ ===========================================================

56 Example of a Multiplexer Inference This section contains a VHDL example that infers generic multiplexer cells (MUX_OPs). The example uses the new attribute to infer an 8 to 1 MUX_OP. Example 8 32 VHDL Example of an 8 to 1 MUX_OP library IEEE, Synopsys; use IEEE.std_logic_1164.all; use Synopsys.attributes.all; entity mux8to1 is port(din : in std_logic_vector(7 downto 0); SEL : in std_logic_vector(2 downto 0); DOUT : out std_logic); end; architecture one of mux8to1 is attribute infer_mux of proc1 : label is true ; proc1:process(sel,din) case SEL is when 000 => DOUT <= DIN(0); when 001 => DOUT <= DIN(1); when 010 => DOUT <= DIN(2); when 011 => DOUT <= DIN(3); when 100 => DOUT <= DIN(4); when 101 => DOUT <= DIN(5); when 110 => DOUT <= DIN(6); when 111 => DOUT <= DIN(7); when others => DOUT <= DIN(0); end case; end one; Note: Although the case statement in Example 8 32 appears completely specified, the others branch is necessary since SEL is of type std_logic_vector, and std_logic is defined to have nine possible values.

57 Example 8 33 shows the MUX_OP inference report for this VHDL source. Example 8 33 Inference Report for 8 to 1 MUX_OP Statistics for MUX_OPs ============================================================ block name/line Inputs Outputs # sel inputs ============================================================ proc1/ ============================================================ During compile, Design Compiler attempts to map the MUX_OP inferred in Example 6 24 to an 8 to 1 multiplexer in the target technology library. If the library does not contain an 8 to 1 multiplexer, Design Compiler will build the 8 to 1 multiplexer using smaller multiplexer cells (such as 4 to 1 multiplexer cells). Figure 8 22 shows the schematic after the VHDL shown in Example 8 32 has been compiled.

58 Figure 8 22 Schematic for 8 to 1 Multiplexer

59 Summary of HDL Compiler Limitations of Multiplexer Inference The following is a summary list of current VHDL Compiler MUX_OP inference limitations. MUX_OPs are not inferred for case statements that contain two or more synthetic operators, unless the variable hdlin_dont_infer_mux_for_resource_sharing is equal to false prior to VHDL input. MUX_OPs are not inferred for if then else statements. MUX_OPs are not inferred for statements embedded in if then else statements, unless the case statement appears in an if (clk event...) or in elsif (clk event...) branch in the VHDL. MUX_OPs are not inferred for case statements in subprograms (function or procedure). MUX_OPs are not inferred for case statements in while loops. MUX_OPs are inferred for incompletely specified case statements, but the resulting logic may not be optimal, so the HDL 382 warning is issued. The following types of case statements are considered incompletely specified: case statements that use a default branch, where the default branch covers more than one value case statements that have a missing case statement branch, or a missing assignment in a case statement branch case statements that contain an if statement, or case statements that contain other case statements case statements that contain dont_cares (X or in VHDL) case statements in an elsif (clk event...) branch in VHDL These limitations are explained in more detail at the end of the HDL Coding Styles: Multiplexers Application Note.

60 Three-State Inference VHDL Compiler can infer three-state gates (high-impedance output) from enumeration encoding in the VHDL language that Design Compiler maps to a specified technology library. See Enumeration Encoding in Chapter 4 for more information. When a variable is assigned the value of Z, the output of the three-state gate is disabled. Example 8 34 shows the VHDL for a three-state gate, and Figure 8 23 shows a threestate gate in a schematic. Example 8 34 Creating a Three-state Gate in VHDL signal OUT_VAL, IN_VAL: std_logic;... if (COND) then OUT_VAL <= IN_VAL; else OUT_VAL <= Z ; assigns high impedance Like the bit value assigned Z in Example 8 34, you can assign high impedance to a four-bit wide bus with ZZZZ. One three-state gate is inferred from a single process. Example 8 35 infers only one three-state gate. Example 8 35 Inferring One Three-state Gate from a Single Process process (sela, a, selb, b) t <= z ; if (sela = 1 ) then t <= a; if (selb = 1 ) then t <= b;

61 Example 8 36 infers two three-state gate. Example 8 36 Inferring Two Three-state Gates process (sela, a) if (sela = 1 ) then t = a; else t = z ; process (selb, b) if (selb = 1 ) then t = b; else t = z ; The VHDL conditional assignment may also be used for threestate inferencing. Assigning the Value Z Assigning the value Z to variables is allowed. The value Z can also appear in function calls, return statements, and aggregates. However, except for compare to Z, you cannot use Z in an expression. Example 8 37 shows an incorrect use of Z (in an expression), and Example 8 38 shows a correct use of Z (in a comparison). Example 8 37 Incorrect Use of the Value Z in an Expression OUT_VAL <= Z and IN_VAL;... Example 8 38 Correct Expression Comparing to Z if IN_VAL = Z then... Note: Expressions that compare values to Z are synthesized as though values are not equal to Z.