Modeling Combinational Logic 3

Transcription

1 3 Modeling Combinational Logic 3 There are two general classes of logic circuits: Combinational The value of the output deps only on the values of the input signals. Sequential The value of the output deps only on the values of the input signals and the previous condition on the circuit. This chapter describes coding examples for combinational logic synthesis, in the following sections: Logic and Arithmetic Expressions Multiplexing Logic Decoders / 3-1

2 Logic and Arithmetic Expressions HDL Compiler implements all Verilog operators, except those listed in Unsupported Verilog Language Constructs on page B-6. The following sections discuss how to create efficient logic and arithmetic expression code: Basic Operators How Statements Are Mapped to Logic How Parentheses Control Structure Arranging Expression Trees for Minimum Delay Adder Carry Chains Inferring Cascaded Adders With a Carry Input Carry Bit Overflow Coding for Late-Arriving Signals Basic Operators In Example 3-1, logical AND and OR operators are used in the always block. / 3-

3 Example 3-1 Logic Equation Code and Gates module logic (a, b, c, d, y); input a, b, c, d; output y; reg y, m, n; ( a or b or c or d) m= a & b; n= c & d; y= m n; module The addition, subtraction, and multiplication operators are used in Example 3-. Note that these operators use basic DesignWare components, which are included with a Design Compiler license. DesignWare components that implement many of the built-in HDL operators are provided by Synopsys. These operators include +, -, *, <, >, <=, >=, and the operations defined by if and case statements. / 3-3

4 Example 3- Arithmetic Operators and GTECH Gates module logic (a,b,c,d,y); input a,b,c,d; output y; reg y,m,n; ( a or b or c or d) m= a + b; n= c - d; y= m * n; module a b c d y How Statements Are Mapped to Logic The logic blocks created by HDL Compiler are custom-built for their environment. For example, in Example 3-3, if a and b are 4-bit quantities, a 4-bit adder is built. If a and b are 9-bit quantities, a 9-bit adder is built. Because HDL Compiler incorporates a large set of these customized logic blocks, it can translate most Verilog statements and operators. Note: If the inputs to an adder, or other operator resources, are 4 bits or less, the hierarchy is automatically collapsed during the execution of the compile command. The description fragment shown in Example 3-3 represents four logic blocks: A comparator that compares the value of b with 10 / 3-4

5 An adder that has a and b as inputs An adder that has a and 10 as inputs A multiplexer (implied by the if statement) that controls the final value of y Example 3-3 Four Logic Blocks if (b < 10) y = a + b; else y = a + 10; How Parentheses Control Structure You can use parentheses to control the design structure. HDL Compiler uses parentheses to define logic groupings. Example 3-4 and Example 3-5 illustrate two different groupings of adders. In Example 3-4, when HDL Compiler reads the code, it groups a + b together by default, then c and d are added one at a time. In Example 3-5, when HDL Compiler reads the code, it groups (a + b) and (c + d) and then adds their results together. This is referred to as a balanced adder tree. These examples show how grouping the logic affects the way the circuit is synthesized. / 3-5

6 Example 3-4 z = a + b + c + d; 4-Input Adder Code and Implementation a b c d z Example Input Balanced Adder Tree Code and Implementation z = (a + b) + (c + d); a b c d Design Compiler considers other factors, such as signal arrival times, to determine which implementation is best for your design. Note: Automatic resource sharing can also affect the structure of a design. Parentheses are regarded as user directives that force HDL Compiler to use the groupings inside them. If you are not sure about the best expression tree for an arithmetic expression, leave the / 3-6

7 expression ungrouped. Design Compiler can reconstruct the expression for minimum delay. To illustrate the effect of parentheses on the construction of an expression tree, consider Example 3-6. Example 3-6 Parentheses in an Arithmetic Expression Q <= ((A + (B + C)) + D + E) + F; The parentheses in the expression in Example 3-6 define the following subexpressions, whose numbers correspond to those in Figure 3-1: 1 (B + C) (A + (B + C)) 3 ((A + (B + C)) + D + E) These subexpressions must be preserved by HDL Compiler. The default expression tree for Example 3-6 is shown in Figure 3-1. Figure 3-1 Expression Tree With Subexpressions Dictated by Parentheses B C 1 A 3 D E F Q / 3-7

8 Design Compiler restructures the expression tree in Figure 3-1 to minimize the delay and still preserve the subexpressions dictated by the parentheses. If all signals arrive at the same time, the result is the expression tree shown in Figure 3-. Figure 3- B Restructured Expression Tree With Subexpressions Preserved C A D E F Q Design Compiler automatically optimizes expression trees to produce minimum delay. If you do not want this, enter the following command: dc_shell> set_minimize_tree_delay false The set_minimize_tree_delay command applies to the current design. The default for the command is true. Arranging Expression Trees for Minimum Delay If your goal is to speed up your design, consider using parentheses to rearrange the sequence of the operations. Consider the statement in Example 3-7. / 3-8

9 Example 3-7 Simple Arithmetic Expression Z <= A + B + C + D; HDL Compiler performs each addition in order, as though parentheses were placed as shown, and constructs the expression tree shown in Example 3-8. Example 3-8 Default Arithmetic Structure Z <= ((A + B) + C) + D; A B C D Z To determine the minimum delay through an expression tree, Design Compiler considers the arrival times of each signal in the expression. If the arrival times of the signals are the same, the length of the critical path of the expression in Example 3-8 equals three adder delays. The critical path delay can be reduced to two adder delays if you add parentheses to the first statement, as shown. Z <= (A + B) + (C + D); HDL Compiler evaluates the expressions in parentheses first and constructs a balanced adder tree, as shown in Example 3-9. / 3-9

10 Example 3-9 Balanced Adder Tree Z <= (A + B) + (C + D); A B C D Z Suppose signals B, C, and D arrive at the same time and signal A arrives last. The expression tree that produces the minimum delay is shown in Figure 3-3. Figure 3-3 B Expression Tree With Minimum Delay (Signal A Arrives Last) C D A Z Adder Carry Chains In many circumstances, you can improve the quality of synthesized circuits by using your high-level knowledge of the design. Any additional architectural information you can provide to HDL Compiler can result in a more efficient circuit. / 3-10

