Abstract

The intended objective of this project is to generate manufacturing test patterns for combinational circuits. The best known algorithms that have been used in manufacturing test equipment are the D and Podem algorithms. This project demonstrates ATPG test generation by going through Verilog RTL design synthesis, place and route, logic simulation, fault simulation and ATPG for manufacturing tests. The synopsys EDA tools such as design compiler, design vision, VCS (Synopsys Verilog Compiler Simulator), TetraMax, and DVE (Discovery Visual Environment) have been investigated along with sequential and combinatorial circuit examples to demonstrate the project objective. The project also gives users an introduction and easy navigation through the UNIX environment.

Table of Contents
ABSTRACT ................................................................................................................................................................. I ACKNOWLEDGMENT ....................................................................................................................................... VIII PREFACE ................................................................................................................................................................. IX CONVENTIONS ........................................................................................................................................................ X I. INTRODUCTION TO DIGITAL DESIGN FLOW............................................................................................1 II. INTRODUCTION TO VERILOG AND VERILOG COMPILED CODE SIMULATOR (VCS) ..................4 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 WHAT IS HDL? ................................................................................................................................................4 VERILOG ..........................................................................................................................................................4 STRUCTURE OF VERILOG MODULE ...................................................................................................................4 VERILOG PORTS ...............................................................................................................................................5 VERILOG OPERATORS ......................................................................................................................................5 LOGICAL OPERATORS ......................................................................................................................................6 VERILOG BOOLEAN LOGICAL OPERATORS ........................................................................................................6 VERILOG REDUCTION LOGICAL OPERATORS ....................................................................................................7 VERILOG ARITHMETIC OPERATORS .................................................................................................................7 DATA TYPES .....................................................................................................................................................8 VERILOG PROGRAM LEVELS .............................................................................................................................9

III.OVERVIEW OF DESIGN FLOW ..................................................................................................................... 11 IV.COMPILER .......................................................................................................................................................... 12 V. VERILOG COMPILED CODE SIMULATOR (VCS) .................................................................................... 12 VI.OVERVIEW OF OBERON PROFILE SETUP ................................................................................................ 14 VII. COMPILATION AND SIMULATION OF RAM .......................................................................................... 17 VIII. DVE (DISCOVERY VISUAL ENVIRONMENT) PROCEDURE .............................................................. 18 8.1 8.2 8.3 8.4 8.5 SEARCH FOR SIGNALS OR SCOPES ................................................................................................................... 21 FINDING VALUES ON THE SIGNAL ................................................................................................................... 23 DEBUGGING STATE MACHINES USING WAVE WINDOW.................................................................................... 25 SET AN EXPRESSION / CREATE NEW SIGNAL .................................................................................................... 25 TRACING DRIVERS AND LOADS ....................................................................................................................... 28

IX.DESIGN COMPILER.......................................................................................................................................... 30 9.1 9.2 9.3 9.4 9.5 9.6 INTRODUCTION .............................................................................................................................................. 30 SPECIFY AND LINK TARGET TECHNOLOGY ..................................................................................................... 30 ANALYZE AND ELABORATE PHASE ................................................................................................................ 30 APPLYING CONSTRAINTS ................................................................................................................................ 33 DESCRIBING THE ENVIRONMENT .................................................................................................................... 33 OPTIMIZING THE DESIGN ................................................................................................................................ 34 9.6.1 Architectural Level ............................................................................................................................... 34 9.6.2 Logic Level Optimizations .................................................................................................................... 34 9.6.3 Gate level Optimizations: ..................................................................................................................... 35 ANALYSIS OF THE RESULTS ............................................................................................................................ 35 9.7.1 Generating textual reports for design properties ................................................................................. 35

9.7

ii

9.8

9.7.2 Visualizing design objects (GUI) .......................................................................................................... 35 SAVING DESIGN .............................................................................................................................................. 35

X. DESIGN COMPILER TUTORIAL: .................................................................................................................. 36 XI.DESIGN VISION ................................................................................................................................................. 48 11.1 11.2 11.3 11.4 INTRODUCTION .............................................................................................................................................. 48 FEATURES AND BENEFITS ............................................................................................................................... 48 OVERVIEW OF DESIGN VISION PROCESS......................................................................................................... 48 STARTING DESIGN VISION ............................................................................................................................. 49 11.4.1 Specifying libraries: ........................................................................................................................... 50 11.4.2 Reading source design ........................................................................................................................ 51 11.4.3 Setting current design ......................................................................................................................... 51 11.4.4 Defining design environment and setting design constraints ............................................................. 51 11.4.5 Check design ...................................................................................................................................... 53 11.4.6 Compiling the design .......................................................................................................................... 53 11.4.7 Analysis of the design ......................................................................................................................... 53 11.4.8 Saving the design database ................................................................................................................ 56

XII. TETRAMAX ...................................................................................................................................................... 57 12.1 12.2 12.3 12.4 12.5 INTRODUCTION .............................................................................................................................................. 57 NECESSITY OF TETRAMAX............................................................................................................................. 57 INTRODUCING MODERN IC TESTING: ............................................................................................................. 57 FEATURES AND BENEFITS ............................................................................................................................... 58 SUPPORTED FAULT MODELS: .......................................................................................................................... 58 12.5.1 Stuck-at fault ...................................................................................................................................... 58 12.5.2 Path delay faults ................................................................................................................................. 59 12.5.3 Transition delay model ....................................................................................................................... 59 12.5.4 IDDQ model ....................................................................................................................................... 59 12.5.5 Bridging model ................................................................................................................................... 60 12.6 OVERVIEW OF TETRAMAX:............................................................................................................................ 60 12.7 TETRAMAX TUTORIAL WITH AN EXAMPLE: .................................................................................................... 62 12.7.1 Read design and library files .............................................................................................................. 62 12.7.2 Build model ........................................................................................................................................ 63 12.7.3 Design Rule Check (DRC) .................................................................................................................. 64 12.7.4 ATPG patters ...................................................................................................................................... 65 12.7.5 RVIEWING RESULTS ................................................................................................................................ 69 12.7.6 SAVING PATTERNS.................................................................................................................................. 69 12.8 DEBUGGING USING TETRAMAX: .................................................................................................................... 71 12.8.1 Analyze the module ............................................................................................................................. 71 12.8.2 View complete module ........................................................................................................................ 72 12.8.3 Backward or forward trace ................................................................................................................ 73 12.8.4 Applying patterns ............................................................................................................................... 74 XIII. IC COMPILER ................................................................................................................................................ 75 13.1 INTRODUCTION TO MILKYWAY ....................................................................................................................... 75 13.2 INTRODUCTION TO IC COMPILER .................................................................................................................... 75 13.3 FLOOR PLANNING .......................................................................................................................................... 77 13.3.1 Aspect ratio ........................................................................................................................................ 78

iii

13.3.2 Rows of standard cells ........................................................................................................................ 78 13.3.3 Power planning .................................................................................................................................. 78 13.3.4 Pin placement ..................................................................................................................................... 78 13.3.5 Macro placement ................................................................................................................................ 78 13.4 PLACEMENT ................................................................................................................................................... 79 13.4.1 Constructive algorithm ....................................................................................................................... 79 13.4.2 Iterative algorithm .............................................................................................................................. 79 13.5 ROUTING ........................................................................................................................................................ 79 13.5.1 Global routing .................................................................................................................................... 80 13.5.2 Detailed routing ................................................................................................................................. 80 13.6 END PRODUCTS OF IC COMPILER STAGE ......................................................................................................... 80 XIV. PRIMETIME .................................................................................................................................................... 81 14.1 INTRODUCTION .............................................................................................................................................. 81 14.2 COMPARING PRIMETIME WITH DESIGN COMPILER ......................................................................................... 81 XV. CONCLUSIONS: ............................................................................................................................................... 82 XVI. REFERENCES ................................................................................................................................................. 84 XVII. APPENDIX A: VERILOG CODES .............................................................................................................. 85 XVIII. APPENDIX B: ACRONYMS ....................................................................................................................... 96 XIX. APPENDIX C: FILE EXTENSIONS ............................................................................................................. 97 XX. APPENDIX D: TROUBLE SHOOTING......................................................................................................... 99

iv

List of figures
Figure 1: Stages of ASIC Implementation .....................................................................................................................1 Figure 2: Over view of the entire process .................................................................................................................... 11 Figure 3: Compiler....................................................................................................................................................... 12 Figure 4: Process related to VCS ................................................................................................................................. 13 Figure 5: VCS detailed process ................................................................................................................................... 14 Figure 6: Complete scenario of user account ............................................................................................................... 15 Figure 7: DVE and its brief description ....................................................................................................................... 19 Figure 8: Complete GUI view of RAM through DVE................................................................................................. 20 Figure 9: Showing RAM with waveform view............................................................................................................ 21 Figure 10: Debugging the design by analyzing search options.................................................................................... 22 Figure 11: Debugging the design by analyzing search options.................................................................................... 22 Figure 12: Alternate way of searching the signal ........................................................................................................ 23 Figure 13: Figure 9.4: Importance of check box.......................................................................................................... 23 Figure 14: Available options in finding values on the signal ...................................................................................... 23 Figure 15: Searching for value on the signal Q [7:0] in a RAM .................................................................................. 24 Figure 16: Moving wave window to the top level ....................................................................................................... 24 Figure 17: Setting the top level name .......................................................................................................................... 24 Figure 18: Setting name to state machine signal ......................................................................................................... 25 Figure 19: Result of setting state names ...................................................................................................................... 25 Figure 20: Showing wave window with new signal updates ....................................................................................... 25 Figure 21: Setting expression to identify reading phase .............................................................................................. 26 Figure 22: Available options to grid a signal ............................................................................................................... 27 Figure 23: Picture showing grid on rand signal of a module for convenience ............................................................. 27 Figure 24: Grid properties .......................................................................................................................................... 27 Figure 25: Trace drivers by right click on the signals.................................................................................................. 28 Figure 26: Trace drivers by clicking on tool bar .......................................................................................................... 28 Figure 27: DVE showing drivers of rand signal .......................................................................................................... 28 Figure 28: Point drivers of rand in console pane ......................................................................................................... 29 Figure 29: Design compiler process ............................................................................................................................ 31 Figure 30: Design Compiler and its internal process ................................................................................................... 32 Figure 31: Fragment of report showing ports .............................................................................................................. 40 Figure 32: Fragment of compilation phase .................................................................................................................. 42 Figure 33: Qor report showing over all statistics of the design ................................................................................... 43 Figure 34: Hierarchical area report .............................................................................................................................. 44 Figure 35: Timing report ............................................................................................................................................. 45 Figure 36: Report showing references to ram module ................................................................................................. 46 Figure 37: Constraints report and their status .............................................................................................................. 47 Figure 38: Design Vision Overview ............................................................................................................................ 49 Figure 39: Design Vision GUI ..................................................................................................................................... 49 Figure 40: Library files in design vision ...................................................................................................................... 50 Figure 41: Analyze, elaborate and read options in Design Vision ............................................................................... 51 Figure 42: Design rule constraints ............................................................................................................................... 52 Figure 43: List of all the input/output in the design ..................................................................................................... 53 Figure 44: Settings for timing report ........................................................................................................................... 54 Figure 45: Schematic view .......................................................................................................................................... 54 Figure 46: From the tool bar ........................................................................................................................................ 55 Figure 47: Schematic view of ram ............................................................................................................................... 55

Figure 48: Available timing analysis options .............................................................................................................. 55 Figure 49: Post synthesis results of RAM using dve ................................................................................................... 56 Figure 50: Modern IC testing ...................................................................................................................................... 58 Figure 51: Circuit to explain stuck-at fault .................................................................................................................. 59 Figure 52: Response of a circuit with a node stuck-at 1 .............................................................................................. 59 Figure 53: Overview of TetraMax process [15] .......................................................................................................... 60 Figure 54: GUI of TetraMax showing various components ........................................................................................ 61 Figure 55: GSV tool bar .............................................................................................................................................. 62 Figure 56: Check box if the netlist is Library module ................................................................................................. 62 Figure 57: build model of TetraMax............................................................................................................................ 63 Figure 58: Build model specifications ......................................................................................................................... 63 Figure 59: ATPG showing initializing of faults .......................................................................................................... 66 Figure 60: Three ATPG engines .................................................................................................................................. 67 Figure 61: Fault classes and their groups ..................................................................................................................... 69 Figure 62: Saving of patterns in available formats ...................................................................................................... 70 Figure 63: Analyzing stuck-at faults ............................................................................................................................ 71 Figure 64: Showing 100 stuck-at faults from which user can select a port to analyze ................................................ 71 Figure 65: Setup dialog box showing primitive and design ......................................................................................... 72 Figure 66: GSV showing primitive view ..................................................................................................................... 72 Figure 67: Design settings and its view ....................................................................................................................... 72 Figure 68: Forward/backward trace ............................................................................................................................. 73 Figure 69: Select port to be traced ............................................................................................................................... 73 Figure 70: Observe backward trace of primitive 9 ...................................................................................................... 74 Figure 71: Selecting patter to be applied to module .................................................................................................... 74 Figure 72: Pattern application ...................................................................................................................................... 74 Figure 73: Outline of IC compiler stage ...................................................................................................................... 76 Figure 74: Example of a floor plan .............................................................................................................................. 77 Figure 75: Gcell or routing grid or routing bin ............................................................................................................ 79 Figure 76: Interconnection of gcells by global router ................................................................................................. 80

vi

List of tables
Table 1: Bitwise logical operators ................................................................................................................................6 Table 2: Boolean logical operators ................................................................................................................................6 Table 3: Reduction Logical Operators ...........................................................................................................................7 Table 4: Verilog Arithmetic Operators ..........................................................................................................................7 Table 5: Data types of Verilog ......................................................................................................................................8 Table 6: Various Verilog simulators and their manufacturers ..................................................................................... 12 Table 7: Logic level optimization showing structuring .............................................................................................. 35 Table 8: Synopsys standard library units ..................................................................................................................... 39 Table 9: Highlighting parameters of noramal ATPG and auto ATPG ......................................................................... 69 Table 10: End products of IC compiler ....................................................................................................................... 80 Table 11: Results of Design Compiler stage (using Single port ram used) ................................................................. 82 Table 12: Conclusions of TetraMax (using addsubtract) ............................................................................................. 82 Table 13: Invoking command for corresponding process ............................................................................................ 83

vii

Acknowledgment
This project presents a two years effort of pursuing excellence in education and personal goals. It represents my Masters project and makes me feel happy as this is a part of my interest. During my research, lot of people extended support technically and morally. It is my real pleasure to thank those people who made this research possible. I would like to give special thanks to my advisor, Dr. Reza Raeisi, for his support throughout my research. I am very much thankful to ECE department staff and faculty for clarifying my queries. Also, I would like to thank my dear family. This research would have not been accomplished without their support. I take this opportunity to thank department of Electrical and Computer Engineering for providing me financial support by giving me Teaching Associate position. Finally and most important, to everyone who stood by me in all times, supported and gave me strength to face all the difficulties.

viii

Preface
I choose this project mainly because of my special interest in VLSI digital testing. I wanted to get familiar with the design flow process. As a part of my interest I documented the process of design flow in this research project. Motivation for this research is the course ECE 242 where testing procedures for digital designs are introduced. Audience This document stands as reference for design engineers and design verification engineers who want to gain experience in using Synopsys tools for synthesis, analysis, generating test-patterns (DFT process), and placement and routing of a RTL model designed in Verilog. For better understanding, familiarity with the below listed process is required Compilation using VCS Design compiler and Design vision for synthesis TetraMax for generating test-patterns IC compiler for placement and routing

ix

Conventions
The following conventions are used in this documentation. Convention Courier Courier italic Description Indicates command syntax. Indicates a user-dened value in Synopsys syntax, such as object_name. A user defined value that is not Synopsys syntax.

Courier bold

Indicates user inputtext you type verbatimin Synopsys syntax and examples. Denotes optional parameters, such as pin1 [pin2 ..pinN] Indicates a choice among alternatives, such as low | medium | high Connects terms that are read as a single term by the system, such as set_input_delay Indicates a continuation of a command line Indicates levels of directory structure Library units for area- , time - sec

[] | _

\ / units case sensitive

All the commands are case sensitive; create_clock CLK is different from create_clock Clk.

I. Introduction to digital design flow

Integrated Circuits (IC) revolutionized modern electronics by serving wider range of applications, and with their low cost and performance efficiency they replaced huge transistor circuits. Application Specific IC (ASIC) is a combination of digital and analog circuits packed into an IC to achieve the desired control/computation function [3]. Advancement of technology in different areas accordingly led to increase in performance and requirements in that area. This led to the advent of ASICs to achieve performance in required areas with reasonable cost. Typical implementation of ICs involves three phases.

Idea Requirements Approach

Definition and Exploration phase

Design entry and RTL

Synthesis
Gate level Netlist
IC compiler Primetime Physical Design Implementation DVE and Tmax

Implementation phase

Design Verification

GSDII
IC Fabrication and Testing Production and Monitoring Figure 1: Stages of ASIC Implementation

Manufacturing and Production phase

Implementation flowchart, figure 1 gives detailed process of real-time ASIC implementation. In this research project definition and exploration phase and implementation phase are discussed in detailed. During definition and exploration phase idea to be implemented, specifications like: speed, power, and functionality, technology constraints like: size and space are considered. After specifications are decided the idea advances through implementation phase where actual designing takes place. Implementation phase is an important phase where most of the specifications are met upon careful examination. In this phase synopsys tools such as Verilog Compiled code Simulator (VCS), design compiler, primetime, IC compiler, and Discovery Visual Environment (DVE) are used to bring shape to the initial idea. Basic implementation of the idea is done in Register Transfer Level (RTL). RTL is expressed usually in hardware description language (HDL) like Verilog or VHDL. A Hardware Description Language (HDL) is a language used to describe a digital system, for example, a network switch, a microprocessor or a memory or a simple flipflop. This just means that, by using a HDL one can describe any hardware (digital) at any level. Functional/Logical verification is performed at this stage to ensure the RTL design matches the idea [2]. Synopsys VCS is used to simulate and debug the RTL design. Next stage to debug and simulate is transformation of RTL into gate-level netlist. This process of transforming RTL to gate-level netlist is called synthesis, and is done using the tools namely Design Compiler (Synopsys), RTL compiler (Cadence), Blast Create (Magma). Design compiler is emphasized in this project. Design compiler along with standard 90nm cell library converts RTL in to gate-level standard cells at the leaves of the design. Next step in implementation phase is design verification and physical implementation of the design. Tools like DVE and TetraMax are used to verify the design. DVE takes either RTL or gate-level design as input and provides excellent amenities to debug and provide good understanding of designs functionality. TetraMax (Tmax in short) is another exceptional tool provided by Synopsys. Tmax accepts the synthesized output from design compiler stage along with 90nm standard cell library as input, and after following few significant steps it generates test patterns. These test patterns verify complete functioning of the design by assuming the present design as faulty model. Tmax also provides ways to debug the design using these test patterns. Complete information regarding these debugging features is discussed later in this project. Physical design implementation is nothing but geometric representation of gate-level netlist. Geometric representation is designing layout for the design according to guidelines and limitations specified in the library files. This process is taken care by IC compiler which is again a part of Synopsys. Three steps that are followed to complete the physical implementation are floor planning, placement, and routing. These processes are self-explanatory as per their names. In floor planning vital features like size of the chip, pin assignment, type of clocks and power planning is done. Placement rst determines how each gate should be placed on the chip. Routing will then wire these gates together, using heuristic algorithms to group together related gates and tweak placement in order to minimize routing congestion and wire delay [4]. All these 2

details are given to manufacturers in the form of GDSII file as shown in figure 1. Some of the similar tools are Blast Fusion (Magma), and Encounter (Cadence). Another important process that is followed in the ASIC implementation is Static Time Analysis (STA) using primetime (PT synopsys). Prime time checks for violations in the same way that you would do it manually, but with much greater speed and accuracy. PT breaks the design down into set of timing paths, calculates signal propagation delay along each path, check violation of timing constraints inside the design and at the input/output interface.

II. Introduction to Verilog and Verilog Compiled code Simulator (VCS)

