SystemVerilog Lecture 3. Prof. Gerald E. Sobelman Dept. of Electrical and Computer Engineering University of Minnesota Minneapolis, MN USA

Transcription

1 SystemVerilog Lecture 3 Prof. Gerald E. Sobelman Dept. of Electrical and Computer Engineering University of Minnesota Minneapolis, MN USA 1

2 Outline Design Example: Booth Multiplier Design Example: 4-point DFT Functions and Tasks: General Issues Module Prototypes Named Port Connections Net Aliases Introduction to Interfaces 2

3 Booth Encoding Booth encoding techniques are used to reduce the number of terms that must be added. Various forms of Booth encoding techniques have been proposed. As an illustration, we will focus on one variation (usually called modified Booth encoding) that reduces the number of partial products that must be added by a factor of two. The method is valid for signed operands and results. We assume that the number of bits, n, in the multiplier operand Y is an even number. 3

4 Booth Encoding Cont. First, consider those cases where Y > 0. Since the bit y n-1 = 0, we can write: Y = n 1 y k k = 0 Each term in the summation can be written as: yk k 1 k 2 2yk yk yk k yk k = ( ) = Use the above expansion for the odd-k terms in the summation for Y to obtain: n n 2 n 2 n 2 n 1 n 1 n 2 n Y= ( y 2 2y 2 ) + y 2 + ( y 2 2y 2 ) + y 2 + L + ( y 2 2y 2 ) + y 2 + ( y 2 2y 2 ) + y 2 2 k n 3 n 4 n 4 n 4 4

5 Booth Encoding Cont. Defining y -1 = 0 and collecting together terms having the same power of two gives: n n 2 n 1 n 1 n 2 n Y= y 2 + ( 2y + y + y ) 2 + ( 2y + y + y ) 2 + L + ( 2y + y + y ) 2 + ( 2y + y + y ) 2 n 3 n 4 n 5 The first term drops out since y n-1 = 0. Define a new set of coefficients z k for k = even #: zk 2yk+ 1+ yk + yk 1, for k = 0, 2, 4, L, n 2 Then, we can re-write the expressions for Y and P in terms of z k as follows: n Y = z 2, P = X Y = ( z X ) 2 k = 2 0 k k 0 n k = 2 0 k n 4 k 5

6 Booth Encoding Cont. Notice what this says: We now have to generate and sum only n/2 partial products z k X instead of the original n partial products y k X. This represents a considerable savings in the required hardware. The only mitigating factor is that each partial product is slightly more complex to generate. Since each z k depends on the values of 3 adjacent multiplier bits (y k+1, y k and y k-1 ), there are 8 possible cases to consider. The corresponding value of z k in each of the 8 cases is shown in the table on the following page. Thus, we will have to be able to generate the following partial products: 0, X, -X, 2X and -2X. We can obtain these easily by generating the two s complement and shifting left by one bit position position. 6

7 Booth Encoding Cont. Using the equation for z k, we obtain the following table of the 8 possible cases: y k+1 y k y k-1 z k = -2y k+1 + y k + y k

8 8x8 Signed Booth Multiplier It can be shown that the previous result also holds for the case where the Y operand is negative. For an 8x8 multiplier design, we will generate 4 partial products (call them a, b, c and d): Negative partial products X, -2X can be implemented as a one's complement plus 1 to the LSB position. Multiplication by 2 (for 2X, -2X) can be implemented as a shift left by one bit position. The partial products have to be sign-extended to 16 bits, which creates a large number of additional bits. It is possible to separately sum the duplicated bits and replace the original array of terms with a simplified array of terms. 8

9 Multiplier Code (cont. on next 2 pages) // behavioral model for a Booth-encoded 8x8 signed multiplier // 16-bit output => interpreted as a 16-bit signed number // simplified array structure after sign-extension terms combined module booth16(input logic signed [7:0] x, y, output logic signed [15:0] p); logic [8:0] a, b, c, d; logic u0, u1, u2, u3; wire [15:0] pp0, pp1, pp2, pp3, pp4; // perform the booth encoding always_comb begin case (y[1:0]) 2'b00 : begin a = 9'b ; u0 = 0; end // 0 2'b01 : begin a = {x[7], x[7:0]}; u0 = 0; end // 1 2'b10 : begin a = {~x[7:0], 1'b1}; u0 = 1; end // -2 2'b11 : begin a = {~x[7], ~x[7:0]}; u0 = 1; end // -1 endcase 9