11 HDL Compiler provides significant control over the preoptimization structure, or organization of components, in your design. Whether or not your design structure is preserved after optimization deps on the Design Compiler options you select. Design Compiler automatically chooses the best structure for your design. You control structure by the way you order assignment statements and the way you use variables. The following examples illustrate two possible descriptions of an adder s carry chain. The ripple carry chain in Example 3-10 results in the slower, smaller adder; Example 3-11 describes the faster, larger carry-lookahead adder. / 3-11

12 Example 3-10 Ripple Carry Chain Code and Implementation // a is the add // b is the aug // c is the carry cin a0 b0 a1 b1 // cin is the carry in c0 = (a0 & b0) (a0 b0) & cin; c1 = (a1 & b1) (a1 b1) & c0; c0 c1 Example 3-11 Carry-Lookahead Chain Code and Implementation // p s are propagate // g s are generate cin a0 b0 a1 b1 p0 = a0 b0; g0 = a0 & b0; p1 = a1 b1; g1 = a1 & b1; c0 = g0 p0 & cin; c1 = g1 p1 & g0 p1 & p0 & cin; Inferring Cascaded Adders With a Carry Input To infer cascaded adders with a carry input, set hdlin_use_carry_in to true (default is false). If your design has two cascaded adders and one has a single-bit input, HDL Compiler replaces the two adders with a simple adder that has a carry input if hdlin_use_carry_in is true. Example 3-1 shows two expressions in which cin is a single-bit variable connected to a carry input. Each expression results in the same implementation. / 3-1

13 Example 3-1 Cascaded Adders With Carry Input z <= a + b + cin; a b t <= a + b; z <= t + cin; cin cin a b z z Carry Bit Overflow When Design Compiler performs arithmetic optimization, it considers how to handle the overflow from carry bits during addition. The optimized structure of an expression tree is affected by the bit-widths you declare for storing intermediate results. For example, suppose you write an expression that adds two 4-bit numbers and stores the result in a 4-bit register. If the result of the addition overflows the 4-bit output, the most significant bits are truncated. Example 3-13 shows how overflow characteristics are handled. Example 3-13 Adding Numbers of Different Bit-Widths t <= a + b; // a and b are 4-bit numbers z <= t + c; // c is a 6-bit number In Example 3-13, three variables are added (a + b + c). A temporary variable, t, holds the intermediate result of a + b. Suppose t is declared as a 4-bit variable so the overflow bits from the addition of a + b are truncated. HDL Compiler determines the default structure of the expression tree, which is shown in Figure 3-4. / 3-13

14 Figure 3-4 a[4] Default Expression Tree With 4-Bit Temporary Variable b[4] c[6] t[4] z[6] Now suppose the addition is performed without a temporary variable (z = a + b + c). HDL Compiler determines that 5 bits are needed to store the intermediate result of the addition, so no overflow condition exists. The results of the final addition might be different from the first case, where a 4-bit temporary variable is declared that truncates the result of the intermediate addition. Therefore, these two expression trees do not always yield the same result. The expression tree for the second case is shown in Figure 3-5. Figure 3-5 a[4] Expression Tree With 5-Bit Intermediate Result b[4] c[6] [5] z[6] / 3-14

15 Now suppose the expression tree is optimized for delay and that signal a arrives late. Design Compiler restructures the tree so that b and c are added first. Because c is declared as a 6-bit number, Design Compiler determines that the intermediate result must be stored in a 6-bit variable. The expression tree for this case, where signal a arrives late, is shown in Figure 3-6. Note how this tree differs from the expression tree in Figure 3-4. Figure 3-6 b[4] Expression Tree for Late-Arriving Signal c[6] a[4] [6] z[6] Coding for Late-Arriving Signals The following sections discuss coding techniques for late-arriving signals: Datapath Duplication Move Late-Arriving Signal Close to Output Note that these techniques apply to HDL Compiler output. When this output is constrained and optimized by Design Compiler, your structure might be changed, deping on such factors as your design constraints and option settings. See the Design Compiler documentation for details. / 3-15

16 Datapath Duplication The following examples illustrate how to duplicate logic to improve timing. In Example 3-14, CONTROL is a late-arriving input signal that selects between two inputs. The selected input drives a chain of arithmetic operations and s at the output port COUNT. Note that CONTROL is needed to complete the first operation. In Example 3-14, notice that there is a SELECT_OP next to a subtracter. (For more information about SELECT_OP, see SELECT_OP on page 3-.) When you see a SELECT_OP next to an operator, you can usually move it to after the operator by duplicating the logic in the branches of the conditional statement that implied the SELECT_OP. Example 3-15 shows this datapath duplication. When you duplicate the operations that dep on the inputs PTR1 and PTR, the assignment to COUNT becomes a selection between the two parallel datapaths. The signal CONTROL selects the datapath. The path from CONTROL to the output port COUNT is no longer the critical path, but this change comes at the expense of duplicated logic. In Example 3-15, the entire datapath is duplicated, because CONTROL arrives late. Had CONTROL arrived earlier, you could have duplicated only a portion of the logic, thereby decreasing the area expense. The designer controls how much logic is duplicated. / 3-16

17 Example 3-14 Code and Structure module BEFORE (ADDRESS, PTR1, PTR, B, CONTROL, COUNT); input [7:0] PTR1,PTR; input [15:0] ADDRESS, B; // CONTROL is late arriving input CONTROL; output [15:0] COUNT; parameter [7:0] BASE = 8 b ; wire [7:0] PTR, OFFSET; wire [15:0] ADDR; assign PTR = (CONTROL == 1 b1)? PTR1 : PTR; // Could be any function f(base,ptr) assign OFFSET = BASE - PTR; assign ADDR = ADDRESS - {8 h00, OFFSET}; assign COUNT = ADDR + B; module SELECT_OP PTR1 PTR SUBTRACTER SUBTRACTER BASE B 16 ADDER COUNT CONTROL / 3-17

18 Example 3-15 Data-Path Duplicated Code and Structure module PRECOMPUTED (ADDRESS, PTR1, PTR, B, CONTROL, COUNT); input [7:0] PTR1, PTR; input [15:0] ADDRESS, B; input CONTROL; output [15:0] COUNT; parameter [7:0] BASE = 8 b ; wire [7:0] OFFSET1,OFFSET; wire [15:0] ADDR1,ADDR,COUNT1,COUNT; assign OFFSET1 = BASE - PTR1; // Could be f(base,ptr) assign OFFSET = BASE - PTR; // Could be f(base,ptr) assign ADDR1 = ADDRESS - {8 h00, OFFSET1}; assign ADDR = ADDRESS - {8 h00, OFFSET}; assign COUNT1 = ADDR1 + B; assign COUNT = ADDR + B; assign COUNT = (CONTROL == 1 b1)? COUNT1 : COUNT; module SUBTRACTER BASE PTR1 8 SUBTRACTER ADDRESS ADDER B 16 DUPLICATED LOGIC SUBTRACTER BASE PTR 8 SUBTRACTER SELECT_OP ADDRESS ADDER COUNT 16 B 16 CONTROL / 3-18