2.1 What is HDL? Hardware Description Language (HDL) is a Computer-Aided Design (CAD) tool for the modern design and synthesis of digital design. Due to increase in the complexity of digital designs, realization of such circuits with Integrated Circuits (ICs) became impossible. This realization required sophisticated CAD tools which includes HDL. The designer uses HDL to describe the system in a computer language, such as C. Debugging a HDL design is stress-free as it includes packages that implement simulator and test benches [5]. The two streams of HDL that are widely used are VHDL and Verilog. In this research project I confine my discussion to Verilog. 2.2 Verilog Verilog in non-technical sense is a textual representation of electronic circuits and systems. Through Verilog electronic design can be analyzed by verifying through simulation, timing analysis, logic synthesis, and test analysis. The history of Verilog takes back to 1980s when a company called Gateway Design Automation developed a HDL for its newly introduced logic simulator, Verilog-XL. Taking over Gateway Design Automation, Cadence brought Verilog language into public domain in 1990. In December 1995, Verilog HDL became IEEE standard 1364-1995 [5]. 2.3 Structure of Verilog module Verilog modules structure is similar to other software languages such as C. Source code is written in high-level language in an editor provided by HDL package, in regards to this research project vi editor is used. Verilog module consists of a declaration and a body. The declaration is part of program where input, output, and inout ports are listed. In the body a meaningful relation between these declared ports is done. // D-Flip Flop showing input signal (d), output (q), Clock //(clk), and reset `define TICK #2 //Flip-flop delay module dflipflop (d, clk, reset, q); inputd, clk, reset; outputq; regq; always @ (posedge clk or posedge reset) begin if (reset) begin q<= 0; end 4

