1. An Overview of Hardware Design Methodology Ian Mitchelle De Vera

2. Outline of the Presentation Design Classifications Typical Design Flow Post Design Design Data Hierarchy Testbenches Design Flow Overview Challenges of Hardware Design

3. Design Classifications ASIC Design Processor Design Memory Embedded Design

4. ASIC Design Application Specific IC  e.g. cruise controller, etc. Typical Characteristics  specific applications  short development time  mass market  low cost  slow performance  via older manufacture facilities Today’s ASIC designs may contain millions of transistors

5. Processor Design Designs that follow certain architectural standards  e.g. microprocessors, signal processors, graphic processors, etc. Typical characteristics  architectural specification  long development time  expensive  fixed market  high performance  via state-of-the-art manufacture facilities

6. Memory On-chip storage device  e.g. RAM, Video RAM, etc. Typical Characteristics  high density  low-high performance  regular structure  special design methodology  special manufacture facilities

7. Embedded Designs Core-based design or intellectual property (IP) design Emerging market New challenges in tools/methodologies System-on-a-chip Video Core Audio Core uController Core RAM ASIC

8. Typical Design Flow Obtain product requirements Derive design specifications Choosing technology and tools Verification a. Simulation b. Design Review c. Synthesis d. Physical Implementation e. Formal Verification System Integration and Test

9. Post Design Setup manufacture line Obtain first silicon Diagnosis of defects / Yield of improvement System bring-up test Silicon debugging / On-chip repair Mass production / Speed Grading Ship to customers

10. Design Data Hierarchy There are four levels of abstraction in the design process: A.Behavior Level  Like a C program  Behavioral code consists of a process containing constructs like loops, conditions, array and variable declarations.  Focuses on functionality and the system level architecture but less on defining architectural details (e.g. sequential or parallel structure)  Simulation on this level is faster because the description is more abstract than RTL.

11. B. RTL (Register Transfer Level)  explicitly define all state-holding elements  specifies the architecture in detail C.Gate Level  All high-level constructs (if, case, assign) are converted to gates (and, or, not). D.Transistor Level  All are converted to nmos, pmos, etc. E. Layout (final picture)

12. Data Hierarchy Behavior RTL Gate Level Transistor/Layout Functional Simulation Synthesis Test Generation Design for Test Physical Prop. Area/Timing Optimization Specification Implementation Less Complex Very Complex

13. if (x = 0) A = T1 else A = T2 T0 T2 T1 x  0 x = 0 C Program (if, else) Verilog, VHDL AND, OR, NOT CMOS, PMOS, NMOS

14. Testbenches Due to increases in design size and complexity, digital design verification has become an increasingly difficult and laborious task. To meet this challenge, verification engineers rely on several verification tools and methods. Testbenches have become the standard method to verify HLL (High Level Language) designs.

15. Testbench Tasks Typically, testbenches perform the following tasks: Instantiate the design under test (DUT) Stimulate the DUT by applying test vectors to the model. Output results to a terminal or waveform window for visual inspection. Optionally compare actual results to expected results.

16. Typically, testbenches are written in the industry-standard VHDL or Verilog hardware description languages. Testbenches invoke the functional design, then stimulate it. Complex testbenches perform additional functions—for example, they contain logic to determine the proper design stimulus for the design or to compare actual to expected results.

17. Standard HDL Verification Flow

18. Constructs used in Testbenches The following are some constructs used frequently in testbenches: 1.Generating Clock Signals  designs that use system clocks to sequence logic must generate a clock. Iterative clocks can easily be implemented in both VHDL and Verilog source code 2.Providing Stimulus  to obtain testbench verification results stimulus must be provided to the DUT. Concurrent stimulus blocks are used in testbenches to provide the stimuli. Two methods are employed: absolute-time stimulus and relative-time stimulus.

19. A.absolute time stimulus  simulation values are specified relative to simulation time zero. B.relative time stimulus  supplies initial values, then waits for an event before retriggering the stimulus. Both methods can be combined in a testbench, according to the designer’s needs. 3.Displaying Results  displaying results is facilitated by the $display and $monitor keywords in Verilog.

20. 4.Automatic Verification  automating the verification of testbench results is recommended, particularly for larger designs. Several methods can be used: A. Database comparisons: first, a database file containing expected output (‘golden vector’ file) is created. Then, simu- lation outputs are captured and compared to the reference vectors in the golden vector file. B. Waveform comparison: waveform comparisons can be performed automatically or manually. The automatic method employs a testbench comparator to compare a golden waveform against a testbench output waveform. C. Self-checking Testbenches: a self-checking testbench checks expected results against actual results at run time not at the end of the simulation.

21. Testbench Environment

22. Verilog Example Verification If the simulation succeeds, the following information is shown on the terminal screen:

23. Design Flow Overview Architecture Specification Block Implementation Specification Blk Behavior Model RTL Model Gate Level Model Transistor Level Schematic Design Library Layout Concept! Manufacturing Chip! synthesis custom design Validation of fcn Validation of Timing, Power, etc. Validation of Test/Implementation

24. Challenges of Hardware Design Functional Verification  What functions do we need?  How do we know the design performs all functions we want. Equivalence checking  Specification = Implementation? Test Preparation  Is the chip manufactured correctly? Performance constraints  Timing, power, noise are ok?