19 The amount of datapath duplication is proportional to the number of branches in the conditional statement. For example, if there were four PTR signals in Example 3-14 instead of two (PTR1 and PTR), the area penalty would be larger, because you would have two more duplicated datapaths. In general, the improved design with the datapath duplicated is better with respect to timing but the area is larger. Note that logic duplication also increases the load on the input pins. Move Late-Arriving Signal Close to Output Example 3-16 shows code that contains operators in the conditional expression of an if statement and the structure implied by the code. The signal A in the conditional expression is a late-arriving signal, so you should move the signal closer to the output. The signal A is an input to the adder. Example 3-17 restructures the code to do this and shows the resulting implementation. / 3-19

20 Example 3-16 Input A Is Late-Arriving module cond_oper (A, B, C, D, Z); parameter N = 8; // A is late arriving input [N-1:0] A, B, C, D; ADDER A B 4 COMPARATOR SELECT_OP C Z D output [N-1:0] Z; reg [N-1:0] Z; or B or C or D) if (A + B < 4) Z <= C; else Z <= D; module / 3-0

21 Example 3-17 Improved Verilog With Operator in Conditional Expression module cond_oper_improved (A, B, C, D, Z); parameter N = 8; SUBTRACTER SELECT_OP // A is late arriving input [N-1:0] A, B, C, D; 4 B A COMPARATOR C D Z output [N-1:0] Z; reg [N-1:0] Z; or B or C or D) if (A < 4 - B) Z <= C; else Z <= D; module Multiplexing Logic Multiplexers are commonly modeled with if and case statements. When creating the GTECH netlist, HDL Compiler uses the SELECT_OP to build a MUX structure unless the faster MUX_OP (generic multiplexer cell) is requested. / 3-1

22 To model effectively, you need to know how to control multiplexing structure, code for late-arriving signals, and use the directives infer_mux, full_case and parallel_case. These topics are discussed in the following sections: SELECT_OP Basic Types of Multiplexing Logic MUX Type Single SELECT_OP No Priority Logic MUX Type Single SELECT_OP With Priority Logic MUX Type Multiple SELECT_OPs With Priority Logic Multiplexer Chain and Tree Structures Modeling Complex MUX Inferences: Bit and Memory Accesses MUX_OP Inference Full Case and Parallel Case Coding if and case Statements for Late-Arriving Signals SELECT_OP The generic SELECT_OP components are used by HDL Compiler to implement conditional operations, such as if statements or case statements. SELECT_OP components behave like one-hot multiplexers; the control lines are mutually exclusive, and each SELECT_OP control input allows the data on the corresponding SELECT_OP data input to pass to the output of the SELECT_OP. Do not confuse SELECT_OP components with one-hot multiplexers in a technology library. Design Compiler does not map to one-hot multiplexers in a technology library. Sequential if statements allow you to structure HDL for late-arriving signals. / 3-

23 Basic Types of Multiplexing Logic Table 3-1 describes the three basic types of multiplexing logic you can generate using if and case statements. By default, HDL Compiler uses SELECT_OP components to build the MUX structure. To improve speed, a MUX_OP can be inferred instead of the SELECT_OP. See MUX_OP Inference on page Table 3-1 Types of Multiplexing Logic Type Coding style to use Examples Single SELECT_OP with no priority encoding To build this type, use case statements or if-else-if statements that are parallel, that is, at most, only one condition is true. case (sel) b00 : y = a; b01 : y = b; b10 : y = c; b11 : y = d; case Single SELECT_OP with priority encoding To build this type, use case statements or if-else-if statements that are not parallel, that is, more than one condition may be true. In this case, priority logic encoding is needed to ensure that the first true condition is implemented. if (sel== b00) y = a; else if (sel== b01) y = b; else if (sel== b10) y = c; else y = d; else if (sel[]) z = c; else if (sel[1]) z = b; else if(sel[0]) z = a; / 3-3

24 Table 3-1 Types of Multiplexing Logic (Continued) Multiple SELECT_OPs with priority encoding To build this type, use sequential if statements. if (sel[0]) z = a; if (sel[1]) z = b; if (sel[]) z = c; Example 3-18 MUX Type Single SELECT_OP No Priority Logic To create a MUX implementation with a single SELECT_OP and no priority-encoded logic, use a parallel case statement or parallel if-else-if statements. Example 3-18 creates a MUX using a parallel case statement. Example 3-19 uses parallel if-else-if statements. Parallel case Statement MUX module mux(a, b,c,d,sel,y); input a,b,c,d; input [1:0] sel; output y; reg y; (a or b or c or d or sel) case (sel) b00 : y = a; b01 : y = b; b10 : y = c; b11 : y = d; case module / 3-4

25 d c b a SELECT_OP y sel[1] GTECH_NOT GTECH_AND sel[0] Example 3-19 uses parallel if-else-if statements which creates a MUX implementation with a single SELECT_OP and no priority-encoded logic. Example 3-19 Parallel if-else-if Statement MUX module mux (a, b,c,d,sel,y); input a,b,c,d; input [1:0] sel; output y; reg y; (sel or a or b or c or d) if (sel== b00) y = a; else if (sel== b01) y = b; else if (sel== b10) y = c; else y = d; module / 3-5

26 d c b a SELECT _OP y sel[1:0] GTECH_OR GTECH_NOT GTECH_AND MUX Type Single SELECT_OP With Priority Logic Use a nonparallel case statement or nonparallel if-else-if statements to create a MUX with a single SELECT_OP and priority encoded logic. Priority logic is needed to ensure that the first true condition is implemented. Example 3-0 uses a nonparallel casex statement. Example 3-1 and Example 3- create a MUX using nonparallel if-else-if statements. In Example 3-0, the casex statement enables you to take advantage of don t care conditions, so you don t have to specify all possible 0/1 combinations of sel. / 3-6