else begin q<= `TICK d; end end endmodule

//perform buffer

Program 1: Example of Verilog module in a D - Flip Flop

Program 1 refers to a D flip flop which is used as an example of Verilog module. Name of the module dflipflop is user defined, and the fact that Verilog is a case sensitive language should be kept in mind before proceeding further. Dflipflop, dflipflop, and dFlipFlop are all three different names. Inputs and outputs follow the same rules as module. The declaration of the module starts with predefined word module, a user defined name followed by list of input and output ports enclosed in parentheses and are separated by commas. The closing parenthesis is followed by a semicolon. There is no preference to the order of ports inside the parenthesis and can be interchanged. The order in which the inputs and outputs, and their declarations are written is irrelevant as shown in program 2. module dflipflop (q, reset, clk, d); outputq; inputd, clk, reset; regq;
Program 2: Fragment of D-flip flop to show the order is not a preference

2.4 Verilog ports Type of Verilog ports can be of the following modes: Input: The port is only an input port. In assignment statements, the port should only be on the right-hand side of the statement. Output: The port is only an output port. In assignment statements, the port should only be on the left-hand side of the statement. Inout: The port can be used as both an input and output. The inout port represents a bidirectional bus [5]. 2.5 Verilog Operators Operators play vital role in programming and in Verilog these operators are classified into four different types based on the function they perform. 1. Logical operators (bitwise) 2. Relational operators 3. Arithmetic operators 4. Shift and rotate operators In this research project, logical and arithmetic operators are discussed in detail.

2.6 Logical Operators Verilog logical operators are internally classified into three groups: bitwise, boolean logical, and reduction. Table 1.1 shows Verilog Bitwise logical operators
Table 1: Bitwise logical operators [5]

Operators &

Equivalent Logic

Operand Type Bit

Result type Bit

Bit

Bit

~(&)

Bit

Bit

~(|)

Bit

Bit

Bit

Bit

~^

Bit

Bit

Bit

Bit

Consider the following example of bitwise logical operators; A= 1010, B= 0101, and F = A|B The name bitwise is self-explanatory, which means the operation is done bit by bit. According to the values assumed F is a 4 bit signal 1111. 2.7 Verilog Boolean logical operators Boolean logical operators respond with 1 (true value) or 0 (false value) for an expression. Considering an example will make the concepts clear. A= 1000, B= 0111 if F= A||B then F =1. Table 2 shows various Boolean logical operators.
Table 2: Boolean logical operators [5]

Operator && ||

Operation AND OR 6

Number of operands Two Two

2.8 Verilog Reduction logical operators The self-explanatory term reduction operator states some form of reduction to the input bits. This is explained clearly with the help of an example, statement F=|A, A= 0110 gives an output of (0 |1|1|0) 1.Various reduction operators and their symbols are given in table 3.
Table 3: Reduction Logical Operators

Operator & | ~& ~ | ^ ~^ !

Operation Reduction AND Reduction OR Reduction NAND Reduction NOR Reduction XOR Reduction XNOR NEGATION

Number of operands One One One One One One One

2.9 Verilog Arithmetic Operators All the arithmetic operations are performed with the help of arithmetic operators and its syntax is generally given by F= A (operator) B, this operator can be replaced by any arithmetic operators from table 4. An example of arithmetic operator is Modulus, F = (A % B) returns the remainder of (A/B).
Table 4: Verilog Arithmetic Operators [5]

Operator + * / % ** {,}

Description A or B type F type Addition A numeric numeric A+B B numeric Subtraction A numeric numeric AB B numeric Multiplication A numeric numeric A*B B numeric Division A numeric Numeric A/B B numeric Modulus A numeric, not real numeric, not real A%B B numeric, not real Exponent A numeric Numeric A**B B numeric Concatenation A numeric or array Same as A {A,B} B numeric or array

2.10 Data types Data type refers to data storage format that contains a specific type or range of values. As HDL is used to describe the digital circuits in the form of text, several formats are required to serve the purpose. For instance, when a signal is defined we need to specify its type so that we restrict the signal to admit only few values. Verilog data types are discussed in the following section. Verilog supports numerous data types namely: nets, integer, registers, parameters, and arrays.
Table 5: Data types of Verilog

Data type

Predefine word

Nets

Wire

Register

Reg

Vector

wire or reg with variables enclosed in [] Integer Real

Integer Real

Parameter

Parameter

Array

NA
2

Explanation Here in the first case a net named sum is defined and in the second case sum is declared along with a value wire sum; assigned to it. wire sum= 1b 0 Note: nets do not have any memory, they are used to drive circuits or as an interconnection. A variable q of register type is defined. reg q; Note: unlike nets register data type stores values until they are updated. Here in both the cases variables x, y are single wire[2:0]x = 3b100; reg[2:0]y = 3b 101 variables holding multiple bits. Variable k1 is defined as an Integer k1; integer data type. Real data type can hold Real average; even floating values along with integers Parameter is similar concept to that of global variables in Parameter M= 2; C or any other programming language Function of Array is to hold Reg [2:0] x [0:2] multiple vectors together. X2 X1 X0 Here x can hold 3 variables 1 0 2 1 0 2 1 0 of 3 bits each.

Syntax

These data types are used throughout this research project in various programs. Table 5 shows different data types and their declaration syntax along with their explanations. And regarding arrays, Verilog only supports single dimension array. 2.11 Verilog Program levels Verilog can be used to program the digital designs at various levels namely; behavioral level, register transfer level, and gate level. Behavioral Level: When a design is behavioral model, the module will include predefined words such as always or initial. Describing the design in algorithmic way, the functionality is defined by which operation must occur, not by how they are implemented in hardware. Behavioral code is faster to simulate and easy to debug. Behavioral code is not synthesizable. module half_adder (X, Y, Sum, Carry); inputX, Y; outputsum, carry; regsum, carry; always @(X, Y) begin sum = X ^ Y; carry = X&Y; end endmodule
Program 3: Behavioral program for half adder

Register transfer level: RTL design is synthesizable; this is the noticeable feature of RTL. RTL is description of the function at block level where each block may be synthesizable. The code is characterized by arithmetic expressions. In RTL design, all the registers are defined and combination logic is implemented. RTL design is technology and library dependent unlike behavioral. module half_adder (X, Y, Sum, Carry); inputX, Y; outputsum, carry; xor x1(sum, X, Y); and a1(carry, X, Y); endmodule
Program 4: RTL program for half adder

Gate level: The process of synthesized output is the gate-level. In this project we use tools developed by Synopsys to convert RTL to gate-level. module full adder ( a, b, c, sum, carry ); input a, b, c; output sum, carry; 9

n1; XOR2X1 U1 ( .IN1(c), .IN2(n1), .Q(sum) ); AO22X1 U2 ( .IN1(a), .IN2(b), .IN3(c), .Q(carry) ); XOR2X1 U3 ( .IN1(a), .IN2(b), .Q(n1) ); endmodule
Program 5: Gate level program of fulladder after synthesized

wire

.IN4(n1),

Above three modes of Verilog programming has their own merits and usages but in this project RTL and gate-level are used. Program 5 is gate-level and plays vital role in the entire process, acts as inputs to almost all the tools.

10

III.

Overview of Design flow

Figure 2: Over view of the entire process

11

IV.

Compiler

A program that translates source code (high level language) into object code (low level language) is called a compiler. Compiler requires some time before it generates an executable program, this is because compiler looks at the entire source code, collects, and re-organizes entire instructions set. Source code Object code

Compiler

Error Message
Figure 3: compiler

Source code in general is any high level programming language that user can understand and object code is a low level language like assembly level or machine level (binary) language that can be understood by computer. In order to analyze any digital design we use simulations. The use of a mathematical model to recreate a practical situation, so that various outcomes can be more accurately estimated is called simulation [6]. Table 6 shows different simulators available for Verilog programs.
Table 6: Various Verilog simulators and their manufacturers

Simulator Company/Author Name ISE Simulator Xilinx ModelSim Mentor Graphics Quarters II Altera Simulator SpeedSim Cadence Design System VCS Synopsys Verilog-XL Cadence This research project focuses on synopsys tools and so we are using VCS compiler from available Verilog compilers. VCS also provides tools in debugging the Verilog design graphically which are discussed later in this document.

V. Verilog Compiled code Simulator (VCS)

As discussed in table 6,VCS is a Synopsys simulator used to simulate and debug Verilog code. Complete scenario of VCS is shown in figure 4. This portion of research project stands as a reference for design engineers intending to simulate and debug a digital design. In later sections of VCS a new tool called Discovery Visual Environment (DVE) will be introduced to debug in graphical environment. 12

Figure 4: Process related to VCS

13

Significant processes of this section are: 1. Compilation of Verilog source code 2. Simulation of design to review the results 3. Debugging graphically with the help of DVE. Figure 5 shows process in detail and explains how VCS is responsible for viewing and debugging a design.
Verilog design (RTL)

Verilog Testbench

VCS

C source file (Object file) C compiler Executable File

RTL Simulation

Simv

Value Change Dump (VPD)

Sim results using Test bench

DVE
Figure 5: VCS detailed process

From figure 5 it is clear that VCS takes RTL code and test bench as input. In the process of simulation VCS compiles the code into C source files which are in general referred as object files. Upon conversion to object files VCS invokes C compiler which generates executable file (Simv in our case) that is responsible for debugging and graphical representation of design. DVE is responsible for GUI debugging of the design. In order to start the process of simulation one should go through certain process which is discussed in the following sections.

VI.

Overview of Oberon profile setup

Entire process of simulation and design flow takes place in working directory of oberon. Working directory internally consists of three folders source, lib, and work. Before the process of design flow is started, all these folders should be created and complete scenario of this folder system is given in figure 6. 14

Verilog (Working directory) Programs folder

Intermediate files form Synopsys tool

Source User enters into oberon server

Work

lib Library files

Figure 6: Complete scenario of user account

Step 1: After logging into the Oberon server create a working directory, where entire process is going to take place. In figure 6 working directory is Verilog. This is just an example you can have your own names for the working directory. [mallik@oberon ~]mkdir verilog Keep in mind that all the operations are to be performed only after you login into the working directory. After this is accomplished, enter into the directory using the following command; [mallik@oberon [mallik@oberon [mallik@oberon [mallik@oberon [mallik@oberon ~]cdverilog verilog]cdsource verilog]cdlib verilog]cd .. verilog]source /usr/local/scripts/synopsys

At this point of time as shown in figure 6, user is logged into working directory and has created three folders with specific names. To view this, use ls at the terminal to have a look at contents of the directory. Last line in the above set of commands is the most important and should be given at the terminal every time user logs in. Step 2: Once user is in the working directory, he/she can enter into the source sub-directory and start writing or editing code by opening a text editor. To open a text editor one need to use command vi file_name. After coding is done press shift+zz without exiting the editor and it saves the work done taking user back to main screen. Write the testbench for the following code using the same method discussed above but using a 15

different file name or just modifying the file name. For example for the file name.v the testbench can be name_tb.v so that there is no confusion. Step 3: After the program is written, to make sure the program is without any flaws we need to compile the program along with the testbench. To compile the program, get back to the working directory and enter the following commands at the terminal. [mallik@oberon verilog]vcs PP name.v name_testbench.v Above command compiles the code and the corresponding testbench. In case of any errors while compilation one needs to check the code and remove errors. After successful compilations of the code, user advances into the process of simulation. In case user wants to save time in running these commands, commands can be saved in a text file with an extension of .f in the same subdirectory where all the main files exists. Once this file is saved, to execute we follow the command as shown [mallik@oberon verilog]vcs PP file.f Step 4: Compilation of the file is done, now what? We have to check for the simulation results. To check the simulation results according to the inputs specified in testbench we use the command ./simv. ./simv at the terminal creates a file in the working directory with an extension .vdp. In most of the cases the file created is vcdplus.vdp. To view this file in graphical representation use the command [mallik@oberon verilog] ./simv [mallik@oberon verilog]dve vpd vcdplus.vpd Above command invokes a new interface called DVE (Discovery Visual Environment). Right click on the name of the module in the box and select add to waveform which shows the simulation results in the form of a waveform. DVE will be discussed in depth later in the document. Note: To get vcdplus.vpd file in the current working directory, user should include $vcdpluson(); in testbench inside the initial block. Entire process of simulation and all the above four steps will be discussed in detail with an example in the form of a tutorial. VCS takes a set of Verilog files as input and produces an executable simulator as an output. VCS is capable of compiling both behavioral Verilog models and RTL Verilog models. Behavioral models are often not synthesizable, so any hardware we intend to synthesize will need to be written at the register transfer level.

16

VII. Compilation and simulation of a digital design

1. Once user enters into the oberon server and then into the working directory (verilog), compilation and simulation can be done in the following way.
[mallik@oberon ~] cd verilog [mallik@oberon verilog] vcs PP ram_iitk.v ram_iitk_tb.v Parsing design file 'ram_iitk.v' Parsing design file 'ram_iitk_tb.v' Top Level Modules: test TimeScale is 1 ns / 100 ps Starting vcs inline pass... 1 module and 0 UDP read. However, due to incremental compilation, no re-compilation is necessary. ld -r -m elf_i386 -o pre_vcsobj_1_1.o --whole-archive pre_vcsobj_1_1.a --nowhole-archive if [ -x ../simv ]; then chmod -x ../simv; fi g++ -o ../simv -melf_i386 -m32 SIM_l.o 5NrI_d.o 5NrIB_d.o pre_vcsobj_1_1.o rmapats_mop.ormapats.o /usr/local/synopsys/linux/lib/libvirsim.so /usr/local/synopsys/linux/lib/librterrorinf.so /usr/local/synopsys/linux/lib/libsnpsmalloc.so /usr/local/synopsys/linux/lib/libvcsnew.so /usr/local/synopsys/linux/lib/vcs_save_restore_new.o /usr/local/synopsys/linux/lib/ctype-stubs_32.a -ldl -lm -lc -lpthread -ldl ../simv up to date CPU time: .048 seconds to compile + .024 seconds to elab + .180 seconds to link

After compilation is done an executable file simv is generated by VCS as shown in figure 5. And accessing this simv will give simulation results.VCS compiles the code based on any change in the module or in the inputs. If there is no change in the design from the time of previous compilation VCS gives a message as shown below;
The design hasn't changed and need not be recompiled. If you really want to, delete the file simv.daidir/.vcs.timestamp and run VCS again.

If there is change in only few modules, only those modules will be recompiled as shown below;
TimeScale is 1 ns / 100 ps Starting vcs inline pass... 1 module and 0 UDP read. recompiling module test because: This module or some inlined child module(s) has/have been modified. if [ -x ../simv ]; then chmod -x ../simv; fi g++ -o ../simv -melf_i386 -m32 _vcsobj_1_1.o 5NrI_d.o 5NrIB_d.o SIM_l.ormapats_mop.ormapats.o /usr/local/synopsys/linux/lib/libvirsim.so /usr/local/synopsys/linux/lib/librterrorinf.so /usr/local/synopsys/linux/lib/libsnpsmalloc.so /usr/local/synopsys/linux/lib/libvcsnew.so

17

/usr/local/synopsys/linux/lib/vcs_save_restore_new.o /usr/local/synopsys/linux/lib/ctype-stubs_32.a -ldl -lm -lc -lpthread -ldl ../simv up to date CPU time: .092 seconds to compile + .020 seconds to elab + .180 seconds to link

2. Once the compilation phase is completed, to view simulation results we need to access simv folder at terminal so that it gives all the simulation results according to the time specified in testbench.
[mallik@oberon verilog] ./simv Beginning Simulation...
Pattern# Pattern# Pattern# Pattern# Pattern# Pattern# Pattern# Pattern# Pattern# Pattern# Pattern# Pattern# Pattern# Pattern# Pattern# Pattern# Pattern# Pattern# Pattern# Pattern# Pattern# 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 time time time time time time time time time time time time time time time time time time time time time 1950: 2950: 3950: 4950: 5950: 6950: 7950: 8950: 9950: 10950: 11950: 12950: 13950: 14950: 15950: 16950: 17950: 18950: 19950: 20950: 21950: WE=0; WE=1; WE=1; WE=1; WE=1; WE=1; WE=1; WE=1; WE=1; WE=0; WE=0; WE=0; WE=0; WE=0; WE=0; WE=0; WE=0; WE=1; WE=0; WE=1; WE=0; Address=0; Address=0; Address=1; Address=2; Address=3; Address=4; Address=5; Address=6; Address=7; Address=0; Address=1; Address=2; Address=3; Address=4; Address=5; Address=6; Address=7; Address=0; Address=0; Address=0; Address=0; Data=00; Data=01; Data=02; Data=04; Data=08; Data=10; Data=20; Data=40; Data=80; Data=07; Data=08; Data=09; Data=10; Data=11; Data=12; Data=13; Data=14; Data=aa; Data=55; Data=55; Data=aa; Expected Expected Expected Expected Expected Expected Expected Expected Expected Expected Expected Expected Expected Expected Expected Expected Expected Expected Expected Expected Expected Q=xx; Q=01; Q=02; Q=04; Q=08; Q=10; Q=20; Q=40; Q=80; Q=01; Q=02; Q=04; Q=08; Q=10; Q=20; Q=40; Q=80; Q=aa; Q=aa; Q=55; Q=55; Actual Actual Actual Actual Actual Actual Actual Actual Actual Actual Actual Actual Actual Actual Actual Actual Actual Actual Actual Actual Actual Q=xx Q=01 Q=02 Q=04 Q=08 Q=10 Q=20 Q=40 Q=80 Q=01 Q=02 Q=04 Q=08 Q=10 Q=20 Q=40 Q=80 Q=aa Q=aa Q=55 Q=55

Good! End of Good Simulation. $finish called from file "ram_iitk_tb.v", line 94. $finish at simulation time 229500 V C S S i m u l a t i o n R e p o r t Time: 22950000 ps CPU Time: 0.480 seconds; Data structure size: Wed Feb 29 09:44:39 2012

0.0Mb

As mentioned earlier simulation results are according to testbench. Programs for ram ram_iitk.v and its testbench ram_iitk_tb.v are given later in the document (Appendix A).

VIII. DVE (Discovery Visual Environment) procedure

Next step in this process is to debug the simulated design graphically. To fulfill this purpose DVE (Discovery Visual Environment) is used. DVE is a Graphical User Interface (GUI) for debugging Verilog, VHDL, SystemVerilog, and System C digital designs. DVE is invoked from VCS. A dump file vcdplus.vpd is given as input to DVE; this dump file has information regarding simulation. Dump file is created upon introducing $vcspluson(); in the testbench of the design after declaration of initial block. This dump file is given as input to dve in the following way. [mallik@oberon verilog] dve vpd vcdplus.vpd

18

Figure 7 gives an outline of DVE and gives information regarding all the possible views. Once DVE is invoked, it displays current program and its test bench in the hierarchy panel and one can continue debugging by following steps mentioned in the coming sections.

4 3 1 2

Figure 7: DVE and its brief description

1. Hierarchy pane: List of all the designs modules and its testbench. 2. Variable/data pane: List of all the variables that can be viewed in GUI is listed. 3. Console pane: When user double clicks on a module in hierarchy pane, the code associated with that model is displayed for debugging. 4. Tool bar: Tool bar consists of various tools that will be highlighted according to the pane in which user is operating. 5. This portion of the DVE can be used for graphing signals or for viewing drivers of target signal. The wave view can be found in later figures regarding DVE. 6. History/Log pane: User can find list of previously used commands and can save session if required. DVE can be invoked in two different modes, post-processing mode and interactive mode. This project deals with post-processing mode. As mentioned earlier in this post processing mode a dump file is created from simulation and this dump file (vcdplus.vpd) is given as input to DVE.

19

A view can have multiple instances per TopLevel window. Examples of views are Source, Wave, List, Memory, and Schematic. Panes can be docked on any side to a Top Level window or left floating in the area of a frame not occupied by docked panes(called the workspace) [2]. To invoke dve in post-processing mode one should give the following command at unix prompt after simulation phase. [mallik@oberon verilog] dve vpd vcdplus.vpd -vpd in the above command specifies the file format that is being fed to dve. An example to the above process regarding ram is shown in figure 8.

Figure 8: Complete GUI view of RAM through DVE

20

To view wave form, right click on the name of the module and select add to waveforms new waveform. This invokes a wave view to existing DVE as shown in figure 9.

Figure 9: Showing RAM with waveform view

Once we have this view, all the possible ways to debug the design are discussed in the followings sections of document. 8.1 Search for signals or scopes: Noteworthy process in debugging is to find the signal and its occurrence in the design. Selecting edit > search for signals/instances pops up a window as shown in figure 10. User can search for signals/variables, scopes, and modules accessing figure 10. For instance, here a signal named clock is searched in the design, so signals/variables is selected. Observe figure 11 where name of the scope is given and so scope is selected. Upon clicking search all the occurrences of the target signal are displayed.

21

Figure 10: Debugging the design by analyzing search options

Figure 11: Debugging the design by analyzing search options

Apart from this way, we can drag and drop the signal from the console pane to search shown in figure 12. 22

Figure 12: Alternate way of searching the signal

Searching signal using figure 12 takes it to the first occurrence of that signal in the source code. Another handy feature is to check/uncheck the box at right corner of console. This will enable or disable to open in new views. If the box is checked, there wont be multiple views on the screen, new view is just updated on the current screen and vice versa. Refer to figure 13 for details.

Figure 13: Figure 9.4: Importance of check box

8.2 Finding values on the signal: This feature of DVE is useful in locating values on the signal or occurrence of values on the signal. User has various options to do this step; all the options are shown in figure 14.

Figure 14: Available options in finding values on the signal

From above figure if any edge, rising, and falling is selected, in the wave window occurrence of correspond edges is displayed and one can navigate among the occurrences using the circled option in the figure 14. If a particular value is to be searched then we have to select value from the drop down menu and enter the target value. Figure 15 shows the scenario when it detects the target, it is represented with a vertical line across the signal.

23

Figure 15: searching for value on the signal Q [7:0] in a RAM

This particular function is to ease users debugging. It includes moving wave window to top level or to bottom level, setting name to GUI. Refer to figures 16 and 17 for details. When user is working with several DVE windows it is difficult to decide the desired window, so giving name to each window will reduce the efforts of user. Window>move to> new toplevel. To select a new title for the window;Window>set top level title.

Figure 16: Moving wave window to the top level

Figure 17: Setting the top level name

24

8.3 Debugging state machines using wave window: While dealing with state machines, it might become difficult to deal with number. There is a powerful and important tool provided by DVE, to set names of states and signal shows exact name of the state as in figure 18. Right click on the target signal and select set radix > state name to set name to the state as defined in testbench.

Figure 18: Setting name to state machine signal

Figure 19: Result of setting state names

8.4 Set an expression / create new signal: This feature of DVE allows user to debug by setting a new expression in the design with actually making any changes to source code. This is an innovative feature and solves numerous glitches at its root level. Figure 20 give complete details of how to set an expression. Right click on the signal > set expression. In figure 21 user wants to create a signal which goes to 1 (high)when signal is read but not right in equation terms; reading phase = !WE&RE; and the wave view is updated with a new signal as shown in fig 20. As highlighted with a dotted rectangle in figure 21, user has various logical and combinational logic operators to set an expression.

Figure 20: Showing wave window with new signal updates

25

Figure 21: setting expression to identify reading phase

Grid: Signal grid is another problem solver. User can grid signals and enable the grid count to debug the design. This process is illustrated in figure 22. In order to enable grid on a signal, select a signal, click on grid and a new grid window opens up as shown in figure 22. Next immediate step in starting the grid process is to click get selected signal(s) as highlighted in the figure. Next check the boxes enable grid count ,and show grid. User has an option to select the range (from time A to time B) of signal to be grid. Refer to figure 23 to see the grid properties. Figure 22 and 23 shows different signals just for convenience. Viewers are not to be confused by the signals used in both the figures. The Grid Properties window lets you have even more control over the grid. For example you can set its cycle time to a custom value. This could be very useful if you want to be able to visually inspect drifting clocks or duty-cycle issues, etc [7] refer to figure 24.

26

Figure 22: Available options to grid a signal

Figure 23: picture showing grid on rand signal of a module for convenience

Figure 24: Grid properties [7]

27

8.5 Tracing drivers and loads: Tracing drivers plays vital role in debugging and is a very important feature presented by DVE. Tracing option enables user to view drivers/loads that contribute to change in the value of a signal. When a driver is traced, a new Driver pane will be created if none exists in the current top level frame. If a driver pane exists, the driver information will be added to the top of the list. Furthermore DVE highlights the occurrence of first driver/load in the console pane. To do this we can follow 4 different ways which are listed in the document. a. Right click on the signal and select trace loads/drivers b. Directly double clicking the signal c. Using options from tool bar as showing in figure 26 d. Trace >drivers/loads

Figure 266: Trace drivers by clicking on tool bar

Figure 255: trace drivers by right click on the signals

Figure 27 shows tracing of drivers for signal rand in the design. The drivers pane on the right shows the occurrence of the drivers, and it reads V1:mainpr . This mean the signal rand is found in the main program of source code (not the rest bench) and is highlighted in the hierarchy pane.

Figure 27: DVE showing drivers of rand signal

Figure 27 shows all the possible mentions of rand signal occurrences except for the occurrence in the console pane. Occurrence of rand signal in console pane is shown in figure 28.

28

Figure 28: Point drivers of rand in console pane

DVE when ran in interactive mode, many other debugging features come into practice. a. Execute UCLI/Tcl commands b. Set line, time, or event break points c. Line stepping d. Using interactive rewind feature (extremely useful) e. View annotations reflecting the actual value (powerful debug tool) Verilog code for RAM design: ram_iitk.v. Refer to appendix A Verilog testbench for RAM: ram_iitk_tb.v Refer to appendix A Next stage to compilation, simulation, and debugging is synthesis. At this stage, design compiler (dc_shell in short) accepts totally simulated and verified design along with standard cell library as input and initiates the process of synthesis.

29

IX.
9.1 Introduction

Design Compiler

Design compiler is a logic synthesis tool provided by Synopsys. The process of translating RTL design into a gate-level design is called synthesis.RTL synthesis is an automated design task in which high-level design descriptions written in Hardware Description Languages (such as VHDL, Verilog, or SystemVerilog) are transformed into gate-level netlist that is technology dependent. Gate-level netlist is fundamentally an implementation of the current design using library modules (pre-defined gates in the standard cell (technology) library) and their interconnections. Complete picture of design compiler is shown in figure 29. The synthesis tool (dc compiler) follows several steps in achieving the end product (gate-level netlist) which are outlined in figure 30. Each of these steps will be discussed in detail in the following sections. 9.2 Specify and link Target technology: At this stage user specifies various technology library files and their locations. To synthesize a design, user needs technology library that will contain description of the cells from the manufacturer, and their timing. This is usually a .db file found in library installation directory [8]. To synthesize a design we need to follow the process as given below i. Specify search path to acquire .db file by search_path ii. Specify technology library that user wants his/her design to be mapped to. settarget_library iii. Specify link libraries, this is an optional .db files which are pre synthesized and ready to be read in. setlink_library iv. Specify symbol library: Symbol libraries contain definitions of the graphic symbols that represent library cells in the design schematics. Semiconductor vendors maintain and distribute the symbol libraries. Design Compiler uses symbol libraries to generate the design schematic [9]. Set symbol_library The entire process is done in our case by setup file .synopsys_dc.setup which is usually found in either synopsys root directory or in users home directory. Fragment of setup file is displayed below. # Search Path setsearch_path "$search_path ./libs ./source ./db ./" # Setup libraries setlink_library "* core_typ.db" settarget_library "core_typ.db" setsymbol_library "core.sdb" 9.3 Analyze and Elaborate phase: Synthesis is a complex task consisting of many phases and requires various inputs in order to produce a functionally correct netlist [8]. At this step the HDL design is read into design compiler for synthesis.

30

Overview of Design compiler

Figure 29: Design compiler process

31

Library Files

Verilog design (RTL)

Design Compiler
Specify and link Target technology

Analyze and Elaborate Phase

Uniquify

Apply Constraints

Mapping and Optimization

Compile

Gate-level Netlist

Standard Delay Format

Design Constraints file

Figure 30: Design Compiler and its internal process

This is done in two steps analyze and elaborate. In analyze phase, the source design is read and checked for any syntax errors, if found should be rectified before proceeding to elaborate phase. Creates HDL library objects in an HDL-independent intermediate 32

format and saves these intermediate files in a specified location home/verilog/work Once an analysis is completed we proceed to elaborate phase. During elaborate phase: i. Design Compiler translates the design into a technology-independent design (GTECH) from the intermediate files produced during analysis ii. Replaces the HDL arithmetic operators in code with technology library components iii. Links the design automatically to all the essential references iv. Allows changing of parameter values (generics) defined in the source code moduleRamChip (Address, Data, CS, WE, OE); parameterAddressSize = 1; parameterWordSize = 1; input [AddressSize-1:0] Address; inout [WordSize-1:0] Data; input CS, WE, OE; reg [WordSize-1:0] Mem [0:1<<AddressSize]; assign Data = (!CS && !OE) ? Mem[Address] : {WordSize{1'bz}}; always @(CS or WE) if (!CS && !WE) Mem[Address] = Data; always @(WE or OE) if (!WE && !OE) $display("Operational error in RamChip: OE and WE both active"); endmodule If user wants to instantiate the value of WordSizeto be 8 bit, use elaborate command in the following way dc_shell>elaborate RamChip -paramWordSize=8 9.4 Applying constraints: This section explains how to apply constraints to the HDL design. These constraints include design rule constraints and optimization constraints. 9.6.1 Design rule constraints: Specifications related to transition time, fanout, and capacitance come under design rules. 9.6.2 Optimization constraints: Specifications related to clock definition, clock delay, input and output delay, and area. Design Compiler can violate optimization constraints if necessary to avoid violating design rule constraints, indicating the preference given to design rule constraints. 9.5 Describing the environment: This step is not mentioned in the figure 30 as it is already defined in technology library. User need not specify any extra specifications. The environment description includes: i. Defining operating conditions: Operating conditions include process, voltage, and temperature rage variations. These operating conditions are specified in

33

technology library. The cell and wire delays are scaled according to these conditions. ii. Modeling wire loads: Wire load models are used to estimate the effect of interconnect nets on capacitance, resistance, and area before real data is obtained from the actual layout. These models are statistical models and they estimate the wire length as a function of net's fanout [10]. 9.6 Optimizing the design: At this particular point of time, Design Compiler maps the HDL source code with cells available in the technology library. After the mapping is completed it translates the HDL into gate-level netlist. Optimization is done in several phases. According to the constraints specified during synthesis, different optimization procedures are applied. Optimization is done on three different levels. 9.6.1 Architectural Level: High-level optimization on HDL design modules corresponds to architectural level. Some of the tasks included in architectural level are: a. Arithmetic Optimization: Design Compiler rearranges the operations in arithmetic expressions according to constraints applied, to minimize timing or the area of gate-level design. These rearrangements are performed to improve implementation of the design and are based on rules of algebra. b. Resource Sharing: Resource Sharing is done for better area constraint (minimum area). Resource sharing refers to sharing of single hardware resource with multiple hardware operators in GTECH (generic technology-independent netlist). Nonexistence of resource sharing results in repeated hardware of similar functionality and also in the increase of area. c. Selecting DesignWare Implementation: Selecting a DesignWare implementation means that the implementation selection of a particular resource is left to the Design Compiler. For example, the Basic IP Library contains two implementations (ripple and carry-lookahead) for the + operator (the DesignWare Foundation Library provides more implementations for the '+' and other operators). When selecting DesignWare implementation, Design Compiler considers all available implementations and makes it selection according to your constraints [10]. 9.6.2 Logic Level Optimizations: In the synthesis process HDL design is now a GTECH netlist. As a part of Logic level optimizations on the design, structuring and flattening of the design is implemented. a. Structuring: Structuring evaluates the design equations represented by the GTECH netlist and tries by using Boolean algebra to factor out common sub-expressions in these equations. The sub-expressions that have been identified and factored out can then be shared between the equations [10]. Structuring can be set for timing(default) or Boolean optimization. The later helps in reducing area, but has a greater impact on timing. Thus circuits that are timing sensitive should not be structured for Boolean optimization.

34

Table 7: Logic level optimization showing structuring [2]

Before structuring After structuring P = ax + ay + c P = aI + c Q=x+y+z Q=I+z I=x+y b. Flattening: Conversion of logic into two level sum-of-products form is called Flattening. Flattening produces fast logic (by minimizing the levels of logic between the inputs and outputs) at the expense of the area increase [10]. In general one should compile the design using default settings (flatten and structure are set as false). If timing objectives are not met flattening and structuring should be employed. Flattening of a design is recommended if and only if the design contains unstructured or random logic. 9.6.3 Gate level Optimizations: Conversion of technology-independent netlist into technology-dependent netlist is known as Gate level optimizations. This conversion is done by mapping cells in technology-independent netlist to standard library cells. Several gate-level optimizations in the synthesis process are listed below: a. Mapping: The term Mapping is self-explanatory. The above discussed mapping which aids in conversion is done at this particular stage. b. Delay Optimization: After mapping to cells in standard technology library there is a possibility of timing violations. This timing violations is fixed by delay optimization. c. Design rule fixing: Design Compiler inserts buffers or resizes existing cells in order to fix design rule violations. In this process of fixing design rules timing constraints can be violated (as discussed in stage 3). d. Area Optimization: Area optimization is the last step that Design Compiler performs on the design. During this phase, only those optimizations that don't break design rules or timing constraints are allowed [10]. All the optimizations performed depend on constraints specified by user. As a matter of this reason, setting realistic constraints is mandatory in the process of synthesis. 9.7 Analysis of the results: Analyzing the results is as important as all the above steps in synthesis process. User can choose to use Design Vision (GUI of Design compiler) to analyze the results. Design analysis can be done using two methods: 9.7.1 Generating textual reports for design properties: This step includes invoking several commands at terminal to generate reports for vital design objects namely timing and area, cells, clocks, ports, buses, pins, nets, hierarchy, resources, constraints in the design. 9.7.2 Visualizing design objects (GUI): Viewing schematic, symbol view, hierarchy view, and viewing other graphical properties can be performed at this stage. Analysis is done to examine and confirm that the user specified constraints is met during the synthesis process and if needed re-synthesis is done. 9.8 Saving design: Saving design in several useful formats should be done to convey the specified constraints during the synthesis process, to successive stages of ASIC implementation flow (figure 1). 35

X. Design Compiler tutorial:

First and foremost process is to invoke design compiler. In order to do this, user has to be in working directory (verilog, in this case, refer to figure 6). [mallik@oberon verilog] dc_shell 10.1 After invoking the Design Compiler (will be referred as dc_shell ), linking the target library and source library is done. and the process of analyze and elaborate is to be performed. Refer to previous section for more details on analyze and elaborate: dc_shell> set link_librarysaed90nm_max.db saed90nm_max.db dc_shell> set target_librarysaed90nm_max.db saednm90nm_max.db 10.2 The next stage is to read the design. This can be done in two ways. If the design is in .ddc format we can directly perform analyze and elaborate in a single step with the help of read_ddc. For designs in verilog the process of analyze and elaborate is to be performed. Refer to previous section for more details on analyze and elaborate Format for both analyze and elaborate: dc_shell>analyze -format <format> -lib <working directory>\ <list of file names> dc_shell>elaborate -arch <architecture > -lib <working \ directory>param <parameter> Correspondingly commands applied on ram_iitk.v whose module name is reg_sram is given below:
dc_shell> analyze -format verilog -lib work ram_iitk.v Running PRESTO HDLC Searching for ./ram_iitk.v Searching for /usr/local/synopsys/libraries/syn/ram_iitk.v Searching for /usr/local/synopsys/dw/syn_ver/ram_iitk.v Searching for /usr/local/synopsys/dw/sim_ver/ram_iitk.v Searching for ./libs/ram_iitk.v Searching for ./source/ram_iitk.v Compiling source file ./source/ram_iitk.v Warning: ./source/ram_iitk.v:24: Intraassignment delays for blocking assignments are ignored. (VER-129) Warning: ./source/ram_iitk.v:32: Intraassignment delays for blocking assignments are ignored. (VER-129) Presto compilation completed successfully. Loading db file '/home/mallik/verilog/libs/saed90nm_max.db' 1

Success message is indicated by binary notation, 1 for success and 0 for failure. In the elaborate command, name of the module is reg_sram and format of the architecture is verilog:

36

dc_shell> elaborate -arch verilog -lib work reg_sram Running PRESTO HDLC Inferred memory devices in process in routine reg_sram line 17 in file './source/ram_iitk.v'. =============================================================================== | Register Name | Type | Width | Bus | MB | AR | AS | SR | SS | ST | =============================================================================== | mem_data_reg | Flip-flop | 8 | Y | N | N | N | N | N | N | | mem_data_reg | Flip-flop | 8 | Y | N | N | N | N | N | N | | mem_data_reg | Flip-flop | 8 | Y | N | N | N | N | N | N | | mem_data_reg | Flip-flop | 8 | Y | N | N | N | N | N | N | | mem_data_reg | Flip-flop | 8 | Y | N | N | N | N | N | N | | mem_data_reg | Flip-flop | 8 | Y | N | N | N | N | N | N | | mem_data_reg | Flip-flop | 8 | Y | N | N | N | N | N | N | | mem_data_reg | Flip-flop | 8 | Y | N | N | N | N | N | N | =============================================================================== Statistics for MUX_OPs =========================================================== | block name/line | Inputs | Outputs | # sel inputs | MB | =========================================================== | reg_sram/20 | 8 | 8 | 3 | N | =========================================================== Presto compilation completed successfully.Elaborated 1 design. Current design is now 'reg_sram'. 1

This information tells you the Design Compiler decided to infer memory type (flip-flop or latch) as flip-flop, the number of bits (8), whether it uses an asynchronous set/reset (AS, AR) or synchronous set/reset (SS, SR) and some other information. Verifying these results would give user accuracy. 10.3 To ensure that we are optimizing top_level design, we use current_design. At this stage user sets module of interest as current module:
dc_shell>current_design Current design is 'reg_sram'. {reg_sram}

10.4 At this stage user verifies that the design compiler is able to read all modules regarding source design (link). Command uniquify instantiates all defined modules as a separate modules. If a module is instantiated more than one time, this command will make separate modules for each instance. This allows each to be optimized independently for their particular usage [11]:
dc_shell> link Linking design 'reg_sram' Using the following designs and libraries: ------------------------------------------------------------saed90nm_max (library) /home/mallik/verilog/libs/saed90nm_max.db 1 dc_shell>uniquify // check the design for errors such as //missing module definitions
1

37

10.5 Following above process design is read into the Design Compilers memory. The design is analyzed for the syntactical errors and non-synthesizable structures and prepared for synthesis by analyze and elaborate commands. Designs consistency never came as a point of interest but at this stage user needs to check the design consistency and internal representation of the design so running the check_design command on the design is mandatory:
dc_shell>check_design 1

Check_design may result in some errors namely: unconnectedports, constant-valued ports, cells with no input or output pins, mismatches between a cell and its reference, multiple driver nets, connection class violations, and recursive hierarchy definitions[12]. 10.6 Constraining a Design: As discussed previously design rule constraints and optimization constraints are applied to the design. These constraints to the design should be realistic; else design compiler stays at this stage forever trying to meet the unrealistic constraints. In general, constraints describe user design goals to the synthesizer and what the synthesizer can or cannot do with the design to meet your design goals [10].Noteworthy design constraint is defining a system clock (for a synchronous clock). Later clock properties such as period, latency, uncertainty, and clock transition are specified and fed to the design. a. Period: Time period states the frequency of the operation as we define. Command used for this purpose is create_clock. Along with a name certain characteristics can also be assigned to the clock like period, positive edge start time, and negative edge falling time. This can be illustrated below:
dc_shell> create_clock period 10 waveform {0 5} CLK

Above example shows a clock named CLK is created with a time period of 10ns and duty cycle of 50% (pulse ratio 50% HIGH and 50%LOW). Clock is started at 0ns and falling edge occurs at 5ns. The values in flower bracket represents the duty cycle, changing the later value will result in change of duty cycle. If the period is unrealistically small, then the tools will spend forever trying to meet timing and ultimately fail. If the period is too large, then the tools will have no trouble but you will get a very conservative implementation. b. Uncertainty: Clock uncertainty can be used to model the variation of the clock propagation times in the different branches of the clock tree. This variation is due to different lengths of these branches (clock skew) but uncertainty can also be used to model clock jitter (variation in clock period length) [12]. c. Latency: Clock latency specifies the time taken by clock signal to reach from clock source to register point in the design. d. Transition time: The word transition means change. The time involved in changing signal state is called transition time. LOW HIGH or HIGH LOW. Constraints script
dc_shell> create_clock -period 40 -waveform {0 20} -name CLK Warning: Creating virtual clock named 'CLK' with no sources. (UID-348) 1 dc_shell>set_clock_latency 0.3 CLK

38

10.7 Set input constraints: e. Setting delay on input implies the arrival of input is delayed with respect to clock signal. It is used at the input ports; to specify the time it takes for the data to be stable after the clock edge. This situation is explained in detail with an example: For a clock with time period of 40ns and 50% duty cycle carefully observe below command
dc_shell> set_input_delay 2.0 clock CLK [all_inputs]

here all the input signals take 2 ns time before they stabilize and holds the signal for another 38 ns. f. Setting delay on output is to make the signal available few seconds preior to the change in clock edge. Input constraint script
dc_shell> 1 dc_shell> 1 dc_shell> 1 dc_shell> 1 dc_shell> 1 set_input_delay 2.0 -clock CLK [all_inputs] set_output_delay 1.65 -clock CLK [all_outputs] set_load 0.1 [all_outputs] set_max_fanout 1 [all_inputs] set_fanout_load 8 [all_outputs]

10.8 Set area constraints: At this section user specifies area constraint for design compiler to achieve a limit and is set with the help of set_max_area. Before we proceed to compile and actual synthesis process we can have a list of all ports in the design with the help of report_port. Fragment of ports is given in figure 31. 10.9 Optimizing and compile of design: During compilation several design attributes and their values are displayed in order to have a clear view and understanding on the units refer to table 6.
Table 8: Synopsys standard library units

Attribute Units Area Micro meters (m) Time Nano seconds (ns) Voltage Milli volts (mV) Capacitance Pico farads (pF) Power Nano Watts (nW) The amount of time by which a violation is avoided is called slack. The design is said to be synthesized if the slack is met and will be displayed in the analysis section of synthesis. Invoking compilation acts as a start for several functions like mapping, delay optimization, design rule fixing phase, and area recovery phase. Entire process is outlined in figure 32. Units regarding area and time are specified in table 8 according to Synopsys standards. Looking at the compile fragment report negative slack of the design can be determined; negative slack describes the deviation of critical path and the clock constraint. Larger the negative slack values worst is the design. Larger negative values 39

imply that the design doesnt meet the required time period/frequency. Total negative
dc_shell> report_port Information: Updating design information... (UID-85) **************************************** Report : port Design : reg_sram Version: D-2010.03-SP2 Date : Wed Feb 29 10:39:36 2012 **************************************** Pin Wire Max MaxConnection Port Dir Load LoadTrans Cap Class ----------------------------------------------------------------Address[0] in 0.0000 0.0000 ---Address[1] in 0.0000 0.0000 ---Address[2] in 0.0000 0.0000 ---Clock in 0.0000 0.0000 ---Data[0] in 0.0000 0.0000 ---Data[1] in 0.0000 0.0000 ---Data[2] in 0.0000 0.0000 ---Data[3] in 0.0000 0.0000 ---Data[4] in 0.0000 0.0000 ---Data[5] in 0.0000 0.0000 ---Data[6] in 0.0000 0.0000 ---Data[7] in 0.0000 0.0000 ---WE in 0.0000 0.0000 ---Q[0] out 0.1000 0.0000 ---Q[1] out 0.1000 0.0000 ---Q[2] out 0.1000 0.0000 ---Q[3] out 0.1000 0.0000 ---Q[4] out 0.1000 0.0000 ---Q[5] out 0.1000 0.0000 ---Q[6] out 0.1000 0.0000 ---Q[7] out 0.1000 0.0000 ---1 Figure 31: Fragment of report showing ports

slack is the sum of all the endpoints negative slack. If these values are found to be larger, timing constraint is not met and also states that there are several slow paths. The design rule cost is an indication of how many cells violate one of the standard cell library design rules constraints. Observing figure 32 give how design compiler tries to optimize the design. Each and every line of figure 32 is design compilers attempt to reach best results. For this reason values of the area in mapping phase goes decreasing and after attaining efficient values design compiler advances to next phase. dc_shell> compile -map_effortmedium -area_effortmedium
Information: Evaluating DesignWare library utilization. (UISN-27) ============================================================================ | DesignWare Building Block Library | Version | Available | ============================================================================ | Basic DW Building Blocks | D-2010.03-DWBB_1006
| * |

| Licensed DW Building Blocks | | | ============================================================================

40

Beginning Pass 1 Mapping -----------------------Processing 'reg_sram' Updating timing information Information: Updating design information... (UID-85) Beginning Implementation Selection ---------------------------------Beginning Mapping Optimizations (Medium effort) ------------------------------ELAPSED WORST NEG TOTAL NEG DESIGN TIME AREA SLACK SLACK RULE COST ENDPOINT --------- --------- --------- --------- --------- ------------------0:00:02 4839.4 0.00 0.0 0.5 0:00:02 4839.4 0.00 0.0 0.5 0:00:02 4839.4 0.00 0.0 0.5 0:00:02 4839.4 0.00 0.0 0.5 0:00:02 4839.4 0.00 0.0 0.5 0:00:02 3264.4 0.00 0.0 0.3 0:00:02 3264.4 0.00 0.0 0.3 0:00:02 3264.4 0.00 0.0 0.3 0:00:02 3264.4 0.00 0.0 0.3 0:00:02 3264.4 0.00 0.0 0.3 0:00:02 3264.4 0.00 0.0 0.3 0:00:02 3264.4 0.00 0.0 0.3 0:00:02 3264.4 0.00 0.0 0.3 Beginning Delay Optimization Phase ---------------------------------ELAPSED WORST NEG TOTAL NEG DESIGN TIME AREA SLACK SLACK RULE COST ENDPOINT --------- --------- --------- --------- --------- ------------------0:00:02 3264.4 0.00 0.0 0.3 0:00:02 3264.4 0.00 0.0 0.3 0:00:02 3264.4 0.00 0.0 0.3 Beginning Design Rule Fixing (max_fanout) ---------------------------ELAPSED WORST NEG TOTAL NEG DESIGN TIME AREA SLACK SLACK RULE COST ENDPOINT --------- --------- --------- --------- --------- ------------------0:00:02 3264.4 0.00 0.0 0.3 0:00:02 3275.7 0.00 0.0 0.0 Beginning Area-Recovery Phase (cleanup) ----------------------------ELAPSED WORST NEG TOTAL NEG DESIGN TIME AREA SLACK SLACK RULE COST ENDPOINT --------- --------- --------- --------- --------- ------------------0:00:02 3275.7 0.00 0.0 0.0 0:00:02 3275.7 0.00 0.0 0.0 0:00:02 3270.0 0.00 0.0 0.0 0:00:02 3265.9 0.00 0.0 0.0 0:00:02 3264.3 0.00 0.0 0.0

41

0:00:02 3264.3 0.00 0.0 0.0 0:00:02 3264.3 0.00 0.0 0.0 0:00:02 3264.3 0.00 0.0 0.0 0:00:02 3264.3 0.00 0.0 0.0 0:00:02 3264.3 0.00 0.0 0.0 0:00:02 3264.3 0.00 0.0 0.0 0:00:02 3264.3 0.00 0.0 0.0 0:00:02 3264.3 0.00 0.0 0.0 0:00:02 3264.3 0.00 0.0 0.0 0:00:02 3264.3 0.00 0.0 0.0 Loading db file '/home/mallik/verilog/libs/saed90nm_max.db' Optimization Complete --------------------Information: Defining new variable 'compile_group_pull_control_logic'. (CMD-041) 1 Figure 32: Fragment of compilation phase

10.10 Analysis phase: Analysis phase includes invoking of several reports that give complete picture of the synthesis constraints and their practical values. These values are typical and design dependent a To have a clear picture of overall violations, timing analysis, area, and design rules we invoke qor(Quality of Results) report. The report_qor command provides lots of information which may pinpoint the possible design problems and what areas in our design need more detailed analyses:
dc_shell>report_qor Information: Updating graph... (UID-83) Information: Updating design information... (UID-85) **************************************** Report : qor Design : reg_sram Version: D-2010.03-SP2 Date : Wed Feb 29 10:43:54 2012 **************************************** Timing Path Group 'CLK' ----------------------------------Levels of Logic: 5.00 Critical Path Length: 33.51 Critical Path Slack: 2.84 Critical Path Clk Period: 40.00 Total Negative Slack: 0.00 No. of Violating Paths: 0.00 Worst Hold Violation: 0.00 Total Hold Violation: 0.00 No. of Hold Violations: 0.00 ----------------------------------Cell Count ----------------------------------Hierarchical Cell Count: 0 Hierarchical Port Count: 0 Leaf Cell Count: 208 Buf/Inv Cell Count: 46 CT Buf/Inv Cell Count: 0 -----------------------------------

42

Area ----------------------------------Combinational Area: 1550.131202 Noncombinational Area: 1592.524780 Net Area: 121.604374 ----------------------------------Cell Area: 3142.655982 Design Area: 3264.260356 Design Rules ----------------------------------Total Number of Nets: 221 Nets With Violations: 0 ----------------------------------Hostname: oberon.engr.csufresno.edu Compile CPU Statistics ----------------------------------Resource Sharing: 0.05 Logic Optimization: 0.40 Mapping Optimization: 0.41 ----------------------------------Overall Compile Time: 1.94 1 Figure 33: Qor report showing over all statistics of the design

After viewing the overall statistics if there are any violations and user wishes to view those violations we can make use of report_violation
dc_shell>report_constraint -all_violators **************************************** Report : constraint -all_violators Design : reg_sram Version: D-2010.03-SP2 Date : Wed Feb 29 10:47:06 2012 **************************************** This design has no violated constraints.

Since in this particular design we dont have any violations the command doesnt display any. In case of any violations, it displays all the violated items along with the type of violations so that only those can be fixed and recompiled. To view area in both combinational, non-combinational, individual components that contribute to the total area, invoke command report_areahierarchy. In this research project design compiler did not produce any individual components but in general you can expect individual component contribution to area. Later in this document individual contributions is displayed using another command. Note that few sections of this particular fragment is smaller in font size to give exact picture.
dc_shell>report_area -hierarchy **************************************** Report : area

43

Design : reg_sram Version: D-2010.03-SP2 Date : Wed Feb 29 10:54:09 2012 **************************************** Library(s) Used: saed90nm_max (File: /home/mallik/verilog/libs/saed90nm_max.db) Number Number Number Number of of of of ports: nets: cells: references: 21 221 208 9 1550.131202 1592.524780 121.604374 3142.655982 3264.260356

Combinational area: Noncombinational area: Net Interconnect area: Total cell area: Total area:

Hierarchical area distribution

-----------------------------Global cell area Local cell area ------------------ ----------------------Hierarchical cell Absolute Percent CombiNoncombiTotal Total national national -------------------------------- --------- ------- --------- --------reg_sram 3142.6611 100.0 1550.1323 1592.5239 -------------------------------- --------- ------- --------- --------Total 1550.1323 1592.5239 1

Black boxes -----0.0000 -----0.0000

Design --------reg_sram ---------

Figure 34: Hierarchical area report

Timing analysis can be done with the help of report_timingcommand. Information regarding critical path, path slack, user specified constraints such as delays, rising edge is displayed. If at the end of timing analysis the slack is met only then the design is constrained otherwise design is said to be unconstrained.

dc_shell>report_timing **************************************** Report : timing -path full -delay max -max_paths 1 Design : reg_sram Version: D-2010.03-SP2 Date : Wed Feb 29 10:49:50 2012 **************************************** Operating Conditions: Typical Library: saed90nm_max Wire Load Model Mode: enclosed Startpoint: Address[0] (input port clocked by CLK) Endpoint: Q[0] (output port clocked by CLK) Path Group: CLK

44

Path Type: max Des/Clust/Port Wire Load Model Library -----------------------------------------------reg_sram 8000 saed90nm_max Point Incr Path ----------------------------------------------------------clock CLK (rise edge) 0.00 0.00 clock network delay (ideal) 0.30 0.30 input external delay 2.00 2.30 r Address[0] (in) 0.00 2.30 r U163/ZN (INVX0) 1.81 4.11 f U161/ZN (INVX0) 2.16 6.27 r U158/Z (NBUFFX2) 16.19 22.46 r U135/Q (MUX41X1) 13.05 35.51 f U136/Q (MUX21X1) 0.30 35.80 f Q[0] (out) 0.00 35.81 f data arrival time 35.81 clock CLK (rise edge) 40.00 40.00 clock network delay (ideal) 0.30 40.30 output external delay -1.65 38.65 data required time 38.65 ----------------------------------------------------------data required time 38.65 data arrival time -35.81 ----------------------------------------------------------slack (MET) 2.84 1 Figure 35: Timing report

From figure 35 it is evident that the slack is met. The delay report shows two different calculations. First set of calculations is for data arrival time and later set of calculations is for data required time. Data arrival is the time required for the signal to travel from starting point to the endpoint registers. Data arrival timing displayed here is for the critical path since critical path is the slowest path in entire design and obviously acts as timing of the whole design. In our ram critical path starts at address[0] and ends at Q[0]. In between these two registers the path consists of couple of inverters, a buffer and couple of multiplexors summing up to 5 components which explains level of logic in the qor report (figure 33). From the timing report above it is evident that data-path is an inverter, inverter, buffer, mux, and a mux before it reaches register Q[0]. Timing in these data-path elements sums up to 37.51 ns. As per user constraints output stabilization time is 1.65 which when reduced for a period of 40 ns gives 38.35 ns. The critical path delay as calculated is only 37.51 which is still less than over all data required time. report_hierarchygives individual elements contribution to the total area and report_references along with the list gives the part of each elements contribution to the total area and is displayed in figure 36.

45

dc_shell>report_reference **************************************** Report : reference Design : reg_sram Version: D-2010.03-SP2 Date : Wed Feb 29 11:05:46 2012 **************************************** Attributes: b - black box (unknown) bo - allows boundary optimization d - dont_touch mo - map_only h - hierarchical n - noncombinational r - removable s - synthetic operator u - contains unmapped logic Reference Library Unit Area Count Total Area Attributes -------------------------------------------------------------------AND2X1 saed90nm_max 7.372800 1 7.372800 AO22X1 saed90nm_max 11.980800 64 766.771179 DFFX1 saed90nm_max 24.883200 64 1592.524780 n INVX0 saed90nm_max 5.529600 19 105.062403 MUX21X saed90nm_max 11.059200 8 88.473602 MUX41X saed90nm_max 23.040001 16 368.640015 NAND3X0 saed90nm_max 7.372800 8 58.982399 NBUFFX2 saed90nm_max 5.529600 27 149.299204 NOR2X0 saed90nm_max 5.529600 1 5.529600 -------------------------------------------------------------------Total 9 references 3142.655982 1 Figure 36: Report showing references to ram module

Finally when user wishes to see all the specified constraints and if they are met report_constraint should be used, refer to figure 37
dc_shell>report_constraint **************************************** Report : constraint Design : reg_sram Version: D-2010.03-SP2 Date : Wed Feb 29 11:07:17 2012 **************************************** Weighted Group (max_delay/setup) Cost Weight Cost ----------------------------------------------------CLK 0.00 1.00 0.00 default 0.00 1.00 0.00 -----------------------------------------------------

46

max_delay/setup

0.00

Total Neg Critical Group (critical_range) Slack Endpoints Cost ----------------------------------------------------CLK 0.00 0 0.00 default 0.00 0 0.00 ----------------------------------------------------critical_range 0.00 Weighted Group (min_delay/hold) Cost Weight Cost ----------------------------------------------------CLK (no fix_hold) 0.00 1.00 0.00 default 0.00 1.00 0.00 ----------------------------------------------------min_delay/hold 0.00 Constraint Cost ----------------------------------------------------max_transition 0.00 (MET) max_fanout 0.00 (MET) max_capacitance 0.00 (MET) max_delay/setup 0.00 (MET) critical_range 0.00 (MET) 1 Figure 37: Constraints report and their status

10.11 Saving the design and constraints: Final step in design compiler after synthesizing is to save files in various formats according to synthesis flow. Some of the available formats ram design is saved are shown below
dc_shell>write_file -format ddc -hierarchy -output ram_iitk_up.ddc Writing ddc file 'ram_iitk_up.ddc'. 1 dc_shell>write_file -format verilog -hierarchy -output ram_iitk_up_syn.v Writing verilog file '/home/mallik/verilog/ram_iitk_up_syn.v'. Warning: Verilog 'assign' or 'tran' statements are written out. (VO-4) 1 dc_shell>write_sdcram_iitk_up_sdc.sdc 1 dc_shell>write_sdfram_iitk_up_sdf.sdf Information: Annotated 'cell' delays are assumed to include load delay. (UID-282) Information: Writing timing information to file '/home/mallik/verilog/ram_iitk_up_sdf.sdf'. (WT-3) 1 dc_shell>write_saif -output ram_iitk_up_saif.saif Loading db file '/home/mallik/verilog/libs/saed90nm_max.db' Information: Writing backward SAIF information to file 'ram_iitk_up_saif.saif'. (PWR-458) 1

47

Information regarding several file formats and for trouble shooting in design compilerrefer to appendix. To view the design graphically we use GUI version of design compiler, Design Vision. User can choose to perform entire synthesis in design vision too. Apart from performing synthesis in design vision, user can take advantage of GUI and view complete design as a hierarchy view or a symbol view.

XI.
11.1 Introduction

Design Vision

Synopsys provides a graphical user interface to Design Compiler and is called Design Vision. Intention behind designing this tool is to perform analysis on synthesis results. Design Vision is a Synopsys tool to analyze and view design at gate level and at the generic technology level.Design vision has the same static timing engine as Design Compiler. Using this tool timing analysis and modification of blocks that are being synthesized can be done. 11.2 Features and benefits Salient features of Design Vision are listed below: 1. GUI version for synthesis performed through Design Compiler 2. A logic hierarchy view for easy visualization and navigation of the design [1] 3. Schematic generation for hierarchal and symbol views 4. Histograms for visualizing trends in slack, capacitance etc. 5. Command line interface along with GUI 6. Supports both dcsh(Design Compiler shell) commands and dctcl(Design Compiler tool command language) commands 7. Visual timing analysis 11.3 Overview of Design Vision process Significant process in Design Vision is given in figure 38. If at the end of this process user is not satisfied with the results, resynthesizing of design is allowed after modification. Figure 38 reflects only important steps in the process, there are several other steps done by the user at result analysis. Specific information regarding individual menu items can be found using online help option provided with the tool. Process followed in Design Visionis similar to design compilers, for example from figure 38, reading of a design includes analyze and elaborate commands. Define design constraints include defining design rule constraints and optimization constraints. When Design Vision is invoked at command line interface several setup files are executed such as synopsys_dc.setup(fragment of this file is shown in introduction of Design Compiler), and dv_setup.tcl these files are located in installation directory, home, and working directory.

48

Read design from disk

Define design constraints

Compile design

View analysis results

Figure 38: Design Vision Overview

11.4 Starting Design Vision Invoking Design Vision involves in giving a command design_vision at UNIX prompt in the working directory
[mallik@oberon verilog] design_vision

This command will invoke Design Vision window as shown in figure 39.

6 1 2

3
Figure 39: Design Vision GUI

49

Design Vision as shown in figure 39, has the look and feel of the Microsoft windows GUI. The window consists of a title bar, a menu bar, and several tool bars at the top of the window and a status bar at the bottom. Workspace between toolbars and the status bar can be used to display graphical contents. Below is the description of Design Vision window: 1. Logic Hierarchy View pane: It shows entire hierarchy of the current design. 2. Objects list: This pane is a context based panel which will display contents based upon the selection in the drop down box at the top of the panel. To display information about other types of objects, select the object type in the list above the table. 3. Log/history pane: This part of Design Vision window displays each and every command along with its result and errors. This pane should be screened to identify errors and debug. This is also called as console. 4. Command line: Provides user with the functionality of Design Compiler. 5. This part of Design Vision window can be used by any floating pane such as schematic view, report script, histogram views (end point slack, path slack, net capacitance), and list views. 6. Menu and toolbars. View windows are user friendly and can be modified based on size and location of the window (drag to change the position). Appearance of schematics can be changed with the help of view>preferences, opens the preference box to adjust desired options. Following sections gives instructions on some basic pre-synthesis and synthesis tasks using Design Vision. 11.4.1 Specifying libraries: Specifying libraries is one of the significant steps to be followed before starting to work on design. Library files can be specified directly in .synopsys_dc.setup or in file>setup as shown in figure 40.

Figure 40: Library files in design vision

The link and target libraries are technology libraries that define the semiconductor vendors set of cells and related information, such as cell names, cell pin names, delay 50

arcs, pin loading, design rules, and operating conditions. The symbol library defines the symbols for schematic viewing of the design. The synthetic library is a specially licensed DesignWare library. 11.4.2 Reading source design: Design can be read in two ways as discussed below: a. Analyze and elaborate: The analyze command verifies HDL for proper syntax and synthesizable logic, translates the design files into an intermediate format, and stores the intermediate files in the directory specified. The elaborate command verifies the intermediate format before building a design. Elaborate determines whether it has proper mapping into the synthetic library modules. b. Read (analyze and elaborate together): Read option combines functions of both analyze and elaborate. User cannot expect exact same function as analyze and elaborate as read option does not perform certain design checks that are done during analyze and elaborate. Figure 41 give user an idea of finding these options in Design Vision.

Figure 41: Analyze, elaborate and read options in Design Vision

In case of any error message, which is displayed at the bottom of GUI window, user needs to fix these errors (most probably syntax errors) before running the analyze phase. Your design is converted into gate level model no later than the elaborate phase. 11.4.3 Setting current design: Before moving any further setting current design is important. Usually current design is set to top level design by analyze and elaborate process but in some cases setting of the design is required manually. This is done from the file menu as list > top-level design name. Command line can also be used for this purpose by giving command current_desing. 11.4.4 Defining design environment and setting design constraints: Defining design environment is modeling the environment during synthesize. This modeling involves external operating conditions like temperature, voltage; loads, drives fanout, and wire load models. This process in done by specifying technology library file to design vision. Setting design constraints involves invoking large number of commands as specified in design compiler section. a. Design rule constraints: Specifications related to transition time, fanout, and capacitance come under design rules. Refer to figure 42 for more information. 51

b. Optimization constraints: Specifications related to clock definition, clock delay, input and output delay, and area.

Figure 42: Design rule constraints

Optimization constraints involve in invoking several commands as shown below. Detailed description regarding these commands is given in constraining a design section of design compiler. Setting the clock: At this point of time we are creating a virtual clock which would be analogous to the system clock. Type the command below to create a clock of a user defined name into the design_vision field. create_clock -period 40 -waveform {0 20} -name CK Which will create a virtual clock with a 40ns period, 50%duty cycle = 25Mhz clock. Setting delay on the clock: This step is necessary as any designer cannot have any ideal clock in real time. Design compiler has an ideal time which is not matched with any real time. set_clock_latency 0.3 (clock_name) This will give your clock a delay of 0.3 nsec. Constraints on inputs and output pins: set_input_delay 2.0 clock (clock_name) [all_inputs] set_output_delay 1.65 clock (clock_name)[all_outputs] set_load 0.1 [all outputs] set_max_fanout 1 [all inputs]
set_fanout_load 8 [all outputs] report_port

report_port lists all the input/output ports in the design as shown in the figure 32.

52

Figure 43: List of all the input/output in the design

11.4.5 Check design: After you are done with specifying all the constraints, select design and click check design and press ok. Design>check design>OK. If the netlist has problems like connectivity, shorts,opens or multiple instantiations y user willsee errors in the LOG window. If there are no errors then all the above specified constraints are accurately applied to the design and the design is ready for compilation. 11.4.6 Compiling the design: Compiling the design involves translation of high-level design description to target technology. Several settings can be made based on user constraints and requirements but for good initial results default settings are used. Choose Design > Compile Design Selecting compile design opens a dialog box where user can choose desired settings. Select the effort you wish to achieve on the constraints set. High effort will result in longer time to synthesize the design. For better results we select medium effort. 11.4.7 Analysis of the design: This section of synthesis is viewing and analyzing the results after compilation stage. Generating reports include timing, area, references, generating schematics and power constraints. To generate reports for a selected objects follow the below process. a. Select an object b. Choose a report command in design menu to open the associated dialog box. Reports can be generated for cells, ports, timing, and nets c. Click selection in the report dialog box (figure 44 shows settings for timing report) d. Set options as needed e. Click OK 53

Figure 44: Settings for timing report

Apart from the above process user can view schematic of the design. After the elaboration phase you will have your design displayed in the Logic Hierarchy column, right clicking on this design will give you an option to view schematic (fig 45, 46).

Figure 45: Schematic view

54

Another option of selecting the schematic view is from the tool bars (figure 46).

Figure 46: From the tool bar

Example of a schematic view is given in figure 47

Figure 47: Schematic view of ram

Figure 37 shows available timing options that can be performed during analysis of results.

Figure 48: Available timing analysis options

55

11.4.8 Saving the design database: After all the above steps and constraints have met, we have to use test-bench against the synthesized design. Save the present work with a syn added to your present name in order to be clear. File>save as>file_name_syn.v Note: if it is saved with previous name all the original content is replaced with the synthesized design, leaving no scope to compare with the original. After exiting the design compiler open a terminal window and compile your synthesized designalong with your verilog model and your testbench. The compilation will be done in the sameway as we did in VCS tutorial followed by simulation and checking the waveforms. The wave forms should resemble pre synthesis results representing the gatelevel netlist to be the same as source HDL figure 49 shows post-synthesis values which seem to be similar to pre-synthesis waveforms. Use the following command at terminal to compile and follow the similar process discussed in VCS to see the waveforms.
[mallik@oberon verilog]vcs PP saed90nm.v name_tb.vname_syn.v

Figure 49: Post synthesis results of RAM using dve

After source HDL is converted in to gate level net list design is taken through TetraMax. TetraMax is one of the Synopsys tools which is used to test the gate-level netlist by generating test patterns to the design and gives complete analysis and debugging using test patterns.

56

XII. TetraMax
12.1 Introduction Test pattern is a sequence when applied to a digital circuit enables automatic test equipment to distinguish between the correct circuit behavior and the faulty circuit behavior caused by defects. TetraMax is one of the advanced ATPG (Automatic Test Pattern Generator) tool. These test patterns are used by semiconductor manufacturers to identify the faulty models before releasing products into the market. TetraMax generates minimum test patterns possible that results in maximum test coverage for a design. The unparalleled ease-of-useand high performance providedby TetraMax ATPG allows RTLdesigners to quickly create efficient,compact tests for even the mostcomplex designs [14]. 12.2 Necessity of TetraMax

Two types of traditional testing available are functional and stuck-at testing. Functional testing is self-explanatory term stating that it tests functionality of the design. In this approach a sequence of input data is given to observe output data. The resulting output data is compared to ideal responses to identify faults. This type of testing has only a limited ability to test the integrity of the devices internal nodes [13]. Complete functional testing is impractical. Using designer generated functional patterns only 75% of SA faults coverage is possible. Scan testing allows user to test sequential circuits and sequential elements of the design by connecting elements into a scan chain and treat them as primary inputs and primary outputs. In including scan into the design user has to face penalties: 1. Inserting scan occupies between 5-20% of the silicon area 2. Scan might have a performance cut off 3. Slower testing, involves huge testing time ATPG can test a much larger number of internal faults than with functional testing alone. ATPG intends in setting all circuit nodes to both 0 and 1, to propagate any defects to nodes where they can be detected by the test equipment.logic. ATPG supplements to get coverage to > 98%. 12.3 Introducing Modern IC testing: Process of modern testing is outlined in the figure 50. DUT (Device Under Test) is of primary interest for designers to test it before releasing the product into market. ATE (Automatic Test Equipment) accepts DUT and applies external test vectors or test patterns to analyze the results. Any mismatch with ideal (in this case consider practical responses) responses will fail the chip testing and result in preventing the particular DUT from releasing into market. All the other good ICs are certified as a good ones as shown in the figure.

57

Figure 50: Modern IC testing [15]

12.4 i.

Features and benefits of TetraMax Features: a. TetraMax has an integrated fault simulator for all the functional vectors b. Integrator graphical user interface and simulation waveform viewer c. Compression of patterns is handy by providing static and dynamic pattern compression d. Built-in GZIP (Gnu Zip) compression which is responsible for reading and writing of designs, libraries, patterns, and fault lists e. Can write test pattern files in a variety of standard formats: STIL, Verilog, VHDL, TDI, TI TDL91, and Fujitsu f. Offers three different modes of ATPG namely Basic Scan ATPG, FastSequential ATPG, and Full-Sequential ATPG. These modes are discussed in detail in later sections of the project. ii. Benefits: a. Generates test patterns for complex and multi-million gate designs b. Can perform direct automated test equipment (ATE) diagnostics, allowing user to quicklymap a test failure to a fault site in the design [13] c. Testing costs are immensely reduced through use of advanced pattern compression d. TetraMax has a decent bond with DFTMAX there by providing engineers DFT engineers with best results.

12.5 Supported Fault models: Generation of test pattern involves testing several faults like stuck-at faults, IDDQ faults, Transition delay faults, and path delay faults. 12.5.1 Stuck-at fault: These faults assume a node to be stuck at either 0 or 1. Taking this into consideration ATPG propagates the effects of these faults to inputs and outputs so that the effect of 58

these faults is observed at primary ports.A stuck-at fault is discussed in detail in figure 40 and 41.

0 0 1 1

0 0 1 1 D

1/0

0/1
0
Figure 52: Response of a circuit with a node stuck-at 1

0
Figure 51: Circuit to explain stuck-at fault

In 0/1, green color refers to fault-free logic and red refers to faulty logic. Above circuits describe stuck-at fault by assuming test signal. Node D is assumed to be stuck-at 1, in this case no matter what the inputs to this gate are, output is always 1. This fault is propagated to output and faulty logic along with fault-free logic is given in figure 41. 12.5.2 Path delay faults: Critical path is the slowest path in the design and so acts as timing of the whole design. The path delay fault model tests and characterizes critical timing paths in a design [13].To detect manufacturing defects or violations, chip (critical path of the chip) is tested at full operating speed to find out the path speed (if too slow then there exists a violation). Stuck-at fault model provides ATPG with most useful tests, however higher quality results are achieved when other fault models are included in the ATPG fault modeling such as path delay fault modeling. 12.5.3 Transition delay model: Delay involved in transition of signals (HIGH to LOW or LOW to HIGH) is called Transition delay and faults caused by these delays are called transition delay faults. This fault model in TetraMax aids user in detecting node that is slow-to- rise and slow-to-fall and generate test pattern accordingly. In order to have access to transition faulty model feature of ATPG, user should have Test-Fault-Max license. Typical procedure followed to detect slow-to-rise (0 to 1transition) or a slow-to-fall (1 to 0 transition) fault is observed with the help of clock signal. ATPG launches a transition with one clock edge and records the effect of transition with other clock edge. This short period of time between launch and capture should be enough to test the correctness of the design behavior at full operating speed. 12.5.4 IDDQ model: IDDQ fault model assumes that due to defect in circuit there is unnecessary current leakage (current drain) at a node to ground or node to power supply due to internal short circuit. ATPG detects these faults by switching as many nodes as possible (without affecting the test pattern sequence) thereby observing excessive current drain caused.

59

12.5.5 Bridging model: Most common defect in semiconductor devices is bridging defect, in such type of defect two unconnected nets or signals are identified to be shot due to some external material during manufacturing process. This type of faults are similar to stuck-at faults, however the fault coverage obtained from stuck-at modeling and bridge modeling may not be similar. Detecting of these faults involve in identifying more than one (independent) nets to have same faulty logic. The net on which actual fault occurred is called the aggressor and the other net is termed as the victim. 12.6 Overview of TetraMax:

TetraMax can be invoked either in command line environment or in GUI. TetraMax accepts synthesized netlist along with standard technology library and initiates the process of ATPG, figure 53 shows complete framework for the process of test pattern generation.

Figure 53: Overview of TetraMax process [15]

Entire process will be discussed in detail with an example in later sections of this document. Any designer whose target is to generate test vectors has to go through these six steps. TetraMax can be invoked at the terminal as shown below: [mallik@oberon verilog] tmax [mallik@oberon verilog] tmax shell -- GUI invoking -- Command line environment

Above command invokes GUI of TetraMax and is ready to start the process of ATPG.When invoking TetraMax a startup file named tmaxtcl.rc (refer to figure 54)is executed automatically. This file performs similar function to .Synopsys_dc.setup in design compiler. GUI of TetraMax (called as tmax from now on) is divided into two parts Graphical

60

Schematic Viewer (GSV) window and transcript window. Other than these two it has several components that are outlined in figure 54.

3 2

4 5
Figure 54: GUI of TetraMax showing various components

1. Transcript window: Transcript window displays each and every function performed in tmax GUI. It displays results, reports, error messages, and has history of entire commands along with their functionality. 2. Command tool bar: Provides fast access to various commands and minimizes the use of drop-down menus and command line filed. It is basically a collection of important functionalities in tmax. 3. Quick access buttons 4. Command-line field 5. Status bar: Status bar is positioned at the very bottom of tmax GUI and contains information regarding current state (Build/DRC/Test), pin/block reference data, red/green color indicating busy/ready status of tmax.

61

GSV pops up between transcript window and command tool bar upon clicking schematic view. GSV has its own tool bar which is shown in figure 55, using this toolbar user can analyze the design, debug, applytestpatterns to view response and verify them, trace forward and backward paths of agate. This tool bar can be viewed only when GSV is active.

Figure 55: GSV tool bar

12.7

TetraMax tutorial with an example:

The process of TetraMax is shown with a different example for convenience (explanation), efforts in implementing ram with TetraMax did not succeed and so have to choose a combinational circuit (a logic selector). 12.7.1 Read design and library files: To read a design in TetraMax, user can adopt three ways Read from menu options; file > read Read netlist at command prompt; BUILD >read_netlistadsu_iitk_syn.v Read netlist using command tool bar (from figure 54) If a file is read using command tool bar, there are some specifications to be mentioned by user as in figure 56. Figure shows several options that represent netlist type. At this stage user reads a netlist (design) and a technology library file (saed90nm.v), while reading netlist check box at library module.

Figure 56: Check box if the netlist is Library module BUILD-T>read_netlist /home/mallik/verilog/adsu_iitk_syn.v Begin reading netlist ( /home/mallik/verilog/adsu_iitk_syn.v )... End parsing Verilog file /home/mallik/verilog/adsu_iitk_syn.v with 0 errors. End reading netlist: #modules=11, top=addSub, #lines=39, CPU_time=0.00 sec, Memory=0MB BUILD-T>read_netlist /home/mallik/verilog/saed90nm.v -library Begin reading netlist ( /home/mallik/verilog/saed90nm.v )... End parsing Verilog file /home/mallik/verilog/saed90nm.v with 0 errors. End reading netlist: #modules=437, top=saed_xbuf, #lines=31218, CPU_time=0.48 sec, Memory=1MB

The above script is displayed on transcript window as we select options from command tool bar. Specifications of netlist that need to be read by TetraMax are given below: 62

o TetraMax supports various file formats like verilog, EDIF, and VHDL. User can perform minimum processing needed to make netlist compatible with TetraMax. o Netlist can be either hierarchal or flat (refer to types of verilog codes) o Netlist can be a single file or multiple files o In case of repetition of netlist, TetraMax will keep the latest module 12.7.2 Build model: Building the ATPG design model takes those parts of the design that are to be part of the ATPG process, removes the hierarchy, and puts them into an in-memory image that TetraMax can use [13]. TetraMax creates individuals modules for all the gates when
read netlist adsu_iitk_syn

adsu_iitk_syn

runbuild_model \ add_iitk_syn

In-memory image adsu_iitk_syn

top = add_iitk_syn
OR2X1 OA22X IN2 1 XNOR2X1 AND2X1

INVX1 AO22X1 XNOR2X1

Figure 57: build model of TetraMax

accessing gate level netlist. Figure 57 shows that building a netlist is extracting component that contribute in generating test patter and map them in an in-memory image. Run build model can be done in two ways: Run build using dialog box: o Refer to build in command tool bar which brings up a dialog box to set the top level module name as shown in figure 58

Figure 58: Build model specifications

63

o Refer to the top-level module name which should match designs module name. The drop down menu gives all the available modules that TetraMax encountered in the process of building. o Click run. Run build using command line: o BUILD >run_build_modeladdsub This command does the same functionality as the built button in command tool bar. addsubis the module of interest, that is fed to ATPG to begin the process of test patter generation. Script for built stage is given below:
BUILD-T>run_build_modeladdSub ---------------------------------------------------------------Begin build model for topcut = addSub ... ---------------------------------------------------------------There were 0 primitives and 0 faultable pins removed during modeloptimizations End build model: #primitives=56, CPU_time=0.00 sec, Memory=0MB ---------------------------------------------------------------Begin learning analyses... End learning analyses, total learning CPU time=0.00 sec. ----------------------------------------------------------------

12.7.3 Design Rule Check (DRC): Design rule check performs rule checks namely; S rules (Scan chain or shift) C rules (Clocks or capture) Z rules (internal tristate busses and bidi-directional pins) X rules (combinational feedback loops) V rules (Vector statements in the SPF) These rules take care of the following aspects of the design. User should specify details about clock ports and primary inputs in STIL test protocol file (not concentrated in this project) Verifies if the scan chains inputs and outputs are logically connected Makes sure that all the asynchronous set/reset pins and clock pins are in connection with scan only by means of primary ports Verifies if any internal multiple-driver nets can be in conflict Whether the clocks/sets/resets are off when you switch from normal mode to scan shift mode and again when you switch back to normal mode DRC using command tool bar: Click DRC in the command tool bar in the main window of TetraMax. DRC dialog box pops-up and continue with the process by clicking run tab. For basic design flow, accept the default settings and click run [13].

64

DRC using command line: Use run_drcto perform DRC at command line. If user has any STIL file it can be specified along with the command as shown run_drcfilename. File name is the user_defined name for STIL file Script for DRC process is shown below
DRC-T>run_drc --------------------------------------------------------------------------Begin scan design rules checking... --------------------------------------------------------------------------Begin simulating test protocol procedures... Test protocol simulation completed, CPU time=0.00 sec. --------------------------------------------------------------------------Begin scan chain operation checking... Scan chain operation checking completed, CPU time=0.00 sec. --------------------------------------------------------------------------Begin nonscan rules checking... Nonscan cell summary: #DFF=0 #DLAT=0 #RAM_outs=0 tla_usage_type=none Nonscan rules checking completed, CPU time=0.00 sec. --------------------------------------------------------------------------Begin DRC dependent learning... Fast-sequential depth results: control=0(0), observe=0(0), detect=0(0), CPU time=0.00 sec DRC dependent learning completed, CPU time=0.00 sec. --------------------------------------------------------------------------DRC Summary Report --------------------------------------------------------------------------No violations occurred during DRC process. Design rules checking was successful, total CPU time=0.00 sec. --------------------------------------------------------------------------

There are no violations in the design as mentioned at the end of DRC process. In case of any violations they can be analyzed using GSV and before proceeding further,all the DRC errors should be fixed. 12.7.4 ATPG patters: Patterns can be generated using ATPG button on command tool bar and also through command line. Running ATPG through command tool bar Before performing ATPG user introduces stuck-at faults into the design through TetraMax as shown in figure 59. Before generating test patterns fault list (add faults to which the test patterns correspond to) must be initialized. Various settings can be done at this stage of pattern generation as shown in figure. Set abort limit Set coverage percentage Adding faults source Selecting fault modeling (stuck-at model) And type of ATPG can also be set (basic scan setting / Fast sequential settings / full sequential settings ) 65

In later sections difference between running ATPG normally and using auto is discussed with an example. After above stated settings are made for basic ATPG user can select run and patterns are observed in transcript window.

Figure 59: ATPG showing initializing of faults

Running ATPG through command line: Above specified constraints can also be specified through command line as shown; Abort limit: Setting abort limit is optional but has noticeable effect during debugging of design. During patterns generation several assumptions are made and paths in the design are made sensitive to identify the fault locations. Setting abort limit provides ATPG to continue the process, even though the assumptions are proved wrong. Until this abort limit is hit ATPG continues to back track the algorithm to identify faults. TEST-T > set atpg abort N; N is usually 5-1000 CPU limit: User can select time spent by atpg on a fault by specifying max_sec_per_faultatATPG stage. TEST-T > set atpg time max_sec_per_fault [time] Use this option to limit CPU time spent by ATPG on a fault. Pattern limit: User has an option to stop the process of ATPG on acquiring specific number of pattern. TEST-T > set atpg patterns N ; N=0 to disable the limit Specifying this command enables stopping of ATPG process when the required number of patterns are met. As already mentioned user can choose from available three ATPG engines as shown in figure 60. The usage of these three engines differs with the type of design used for ATPG. 66

Figure 60: Three ATPG engines

Basic Scan: ATPG uses basic scan engines for fast and high performance (user requirements). Gives good coverage for full-scan designs Fast-Sequential: Fast-sequential gives higher coverage for a design with memories and for near fullscan designs. Full-Sequential: Full-Sequential is good for designs with DFT violations. It is the most powerful engine that supports more complex designs. After desired settings are made ATPG may be performed either in regular run mode or by auto mode. Observe that transcript window reflects every change we induce in the design process.
TEST-T>remove_faults -all 0 faults were removed from the fault list. TEST-T>add_faults -all 214 faults were added to fault list. TEST-T>run_atpg -ndetects 1 ATPG performed for stuck fault model using internal pattern source. ---------------------------------------------------------#patterns #faults #ATPG faults test process stored detect/active red/au/abort coverage CPU time --------- ------------- ------------ -------- -------Begin deterministic ATPG: #uncollapsed_faults=214, abort_limit=10... 17 202 12 0/0/0 94.39% 0.00 23 12 0 0/0/0 100.00% 0.00 Uncollapsed Stuck Fault Summary Report ----------------------------------------------fault class code #faults ------------------------------ ---- --------Detected Possibly detected Undetectable ATPG untestable Not detected DT PT UD AU ND 214 0 0 0 0

----------------------------------------------total faults 214 test coverage 100.00% ----------------------------------------------Pattern Summary Report

----------------------------------------------#internal patterns 23 #basic_scan patterns 23 -----------------------------------------------

67

Above script in transcript window shows running ATPG in normal mode which has less compression on patterns as a result the patterns obtained are more in number. Script showing design ATPG in auto mode is displayed below:
TEST-T>remove_faults -all 0 faults were removed from the fault list. TEST-T>add_faults -all 214 faults were added to fault list. TEST-T>run_atpg -auto_compression -ndetects 1 ATPG performed for stuck fault model using internal pattern source. ---------------------------------------------------------#patterns #faults #ATPG faults test process stored detect/active red/au/abort coverage CPU time --------- ------------- ------------ -------- -------Begin deterministic ATPG: #uncollapsed_faults=214, abort_limit=10... 15 214 0 0/0/0 100.00% 0.00 Uncollapsed Stuck Fault Summary Report ----------------------------------------------fault class code #faults ------------------------------ ---- --------Detected DT 214 Possibly detected PT 0 Undetectable UD 0 ATPG untestable AU 0 Not detected ND 0 ----------------------------------------------total faults 214 test coverage 100.00% ----------------------------------------------Pattern Summary Report ----------------------------------------------#internal patterns 15 #basic_scan patterns 15 ----------------------------------------------CPU Usage Summary Report ----------------------------------------------Total CPU time 0.00 ------

ImportanceofAuto mode: ATPG through auto adds faults in the design if not present AU faults are detected upon quicke run. At this point ATPG doesnt store any patterns to detect AU faults, the decision is made randomly [13] After completion of process patterns are stored with high merge efforts where as in regular run mode user can select this effort (observe the difference in the script given above) Gives report of CPU time along with fault and test coverage While saving patterns runs one pass of static compression

68

Table 9: Highlighting parameters of noramal ATPG and auto ATPG

Parameters Patters Fault coverage

Normal ATPG 23 17 to achieve 94.39% 23 to achieve 100% Reports shown Stuck fault summery Pattern summery Faults detected 214 Compression Medium

Auto ATPG 15 15 to achieve 100% Stuck fault summery Pattern summery CPU usage summery 214 High

12.7.5 Reviewing results: Soon after the ATPG phase faults along with fault coverage, CPU timing, and number of patterns are displayed in the script (in practice it is transcript window) as shown in step 4. Reviewing results involves in going through various types of faults that are possible in the design. During ATPG TetraMax classifies faults into 11 fault classed and groups them into 5 major fault groups as listed below.
Possiblly detected [PT] ATPG untestable, Possibly detected [AP] Not analyzed,Possibly detected [NP] Undetectable [UD] Undetectable Unused [UU] Undetectable Tied [UT] Undetectable Blocked [UB] Undetectable Redundant [UR] ATPG untestable [AU] ATPG untestabel, not detected [AN] Not detected [ND] Not controlled [NC] Not observed [ND]

Detected [DT] Detected by Simulation [DS] Detected by Implication [DI]

Figure 61: Fault classes and their groups

In the process of ATPG TetraMax provides two types of pattern compression: Dynamic compression: Dynamic compression is processed during execution of ATPG phase using auto mode. This is performed using high merge effort during ATPG. Static compression: This compression is performed after the patterns are generated; this is done using command pattern_compression 12.7.6 Saving Patterns: After the patterns are generated and reviewed, they are written as a file for any further use. TetraMax allows user to save file in various formats according to requirement as shown in figure 62. Usually patterns are saved in verilog-single files.

69

Figure 62: Saving of patterns in available formats

Before saving user can also choose from below options Choose from compression choices: none, GZIP, or proprietary Writing all the partner or select a range to write a pattern STIL, verilog, WGL, VHDL, or binary outputs Fragment of a saved file is shown below:
if (verbose >= 1) $display("// %t : Begin patterns, first pattern = 0", $time); pattern = 0; // 0 pattern = 2; // 400 ALLPIS = 9'b111001011; ALLPIS = 9'b110011001; XPCT = 4'b0011; XPCT = 4'b1000; MASK = 4'b1111; MASK = 4'b1111; #0 ->capture; #0 ->capture; #200; // 200 #200; // 600 pattern = 1; // 200 ALLPIS = 9'b011110111; XPCT = 4'b0010; MASK = 4'b1111; #0 ->capture; #200; // 400 pattern = 3; // 600 ALLPIS = 9'b101101111; XPCT = 4'b0010; MASK = 4'b1111; #0 ->capture; #200; // 800

In a verilog file where patterns are written, it displays pattern number, the pattern, and the time at which it was used for simulation. 70

12.8

Debugging using TetraMax:

Once user generated patterns using TetraMax, debugging can also be done using TetraMax. TetraMax can analyze and simulate the faults with the help of patterns. 1. Analyze the module 2. View complete module In Primitive view In design view 3. Back trace or forward trace 4. Apply patterns 12.8.1 Analyze the module: In order to analyze the module we need to click on analyze on GSV toolbar (figure 55) to open a dialog box and select either faults or rules. In this project only faults are analyzed. Select stuck-at drop down menu and choose at 0 or at 1 Click on fill, which intern opens a sub dialog box for the user to select the class of the faults. First and last options are user defined and varies based on number of faults identified from ATPG phase. In this case the number of faults is 214 so we can select the last to be any number prior to 214. Refer to figure 52 After above settings are made figure should resemble 53. User can select a port that needs to be analyzed and refer to figure 55 to see analyses of the port A[3] stuck-at 0

Figure 63: Analyzing stuck-at faults

Figure 64: Showing 100 stuck-at faults from which user can select a port to analyze

71

12.8.2 View complete module: In primitive view: o To view the module in the form of gate-level components (actual gates), we use this option and are displayed as gates with a technology name as shown. o To view design in primitive mode, click on setup in GSV tool bar (refer to figure 55). Upon clicking a dialog box opens up for the user to select the option

Figure 65: Setup dialog box showing primitive and design

o GSV with a primitive design is displayed

Figure 66: GSV showing primitive view

To view module in design view: o Design view allows user to view components of the module in Technology library module along with a technology name. o Follow similar process as in figure 55 to select design view and is displayed as below

Figure 67: Design settings and its view

72

12.8.3 Backward or forward trace: Once the design is viewed to analyze, user can perform forward trace or a backward trace to the component of interest. To select backward or forward trace click on show > forward/backward trace > next/next multiple TetraMax then confirms the port user wants to backward/forward trace as in figure 69. User can add a single port or multiple ports to be traced by selecting ports and click add Refer to figure 70 and compare it to previous figures to observe the trace

Figure 68: Forward/backward trace

Figure 69: Select port to be traced

73

Figure 70: Observe backward trace of primitive 9

12.8.4 Applying patterns: Patterns can be applied on either selected paths (as above) or complete module (select complete module form setup). Click on setup > pattern no User can select a single a pattern at a time or all the patterns together If a single patter is selected, choose the patter number as shown in figure 60

Figure 71: Selecting patter to be applied to module

Observe the change in patter before and after application of pattern 2 in figure 72

Before

After

Applying all patterns at once Figure 72: Pattern application

74

XIII. IC Compiler
13.1 Introduction to milkyway Milkyway is a foundation database for Galaxy design platform. It unifies the design storage for Galaxy platform. The production-proven, widely used Milkyway database provides persistent data storage that links Galaxy platform tools together thereby eliminating the need for large, intermediate exchange files and preventing design intent loss through mismatched syntax of exchange formats [16]. Milkyway is an environment that is set before design can be placed and routed exhausting IC compiler. This database contains all the logical and physical data that will be needed during IC compiler. Milkyway is capable of signal integrity, power reduction, yield attachment and many others that are required for efficient ASIC flow. Some of the features of Milkyway: 1. Production-proven database for all Galaxy design platform tools 2. Capable of handling large designs 3. Eliminates the need of large design exchange files 4. Supports designs in the latest technologies including 90nm, 65nm, and 45nm 5. Precludes design intent mismatches from faulty semantics of exchange files Any practical design implementations deals with generation of tremendous volumes of data and imagine the amount involved for really large designs! This brings the need of a common database without which tools must communicate through ASCII design interchange files leaving scope of mismatch in the file formats. Exchanging ASCII files by the design engineers at the cost of several problems, Milkyway presents solution to these situations. 1. Provides binary exchange format access to implementation tools 2. Saves time by eliminating the need for ASCII design interchange file to transfer design data 3. Prevents costly errors by reducing the semantic gap between various implementation tools. By this feature, each tool is able to view and implement the design in the same way 13.2 Introduction to IC compiler Next step in the ASIC flow is physical implementation of the design. During this physical implementation the optimized gate-level netlist (produced during synthesis of the design using design compiler) and standard cell library is fed as input to IC compiler.This is a collectionof logic functions such as OR, AND, XOR, etc. The representation in the library is that ofthe physical shapes that will be fabricated [2]. Other important inputs to IC compiler are design constraints which resemble to the ones set during synthesis (design compiler phase). The reason behind usage of similar timing constraints is that the timing is considered similar throughout the ASIC flow process. Physical implementation of the ASIC flow is also called as place and route. As the name of the stage reads, it is placing the gate-level design and routing between its gates so that the routed design represents the gate-level netlist before proceeding to fabrication. This research project gives detailed explanation of IC compiler, a working example cannot be provided due to limited resources available. A complete over view of IC compiler process is given in figure 73. 75

IC compiler

FLOOR PLANNING Estimate size of the chip Arrange block on the chip Pin Assignment Power planning is done Type of clock is decided

Verified design
PLACEMENT Chip density is met Total wire length is minimized Number of horizontal/vertical wire segments crossing a line.

ROUTING Overall connection between blocks and nets Track the connections and their direction Actual connection all the nets Minimize area, wire length, delay in critical paths

Figure 73: Outline of IC compiler stage

76

As depicted in figure 73, physical implementation consists of three main stages: 1. Floor planning 2. Placement 3. Routing For a design to reach fabrication stage it has to go through all the above mentioned three stages. 13.3 Floor Planning: At this stage, user maps logical description of the design with physical description of the design. Logical description is the gate-level netlist and physical description is floor plan of the design. Goal of the stage is to minimize the area, and timing delay. An example of floor plan is showed in figure 74. I/O pins

Y
I/O pins

X
I/O pins

Figure 74: Example of a floor plan [2]

Floor planning is the important stage in the physical implementation. Quality of timing details depends on floor planning. Better the floor planning better is the quality of timing. An integrated circuit (IC) consists of three basic elements: 1. Input/output ports:Provides connection to and from IC to external circuits. 2. Standard cells: IC is made up of standard cells which are responsible for the logic (functionality) of the design.

77

3. Memory elements: Memory elements store information required to generate the accurate functionality of the design. To minimize the area a special memory elements named macros are used. Important terminologies involved in floor planning are aspect ratio, power planning, pin placement, macro placement, and few more. Some of these terms are explained in the following section referring to figure 74. 13.3.1 Aspect ratio: Aspect ratio is defined as the horizontal tovertical ratio. This ratio gives shape of the design (usually type of rectangle used). In figure 74 A.R is . Usually vertical layers are always even and horizontal layers can be either odd or even. A design with A.R > 1 is always long rectangle A.R < 1 is always wide rectangle A.R = 1 is a Square IC 13.3.2 Rows of standard cells: Standard cells in the design are placed in rows. The space between rows and height are always equal but width of the rows may vary as shown in figure 74. 13.3.3 Power planning: Any functioning chip requires power. After standard cells are placed in rows power is made available to them by a ring which is designed around the horizontal layers. This ring contains both VDD and VSS to give standard cells the access of both source power and ground. This process is done by power mesh, power mesh is horizontal and vertical lines of metal through both VDD and VSS are made available to all the standard cells. 13.3.4 Pin placement: Pin placement refers to arranging pins in the design. User gets a better idea after knowing the timing, utilization, and congestion of the chip. 13.3.5 Macro placement: The process of floor planning is initiated by placing macros on the core. Based on the placement of macros standard cells are placed. If two macros are close to each other such that a standard can fit in that place it should be blocked to prevent congestion. Types of blocking is given below: Standard cell blockage: As the name suggests there should be no standard cell in this type of blockage. Non buffer blockage: This portion of the chip can accommodate only buffers. Blockage below power lines: It is advisable to create blockages under power lines, so that they do not cause congestion problems later. After routing, if you see an area in the design with a lot of DRC violations, place small chunks of placement blockages to ease congestion [2]. During physical implementation design engineers prefer flattened model rather than hierarchy model because in flat design flow, the placement and routing resources are always visible [2]. In flat design initial design is divided into sub modules, which is handy for the design engineers. More details regarding the flatten design is given in design compiler stage and examples regarding flattened design is given in appendix. After the floor planning is done user checks for DRC violations which are to be fixed manually before we proceed to placement phase. After the DRC violations are fixed and floor planning meets the requirements the design is advanced to placement phase.

78

13.4 Placement: Placement stage defines the positioning of particular standard cells in a row. The positioning is done keeping interconnections of a standard cell in mind (space is already set for interconnections). After placement, we can see the accurate estimates of the capacitive loads of each standard cell must drive [2]. Aspects concentrated in placement stage are: 1. Area constraint is maintained by adjusting the density of the chip (no density overflows or no cell overlaps) 2. Minimize the total wire length for maximum time optimization 3. Reduce the number of horizontal/vertical wire segments crossing a line [2] Placement phase uses an algorithm to implement this stage. Some of the algorithms are as follows: 13.4.1 Constructive algorithm: A pre-defined set of rules are followed to arrive at the target placement of the design. Example: Min cut, cluster growth, etc., 13.4.2 Iterative algorithm: These algorithms are not used to initiate a placement process but used for betterment of the existing placement. Algorithm follows series of iterations ending up with a better placement model with cost effective factor. Example: Forcedirected relaxation algorithm, Steinbergs algorithm, etc., A constructive algorithm Min cut is discussed in detail. A general idea is discussed with a clear explanation. Min-Cut algorithm Any designer who wants to initiate the process of placement will be choosing a min-cut algorithm because of its accuracy and simplicity. Steps involved in this algorithm: 1. Cuts the placement area into two parts known as bins. Each bin is then optimized for cost. It counts number of nets crossing the line which is cost function. Reducing the cost function will be optimal for the placement. 2. Interchange the standard cells between the binsto minimize the cost function. 3. Repeats the steps 1, 2 for each bin till it optimizes entire design. Cost function is not effected only by the number of crossings but also various other factors namely, congestion, distance of each net, signal reliability issues, etc., Placement phase is done in two steps global placement, and detailed placement. 13.5 Routing: Next stage to floor planning and placement is routing. Routing of a design is interconnecting various blocks present in the chip with other. Just as placement, routing is also done in two phases: 1. Global routing 2. Detailed routing Routing is done with the help of gcell, an example of gcell is shown in figure 75. Entire chip is

Figure 75: Gcell or routing grid or routing bin

79

divided into small blocks called routing bin or routing grid or gcell. Size of each gcell depends on the algorithm used and each cell has finite number of horizontal and vertical wires. 13.5.1 Global routing: At this stage of routing global routing connects two different gcells each from center of the cell as shown in figure 76. Global router only provides connections to all the gcells present but does not provide specific tracks between the placed standard cells.

Figure 76: Interconnection of gcells by global router

13.5.2 Detailed routing: Actual interconnection between placed standard cells is done by detailed router. This interconnection is usually done with the help of metal. Detailed router aims in minimizing the total interconnection length, delay in critical path. During final routing, the width, layer, and exact location of the inter connections are decided [2]. After final routing is done some important specifications can be drawn from the chip. The parasitic capacitance, resistance of each net, delays in the design, and accurate timing of the design. 13.6 End products of IC compiler stage

After going through entire process mentioned above user is interested in end product of IC compiler stage which would be useful for manufacturer as shown in table 10.
Table 10: End products of IC compiler

File name Parasitic (.spef) Standard delay format (.sdf)

Standard Design Constraints (.sdc) Verilog file (.v) Timing and power reports

Description Used for delay calculation as it contains information regarding max and min delays required by primetime. This file is an input for post STA (Static Time Analysis) and contains information regarding cell and net delays. This is exported to do the simulation of the design and to find if the design is operating at the frequency without any setup/hold violation [12]. An SDC file to communicate the design intent, including timing and area requirements between EDA tools. Contains information as, SDC version, SDC units, design constraints and comments. A hierarchical Verilog file for the current design, extracted from layout. Can be used to perform post layout verification on netlist using VCS. Information regarding timing and power of the IC

80

XIV. PrimeTime
14.1 Introduction PrimeTime is a STA (Static Time Analysis) tool. PrimeTime is a full-chip, gate-level static timing analysis tool that is an essential part of thedesign and analysis flow [17]. PrimeTime validates timing performance of a design by checking all possible paths for timing violations. PrimeTime (PT) substitutes manual timing verification with much accuracy and speed. PT analyzes timing delays and violation in the design. PrimeTime analyzes the design for violations by breaking the design into set of timing paths, calculates delay and timing violations in each path, checks for the violations of the design constraints in the design and at input output ports. PT uses longest path to calculate maximum delay and shortest path to calculate minimum delay. PT also considers below mentioned aspects for timing analysis: Clock path Clock gating path Clock asynchronous path 14.2 Comparing PrimeTime with Design compiler Both the tools use the same technology libraries and read same data files in .db and .ddc formats Operation is similar and share similar commands Uses similar algorithm for delay calculations and results in identical results Supports SDC format for specifying design constraints, including timing, and the area constraints of the design. Upon identification of errors or violations during STA, user has to go back and identify the source of error and repeat the whole process.

81

XV. Conclusions:
Objective of this research project is to present complete ASIC flow procedure with detailed description, which has been achieved by providing tutorials all along. The design was successfully taken through VCS, DVE, Design Compiler, and TetraMax. Due to limited resources a working example couldnt be given for IC compilerand PrimeTime. Research at a full stretch is done on above specified (practical) Synopsys tools along with IC compiler and PrimeTime (theoretical). Table 13 gives different commands to invoke various tools of synopsys. Design is successfully Compiled and Simulated using VCS, debugging techniques are successfully discussed using DVE (Discovery Visual Environment), design is successfully synthesized using Design Compiler, and Patterns are generated for the synthesized design using TetraMax. Some of the important conclusions made through Design Compiler stage are given in table11; conclusions from TetraMax are given in Table 12. Observe that critical path slack and successful slack are equivalent showing successful synthesis.
Table 11: Results of Design Compiler stage (using Single port ram used)

Parameter Non Combinational Area ( Combinational Area ( ) Total Area ( ) Critical Path Slack (sec) Critical Path Length (sec) Successful Slack (sec) Total Negative Slack (sec) Levels of logic Parameters Patters Fault coverage Normal ATPG 23 17 to achieve 94.39% 23 to achieve 100% Reports shown Stuck fault summery Pattern summery Faults detected 214 Compression Medium

Value ) 1592.52 1550.13 3264.26 2.84 33.51 2.84 0.00 5 Auto ATPG 15 15 to achieve 100% Stuck fault summery Pattern summery CPU usage summery 214 High

Table 12: Conclusions of TetraMax (using addsubtract)

Different verilog designs are used to achieve the above processes. All verilog modules used and synthesized verilog code are given in appendix A.

82

Table 13: Invoking command for corresponding process

Invoking command vcs simv dve vpd vcdplus.vpd simv gui dc_shell design_vision tmax pt_shell primetime icc_shell

Resulting tool Compilation Simulation Discovery Visual Environment post processing mode Discovery Visual Environment interactive mode Design Compiler Design Compiler GUI TetraMax GUI Prime time shell mode Prime time GUI mode Ic compiler

83

XVI. References
1. Synopsys Inc.,Design Vision user guide, March 2003. 2. Hima BinduKommuru and Hamid Mahmoodi, ASIC Design Flow Tutorial Using Synopsys Tools, M.S project, San Francisco State University, San Francisco, CA, 2009. 3. NOKIA. (2009, Aug.), ASIC Design Flow, Presented at Annual Meeting. [Online]. Available: http://elearning.vtu.ac.in/Programme12/Industrial%20programme/nokia/ASICFlow_V2% 2019-08.pdf 4. Prof. John Wawrzynek, Prof. KrsteAsanovi, and Dr. John Lazzaro, course in Fall 2011, CS 250, Topic: VLSI Systems Design., Department of Electrical Engineering and Computer Science,University of Berkley, 2011. 5. Nazeid M. Botros. HDL Programming Fundamentals VHDL and Verilog,Davinci Engineering Press, Nov. 2005. 6. WebFinance Inc., Simulation., Internet: http://www.investorwords.com/4583/ simulation.html, 2005. 7. YaronIlani, Apps. Consultant, Cool things you can do with DVE. [Videorecording], Synopsys Inc., April 2011. 8. Eric Yan, Digital IC Design: Synopsys Design Compiler A quick Tutorial, Nov. 2007. [Blog]. Available: http://digital-ic-design.blogspot.com/2007/11/synopsys-designcompiler-quick-tutorial.html 9. VLSI Experts team, Synopsys Design Constraints basics, Feb. 2011. [Blog]. Available: http://vlsi-expert.blogspot.com 10. Prof. Lauri Heart Tribe and Prof. LauriKettunen, Topic: Design Compiler Tutorial., Department of Computer Science, Tampere University of Technology, Sept.2009. 11. Matthew Guthaus, course in Spring 2007, CMPE 125, Topic: Logic Design with Verilog, Department of Computer Science, University of Santa Cruz, 2007. 12. Prof. Christopher Batten, Course in Spring 2012, ECE 5950, Topic: Complex Digital ASIC Design, School of Electrical and Computer Engineering, Cornell University. 13. Synopsys Inc., TetraMaxATPGuserguide, Version E-2010.12, December 2010. 14. Synopsys Inc., TetraMAX ATPG Automatic Test Pattern Generation, Oct. 2010. 15. National Chip Implementation Center (2004, Aug.), Design for Testability with DFT Compiler and TetraMax, Presented during training session. [Online]. 16. Synopsys Inc., Milkyway Foundation database for the Galaxy Design Platform, 2012 Jan. [Online]. Available: http://www.synopsys.com/solutions/endsolutions/galaxyimplementation/pages/milkyway. aspx 17. Synopsys Inc., Primetime Fundamentals user guide, December 2011. 18. Actel Corporation, RTL Register-Based Memory Implementations,May 2010.

84

XVII. AppendixA: verilog Codes

`timescale 1 ns/100 ps //############################################# //# Single-port SRAM description : //# Active High write enable (WE) //# Rising clock edge (Clock) //############################################# module reg_sram(Data, Q, Clock, WE, Address); parameter width = 8; parameter depth = 8; parameteraddr = 3; input Clock, WE; input [addr-1:0] Address; input [width-1:0] Data; output [width-1:0] Q; wire [width-1:0] Q; reg [width-1:0] mem_data [depth-1:0]; always @(posedge Clock) if(WE) mem_data[Address] = #1 Data; assign Q = mem_data[Address]; endmodule
Program 6: Single port verilog Ram [18]

