ECE 426 VLSI System Design Lecture 6 Verilog

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

Announcements } Breaking News } Intel announces new “Madison” version of Itanium 2 at International Solid State Circuits Conference (ISSCC) • 410 Million Transistors • 6 Mbyte L 3 Cache • Planned for next year: dual-core Itanium 2 with >500 M 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. 2/12/03 ECE 426 - Lecture 6 2

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

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 2/12/03 ECE 426 - Lecture 6 4

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

General Coding Guidelines 1. 1 Create a separate Verilog file for each module. Name each file <module_name>. v. 1. 2 1. 3 1. 4 1. 5 1. 6 1. 7 Limit lines to 80 characters or less. Avoid tabs when indenting. Use 4 spaces for each level of indentation. Use a standard header in each Verilog file Use a uniform naming convention Use consistent ordering for bit vectors [high: low] 1. 8 Include Comments 1. 9 Use symbolic constants with parameter and/or `define 1. 10 Collect symbolic constants into “include files” 1. 11 Use consistent order in port lists (in / out / inout) 2/12/03 ECE 426 - Lecture 6 6

General Coding Guidelines 1. 1 Create a separate Verilog file for each module. Name each file <module_name>. v. 1. 2 Limit lines to 80 characters or less. 1. 3 Avoid tabs when indenting. 1. 4 Use 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. . . endmodule 2/12/03 ECE 426 - Lecture 6 7

General Coding Guidelines 1. 5 Header Files // // // // // This confidential and proprietary software may be used only as authorized by a licensing agreement from My. Company, Inc. (c) COPYRIGHT 2003 My. Company, Inc. Legal Stuff The entire notice above must be reproduced on all authorized copies File Author Version Abstract : : counter. v George Tirebiter 0. 1 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 2/12/03 ECE 426 - Lecture 6 georget Version Control Stuff 8

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

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

General Coding Guidelines 1. 11 Use 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 2/12/03 ECE 426 - Lecture 6 11

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

Combinational Logic Guidelines 3. 1 Use functional descriptions rather than “lowlevel” logic descriptions. Example: assign cmp_out = (in 1 == in 2) instead of assign cmp_out = ~|(in 1 ^ in 2); correct? // is this 3. 2 Use continuous assignment (assign) statements for simple combinational logic expressions. 2/12/03 ECE 426 - Lecture 6 13

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

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

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

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

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

Sequential Logic Guidelines 4. 6 Use a common clock edge for to trigger all flipflops in your design. Don’t mix clock edges. 4. 7 If 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. 8 Avoid gated clocks. 2/12/03 ECE 426 - Lecture 6 19

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

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

Coming Up } More about Testbench Design } System-Level Design 2/12/03 ECE 426 - Lecture 6 22

2/12/03 ECE 426 - Lecture 6 23

2/12/03 ECE 426 - Lecture 6 24

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 2/12/03 ECE 426 - Lecture 6 25

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

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 2/12/03 ECE 426 - Lecture 6 27

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

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 2/12/03 ECE 426 - Lecture 6 29

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 2/12/03 ECE 426 - Lecture 6 30

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

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 2/12/03 ECE 426 - Lecture 6 32

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 2/12/03 ECE 426 - Lecture 6 33

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 2/12/03 ECE 426 - Lecture 6 34

2/12/03 ECE 426 - Lecture 6 35

2/12/03 ECE 426 - Lecture 6 36

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 2/12/03 ECE 426 - Lecture 6 37

Levels of Verification } } Board System / Subsystem ASIC / FPGA Unit / Subunit 2/12/03 ECE 426 - Lecture 6 38

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

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

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

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) 2/12/03 ECE 426 - Lecture 6 42

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