27 Example 3-0 Example 3-1 Nonparallel casex Statement MUX module case1(a, b, c, d, sel, z); input a, b, c, d; input [3:0] sel; output z; reg z; or b or c or d or sel) casex (sel) 4 b1xxx: z = d; 4 bx1xx: z = c; 4 bxx1x: z = b; 4 bxxx1: z = a; default: z = 1 b0; case module In Example 3-1, z is assigned 0 before the if-else-if statements to handle the condition where none of the if-else-if statements are true. Nonparallel if-else-if With Initial Default Statement module single_if(a, b, c, d, sel, z); input a, b, c, d; input [3:0] sel; output z; reg z; or b or c or d or sel) z = 0; if (sel[3]) z = d; else if (sel[]) z = c; else if (sel[1]) z = b; else if(sel[0]) z = a; module / 3-7

28 SELECT_OP d c b a 0 z sel[3] sel[] sel[3] sel[1] sel[] sel[3] sel[0] sel[1] sel[] sel[3] sel[0] sel[1] sel[] sel[3] Example 3- Example 3- uses nonparallel if-else-if statements to create a MUX with a single SELECT_OP and priority-encoded logic. Notice that the final else branch executes if none of the other branches are true. Contrast this with Example 3-1, where the last if in the chain has no else clause; by itself, this if-else-if code could execute without making an assignment to z. To fix this problem, the initial statement z = 0 is added before the if-else-if statements, which is reflected in the additional input to the SELECT_OP for 0, the prior value of z. Nonparallel if-else-if With Final else Statement module m (p, q, r, s, a, z); input p, q, r, s; input [0:4] a; output z; reg z; or p or q or r or s) if ( p ) / 3-8

29 z = a[0]; else if ( q ) z = a[1]; else if ( r ) z = a[]; else if ( s ) z = a[3]; else z = a[4]; module SELECT_OP a[0:4] z q p r s MUX Type Multiple SELECT_OPs With Priority Logic Sequential if statements allow you to create a priority-encoded implementation that can help in handling late-arriving signals. Assignment priority is from bottom to top, that is, the last if statement in your code translates to the data signal in the last SELECT_OP in the chain of SELECT_OPs. Example 3-3 and Example 3-4 show code for priority-encoded MUX implementations. For more information, see Coding if and case Statements for Late-Arriving Signals on page / 3-9

30 Note: If you use the if-else--if construct to build a priority-encoded MUX, you must use named blocks in the code, as shown in Example 3-4. The truth table for Example 3-3 is shown below. S[1] S[] S[3] S[4] Output x x x 1 d x x 1 0 c x b a In Example 3-3, note that the inputs sel[0] and a to the first SELECT_OP in the chain have the longest delay to the output z. The inputs sel[3] and d to the last SELECT_OP in the chain have the shortest delay to the output. Example 3-3 Sequential if Statement MUX module mult_if(a, b, c, d, sel, z); input a, b, c, d; input [3:0] sel; output z; reg z; or b or c or d or sel) z = 0; if (sel[0]) z = a; if (sel[1]) z = b; if (sel[]) z = c; if (sel[3]) z = d; module / 3-30

31 SELECT_OP SELECT_OP c SELECT_OP b a 0 sel[] SELECT_OP d z sel[3] sel[0] sel[1] Example 3-4 If you use the if-else--if construct to build a priority encoded MUX, you must use named blocks in the code, as shown in Example 3-4. if-else--if Statement MUX Needs Named Blocks module m1 (p, q, r, s, a, x); input p, q, r, s; input [0:4] a; output x; reg x; or p or q or r or s) if ( p ) x = a[0]; else :b1 if ( q ) x = a[1]; else :b if ( r ) x = a[]; else :b3 if ( s ) x = a[3]; else x = a[4]; module / 3-31

32 SELECT_OP SELECT_OP SELECT_OP SELECT_OP x a[0:4] s o o o o r p q Multiplexer Chain and Tree Structures Example 3-5 and Example 3-6 show code for a multiplexer chain and a multiplexer tree structure, respectively. Note that the examples are parameterized so that you can customize them to fit your application. In Example 3-5, the structure implied by the HDL is a chain of multiplexing logic. Example 3-6 shows Verilog code that implies the same multiplexing functionality shown in Example 3-5, but in a tree structure rather than a chain structure. This does not mean that Design Compiler necessarily infers multiplexer cells for this logic. For information on how Design Compiler maps to multiplexer cells in the technology library, see the Design Compiler Reference Manual: Optimization and Timing Analysis. In general, the tree version is better with respect to timing but a little worse with respect to area. To optimize your HDL for timing, use the tree version. If area is of greater concern, use the chain version. / 3-3

33 A late-arriving signal can also indicate the need for a chain structure. For example, if data_in[0] is a late-arriving input, the chain structure shown in Example 3-5 is the better startpoint. Example 3-5 Code for Multiplexer Chain module mux_chain (sel, data_in, data_out); parameter N = 5; input [N-1:0] sel; input [N:0] data_in; output data_out; reg data_out; function mux_chain_func; input [N-1:0] sel; input [N:0] data_in; reg [N-1:0] i_sel; reg [N:0] i_data; reg result; integer I; i_sel = sel; i_data = data_in; mux_chain_func = i_data[n]; for (I = N-1; I >= 0; I=I-1) if (i_sel[i]) mux_chain_func = i_data[i]; function or data_in) data_out <= mux_chain_func(sel, data_in); module / 3-33

34 SELECT_OP data_in[4] data_in[5] sel[4] SELECT_OP SELECT_OP SELECT_OP data_in[0] SELECT_OP data_in[1] data_out data_in[] data_in[3] sel[3] sel[] sel[1] sel[0] / 3-34