`timescale 1 ns/100 ps module test; parameter width = 8; // bus width parameteraddr_bits = 3; // # of addr lines parameternumvecs = 21; // actual number of vectors parameterClockper = 1000; // 100ns period reg [width-1:0] Data; reg [addr_bits-1:0] Address; reg Clock, WE; reg [width-1:0] data_in [0:numvecs-1]; reg [width-1:0] data_out [0:numvecs-1]; wire [width-1:0] Q; integer i, j, numerrors; reg_sram u0(.Data(Data), .Q(Q), .Clock(Clock), .WE(WE), .Address(Address)); initial begin // sequential test patterns entered at neg edge Clock data_in[0]=8'h00; data_out[0]=8'hxx; data_in[1]=8'h01; data_out[1]=8'h01; data_in[2]=8'h02; data_out[2]=8'h02; data_in[3]=8'h04; data_out[3]=8'h04; 85

data_in[4]=8'h08; data_out[4]=8'h08; data_in[5]=8'h10; data_out[5]=8'h10; data_in[6]=8'h20; data_out[6]=8'h20; data_in[7]=8'h40; data_out[7]=8'h40; data_in[8]=8'h80; data_out[8]=8'h80; data_in[9]=8'h07; data_out[9]=8'h01; data_in[10]=8'h08; data_out[10]=8'h02; data_in[11]=8'h09; data_out[11]=8'h04; data_in[12]=8'h10; data_out[12]=8'h08; data_in[13]=8'h11; data_out[13]=8'h10; data_in[14]=8'h12; data_out[14]=8'h20; data_in[15]=8'h13; data_out[15]=8'h40; data_in[16]=8'h14; data_out[16]=8'h80; data_in[17]=8'haa; data_out[17]=8'haa; data_in[18]=8'h55; data_out[18]=8'haa; data_in[19]=8'h55; data_out[19]=8'h55; data_in[20]=8'haa; data_out[20]=8'h55; end initial begin Clock = 0; WE = 0; Address = 0; Data = 0; numerrors = 0; end always#(Clockper / 2) Clock = ~Clock; initial begin #2450 WE = 1; #8000 WE = 0; #8000 WE = 1; #1000 WE = 0; #1000 WE = 1; #1000 WE = 0; end initial begin $vcdpluson; #1450; for (j = 0; j <= width; j = j + 1) #1000 Address = j; for (j = 1; j <= width; j = j + 1) #1000 Address = j; Address = 0; end initial 86

begin $display("\nBeginning Simulation..."); //skip first rising edge for (i = 0; i <= numvecs-1; i = i + 1) begin @(negedge Clock); // apply test pattern at neg edge Data = data_in[i]; @(posedge Clock) #450; //45 ns later // check result at posedge + 45 ns $display("Pattern#%d time%d: WE=%b; Address=%h; Data=%h; Expected Q=%h; Actual Q=%h",i, $stime, WE, Address, Data, data_out[i], Q); if ( Q !== data_out[i] ) begin $display(" ** Error"); numerrors = numerrors + 1; end end if (numerrors == 0) $display("Good! End of Good Simulation."); else if (numerrors> 1) $display( "%0d ERRORS! End of Faulty Simulation.",numerrors); else $display( "1 ERROR! End of Faulty Simulation."); #1000 $finish; // after 100 ns later end endmodule
Program 7: Single port Ram Testbench [18] module reg_sram ( Data, Q, Clock, WE, Address ); input [7:0] Data; output [7:0] Q; input [2:0] Address; input Clock, WE; wire N10, N11, N12, \mem_data[7][7] , \mem_data[7][6] , \mem_data[7][5] , \mem_data[7][4] , \mem_data[7][3] , \mem_data[7][2] , \mem_data[7][1] , \mem_data[7][0] , \mem_data[6][7] , \mem_data[6][6] , \mem_data[6][5] , \mem_data[6][4] , \mem_data[6][3] , \mem_data[6][2] , \mem_data[6][1] , \mem_data[6][0] , \mem_data[5][7] , \mem_data[5][6] , \mem_data[5][5] , \mem_data[5][4] , \mem_data[5][3] , \mem_data[5][2] , \mem_data[5][1] , \mem_data[5][0] , \mem_data[4][7] , \mem_data[4][6] , \mem_data[4][5] , \mem_data[4][4] , \mem_data[4][3] , \mem_data[4][2] , \mem_data[4][1] , \mem_data[4][0] , \mem_data[3][7] , \mem_data[3][6] , \mem_data[3][5] , \mem_data[3][4] , \mem_data[3][3] , \mem_data[3][2] , \mem_data[3][1] , \mem_data[3][0] , \mem_data[2][7] , \mem_data[2][6] ,

87

\mem_data[2][5] , \mem_data[2][4] , \mem_data[2][3] , \mem_data[2][2] , \mem_data[2][1] , \mem_data[2][0] , \mem_data[1][7] , \mem_data[1][6] , \mem_data[1][5] , \mem_data[1][4] , \mem_data[1][3] , \mem_data[1][2] , \mem_data[1][1] , \mem_data[1][0] , \mem_data[0][7] , \mem_data[0][6] , \mem_data[0][5] , \mem_data[0][4] , \mem_data[0][3] , \mem_data[0][2] , \mem_data[0][1] , \mem_data[0][0] , N15, N16, N17, N19, N20, N21, n4, n5, n6, n7, n8, n9, n10, n11, n12, n13, n14, n15, n16, n17, n18, n19, n20, n21, n22, n23, n24, n25, n26, n27, n28, n29, n30, n31, n32, n33, n34, n35, n36, n37, n38, n39, n40, n41, n42, n43, n44, n45, n46, n47; assign N10 = Address[0]; assign N11 = Address[1]; assign N12 = Address[2]; NAND2X2 U2 ( .IN1(WE), .IN2(N12), .QN(n4) ); NAND2X2 U3 ( .IN1(WE), .IN2(n45), .QN(n5) ); fdef1a3 \mem_data_reg[5][7] ( .D(Data[7]), .E(N19), .CLK(n38), .Q( \mem_data[5][7] ) ); fdef1a3 \mem_data_reg[5][6] ( .D(Data[6]), .E(N19), .CLK(n38), .Q( \mem_data[5][6] ) ); fdef1a3 \mem_data_reg[5][5] ( .D(Data[5]), .E(N19), .CLK(n38), .Q( \mem_data[5][5] ) ); fdef1a3 \mem_data_reg[5][4] ( .D(Data[4]), .E(N19), .CLK(n37), .Q( \mem_data[5][4] ) ); fdef1a3 \mem_data_reg[5][3] ( .D(Data[3]), .E(N19), .CLK(n37), .Q( \mem_data[5][3] ) ); fdef1a3 \mem_data_reg[5][2] ( .D(Data[2]), .E(N19), .CLK(n37), .Q( \mem_data[5][2] ) ); fdef1a3 \mem_data_reg[5][1] ( .D(Data[1]), .E(N19), .CLK(n36), .Q( \mem_data[5][1] ) ); fdef1a3 \mem_data_reg[5][0] ( .D(Data[0]), .E(N19), .CLK(n36), .Q( \mem_data[5][0] ) ); fdef1a3 \mem_data_reg[1][7] ( .D(Data[7]), .E(N15), .CLK(n28), .Q( \mem_data[1][7] ) ); fdef1a3 \mem_data_reg[1][6] ( .D(Data[6]), .E(N15), .CLK(n33), .Q( \mem_data[1][6] ) ); fdef1a3 \mem_data_reg[1][5] ( .D(Data[5]), .E(N15), .CLK(n37), .Q( \mem_data[1][5] ) ); fdef1a3 \mem_data_reg[1][4] ( .D(Data[4]), .E(N15), .CLK(n29), .Q( \mem_data[1][4] ) ); fdef1a3 \mem_data_reg[1][3] ( .D(Data[3]), .E(N15), .CLK(n36), .Q( \mem_data[1][3] ) ); fdef1a3 \mem_data_reg[1][2] ( .D(Data[2]), .E(N15), .CLK(n35), .Q( \mem_data[1][2] ) ); fdef1a3 \mem_data_reg[1][1] ( .D(Data[1]), .E(N15), .CLK(n34), .Q( \mem_data[1][1] ) ); fdef1a3 \mem_data_reg[1][0] ( .D(Data[0]), .E(N15), .CLK(n40), .Q( \mem_data[1][0] ) ); fdef1a3 \mem_data_reg[4][7] ( .D(Data[7]), .E(n7), .CLK(n36), .Q( \mem_data[4][7] ) ); fdef1a3 \mem_data_reg[4][6] ( .D(Data[6]), .E(n7), .CLK(n35), .Q( \mem_data[4][6] ) ); fdef1a3 \mem_data_reg[4][5] ( .D(Data[5]), .E(n7), .CLK(n35), .Q( \mem_data[4][5] ) ); fdef1a3 \mem_data_reg[4][4] ( .D(Data[4]), .E(n7), .CLK(n35), .Q(

88

\mem_data[4][4] ) ); fdef1a3 \mem_data_reg[4][3] \mem_data[4][3] ) ); fdef1a3 \mem_data_reg[4][2] \mem_data[4][2] ) ); fdef1a3 \mem_data_reg[4][1] \mem_data[4][1] ) ); fdef1a3 \mem_data_reg[4][0] \mem_data[4][0] ) ); fdef1a3 \mem_data_reg[0][7] \mem_data[0][7] ) ); fdef1a3 \mem_data_reg[0][6] \mem_data[0][6] ) ); fdef1a3 \mem_data_reg[0][5] \mem_data[0][5] ) ); fdef1a3 \mem_data_reg[0][4] \mem_data[0][4] ) ); fdef1a3 \mem_data_reg[0][3] \mem_data[0][3] ) ); fdef1a3 \mem_data_reg[0][2] \mem_data[0][2] ) ); fdef1a3 \mem_data_reg[0][1] \mem_data[0][1] ) ); fdef1a3 \mem_data_reg[0][0] \mem_data[0][0] ) ); fdef1a3 \mem_data_reg[7][6] \mem_data[7][6] ) ); fdef1a3 \mem_data_reg[7][5] \mem_data[7][5] ) ); fdef1a3 \mem_data_reg[7][4] \mem_data[7][4] ) ); fdef1a3 \mem_data_reg[7][3] \mem_data[7][3] ) ); fdef1a3 \mem_data_reg[7][2] \mem_data[7][2] ) ); fdef1a3 \mem_data_reg[7][1] \mem_data[7][1] ) ); fdef1a3 \mem_data_reg[7][0] \mem_data[7][0] ) ); fdef1a3 \mem_data_reg[3][7] \mem_data[3][7] ) ); fdef1a3 \mem_data_reg[3][6] \mem_data[3][6] ) ); fdef1a3 \mem_data_reg[3][5] \mem_data[3][5] ) ); fdef1a3 \mem_data_reg[3][4] \mem_data[3][4] ) ); fdef1a3 \mem_data_reg[3][3] \mem_data[3][3] ) ); fdef1a3 \mem_data_reg[3][2] \mem_data[3][2] ) ); fdef1a3 \mem_data_reg[3][1] \mem_data[3][1] ) ); fdef1a3 \mem_data_reg[3][0] \mem_data[3][0] ) ); fdef1a3 \mem_data_reg[6][7] \mem_data[6][7] ) );

( .D(Data[3]), .E(n7), .CLK(n34), .Q( ( .D(Data[2]), .E(n7), .CLK(n34), .Q( ( .D(Data[1]), .E(n7), .CLK(n34), .Q( ( .D(Data[0]), .E(n7), .CLK(n33), .Q( ( .D(Data[7]), .E(n6), .CLK(n39), .Q( ( .D(Data[6]), .E(n6), .CLK(n38), .Q( ( .D(Data[5]), .E(n6), .CLK(n29), .Q( ( .D(Data[4]), .E(n6), .CLK(n29), .Q( ( .D(Data[3]), .E(n6), .CLK(n29), .Q( ( .D(Data[2]), .E(n6), .CLK(n28), .Q( ( .D(Data[1]), .E(n6), .CLK(n28), .Q( ( .D(Data[0]), .E(n6), .CLK(n28), .Q( ( .D(Data[6]), .E(N21), .CLK(n43), .Q( ( .D(Data[5]), .E(N21), .CLK(n43), .Q( ( .D(Data[4]), .E(N21), .CLK(n43), .Q( ( .D(Data[3]), .E(N21), .CLK(n42), .Q( ( .D(Data[2]), .E(N21), .CLK(n42), .Q( ( .D(Data[1]), .E(N21), .CLK(n42), .Q( ( .D(Data[0]), .E(N21), .CLK(n41), .Q( ( .D(Data[7]), .E(N17), .CLK(n33), .Q( ( .D(Data[6]), .E(N17), .CLK(n33), .Q( ( .D(Data[5]), .E(N17), .CLK(n32), .Q( ( .D(Data[4]), .E(N17), .CLK(n32), .Q( ( .D(Data[3]), .E(N17), .CLK(n32), .Q( ( .D(Data[2]), .E(N17), .CLK(n32), .Q( ( .D(Data[1]), .E(N17), .CLK(n31), .Q( ( .D(Data[0]), .E(N17), .CLK(n30), .Q( ( .D(Data[7]), .E(N20), .CLK(n41), .Q(

89

fdef1a3 \mem_data_reg[6][6] ( .D(Data[6]), .E(N20), .CLK(n41), \mem_data[6][6] ) ); fdef1a3 \mem_data_reg[6][5] ( .D(Data[5]), .E(N20), .CLK(n40), \mem_data[6][5] ) ); fdef1a3 \mem_data_reg[6][4] ( .D(Data[4]), .E(N20), .CLK(n40), \mem_data[6][4] ) ); fdef1a3 \mem_data_reg[6][3] ( .D(Data[3]), .E(N20), .CLK(n40), \mem_data[6][3] ) ); fdef1a3 \mem_data_reg[6][2] ( .D(Data[2]), .E(N20), .CLK(n39), \mem_data[6][2] ) ); fdef1a3 \mem_data_reg[6][1] ( .D(Data[1]), .E(N20), .CLK(n39), \mem_data[6][1] ) ); fdef1a3 \mem_data_reg[6][0] ( .D(Data[0]), .E(N20), .CLK(n39), \mem_data[6][0] ) ); fdef1a3 \mem_data_reg[2][7] ( .D(Data[7]), .E(N16), .CLK(n31), \mem_data[2][7] ) ); fdef1a3 \mem_data_reg[2][6] ( .D(Data[6]), .E(N16), .CLK(n31), \mem_data[2][6] ) ); fdef1a3 \mem_data_reg[2][5] ( .D(Data[5]), .E(N16), .CLK(n31), \mem_data[2][5] ) ); fdef1a3 \mem_data_reg[2][4] ( .D(Data[4]), .E(N16), .CLK(n30), \mem_data[2][4] ) ); fdef1a3 \mem_data_reg[2][3] ( .D(Data[3]), .E(N16), .CLK(n30), \mem_data[2][3] ) ); fdef1a3 \mem_data_reg[2][2] ( .D(Data[2]), .E(N16), .CLK(n30), \mem_data[2][2] ) ); fdef1a3 \mem_data_reg[2][1] ( .D(Data[1]), .E(N16), .CLK(n44), \mem_data[2][1] ) ); fdef1a3 \mem_data_reg[2][0] ( .D(Data[0]), .E(N16), .CLK(n44), \mem_data[2][0] ) ); fdef1a3 \mem_data_reg[7][7] ( .D(Data[7]), .E(N21), .CLK(n44), \mem_data[7][7] ) ); INVX2 U15 ( .INP(n9), .ZN(n46) ); INVX2 U16 ( .INP(n11), .ZN(n47) ); NOR3X1 U17 ( .IN1(n5), .IN2(n11), .IN3(n46), .QN(N16) ); NOR3X1 U18 ( .IN1(n46), .IN2(n11), .IN3(n4), .QN(N20) ); NOR3X1 U19 ( .IN1(n5), .IN2(n9), .IN3(n47), .QN(N15) ); NOR3X1 U20 ( .IN1(n47), .IN2(n9), .IN3(n4), .QN(N19) ); NOR3X1 U21 ( .IN1(n5), .IN2(n9), .IN3(n11), .QN(n6) ); NOR3X1 U22 ( .IN1(n4), .IN2(n9), .IN3(n11), .QN(n7) ); INVX0 U23 ( .INP(N11), .ZN(n8) ); inv1a3 U24 ( .A(n8), .Y(n9) ); INVX0 U25 ( .INP(N10), .ZN(n10) ); inv1a3 U26 ( .A(n10), .Y(n11) ); mx2a3 U27 ( .D0(n27), .D1(n26), .S(N12), .Y(Q[7]) ); mx2a3 U28 ( .D0(n25), .D1(n24), .S(N12), .Y(Q[6]) ); mx2a3 U29 ( .D0(n23), .D1(n22), .S(N12), .Y(Q[5]) ); mx2a3 U30 ( .D0(n21), .D1(n20), .S(N12), .Y(Q[4]) ); mx2a3 U31 ( .D0(n19), .D1(n18), .S(N12), .Y(Q[3]) ); mx2a3 U32 ( .D0(n17), .D1(n16), .S(N12), .Y(Q[2]) ); mx2a3 U33 ( .D0(n15), .D1(n14), .S(N12), .Y(Q[1]) ); mx2a3 U34 ( .D0(n13), .D1(n12), .S(N12), .Y(Q[0]) ); NOR3X1 U35 ( .IN1(n46), .IN2(n4), .IN3(n47), .QN(N21) ); NOR3X1 U36 ( .IN1(n5), .IN2(n47), .IN3(n46), .QN(N17) ); INVX0 U37 ( .INP(N12), .ZN(n45) ); buf1a3 U38 ( .A(Clock), .Y(n28) ); buf1a3 U39 ( .A(Clock), .Y(n29) );

.Q( .Q( .Q( .Q( .Q( .Q( .Q( .Q( .Q( .Q( .Q( .Q( .Q( .Q( .Q( .Q(

90

buf1a3 U40 ( .A(Clock), .Y(n30) ); buf1a3 U41 ( .A(Clock), .Y(n31) ); DELLN1X2 U42 ( .INP(Clock), .Z(n32) ); NBUFFX2 U43 ( .INP(Clock), .Z(n33) ); NBUFFX2 U44 ( .INP(Clock), .Z(n34) ); NBUFFX2 U45 ( .INP(Clock), .Z(n35) ); NBUFFX2 U46 ( .INP(Clock), .Z(n36) ); NBUFFX2 U47 ( .INP(Clock), .Z(n37) ); NBUFFX2 U48 ( .INP(Clock), .Z(n38) ); NBUFFX2 U49 ( .INP(Clock), .Z(n39) ); NBUFFX2 U50 ( .INP(Clock), .Z(n40) ); NBUFFX2 U51 ( .INP(Clock), .Z(n41) ); NBUFFX2 U52 ( .INP(Clock), .Z(n42) ); NBUFFX2 U53 ( .INP(Clock), .Z(n43) ); NBUFFX2 U54 ( .INP(Clock), .Z(n44) ); MUX41X1 U55 ( .IN1(\mem_data[4][0] ), .IN3(\mem_data[6][0] ), .IN2( \mem_data[5][0] ), .IN4(\mem_data[7][0] ), .S0(n9), .S1(n11), ); MUX41X1 U56 ( .IN1(\mem_data[0][0] ), .IN3(\mem_data[2][0] ), .IN2( \mem_data[1][0] ), .IN4(\mem_data[3][0] ), .S0(n9), .S1(n11), ); MUX41X1 U57 ( .IN1(\mem_data[4][1] ), .IN3(\mem_data[6][1] ), .IN2( \mem_data[5][1] ), .IN4(\mem_data[7][1] ), .S0(n9), .S1(n11), ); MUX41X1 U58 ( .IN1(\mem_data[0][1] ), .IN3(\mem_data[2][1] ), .IN2( \mem_data[1][1] ), .IN4(\mem_data[3][1] ), .S0(n9), .S1(n11), ); MUX41X1 U59 ( .IN1(\mem_data[4][2] ), .IN3(\mem_data[6][2] ), .IN2( \mem_data[5][2] ), .IN4(\mem_data[7][2] ), .S0(n9), .S1(n11), ); MUX41X1 U60 ( .IN1(\mem_data[0][2] ), .IN3(\mem_data[2][2] ), .IN2( \mem_data[1][2] ), .IN4(\mem_data[3][2] ), .S0(n9), .S1(n11), ); MUX41X1 U61 ( .IN1(\mem_data[4][3] ), .IN3(\mem_data[6][3] ), .IN2( \mem_data[5][3] ), .IN4(\mem_data[7][3] ), .S0(n9), .S1(n11), ); MUX41X1 U62 ( .IN1(\mem_data[0][3] ), .IN3(\mem_data[2][3] ), .IN2( \mem_data[1][3] ), .IN4(\mem_data[3][3] ), .S0(n9), .S1(n11), ); MUX41X1 U63 ( .IN1(\mem_data[4][4] ), .IN3(\mem_data[6][4] ), .IN2( \mem_data[5][4] ), .IN4(\mem_data[7][4] ), .S0(n9), .S1(n11), ); MUX41X1 U64 ( .IN1(\mem_data[0][4] ), .IN3(\mem_data[2][4] ), .IN2( \mem_data[1][4] ), .IN4(\mem_data[3][4] ), .S0(n9), .S1(n11), ); MUX41X1 U65 ( .IN1(\mem_data[4][5] ), .IN3(\mem_data[6][5] ), .IN2( \mem_data[5][5] ), .IN4(\mem_data[7][5] ), .S0(n9), .S1(n11), ); MUX41X1 U66 ( .IN1(\mem_data[0][5] ), .IN3(\mem_data[2][5] ), .IN2( \mem_data[1][5] ), .IN4(\mem_data[3][5] ), .S0(n9), .S1(n11), ); MUX41X1 U67 ( .IN1(\mem_data[4][6] ), .IN3(\mem_data[6][6] ), .IN2( \mem_data[5][6] ), .IN4(\mem_data[7][6] ), .S0(n9), .S1(n11), ); MUX41X1 U68 ( .IN1(\mem_data[0][6] ), .IN3(\mem_data[2][6] ), .IN2( \mem_data[1][6] ), .IN4(\mem_data[3][6] ), .S0(n9), .S1(n11), );

.Q(n12) .Q(n13) .Q(n14) .Q(n15) .Q(n16) .Q(n17) .Q(n18) .Q(n19) .Q(n20) .Q(n21) .Q(n22) .Q(n23) .Q(n24) .Q(n25)

91

MUX41X1 U69 ( .IN1(\mem_data[4][7] ), .IN3(\mem_data[6][7] ), .IN2( \mem_data[5][7] ), .IN4(\mem_data[7][7] ), .S0(n9), .S1(n11), .Q(n26) ); MUX41X1 U70 ( .IN1(\mem_data[0][7] ), .IN3(\mem_data[2][7] ), .IN2( \mem_data[1][7] ), .IN4(\mem_data[3][7] ), .S0(n9), .S1(n11), .Q(n27) ); endmodule Program 8: Flattened model (synthesized model) after synthesis stage

moduleaddSub(A, B, sel, Result); inputsel; input [3:0] A,B; output [3:0] Result; wire [3:0] Result; assign Result = (sel)? A + B : A - B; endmodule
Program 9: verilog code for Add/Subtract module

module main; reg [3:0] A, B; regsel; wire [3:0] Result; addSub as1(A, B, sel, Result); initial begin A = 4'b0001; B = 4'b1010; end initial begin forever begin #10 $vcdpluson; A = A + 1'b1; B = B + 1'b1; end end initial begin sel = 1; #200 sel = 0; end endmodule
Program 10: Testbench for Add/Subtract module

moduleaddSub ( A, B, sel, Result ); input [3:0] A; input [3:0] B; output [3:0] Result; inputsel; wire n7, n8, n9, n10, n11, n12, n13, n14, n15, n16, n17, n18, n19, n20, 92

n21, n22, n23, n24, n25, n26, n27, n28, n29, n30; INVX1 U4 ( .INP(n25), .ZN(n7) ); INVX1 U5 ( .INP(B[2]), .ZN(n8) ); INVX1 U7 ( .INP(B[0]), .ZN(n10) ); INVX1 U8 ( .INP(sel), .ZN(n11) ); AO22X1 U9 ( .IN1(sel), .IN2(n12), .IN3(n13), .IN4(n11), .Q(Result[3]) ); XOR2X1 U10 ( .IN1(n14), .IN2(n15), .Q(n13) ); OA22X1 U11 ( .IN1(n16), .IN2(n8), .IN3(A[2]), .IN4(n17), .Q(n15) ); AND2X1 U12 ( .IN1(n17), .IN2(A[2]), .Q(n16) ); XNOR2X1 U14 ( .IN1(B[3]), .IN2(A[3]), .Q(n14) ); OA22X1 U15 ( .IN1(B[2]), .IN2(n19), .IN3(A[2]), .IN4(n20), .Q(n18) ); AND2X1 U16 ( .IN1(n20), .IN2(A[2]), .Q(n19) ); AO22X1 U17 ( .IN1(n21), .IN2(sel), .IN3(n22), .IN4(n11), .Q(Result[2]) ); XOR2X1 U18 ( .IN1(n17), .IN2(n23), .Q(n22) ); AO22X1 U19 ( .IN1(A[1]), .IN2(n7), .IN3(n24), .IN4(n9), .Q(n17) ); OR2X1 U20 ( .IN1(n7), .IN2(A[1]), .Q(n24) ); XOR2X1 U22 ( .IN1(n8), .IN2(A[2]), .Q(n23) ); AO22X1 U23 ( .IN1(n26), .IN2(A[1]), .IN3(B[1]), .IN4(n27), .Q(n20) ); OR2X1 U24 ( .IN1(A[1]), .IN2(n26), .Q(n27) ); AO22X1 U25 ( .IN1(sel), .IN2(n28), .IN3(n29), .IN4(n11), .Q(Result[1]) ); XOR2X1 U26 ( .IN1(n25), .IN2(n30), .Q(n29) ); XOR2X1 U27 ( .IN1(n26), .IN2(n30), .Q(n28) ); XOR2X1 U28 ( .IN1(B[1]), .IN2(A[1]), .Q(n30) ); AND2X1 U29 ( .IN1(A[0]), .IN2(B[0]), .Q(n26) ); AO21X1 U30 ( .IN1(A[0]), .IN2(n10), .IN3(n25), .Q(Result[0]) ); XNOR2X1 U31 ( .IN1(n18), .IN2(n14), .Q(n12) ); INVX0 U32 ( .INP(B[1]), .ZN(n9) ); NOR2X2 U33 ( .IN1(n10), .IN2(A[0]), .QN(n25) ); XNOR2X1 U34 ( .IN1(n20), .IN2(n23), .Q(n21) ); endmodule
Program 11: Flattened model for Add/Subtract model

module counter ( out, clk, reset ) ; input clk, reset; output [3:0] out; reg [3:0] out; wire [3:0] next; // This statement implements reset and increment assign next = reset ? 4'b0 : (out + 4'b1); 93

// This implements the flip-flops always @ ( posedge clk ) begin out<= #1 next; end endmodule // counter
Program 12: A basic counter [2] // This stuff just sets up the proper time scale and format for the // simulation, for now do not modify. //`timescale 1ns/10ps moduletimeunit; initial $timeformat(-9,1," ns",9); endmodule // Here is the testbench proper: modulecounter_testbench ( ) ; // Test bench gets wires for all device under test (DUT) outputs: wire [3:0] out; // Regs for all DUT inputs: reg clk; reg reset; counterdut (// (dut means device under test) // Outputs .out (out[3:0]), // Inputs .reset (reset), .clk (clk)); // Setup clk to automatically strobe with a period of 20. always #10 clk = ~clk; initial begin // First setup up to monitor all inputs and outputs $vcdpluson; $monitor ("time=%5d ns, clk=%b, reset=%b, out=%b", $time, clk, reset, out[3:0]); // First initialize all registers clk = 1'b0; // what happens to clk if we don't // set this?; reset = 1'b0; @(posedge clk);#1; // this says wait for rising edge // of clk and one more tic (to prevent // shoot through) reset = 1'b1; @(posedge clk);#1; reset = 1'b0; // Lets watch what happens after 7 cycles @(posedge clk);#1; @(posedge clk);#1; @(posedge clk);#1; @(posedge clk);#1; @(posedge clk);#1; @(posedge clk);#1; @(posedge clk);#1; // At this point we should have a 4'b0110 coming out outbecause // the counter should have counted for 7 cycles from 0 if(out != 4'b0110) begin $display("ERROR 1: Out is not equal to 4'b0110");