10 case (y[3:1]) 3'b000 : begin b = 9'b ; u1 = 0; end // 0 3'b001 : begin b = {x[7], x[7:0]}; u1 = 0; end // 1 3'b010 : begin b = {x[7], x[7:0]}; u1 = 0; end // 1 3'b011 : begin b = {x[7:0], 1'b0}; u1 = 0; end // 2 3'b100 : begin b = {~x[7:0], 1'b1}; u1 = 1; end // -2 3'b101 : begin b = {~x[7], ~x[7:0]}; u1 = 1; end // -1 3'b110 : begin b = {~x[7], ~x[7:0]}; u1 = 1; end // -1 3'b111 : begin b = 9'b ; u1 = 0; end // 0 endcase case (y[5:3]) 3'b000 : begin c = 9'b ; u2 = 0; end // 0 3'b001 : begin c = {x[7], x[7:0]}; u2 = 0; end // 1 3'b010 : begin c = {x[7], x[7:0]}; u2 = 0; end // 1 3'b011 : begin c = {x[7:0], 1'b0}; u2 = 0; end // 2 3'b100 : begin c = {~x[7:0], 1'b1}; u2 = 1; end // -2 3'b101 : begin c = {~x[7], ~x[7:0]}; u2 = 1; end // -1 3'b110 : begin c = {~x[7], ~x[7:0]}; u2 = 1; end // -1 3'b111 : begin c = 9'b ; u2 = 0; end // 0 endcase 10

11 case (y[7:5]) 3'b000 : begin d = 9'b ; u3 = 0; end // 0 3'b001 : begin d = {x[7], x[7:0]}; u3 = 0; end // 1 3'b010 : begin d = {x[7], x[7:0]}; u3 = 0; end // 1 3'b011 : begin d = {x[7:0], 1'b0}; u3 = 0; end // 2 3'b100 : begin d = {~x[7:0], 1'b1}; u3 = 1; end // -2 3'b101 : begin d = {~x[7], ~x[7:0]}; u3 = 1; end // -1 3'b110 : begin d = {~x[7], ~x[7:0]}; u3 = 1; end // -1 3'b111 : begin d = 9'b ; u3 = 0; end // 0 endcase end // form the partial product terms assign pp0 = {7'b , ~a[8], a[7:0]}; assign pp1 = {5'b00000, ~b[8], b[7:0], 2'b00}; assign pp2 = {3'b000, ~c[8], c[7:0], 4'b0000}; assign pp3 = {1'b0, ~d[8], d[7:0], 6'b000000}; assign pp4 = {1'b1, 1'b0, 1'b1, 1'b0, 1'b1, 1'b0, 2'b11, 1'b0, u3, 1'b0, u2, 1'b0, u1, 1'b0, u0}; // add up the partial product terms assign p = pp0 + pp1 + pp2 + pp3 + pp4; endmodule 11

12 Exhaustive Testbench (cont. on next page) module tb16; // testbench for the 8-bit by 8-bit Booth multiplier // exhaustive checking of all 256*256 possible cases logic signed [7:0] x, y; // 8-bit inputs logic signed [15:0] p; // 16-bit output of the multiplier circuit int check; // value used to check correctness int num_correct = 0; // counter to keep track of number correct int num_wrong = 0; // counter to keep track of number wrong // instantiate the 8-bit by 8-bit Booth-encoded signed multiplier booth16 mult_instance(x, y, p); 12

13 // exhaustive simulation of all 256*256 = 65,536 possible cases initial begin // loop through all possible cases and record the results for (int i = 0; i < 256; i++) begin x = i; for (int j = 0; j < 256; j++) begin y = j; check = x*y; // compute and check the product #10 if (p == check) num_correct += 1; else num_wrong += 1; end end // following line is commented out, but is useful for debugging // $display("%d * %d = %d (%d)", x, y, p, check); // print the final counter values $display("num_correct = %d, num_wrong = %d", num_correct, num_wrong); end endmodule 13