35 Example 3-6 Code for Multiplexer Tree module mux_tree(sel, data_in, data_out); parameter N = 8; parameter logn = 3; input [N-:0] sel; input [N-1:0] data_in; output data_out; reg data_out; function even; input [31:0] num; even = ~num[0]; function function mux 1; input sel; input [1:0] data; if (sel) mux 1 = data[0]; else mux 1 = data[1]; function function mux_tree_func; input [N-:0] sel; input [N-1:0] data_in; reg [N-1:0] i_sel, temp_sel; reg [N-1:0] i_data, result; integer I, J, K, S; integer TREE_DEPTH; integer SEL_LEN, DATA_LEN; i_data[n-1:0] = data_in[n-1:0]; i_sel[n-:0] = sel[n-:0]; i_sel[n-1] = 1 b0; DATA_LEN = N; SEL_LEN = N-1; for (TREE_DEPTH=logN-1; TREE_DEPTH>=0; / 3-35

36 TREE_DEPTH=TREE_DEPTH-1) SEL_LEN = (DATA_LEN+1)/; S = SEL_LEN-1; J = (DATA_LEN+1)/; J = J-1; if (even(data_len)) for (I=DATA_LEN-1; I>=1; I=I-) result[j] = mux 1(i_sel[I-1], {i_data[i], i_data[i-1]}); temp_sel[s] = {i_sel[i-1], i_sel[i]}; J = J-1; S = S-1; else for (I=DATA_LEN-1; I>=; I=I-) result[j] = mux 1(i_sel[I-1], {i_data[i],i_data[i-1]}); temp_sel[s] = {i_sel[i-1], i_sel[i]}; J = J-1; S = S-1; result[0] = i_data[0]; temp_sel[0] = i_sel[0]; i_data[n-1:0] = result[n-1:0]; i_sel[n-1:0] = temp_sel[n-1:0]; DATA_LEN = (DATA_LEN+1)/; mux_tree_func = result[0]; function or data_in) data_out <= mux_tree_func(sel, data_in); module / 3-36

37 Figure 3-7 Structure Implied by Multiplexer Tree Code in Example 3-6 SELECT_OP data_in[1] SELECT_OP data_in[0] data_in[] sel[1] SELECT_OP data_in[4] sel[0] SELECT_OP data_in[3] SELECT_OP data_out data_in[5] sel[4] sel[3] sel[] sel[1] sel[0] Control Logic Modeling Complex MUX Inferences: Bit and Memory Accesses In addition to inferring multiplexers from case statements, you can infer them for bit or memory accesses. See Example 3-7 through Example 3-9 for templates. Each example creates the implementation shown in Figure 3-8. By default, HDL Compiler uses a MUX_OP for bit and memory access; SELECT_OP components are generated if hdlin_build_selectop_for_var_index is set to true. The default is false. / 3-37

38 Example 3-7 MUX Inference for Bit Access module mux_infer_bit (x, a, y); input [15:0] x; input [3:0] a; output y; reg y; y = x[a]; module Example 3-8 MUX Inference for Memory Access module mux_infer_memory (a, y); input [3:0] a; output [3:0] y; reg [3:0] x[0:15]; reg [3:0] y; y = x[a]; module Example 3-9 MUX Inference Using Part Select Operator module mux_infer_v000 (x, a, y); input [15:0] x; input [3:0] a; output [3:0] y; wire [3:0] y; assign y = x[a+:4]; module / 3-38

39 Figure 3-8 Implementation MUX_OP MUX_OP Inference Use the following methods to infer MUX_OP components: To generate MUX_OP components for a specific case or if statement, use the infer_mux directive in the Verilog description. Note that the case statement must be parallel; otherwise, a MUX_OP is not inferred and an error is reported. Even when the //synopsys parallel_case directive is used, an error is reported if the case statement is not truly parallel. always@(sel) case (SEL) // synopsys infer_mux b00: DOUT <= DIN[0]; b01: DOUT <= DIN[1]; b10: DOUT <= DIN[]; b11: DOUT <= DIN[3]; case / 3-39

40 This directive can also be set on a block to direct HDL Compiler to infer MUX_OPs for all case statements in that block. Use the following syntax: // synopsys infer_mux block_label_list To generate MUX_OP components for all case and if statements, use the hdlin_infer_mux variable, described in Table 3-. MUX_OP components typically improve the speed of the design at the expense of size. Design Compiler maps inferred MUX_OP components to multiplexer cells in the target technology library. The size of an inferred MUX_OP deps on the number of unique values that are read in the case statement or the if-then-else statement. During compilation, Design Compiler attempts to map the MUX_OP to an appropriate size multiplexer in the target technology library. If the library does not contain a large enough multiplexer, Design Compiler builds the multiplexer with smaller multiplexer cells (such as 4-to-1 multiplexer cells). Note: If you want to use the multiplexer inference feature, the target technology library must contain at least a -to-1 multiplexer. HDL Compiler does not infer MUX_OPs for case statements that contain two or more synthetic operators, unless you set the following variable to false before reading or elaborating the Verilog description: hdlin_dont_infer_mux_for_resource_sharing See the Design Compiler Reference Manual: Optimization and Timing Analysis for detailed information about MUX_OP components. / 3-40

41 HDL Compiler generates an inference report that shows the information HDL Compiler passes on to Design Compiler about the inferred devices. Example 3-30 shows a MUX_OP inference report. Example 3-30 MUX_OP Inference Report Statistics for MUX_OPs block name/line Inputs Outputs # sel inputs MB blk1/0 1 1 N The first column of the report indicates the block that contains the case statement for which the MUX_OP is inferred. The line number of the case statement in Verilog also appears in this column. The remaining columns indicate the number of inputs, outputs, and select lines on the inferred MUX_OP. / 3-41

42 Table 3- Variable Controlling MUX_OP Inference With Variables Description hdlin_infer_mux hdlin_mux_size_limit hdlin_mux_size_min hdlin_mux_oversize_ratio This variable controls MUX_OP inference for all designs you input in the same dc_shell session. Note that the case statement must be parallel; otherwise, a MUX_OP is not inferred and an error is reported. Even when the //synopsys parallel_case directive is used, if the case statement is not truly parallel, an error is reported. Options: default Use default to infer MUX_OPs for case and if statements in blocks that have the infer_mux directive attached or that have the infer_mux directive. This is the default value. none The value of none does not infer MUX_OPs, regardless of the directives set in the Verilog description. HDL Compiler generates the following message during MUX_OP inference when this variable is set: Warning: A mux_op for process %s was not inferred because the variable hdlin_infer_mux was set to none. (ELAB-309) all The value of all infers MUX_OPs for every case and if statement in your design for which one can be used. This can negatively affect the quality of results, because it might be more efficient to implement the MUX_OPs as random logic instead of using a specialized multiplexer structure. This variable sets the maximum size of a MUX_OP that HDL Compiler can infer. If you set this variable to a value greater than 3, HDL Compiler takes longer to process the design. The default value is 3. Sets the minimum number of data inputs for MUX inference. The default value is. Defined as the ratio of the number of MUX inputs to the unique number of data inputs. When this ratio is exceeded, a MUX will not be inferred and the circuit will be generated with SELECT_OPs. The default value is 100. / 3-4