94

//$finish; end // We got this far so all tests passed. $display("All tests completed sucessfully\n\n"); $finish; end // This is to create a dump file for offline viewing. initial begin $dumpfile ("counter.dump"); $dumpvars (0, counter_testbench); end // initial begin endmodule // counter_testbench Program 13: Test bench for Counter [2] module counter ( out, clk, reset ); output [3:0] out; input clk, reset; wire n6, n8, n9, n10, n11, n12, n13, n14, n15; wire [3:0] next; INVX1 U9 ( .INP(reset), .ZN(n8) ); AO21X1 U11 ( .IN1(n15), .IN2(n8), .IN3(n12), .Q(n9) ); AO22X1 U12 ( .IN1(out[2]), .IN2(n12), .IN3(n6), .IN4(n15), .Q(next[2]) ); AO21X1 U14 ( .IN1(n14), .IN2(n8), .IN3(next[0]), .Q(n12) ); XNOR2X1 U15 ( .IN1(out[0]), .IN2(out[1]), .Q(n13) ); DFFX2 \out_reg[0] ( .D(next[0]), .CLK(clk), .Q(out[0]) ); DFFX2 \out_reg[2] ( .D(next[2]), .CLK(clk), .Q(out[2]), .QN(n15) ); DFFX2 \out_reg[3] ( .D(next[3]), .CLK(clk), .Q(out[3]) ); DFFX2 \out_reg[1] ( .D(next[1]), .CLK(clk), .Q(out[1]), .QN(n14) ); INVX0 U16 ( .INP(n11), .ZN(n6) ); NOR2X1 U17 ( .IN1(out[3]), .IN2(n11), .QN(n10) ); AO22X1 U18 ( .IN1(out[3]), .IN2(n9), .IN3(n10), .IN4(out[2]), .Q(next[3]) ); NAND3X1 U19 ( .IN1(out[0]), .IN2(n8), .IN3(out[1]), .QN(n11) ); NOR2X2 U20 ( .IN1(out[0]), .IN2(reset), .QN(next[0]) ); NOR2X1 U21 ( .IN1(reset), .IN2(n13), .QN(next[1]) ); endmodule Program 14: Flattened model for Counter

