1. ECE 551 Digital System Design & Synthesis Lecture 11 Verilog Design for Synthesis

2. Topics Optimization from the Design Level  Interaction of Description and Synthesis  Critical Path Optimization  High-Level Architectures for Datapaths 2

3. Overview  In the previous lecture, we looked at ways the synthesis tool can automatically optimize our logic  In this lecture, we will look at the ways the designer who is writing the HDL code can optimize and manage trade-offs. 3

4. Overview  How you implement something in Verilog can have a profound effect on what is actually synthesized (and the effort required to do it!)  Functionally identical ≠ identical hardware  To be effective, you need to  Know what it is that you are trying to describe (i.e. not viewing Verilog as an abstract language)  Know how the desired hardware should be organized  Know how the synthesis tools will be likely to implement a given description  Describe the hardware in a way that causes the synthesis tools to do what you want 4

5. Knowing what you want to describe Case Study: Multiplier 5

6. 4-Input Multiplier 6 module mult(output reg [31:0] out, input [31:0] a, b, c, d); always@(*) begin out = ((a * b) * c) * d; end endmodule  What does the below code describe?

7. Multiplier Implementation 7  Area: 47381  Delay: 8.37  How can we improve the delay and/or area?

8. Multiplier Redux 8 module multtree(output reg [31:0] out, input [31:0] a, b, c, d); always@(*) begin out = (a * b) * (c * d); end endmodule  What are we describing?  How will it compare in speed and area?

9. Tree Multiplier 9  Area: 47590 vs. 47381  Delay: 5.75 vs. 8.37

10. Multiplier – once again... 10 module multtree(output reg [31:0] out, input [31:0] a, b, c, d); always@(*) begin out = (a * b) * (c * d); end endmodule  How can we reduce the area?