43 Table 3- Variable Controlling MUX_OP Inference With Variables (Continued) Description hdlin_dont_infer_mux_for _resource_sharing hdlin_mux_size_limit true When true, HDL Compiler does not infer a MUX_OP when two or more synthetic operators drive the data inputs of the MUX_OP and it generates the following message during MUX_OP inference: Warning: No mux_op inferred for the case %s because it would lose the benefit of resource sharing. (ELAB-309) false When false, HDL Compiler infers a MUX_OP but resource sharing does not share the data pins that the synthetic operators drive. This can have a negative impact on the area of the final implementation. The default value is 100. This variable sets the maximum size of a MUX_OP that HDL Compiler can infer. If you set this variable to a value greater than 3, HDL Compiler takes longer to process the design. The default value is 3. Example 3-3 attaches the infer_mux directive to the block blk1. HDL Compiler infers a MUX_OP for each case statement in the block. The first case statement reads eight unique values and infers an 8-to-1 MUX_OP. The second case statement reads four unique values and infers a 4-to-1 MUX_OP. HDL Compiler generates the inference report shown in Example / 3-43

44 Example 3-31 Inference Report for a Block Statistics for MUX_OPs block name/line Inputs Outputs # sel inputs MB blk1/53 blk1/ N N Example 3-3 MUX_OP Inference for a Block module muxtwo(din1, DIN, SEL1, SEL, DOUT1, DOUT); input [7:0] DIN1; input [3:0] DIN; input [:0] SEL1; input [1:0] SEL; output DOUT1, DOUT; reg DOUT1, DOUT; //synopsys infer_mux "blk1" or SEL or DIN1 or DIN) : blk1 // this case statement infers an 8-to-1 MUX_OP case (SEL1) 3 b000: DOUT1 <= DIN1[0]; 3 b001: DOUT1 <= DIN1[1]; 3 b010: DOUT1 <= DIN1[]; 3 b011: DOUT1 <= DIN1[3]; 3 b100: DOUT1 <= DIN1[4]; 3 b101: DOUT1 <= DIN1[5]; 3 b110: DOUT1 <= DIN1[6]; 3 b111: DOUT1 <= DIN1[7]; case // this case statement infers a 4-to-1 MUX_OP case (SEL) b00: DOUT <= DIN[0]; b01: DOUT <= DIN[1]; b10: DOUT <= DIN[]; b11: DOUT <= DIN[3]; case / 3-44

45 module Example 3-33 Example 3-33 uses the infer_mux directive for a specific case statement. This case statement contains eight unique values, and HDL Compiler infers an 8-to-1 MUX_OP. HDL Compiler generates the inference report shown in Example MUX_OP Inference for a Specific case Statement module mux8to1 (DIN, SEL, DOUT); input [7:0] DIN; input [:0] SEL; output DOUT; reg DOUT; always@(sel or DIN) : blk1 case (SEL) // synopsys infer_mux 3 b000: DOUT <= DIN[0]; 3 b001: DOUT <= DIN[1]; 3 b010: DOUT <= DIN[]; 3 b011: DOUT <= DIN[3]; 3 b100: DOUT <= DIN[4]; 3 b101: DOUT <= DIN[5]; 3 b110: DOUT <= DIN[6]; 3 b111: DOUT <= DIN[7]; case module / 3-45

46 Example 3-34 Inference Report for case Statement Statistics for MUX_OPs block name/line Inputs Outputs # sel inputs MB blk1/ N MUX_OP Components in Variable Indexing HDL Compiler generates MUX_OP components to implement indexing into a data variable, using a variable address. For example: module E(data, addr, out); input [7:0] data; input [:0] addr; output out; assign out = data[addr]; module In this example, a MUX_OP is used to implement data[addr] because the subscript, addr, is not a known constant. This behavior is controlled by the variable hdlin_build_selectop_for_var_index. By default, it is false and MUX_OP components are used for variable subscripting. If it is set to true, SELECT_OP components plus additional control logic are used to implement variable subscripting. No inference report is printed for MUX_OP components, which implement variable indexing. / 3-46

47 Full Case and Parallel Case Case statements are described as full, parallel, or a mix of the two. HDL Compiler can usually determine automatically whether a case statement is full or parallel. This section describes full and parallel case directive usage, and Examples 3-35 through 3-38 illustrate various combinations of full and parallel case code. For more information, see parallel_case Directive on page 7-10 and full_case Directive on page 7-1. Full Case A case statement is said to be full if all possible branches are listed. In the following example, at least one branch will be taken because all possible values of sel are covered, that is, 00, 01, 10, and 11: module mux(a, b,c,d,sel,y); input a,b,c,d; input [1:0] sel; output y; reg y; (a or b or c or d or sel) case (sel) b00 : y=a; b01 : y=b; b10 : y=c; b11 : y=d; case module If a case statement is not full, such as module mux(a, b,c,d,sel,y); input a,b,c,d; input [1:0] sel; output y; / 3-47

48 reg y; (a or b or c or d or sel) case (sel) b00 : y=a; b11 : y=d; case module It is unknown what happens when sel equals 01 and 10. In this case, HDL Compiler generates logic to test for any value that is not covered by the case branches and creates an implicit default branch that contains no actions. When a variable is assigned in a case statement that is not full, the variable is conditionally assigned and requires a latch. Caution! Marking a case statement as full when it actually is not full can cause the simulation to behave differently from the logic HDL Compiler synthesizes because HDL Compiler does not generate a latch to handle the implicit default condition. Parallel Case A case statement is said to be parallel if at most one of the case branches can evaluate to true. In other words, parallel means that no two branches overlap. When a case is parallel, HDL Compiler can avoid generating priority encoding for the branches. When a case statement is not parallel (more than one branch evaluates to true), priority encoding is needed to ensure that the branch listed first in the case statement takes effect. / 3-48