95

XVIII. Appendix B:Acronyms

Acronym STIL ATE GSV RTL DC PT VCS DVE STA ICC VCD SRC DDC EDA DFT GTECH TCL VPD GZIP Full form Standard Test Interface Language Automatic Test Equipment Graphical Schematic Viewer Register-transfer Level Design Compiler Prime Time Verilog Compiled code Simulator Discovery Visual Environment Static Time Analysis IC Compiler Value Change Dump HDL Source files Design Compiler Database Electronic Design Automation Design For Test Generic Technology Library Tool Command Language VCD Plus Gnu Zip

96

XIX. Appendix C: File Extensions

File format .tcl .sdc .db .slib .sdb .rpt .tf .tluplus .mw Simv .saif .sdf Name of the file Tool Command Language Synopsys Design Constraints Synopsys Database (Technology library) Symbol Library source file Symbol Library (compiled version of .slib) Reports Vendor Technology File TLU + File Milkyway Database Compiled Simulator Switching Activity Interchange Format Standard Delay Format

.ddc: Synopsys internal database format. This format is recommended by Synopsys to handle gate level netlist. .vcd: Value Change Dump format. This This format is used to save signal transition trace information. VCD les are text les, and therefore trace les in this format can quickly get very large. Tools like vcd2vpd, vpd2vcd, and vcd2saif can be used to switch back and forth between dierent formats.

