1. Prof. John Nestor ECE Department Lafayette College Easton, Pennsylvania 18042 nestorj@lafayette.edu ECE 426 - VLSI System Design Lecture 6 - Verilog Coding Guidelines February 12, 2003

2. 2/12/03ECE 426 - Lecture 62 Announcements  Breaking News  Intel announces new “Madison” version of Itanium 2 at International Solid State Circuits Conference (ISSCC) 410 Million Transistors 6 Mbyte L3 Cache Planned for next year: dual-core Itanium 2 with >500M Transistors Gordon Moore keynote: “no exponential is forever” … “but forever can be delayed”  References  M. Keating and P. Bricaud, Reuse Methodology Manual for System on a Chip Designs, Kluwer Academic Publishers, 1999.

3. 2/12/03ECE 426 - Lecture 63 Where we are...  Last Time  Discuss Lab 2  Verification and Testbenches  Today  Verilog Coding Guidelines

4. 2/12/03ECE 426 - Lecture 64 Coding Guidelines  Reasons for coding guidelines  Enhance readability & understandability  Maintainable designs “in the large”  Avoid common pitfalls  Improve chances that design will work in “real life” (as opposed to just during simulation)  Learning what you “should do” vs. what you “can do”  Guidelines vary - choose a set and be consistent

5. 2/12/03ECE 426 - Lecture 65 Guidline Topics  General Coding Guidelines  Module Instantiation and Design Hierarchy  Combinational Logic  Sequential Logic  Finite State Machines