14 Output Produced by the Testbench num_correct = 65536, num_wrong = 0 If the debug statement is not commented out, then a portion of the output produced by that $display statement is as follows: * 100 = ( -5600) -56 * 101 = ( -5656) -56 * 102 = ( -5712) -56 * 103 = ( -5768) -56 * 104 = ( -5824) -56 * 105 = ( -5880) -55 * 100 = ( -5500) -55 * 101 = ( -5555)... 14

15 A Complex Data Type and Add Function We can use structures to conveniently represent complex numbers: // complex data type typedef struct { int r, i; // real and imaginary parts } complex; // complex adder function function complex ComplexAdd (input complex x, y); ComplexAdd.r = x.r + y.r; ComplexAdd.i = x.i + y.i; endfunction 15

16 Complex Subtract and Multiply Functions // complex subtractor function function complex ComplexSub (input complex x, y); ComplexSub.r = x.r - y.r; ComplexSub.i = x.i - y.i; endfunction // complex multiplier function function complex ComplexMul (input complex x, y); ComplexMul.r = (x.r * y.r) - (x.i * y.i); ComplexMul.i = (x.r * y.i) + (x.i * y.r); endfunction 16

17 4-point Discrete Fourier Transform (DFT) The 4-point DFT is defined as: for k = 0, 1, 2, 3, and where W is given by: The W kn are called "twiddle factors" and we can compute the first few of them as follows: W 0 = 1, W 1 = -j, W 2 = -1, W 3 = j 17 = = 3 0 ) ( ] [ n kn W n x k X j e e W j j = = = 2 / 4 2 π π

18 4-point DFT Module // 4-point Discrete Fourier Transform module dft4 (input complex x[4], output complex X[4]); complex W[4] = '{'{1, 0}, '{0, -1}, '{-1, 0}, '{0, 1}}; complex twiddle; always_comb for (int k = 0; k < 4; k++) begin X[k] = '{0, 0}; twiddle = '{1, 0}; for (int n = 0; n < 4; n++) begin X[k] = ComplexAdd(X[k], ComplexMul(x[n], twiddle)); twiddle = ComplexMul(twiddle, W[k]); end end endmodule 18

19 A Simple Testbench module tb1dft4; // simple 4-point DFT testbench complex x[4], X[4]; // inputs and outputs // instantiate the 4-point dft module dft4 instance1(x, X); initial begin // assign input values x = '{'{1, 2}, '{3, 4}, '{5, 6}, '{7, 8}}; // compute and the DFT results #10 $display("x[0] = %d + %d j", X[0].r, X[0].i); $display("x[1] = %d + %d j", X[1].r, X[1].i); $display("x[2] = %d + %d j", X[2].r, X[2].i); $display("x[3] = %d + %d j", X[3].r, X[3].i); end endmodule 19

20 Testbench Output and Matlab Check The output from the testbench is: X[0] = j X[1] = j X[2] = j X[3] = j A check using Matlab gives the same results: >> x = [1+2j, 3+4j, 5+6j, 7+8j] x = i i i i >> X=fft(x) X = i i i 20

21 Functions and Tasks: General Issues A function cannot consume time, i.e.: It cannot have any delay statements It cannot have any event-control statements. A function cannot call a task. Void functions can be called from any function or task. They are useful for implementing debug routines containing $display statements. begin... end is not needed in either functions or tasks. 21

22 Functions & Tasks: General Issues Cont. The default direction for arguments is input. The default type for arguments is logic. task my_task(x, y, z, output int a, b, c); In the above example, x, y and z are input logic, while a, b and c are output int. 22

23 Functions & Tasks: General Issues Cont. In order to improve the readability of large designs, it is possible to include the name of the function or task in the endfunction or endtask statement. For example: function my_function(a, b)... endfunction : my_function task my_task(x, y, z, output int a, b, c);... endtask : mytask 23

24 Module Prototypes: extern module A module prototype is a way of specifying the module name and its inputs and outputs without specifying the behavior or structure of the module: extern module adder(a, b, s, cout); An alternate way of writing it is: extern module adder( input logic [31:0] a, b, output logic [31:0] s, output logic cout); 24

25 Application of Module Prototypes A commonly used Verilog design organization technique is to place each module into a separate file. (Also, the name of the file is usually chosen to be the same as the name of the module it contains.) However, this makes it more difficult to compile designs when a module instantiates other modules, since more than one file must be compiled as a group. Using module prototypes simplifies the compilation process: If a module A instantiates module B, then file A.sv containing module A can also contain the module prototype for module B. Then, the file A.sv can be compiled separately. 25

26 Visibility of Module Prototypes There are two possible locations in a file that a module prototype statement may be placed: If the extern module statement is placed outside of any other module, then it will be visible by any other module. If the extern module statement is placed within some module, then it is visible within the scope of that module. 26

27 Use of the.* with Module Prototypes When we use a module prototype, it seems like we have to list the module arguments twice: once in the module prototype statement again when we define the actual module itself This redundancy (and possible source of errors if the argument lists do not match exactly) can be avoided by using the.* feature: List the arguments explicitly in the module prototype. Use.* as the argument of the module itself. In this case, the compiler will automatically use the arguments specified in the module prototype. 27

28 Example of Using.* Suppose we have a module prototype statement: extern module adder( input logic [31:0] a, b, output logic [31:0] s, output logic cout); Then the adder module can be defined as: module adder(.*); always_comb assign {cout, s} = a + b; endmodule 28

29 Modules Defined Within Other Modules Usually, all modules in a design are global, i.e. they are visible to the entire design. Alternatively, it is possible to use nested modules, i.e. defining one module inside of another module. In this case, the nested module is only visible within the scope of the parent (i.e., the enclosing) module. This helps to reduce accidental "name collisions" in a large design, especially a design that is created by a team of people or one which uses Intellectual Property (IP) from a third party. 29

30 Named Port Connections with.name When a module is instantiated within another module, we must specify the connections between the port names and the signal names connected to those ports. While positional association can be used (i.e., listing the signals in the same order as they were declared in the module definition), it is not good for large designs since errors can be created inadvertently. Therefore, named association is the preferred method for large designs. Can use either the.name or the.* syntax. 30

31 Named Port Connections Using.name If the name of the port is the same as the name of the signal, then it can just be listed once using the.name format: adder a1(.a,.b,.s,.cout); If the name of the port is different than the name of the signal being connected to it, then both names must be used at that port: adder a1(.a(in1),.b(in2),.s,.cout); Here, the port and signal names for s and cout are the same, while the signal names in1, in2 used at the a, b input ports are not the same. 31

32 Implicit Port Connections Using.* If the names of the ports and the signals all match, then it is not necessary to even list them: adder a1 (.* ); When.* is used, all ports and signals having the same name will be automatically connected to each other. You can also put in some explicit named associations for some of the ports when those names are different: adder a1(.a(in1),.b(in2),.*); 32

33 Net Aliases Using alias Sometimes it is convenient to have more than one name for the same net in a design. This can be done using an alias statement. For example: alias clock = CLOCK = clk = CLK; This simply means that all four names refer to the same net. They can all be used interchangeably in a design. Note: Only net data types (i.e., typically the wire type) can be used in an alias statement. 33

34 Module Ports: input, output, inout Any data type can be used in module ports: Packed or unpacked arrays, structures and unions can all be used at ports. The formats of unpacked data types must be the same on both sides of the port, i.e.: Arrays must be of the same dimensions and element sizes. Structures and unions must use the same type definition. The default port direction is inout. The default data type is wire. 34

35 Module Reference Ports: ref In SystemVerilog, ports may also be of another type known as reference ports using the keyword ref. This is like "call by reference" in C/C++. The port passes a reference to a quantity, rather than the quantity itself. In other words, the port name acts like an alias to the quantity. This is done by declaring the port to be of type ref. Note that ports of type ref are not synthesizable. 35

36 Declaring Variables to Be Local It is possible to declare variables to be local to a begin/end or fork/join block. The block may be either named or unnamed. If the block is named, then it is possible to refer to the variable using a hierarchical name notation (i.e., using the dot notation). If the block is unnamed, then it is not possible to refer to the variable using a hierarchical notation. 36

37 Example: Local Variable in a Named Block A variable k which is local to a block named block1: module ex1;... begin : block1 int k;... end : block1 // optional block name used... endmodule : ex1 // optional module name used Another module (typically a testbench) can then refer to this variable using the hierarchical name: ex1.block1.k 37

38 Ex: Local Variable in an Unnamed Block A variable k which is local to an unnamed block: module ex2;... begin int k;... end... endmodule : ex2 // optional module name used Here, it is not possible for another module to refer to the local variable k. 38

39 Interfaces An interface groups several signals together into a single unit. This is then treated as a single port of type interface. All of the information about these signals is specified in one place (the interface declaration) and then any number of modules can use that information. This information is declared only once, rather than having to be declared multiple times, i.e. once in each module. 39

40 Simple Interface: A Bundle of Wires We can simply bundle a set of wires together and give it a name. For example: interface bus; logic [15:0] address, data; logic read, write; endinterface The name of this interface is called bus. It bundles together 16-bit address and data signals, and a read and a write signal. We can now create instances of this interface: bus bus1; // bus1 is the unique instance name 40

41 Using the Interface To access individual signals within the interface, use the "dot" notation, e.g.: bus1.address bus1.data bus1.read bus1.write An interface can be used to connect modules together. To do this, those modules would declare a port to be an interface of that type, e.g.: module fft (bus fft_bus); This declares a port of type bus called fft_bus. 41

42 Including Ports in an Interface The previous example was a "port-less" interface. It is also possible to add ports to an interface. These ports may be of type input, output or inout. This allows those port signals to be shared with other interfaces. A common situation is to include a clock signal as an input port in an interface: interface newbus (input clock); logic [15:0] address, data; logic read, write; endinterface 42

43 Generalizing Interfaces with Parameters Use the #(parameter... ) construction to provide flexibility and generality to an interface. In the interface declaration, this is placed after the name of the interface and before the port list. In the body of the interface declaration, the parameter value can be used with procedural statements to initialize values or to provide some desired behavior. When creating an instance of that interface, include the # symbol with a specific value that you want the parameter to have for that instance. 43

44 Using the Interface To use the interface within a module: Create an instance of the interface. Create an instance of each module which connects to that interface. Can use the.* notation to simplify the port connections. Example code within a module which connects two processors (gp1 and fp1) to a bus (bus1): my_bus bus1 (.* ); gen_purp_proc gp1 (.* ); fft_proc fp1 (.* ); 44

45 Global vs. Local Interfaces A global interface: To make the interface visible to any module in the design, place the interface definition outside of any module. A local interface: To restrict the interface to be local to a given module, place the interface definition inside that module. 45

46 Named vs. Generic Interface Ports There are two ways of using interface ports: Named: In the port list of the module, give both the name of the interface and the name of the port. An example where the interface name is bus and the port name is bus_a is: module example_named(bus bus_a); Generic: In the port list of the module, use the keyword interface followed by the name of the port: module example_generic(interface bus_a); The generic type is more flexible since any type of interface can be connected when the module is instantiated. 46

47 Restricting Access using modport We can provide direction information to signals in the interface using the modport statement. The direction is the one seen from inside the module. The same signal may appear in more than one modport statement, with different directions. interface two_way; wire w, x, y, z; modport block_a (input w, x, output y, z); modport block_b (input y, z, output w, x); endinterface 47

48 References IEEE Standard for SystemVerilog Unified Hardware Design, Specification, and Verification Language, IEEE, IEEE Std 1800 TM -2005, 22 November S. Sutherland, S. Davidmann and P. Flake, SystemVerilog for Design, Kluwer Academic Publishers, C. Spear, SystemVerilog for Verification, Springer, SystemVerilog Tutorials, Doulos Ltd., SystemVerilog Tutorial, electrosofts.com, 48