97

.vpd: VCD Plus. This is a proprietary compressed binary trace format from Synopsys. This file format is used to save signal transition trace information as well. .saif: Switching Activity Interchange Format. Provides information regarding signal transition trace. SAIF les support signals and ports for monitoring as well as constructs such as generates, enumerated types, records, array of arrays, and integers. .sdc: Synopsys Design Constraints. This file is used for all implementation tools in various processes like, synthesis, timing analysis, place and route phase. SDC les are used to communicate design intent, including timing and area requirements between EDA tools. .sdf: Standard Delay Format. Used to convey the timing information of a design after Implementation. This file lets user know about the delay at each cell, net, node. This is exported to do the simulation of design and to find if the design is operating at the frequency without any setup/hold violations. .tf: Vendor technology file. Contains characteristics and design rules for the process. Contains physical and electrical information for each metal layer and is useful during routing a design. .tluplus: TLU-Plus. Contains models of advance process effects that can be used by the parasitic extractor. .db or .lib: Database format or library format. Technology libraries contain information about the characteristics and functions of each cell provided in a semiconductor vendors library. Contains timing and area information for each standard cell. The technology le also denes the operating conditions and wire load models specic to the particular technology. Technology libraries are typically maintained and distributed by semiconductor vendors.

These are some of the important file formats that are required throughout the process of ASIC design flow. There might be some files that are not mentioned in this project and are important in the ASIC flow.