49 Caution! Marking a case statement as parallel when it actually is not parallel can cause the simulation to behave differently from the logic HDL Compiler synthesizes, because HDL Compiler does not generate priority-encoding logic to make sure the branch listed first in the case statement takes effect. Table 3-3 summarizes the types of case statements. Table 3-3 Full and Parallel Case Statements Case statement description Full and parallel Full but not parallel Parallel but not full Not parallel and not full Additional logic No additional logic is generated. Priority-encoded logic: HDL Compiler generates logic to ensure that the branch listed first in the case statement takes effect. Latches created: HDL Compiler generates logic to test for any value that is not covered by the case branches and creates an implicit default branch that requires a latch. Priority-encoded logic: HDL Compiler generates logic to make sure that the branch listed first in the case statement takes effect. Latches created: HDL Compiler generates logic to test for any value that is not covered by the case branches and creates an implicit default branch that requires a latch. Using Design Knowledge In some cases, a designer might know characteristics of a design that would allow a case statement to be implemented as full or parallel, even though HDL Compiler can't determine it. For example, / 3-49

50 the case statement in Example 3-36 is not parallel or full, because the values of inputs w and x cannot be determined. However, if you know that only one of the inputs equals b11 at a given time, you can use the // synopsys parallel_case directive to avoid synthesizing an unnecessary priority encoder. If you know that either w or x always equals b11 (a situation known as a one-branch tree), you can use the // synopsys full_case directive to avoid synthesizing an unnecessary latch. A latch is necessary whenever a variable is conditionally assigned. Marking a case as full tells the compiler that some branch will be taken, so there is no need for an implicit default branch. If a variable is assigned in all branches of the case, HDL Compiler then knows that the variable is not conditionally assigned in that case, and, therefore, that particular case statement does not result in a latch for that variable. However, if the variable is assigned in only some branches of the case statement, a latch is still required as shown in Example 3-38;in addition, other case statements may cause a latch to be inferred for the same variable. Example 3-35 A case Statement That Is Parallel but Not Full input [1:0] a; or w or z) case (a) b11: b = w ; 00: b = z ; case Example 3-36 A case Statement That Is Not Full and Not Parallel or x) case ( b11) w: / 3-50

51 Example 3-37 Example 3-38 b = 10 ; x: b = 01 ; case A case Statement That Is Both Full and Parallel input [1:0] a; or w or x or y or z) case (a) b11: b = w ; b10: b = x ; b01: b = y ; b00: b = z ; case Latch Result When Variable Is Not Fully Assigned reg a, b; reg [1:0] c; case (c) // synopsys full_case 0: a = 1; b = 0; 1: a = 0; b = 0; : a = 1; b = 1; 3: b = 1; // a is not assigned here case Coding if and case Statements for Late-Arriving Signals Designers usually know which signals in a design are late-arriving. This knowledge can be used to structure HDL so that the late-arriving signals are close to the output. This section gives examples of if and case statements for late-arriving signals. / 3-51

52 Note that these techniques apply to HDL Compiler output. When this output is constrained and optimized by Design Compiler, your structure might be changed, deping on such factors as your design constraints and option settings. See the Design Compiler documentation for details. Sequential if Statements: Late-Arriving Data Signal Sequential if statements allow you to structure your HDL based on critical signals. You might want to use sequential if statements if you have a late-arriving signal. Example 3-39 shows code designed to accommodate the late-arriving signal, b_is_late. This code has b_is_late as close as possible to the output z. Example 3-39 MUX Code for b_is_late Data Signal module mult_if_improved(a, b_is_late, c, d, sel, z); input a, b_is_late, c, d; input [3:0] sel; output z; reg z, z1; or b_is_late or c or d or sel) z1 = 0; if (sel[0]) z1 = a; if (sel[]) z1 = c; if (sel[3]) z1 = d; if (sel[1] & ~(sel[] sel[3])) z = b_is_late; else z = z1; module / 3-5

53 a SELECT_OP c SELECT_OP SELECT_OP 0 sel[3] sel[] sel[0] d sel[1] sel[] sel[3] b_is_late sel[3] Control Logic SELECT_OP z Single if Statement: Late-Arriving Control Signal If you have a late-arriving control signal, pull the signal out of the if-else-if statement and push it closer to the output as shown in Example Figure 3-9 shows the structure. Note that CTRL_is_late_arriving is as close to the output as possible. / 3-53

54 Figure 3-9 Structure for Late-Arriving Control Signal A [6] A [5] A [3] A [] A [1] SELECT_OP SELECT_OP SELECT_OP C[1:3,5] Control Logic 5 A [4] z C[1:3] Control Logic C[4] CTRL_is_late_arriving Control Logic / 3-54

55 Example 3-40 MUX Code for Late-Arriving Control Signal module single_if_improved(a, C, CTRL_is_late_arriving, Z); input [6:1] A; input [5:1] C; input CTRL_is_late_arriving; output Z; reg Z; reg Z1; wire Z, prev_cond; or C) if (C[1] == 1 b1) : b1 Z1 = A[1]; else if (C[] == 1 b0) : b Z1 = A[]; else if (C[3] == 1 b1) : b3 Z1 = A[3]; // remove the branch with the late-arriving control signal else if (C[5] == 1 b0): b4 Z1 = A[5];// else Z1 = A[6]; assign Z = A[4]; assign prev_cond = (C[1] == 1 b1) (C[] == 1 b0) (C[3] == 1 b1); or prev_cond or CTRL_is_late_arriving or Z1 or Z) if (C[4] == 1 b1 && CTRL_is_late_arriving == 1 b0) if (prev_cond) Z = Z1; else Z = Z; else Z = Z1; module / 3-55

56 if Statement With Nested case Statement: Late-Arriving Data Signal Example 3-41 shows a case statement nested in an if statement. The data signal DATA_is_late_arriving is late-arriving. Example 3-41 Original Code for case Statement in if Statement module case_in_if_01(a, DATA_is_late_arriving, C, sel, Z); input [8:1] A; input DATA_is_late_arriving; input [:0] sel; input [5:1] C; output Z; reg Z; (sel or C or A or DATA_is_late_arriving) if (C[1]) Z = A[5]; else if (C[] == 1 b0) Z = A[4]; else if (C[3]) Z = A[1]; else if (C[4]) case (sel) 3 b010: Z = A[8]; 3 b011: Z = DATA_is_late_arriving; 3 b101: Z = A[7]; 3 b110: Z = A[6]; default: Z = A[]; case else if (C[5] == 1 b0) Z = A[]; else Z = A[3]; module Figure 3-10 shows the structure implied by the code in Example / 3-56