6. 2/12/03ECE 426 - Lecture 66 General Coding Guidelines 1.1Create a separate Verilog file for each module. Name each file.v. 1.2Limit lines to 80 characters or less. 1.3Avoid tabs when indenting. 1.4Use 4 spaces for each level of indentation. 1.5Use a standard header in each Verilog file 1.6Use a uniform naming convention 1.7Use consistent ordering for bit vectors [high:low] 1.8Include Comments 1.9Use symbolic constants with parameter and/or `define 1.10Collect symbolic constants into “include files” 1.11Use consistent order in port lists ( in / out / inout )

7. 2/12/03ECE 426 - Lecture 67 General Coding Guidelines 1.1Create a separate Verilog file for each module. Name each file.v. 1.2Limit lines to 80 characters or less. 1.3Avoid tabs when indenting. 1.4Use 4 spaces for each level of indentation. module counter(clk, rst, ld, d, q_r); input clk; input rst; input [3:0] d; output [3:0] q_r; always @(posedge clk) begin... end endmodule

8. 2/12/03ECE 426 - Lecture 68 General Coding Guidelines - 1.5 Header Files // This confidential and proprietary software // may be used only as authorized by a licensing // agreement from MyCompany, Inc. // (c) COPYRIGHT 2003 MyCompany, Inc. // // The entire notice above must be reproduced // on all authorized copies // // File : counter.v // Author : George Tirebiter // Version : 0.1 // Abstract : A simple 4-bit counter with synchronous // reset and parallel load features. // // CVS Revision History // // $Log: uart_rfifo.v,v $ // Revision 1.2 2002/07/29 21:16:18 georget Legal Stuff Version Control Stuff

9. 2/12/03ECE 426 - Lecture 69 General Coding Guidelines 1.6Use a uniform naming convention  Clock signals: clk or clk1, clk2, …  Reset signbal: rst  Other signals - use “postfix” to indicate type: 1.7Use consistent ordering for bit vectors [high:low] input [3:0] q_r; input [3:0] data; wire [0:3] bogus;

10. 2/12/03ECE 426 - Lecture 610 General Coding Guidelines 1.8Include Comments  Document ports, wires  Explain non-obvious code  Avoid the obvious 1.9Use symbolic constants with parameter and/or `define 1.10Collect symbolic constants into “include files” `include “system_decls.v”

11. 2/12/03ECE 426 - Lecture 611 General Coding Guidelines 1.11Use consistent order in port lists ( in / out / inout )  Inputs: Clocks Resets Enables Other control signals Data  Outputs: Clocks Resets Enables Other control signals Data  Bidirectional (inout) signals

12. 2/12/03ECE 426 - Lecture 612 Hierarchy / Instantiation Guidelines 1.1 Use hierarchy to break design into logical pieces. 1.2Module instances should be named in all caps with a prefix “ U_” (e.g. U_COUNT1). 1.3Avoid mixing structural and behavioral code in a module 1.4Use explicit signal names for module connections: Counter U_COUNT1 (.clk(clk),.enb(enb),.count_r(count_r) ); 1.5Avoid using the positional notation since this is a common source of errors.

13. 2/12/03ECE 426 - Lecture 613 Combinational Logic Guidelines 3.1Use functional descriptions rather than “low- level” logic descriptions. Example:assign cmp_out = (in1 == in2) instead of assign cmp_out = ~|(in1 ^ in2); // is this correct? 3.2Use continuous assignment (assign) statements for simple combinational logic expressions.

14. 2/12/03ECE 426 - Lecture 614 Combinational Logic Guidelines 3.3When using always blocks for combinational logic: ·Assign outputs using the blocking assignment ( = ). ·Remember to declare outputs as reg s. ·Assign a default value to each output to avoid latch inferences. ·Make sure to include all inputs in the sensitivity list e.g.: always( in1, in2, in3) 3.4When coding for synthesis, don’t use delays in combinational logic. 3.5NEVER allow loops in combinational logic.

15. 2/12/03ECE 426 - Lecture 615 Combinational Logic Guidelines 3.5When designing multiplexers, use case instead of if-else-if.

16. 2/12/03ECE 426 - Lecture 616 Sequential Logic Guidelines 4.1Use flip-flops for sequential logic. Avoid using latches. 4.2Assign outputs using nonblocking ( <= ) assignments. 4.3Use an asynchronous reset only for system reset and initialization. NEVER tie an asynchronous reset to the output of a combinational logic function!

17. 2/12/03ECE 426 - Lecture 617 Sequential Logic Guidelines 4.4Synchronize all asynchronous inputs. Consider metastability issues for inputs which change rapidly.

18. 2/12/03ECE 426 - Lecture 618 Sequential Logic Guidelines 4.5Use handshaking to reliably transfer data between clock domains.

19. 2/12/03ECE 426 - Lecture 619 Sequential Logic Guidelines 4.6Use a common clock edge for to trigger all flip- flops in your design. Don’t mix clock edges. 4.7If possible, use a single clock for your entire system. If that isn’t possible, synchronize signals that pass from one clock domain to another. 4.8Avoid gated clocks.

20. 2/12/03ECE 426 - Lecture 620 Sequential Logic Guidelines 4.9Register module outputs to make timing analysis easier.

21. 2/12/03ECE 426 - Lecture 621 FSM Coding Guidelines 5.1Use separate always blocks for the sequential and combinational parts of the FSM. 5.2Define state codes using symbolic constants defined using parameter. Assign the parameter a size to avoid errors parameter [3:0] INIT=4’d0, SETUP=4’d1, …; 5.3Assign a default next state to gracefully handle what happens when the FSM winds up in an unknown state

22. 2/12/03ECE 426 - Lecture 622 Coming Up  More about Testbench Design  System-Level Design

23. 2/12/03ECE 426 - Lecture 623

24. 2/12/03ECE 426 - Lecture 624

25. 2/12/03ECE 426 - Lecture 625 More Testbench Guidelines  Use abstraction  Identify higher-level behaviors, common cases, e.g. System reset Counter rollover Bus transaction Instruction execution  Write Verilog tasks (subroutines) to generate stimulus  Write tasks to check response

26. 2/12/03ECE 426 - Lecture 626 Testbench Coding for Sequential Circuits?

27. 2/12/03ECE 426 - Lecture 627 Coding Guidelines - File / Module Structure  Include a header block in each file  Name  Date  One file per module  Commenting  Give Signals, Ports, and Variables Meaningful Names  Use a consistent naming scheme  Use Symbolic Constants

28. 2/12/03ECE 426 - Lecture 628 Coding Guidelines Module Instantiation and Hierarchy  Use long form for module connections  Avoid mixing module instantiations and procedural code

29. 2/12/03ECE 426 - Lecture 629 Coding Guidelines- Combinational Logic  Use functional descriptions to enhance reasability  Use assign statements for simple logic  Avoid latch inferences  Make sure always block sensitivity lists are complete

30. 2/12/03ECE 426 - Lecture 630 Coding Guidelines - Sequential Logic  Avoid latches  Use asynchronous reset only for system reset & initialization  Consider using registered outputs  Synchronize asynchronous system inputs  If possible use a single clock  If a single clock isn’t possible

31. 2/12/03ECE 426 - Lecture 631 Coding Guidelines - Finite State Machines

32. 2/12/03ECE 426 - Lecture 632 Architecture Design (Ch. 8)  Goal: design high-level organization of chip  Organization is usually described using the register transfer abstraction  Describes system as connected network of Registers Combinational logic  Treats overall design as a large sequential circuit  Specifies system function on a cycle-by-cycle basis  Used as an input specification for logic synthesis (e.g., Synopsys) tools

33. 2/12/03ECE 426 - Lecture 633 The Datapath-Controller Abstraction  A higher-level description of chip organization  Key idea: break up design into two parts:  Datapath- components that manipulate data  Controller - FSM that controls datapath modules

34. 2/12/03ECE 426 - Lecture 634 Steps in Architecture Design  Propose data unit components  functions performed  data inputs / outputs  control inputs - perform operation when asserted  status outputs - condition info for control unit  Design control-unit FSM  Respond to ext. inputs, status values from data unit  Generate control signals to drive data unit, external outputs  Control-Unit Representations Traditional "bubble and arrow" state diagram Algorithmic State Machine (ASM) diagrams

35. 2/12/03ECE 426 - Lecture 635

36. 2/12/03ECE 426 - Lecture 636

37. 2/12/03ECE 426 - Lecture 637 Verification Plan  Definition: A Specification of the Verification Effort  Prerequisite: Specification document for design  Defnining Success - Must Identify  Features which must be exercisedunder which conditions  Expected Response

38. 2/12/03ECE 426 - Lecture 638 Levels of Verification  Board  System / Subsystem  ASIC / FPGA  Unit / Subunit

39. 2/12/03ECE 426 - Lecture 639 Levels of Verification  Connectivity  Transaction / Cooperative Data Flow  Functionality  Ad Hoc  Designer verifies basic functionality

40. 2/12/03ECE 426 - Lecture 640 Levels of Verification - Notes  Stable interfaces required at each level of granularity

41. 2/12/03ECE 426 - Lecture 641 Rules for Style  Optimize the Right Thing  Good Comments Improve Maintainability  Encapsulation Hides Implementation Details

42. 2/12/03ECE 426 - Lecture 642 Lab 3 Overview  Self-checking testbench for generic counter  Identify important features  Create conditions that test these features  Check conditions  Write message when error occurs  “Insert” errors to demonstrate when self-check fails  Test for varying values of N (2, 8, 10, 16)

43. 2/12/03ECE 426 - Lecture 643 System Design Issues  ASM Diagrams  Synchronization & Metastability  Handshaking  Working with Multiple Clocks