98

XX. Appendix D: Trouble shooting

This section of the document gives some of the trouble shooting techniques that were encountered during research. Case 1: When a clock is defined in test bench as an infinite loop, simulation will never be completed. To check the simulation results user will have to wait sitting there forever. Refer to below code for exact situation: initial begin forever begin clk<= 0; #5 clk<= 1; #5 clk<= 0; end end In this case user will have to wait forever to see the simulation results. Using of a simple command can help user quit the forever loop of clock and display the waveforms accordingly. CTRL+Z will break the loop and gives the intermediate results. Case 2: To view hidden files in UNIX environment use command ls -all Case 3: To view current settings of a variable in shell, use printvar. A situation is given for Situation: dc_shell>printvarsh_enalble_page_mode sh_enalble_page_mode = false printvardisplays current settings of a shell element, upon viewing values of the element it can be set to some other values using setcomand as shown: dc_shell> set sh_enalble_page_mode true true To view multiple variable settings, use sh_*, this command give settings of all the shell variables that start with sh. Case 4: To view full command syntax including options and arguments use help verbose. Situation: dc_shell> help verbose set_input_delay or dc_shell> set_input_delay -help both the commands does the same function of displaying command syntax along with the arguments. 99

Case 5: Using man command for analyzing error, information, and warning messages. Situation:
dc_shell>write_file -format verilog -hierarchy -output ram_iitk_up_syn.v Writing verilog file '/home/mallik/verilog/ram_iitk_up_syn.v'. Warning: Verilog 'assign' or 'tran' statements are written out. (VO-4)

While writing gate-level netlist dc shell displayed a warning with number VO-4, by using man command we can actually look and analyze this warning. dc_shell>man V0-4 man command gives the below information Name: VO-4 (warning) verilog assign or trans statement are written out. Description: In this design, ports are attached to other ports, which forces verilogout to use assign ortransstatements to write-out a correct description. What Next: If the problem exists, it can be solved by the compile command with proper setting of the variableset_fix_multiple_ports_nets. For instructions on how to use the variable, see man page. Case 6: By default TetraMax aborts the process upon identification of any errors. In some cases user discovers that the errors may not cause harm to the process but left with no cluse how to fix them. In this case use set_rules. Situation: BUILD T>report_violations b5 BUILD T>set_rules<rule_id> [error| warning | ignore] [-mask | -nomask] [-autofix | -noautofix] [-reset] [-verbose] First command gives set of rule_ids that violated b5 rules. Using second command user can set the severity of the error as a warning and continue with the process of TetraMax. [error| warning | ignore] specifies the new severity level of the rule. If the rule violation is fatal error by default, you are not allowed to set it to a lower severity level. If no severity is specified, the existing setting is retained. More information regarding this command can be found using help option in TetraMax.

100