11. Shared Multiplier [1] 11 module multshare(output reg [31:0] out, input [31:0] in, input clk, rst); reg [31:0] multval; reg [1:0] cycle; always @(posedge clk) begin if (rst) cycle <= 0; else cycle <= cycle + 1; out <= multval; end always @(*) begin if (cycle == 2'b0) multval = in; else multval = in * out; end endmodule

12. Shared Multiplier [2] 12  Area: 15990 vs. 47590  Critical Path Delay: 3.14  Latency: 3.14 * 4 = 12.56 vs. 5.75

13. Shared Multiplier (cont) 13 module multtree(output reg [31:0] out, input [31:0] a, b, c, d); always@(*) begin out = (a * b) * (c * d); end endmodule  Given that only one multiplier will be allowed for the implementation, could we have done better on the latency than the previous example did? At what cost?

14. Knowing what you want to describe Lesson: You need to think about what sort of hardware you want to design from the very beginning of the process. Synthesis tools will only do so much with the descriptions you give them. 14

15. Knowing what you are describing Case Study: Mixed Flip-Flops 15

16. Mixing Flip-Flop Styles (1) 16 module badFFstyle (output reg q2, input d, clk, rst_n); reg q1; always @(posedge clk) if (!rst_n) q1 <= 1'b0; else begin q1 <= d; q2 <= q1; end endmodule  Say we don’t need to reset q2  What will this synthesize to?

17. Flip-Flop Synthesis (1) 17  Area = 59.0  Slack = 0.53 (clock = 1ns, input delay 0.2)  Q2 now has to implement a load enable that is connected to the reset

18. Mixing Flip-Flop Styles (2) 18 module goodFFstyle (output reg q2, input d, clk, rst_n); reg q1; always @(posedge clk) if (!rst_n) q1 <= 1'b0; else q1 <= d; always @(posedge clk) q2 <= q1; endmodule

19. Flip-Flop Synthesis (2) 19  Area = 50.2 (85% of original area!)  Slack = 0.53 (unchanged)  Without the load enable function, flip flop Q2 is smaller.  Use reset and enable only when you need them!

20. Mixing Flip-Flop Styles 20 module badFFstyle2 (output reg q2, input d, clk, rst_n); reg q1; always @(posedge clk, negedge rst_n) if (!rst_n) q1 <= 1'b0; else begin q1 <= d; q2 <= q1; end endmodule  Would an asynchronous reset have fixed it?

21. Flip-Flop Synthesis (3) 21  Using asynchronous reset instead  Bad: Area = 58.0, slack = 0.57  Good: Area = 49.1, slack = 0.57

22. Knowing what you are describing Lesson: If you don’t know the rules of the language, it’s easy to describe something different than what you intended. Following coding style guidelines makes this easier. 22

23. Knowing the interpretation Case Study: Conditional Multiplier 23

24. Conditional Multiplier [1] 24 module multcond1(output reg [31:0] out, input [31:0] a, b, c, d, input sel); always @(*) begin if (sel) out = a * b; else out = c * d; end endmodule What would you expect this to generate?

25. Conditional Multiplier [2] 25  Area: 15565  Delay: 3.14 Two 32-bit muxes and one multiplier!

26. Selected Conditional Multiplier [1] 26 module multcond2(output reg [31:0] out, input [31:0] a, b, c, d, input sel); wire [31:0] m1, m2; assign m1 = a * b; assign m2 = c * d; always @(*) begin if (sel) out = m1; else out = m2; end endmodule What do you expect here compared to the previous one?

27. Selected Cond. Mult. [2] 27  Area: 30764 vs. 15565  Delay: 3.02 vs. 3.14  Why is the area larger and delay lower?  2 multipliers and a 64-bit mux!  So why did that happen?

28. Resource Sharing Rules 28  Can happen automatically if variable is assigned by multiple expressions (if/else) with the same operation and bit widths  NO combinational feedback can be caused  Inputs may be reordered to reduce mux area  The Verilog HDL Compiler operates according to the following rules for automatic sharing  No sharing in conditional operators x = s ? (a+b) : (a+c); //will use two adders  If/else will permit sharing  Manual control is also available – see reading.

29. Conditional Multipler – One More Time 29  If you know ahead of time that you want two muxes and one multiplier, describe that directly!  Don’t rely on the synthesis tool to improve inefficient HDL; describe what you want first.  Caveat: You have to know what you want. module multcond2(output reg [31:0] out, input [31:0] a, b, c, d, input sel); wire [31:0] op1, op2; assign op1 = sel ? a : c; assign op2 = sel ? b : d; always @(*) begin out = op1 * op2; endmodule

30. Knowing the interpretation Lesson: Different ways of describing the same behavior in Verilog may lead to different results. Understanding how the synthesis tool interprets different Verilog constructs is a valuable skill to becoming an expert designer. 30

31. Knowing the Synthesis Tool Case Study: Decoder Synthesis 31

32. Decoder Synthesis 32  Parameterized decoders are commonly written in one of two ways in Behavioral Verilog  Use the select input as an index to assert only the desired output after negating all outputs  Test the select input in a loop for all decoder outputs, and only asserted the matching output  Will this choice affect  Circuit delay?  Circuit area?  Compiler time?  Surprisingly, the answer is: Yes, quite a lot, even though we are trying to describe the exact same hardware!

33. Decoder Using Indexing 33

34. Decoder Using Loop 34

35. Decoder Verilog: Timing Comparison 35

36. Decoder Verilog: Area Comparison 36

37. Decoder Verilog: Compile Time Comparison 37

38. Knowing the Synthesis Tool Lesson: Never forget that in the end, you are at the mercy of the synthesis tool. Even when something is part of the Verilog Standard, you can’t always be sure it will be supported (or supported well) by every tool. This knowledge comes with time. 38

39. Putting it all Together  If we  Know what hardware we want  Know how to describe what we want  Can interpret the results we get from the synthesis tool  Now we can begin making low-level optimizations 39

40. Late-Arriving Signals  After synthesis, we can identify the critical path(s) that are controlling the overall circuit speed, and which signals are responsible for those path(s).  Assume that one signal to a block of logic is known to arrive after the others. To deal with this:  Circuit reorganization  Rewrite the code to restructure the circuit in a way that minimizes the delay with respect to the late arriving signal  Logic duplication  This is the classic speed-area trade-off. By duplicating logic, we can move signal dependencies ahead in the logic chain. 40

41. Original Code 41

42. Original Synthesis 42 What can we do if A is the late-arriving signal?

43. Reorganized: Operator In if 43 Changed the operation from (A + B) < 24 to A < (24 – B)

44. Reorganized: New Hardware 44 What’s going on here?

45. Duplication Example: Original Design 45

46. Original Hardware 46 ADDRESS PTR OFFSET ADDR What if control is the late arriving signal?

47. Data Duplication : New HDL Code 47

48. Duplication: New Hardware 48 OFFSET1 OFFSET2 ADDR1 ADDR2 COUNT2 COUNT1

49. Exercise 49  Assume we are implementing the below code, and cin is the late arriving signal. How can we optimize the resulting hardware for speed? At what cost? reg [30:0] a, b; reg [31:0] y; reg cin; always@(*) y = a + b + cin;

50. Exercise 50  Rewrite the code below to  1. Minimize area  2. Best performance if sel is late-arriving reg [3:0] x [3:0]; reg [1:0] sel; reg [3:0] y, sum; always@(*) y = sum + x[sel];

51. Exercise 51  Revise to maximize performance wrt late reg [3:0] state; reg late, y, x1, x2, x3; always@(*) case(state) SOME_STATE: if (late) y = x1; else y = x2; default: if (late) y = x1; else y = x3; endcase

52. 52 First, consider how it will synthesize

53. Optimized Example 53  If you have a small number of case items, the case select signal will be shorter path, but may be a long path with a lot of case items.  For non-parallel case statements, the body of first case item may have a much shorter path than that of the default case.  If it is a parallel case statement, the case select signal will be a short path.  Strategy: If possible, move the late signal to the case select or limit it to the first case item.

54. Dealing with late signals in Case 54 reg [3:0] state; reg late, y, x1, x2, x3; always@(*) case(late) 1’b0:if(state == SOME_STATE) y = x2; else y = x3; 1’b1: y = x1; endcase

55. High-Level Datapath Strategies  Low-level optimizations can be very valuable, but from a design perspective, the most important decisions are made at a high level.  Next we will look at three different ways of architecting a datapath and evaluate their trade- offs  Single-cycle  Multi-cycle  Pipelined 55

56. Single-cycle Multiplier  Complete a single computation in one cycle. 56

57. Multi-cycle Multiplier  Spread one operation over multiple cycles.  One active computation.  Share parts of the datapath to reduce area 57

58. Pipelined Multiplier  Spread one operation over multiple cycles.  Multiple active computations.  Need extra pipeline registers. 58

59. Evaluating Tradeoffs  Why might we choose one of these over the other?  Area – self-explanatory  Throughput – What is the rate of results?  Product of Frequency and Results/cycle  Latency – How long does it take to produce one result?  Product of Frequency and Cycles/computation 59

60. Single-cycle Multiplier  Assume the following delays: 32-bit Mult: 6 ns, 64-bit mult 10 ns, Reg Setup: 2 ns Compute the Throughput and Latency 60

61. Multi-cycle Multiplier  Assume Control Logic not on critical path  128-bit mux: 3 ns, hybrid multiplier: 7 ns 61

62. Pipelined Multiplier 62

63. Summary  High-Level Strategies for tradeoffs between Area, Latency, and Throughput  Single cycle  Good: latency – (one long cycle)  Mixed: throughput - (one output per cycle, but low freq)  Bad: area  Multi-cycle  Good: area – (share hardware)  Bad: throughput, latency – (<1 output per cycle)  Pipelined  Good: throughput – (one output per cycle, high freq)  Bad: latency, area – (multiple cycles, extra registers) 63

64. Conclusions  The designer is responsible for some optimizations that cannot be achieved by the synthesis tool.  It takes a lot of knowledge to be an expert designer  Hardware Design  HDL  Synthesis Tool  One of the largest roles of the designer is to understand tradeoffs and make appropriate decisions 64