57 Figure 3-10 Structure Implied by Original Code in Example 3-41 A [] A [6] A [7] DATA_is_late_arriving A [8] SELECT_OP A [3] A [] A [1] A [4] A [5] SELECT_OP z sel Control Logic 5 C Control Logic 6 The late-arriving signal, DATA_is_late_arriving, is an input to the first SELECT_OP in the path. To improve the startpoint for synthesis, modify the HDL to move DATA_is_late_arriving closer to the output Z. You can do this by moving the assignment of DATA_is_late_arriving out of the nested case statement into a separate if statement. This makes DATA_is_late_arriving an input to another SELECT_OP that is closer to the output port Z. Example 3-4 shows the improved version of the code shown in Example / 3-57

58 Example 3-4 Improved Code for case Statement in if Statement module case_in_if_01_improved(a,data_is_late_arriving,c,sel,z); input [8:1] A; input DATA_is_late_arriving; input [:0] sel; input [5:1] C; output Z; reg Z; reg Z1, FIRST_IF; or C or A or DATA_is_late_arriving) if (C[1]) Z1 = A[5]; else if (C[] == 1 b0) Z1= A[4]; else if (C[3]) Z1 = A[1]; else if (C[4]) case (sel) 3 b010: Z1 = A[8]; //3 b011: Z1 = DATA_is_late_arriving; 3 b101: Z1 = A[7]; 3 b110: Z1 = A[6]; default: Z1 = A[]; case else if (C[5] == 1 b0) Z1 = A[]; else Z1 = A[3]; FIRST_IF = (C[1] == 1 b1) (C[] == 1 b0) (C[3] == 1 b1); if (!FIRST_IF && C[4] && (sel == 3 b011)) Z = DATA_is_late_arriving; else Z = Z1; module The structure implied by the modified HDL in Example 3-4 is given in Figure / 3-58

59 Figure 3-11 Structure Implied by Improved HDL in Example 3-4 A [] A [6] A [7] A [0] SELECT_OP SELECT_OP A [3] A [] A [1] A [4] A [5] DATA_is_late_arriving SELECT_OP z sel [:0] Control Logic 4 C [5:1] Control Logic 6 sel [:0] C [4:1] Control Logic case Statement With Nested if Statement: Late-Arriving Control Signal Example 3-43 shows an if statement nested in a case statement. This example assumes that sel[1] is a late-arriving signal. / 3-59

60 Example 3-43 Original Code for if Statement in case Statement module if_in_case(sel, X, A, B, C, D, Z); input [:0] sel; // sel[1] is late arriving input X, A, B, C, D; output Z; reg Z; or X or A or B or C or D) case (sel) 3 b000: Z = A; 3 b001: Z = B; 3 b010: if (X == 1 b1) Z = C; else Z = D; 3 b100: Z = A ^ B; 3 b101: Z =!(A && B); 3 b111: Z =!A; default: Z =!B; case module In Example 3-43, you know that sel[1] is a late-arriving input. Therefore, you should restructure the code in Example 3-43 to get the best startpoint for synthesis. Example 3-44 shows modified code that shifts the depency on sel[1] closer to the output; that is, it moves sel[1] closer to the output and the nested if statement is removed and placed outside the case statement. This code computes two possible values for z into new variables z1 and z. These represent what the final value of z will be if sel[1] is 0 and 1, respectively. Then, a final if statement checks the actual value of sel[1] to select between z1 and z. Because sel[1] is closer to the output, it improves timing if sel[1] is late. / 3-60

61 Example 3-44 Improved Code for if Statement in case Statement module if_in_case_improved(sel, X, A, B, C, D, Z); input [:0] sel; // sel[1] is late arriving input X, A, B, C, D; output Z; reg Z; reg Z1, Z; reg [1:0] i_sel; (sel or X or A or B or C or D) i_sel = {sel[],sel[0]}; case (i_sel) // for sel[1]=0 b00: Z1 = A; b01: Z1 = B; b10: Z1 = A ^ B; b11: Z1 =!(A && B); default: Z1 =!B; case case (i_sel) // for sel[1]=1 b00:if (X == 1 b1) Z = C; else Z = D; b11: Z =!A; default: Z =!B; case if (sel[1]) Z = Z; else Z = Z1; module Priority Encoder Example 3-45 shows code for an 8-to-3 priority encoder using a for loop. A function is used in the example to calculate the highest priority index. / 3-61

62 Example 3-45 Priority Encoder Using Loop Starting With Lowest-Priority Bit module priority_low_high (A, P, F); parameter N = 8; parameter logn = 3; input [N-1:0] A; //Input Vector output [logn-1:0] P; // High Priority Index output F; // Found a one? reg [logn-1:0] P; reg F; function [logn:0] priority; input [N-1:0] A; reg F; integer I; F = 1 b0; priority = {3 b0, F}; for (I=0; I<N; I=I+1) if (A[I]) F = 1 b1; priority = {I, F}; // Override previous index function {P, F} <= priority(a); module Figure 3-1 shows the chain structure implied by the code in Example / 3-6

63 Figure 3-1 Chain Structure for Priority Encoder 1 0 A [0] 1 0 A [1] 1 A [1] A [] A [4] A [3] 1 1 A [3] A [] 1 A [4] A [6] A [5] 1 A [5] 1 A [6] 111 A [7] 1 A [7] P [:0] F Example 3-45 can be modified to create a tree structure. Tree structures generally result in better performance. Decoders Example 3-46 and Example 3-47 show a frequently used coding styles for decoders. Example 3-46 uses a for loop style. / 3-63

64 Example 3-46 Decoder Using for Loop module decoder38_loop (in1, out1); parameter N = 8; parameter logn = 3; input [logn-1:0] in1; output [N-1:0] out1; reg [N-1:0] out1; integer i; for (i=0;i<n;i=i+1) out1[i] = (in1 == i); module Example 3-47 uses an indexing style. Example 3-47 Decoder Using Indexing module decoder_index (in1, out1); parameter N = 8; parameter logn = 3; input [logn-1:0] in1; output [N-1:0] out1; reg [N-1:0] out1; out1 = 0; out1[in1] = 1 b1; module Inferring Decoders To infer decoders, set the hdlin_infer_decoders variable to true and use the templates provided in Example 3-48 and Example In general, anytime you compare a variable with most of its possible values, you infer a decoder. For decoder variable descriptions, see Table 3-4. / 3-64