Download Introduction - Design Verification and Test - Lecture Notes and more Study notes Design and Analysis of Algorithms in PDF only on Docsity!
Module-I
Lecture-I
Introduction to Digital VLSI Design Flow
1. Introduction VLSI Design
The functionality of electronics equipments and gadgets has achieved a phenomenal growth over the last two decades while their physical sizes and weights have come down drastically. The major reason is due to the rapid advances in integration technologies, which enables fabrication of millions of transistors in a single Integrated Circuit (IC) or chip. IC (used interchangeably with “chip” in this lecture) is a device having multiple transistors with interconnects manufactured on a single silicon substrate. Integration with a complexity of 10’s of transistors is called Small Scale Integration, with 100’s is Medium Scale Integration (MSI), with 1000’s is Large Scale Integration (LSI), with 10,000 it is Very Large Scale Integration (VLSI) [1]. As a very huge number of components can be integrated in a single IC fabricated using VLSI technology, the variant of functionalities provided by such ICs can be as large as those which were provided by thousands of LSI ICs. In other words, systems of systems can be implemented in a VLSI IC. However, with this rise in functionality of VLSI ICs, design problem has become huge and complex. To address this complexly issue, after the design specifications are complete almost all the other steps are automated using CAD tools. However, even designs automated using CAD tools may have bugs. Also, due to extremely large size of the design space it is not possible to verify correctness of the design under all possible situations. So technique are required that can verify, without exercising exhaustive input-output combinations, that the design meets all the input specifications; this technique is called formal verification. Finally, when the design meets all specifications (as it is formally verified) it is manufactured and sent to market. In VLSI designs as millions of transistors are packed into a single chip, the device and interconnect sizes are extremely small and so are the inert-component distances. This leads to manufacturing defects and all the chips need to be physically tested by giving input signals from a pattern generator and comparing responses using a logic analyzer; this process is called Testing. So, in the process of manufacturing a VLSI IC there are
three broad steps: DESIGN-VERIFICATION-TEST. There are algorithms and CAD tools which automate these three steps. VLSI ICs can be divided into analog, digital or mixed-signal (both analog and digital on the same chip) based on their functionality. Digital ICs can contain logic gates, flip-flops, multiplexers, and other circuits which work using binary mathematics to process "one" and "zero" signals. Analog ICs, such as current mirrors, voltage followers, filters, OPAMPs etc. work by processing continuous signals. They perform functions like amplification, active filtering, demodulation etc. When single IC has both analog and digital components it is called mixed signal IC e.g, Analog to Digital Converter (ADC). The automation algorithms and CAD tools are mainly available for digital ICs because digital circuits comprise millions of components and transformation of design specifications to silicon implementation can be accomplished using logical procedures (which can be converted to algorithms and tools) [2]. However, most of the analog circuits comprise less than hundred devices and its design is like an “art” which is best performed by designers with “aid” of some CAD tools (which provides feedback to designer if the manual design is progressing fine etc.) [2]. In this course we will deal only with digital VLSI circuits. Henceforth, in this course VLSI IC would imply digital VLSI ICs only and whenever we want to discuss about analog or mixed signal ICs it will be mentioned explicitly. Also, in this course the terms ICs and chips would mean VLSI ICs and chips. This course is concerned with algorithms required to automate the three steps “DESIGN- VERIFICATION-TEST” for Digital VLSI ICs. Although there are individual courses catering to each step, in this course we will try to give a complete picture of algorithms required to automate the entire flow “DESIGN-VERIFICATION-TEST”. This course will give you a comprehensive idea of algorithms required in CAD tools for the whole digital VLSI flow, however, to cover the entire flow at certain points we will go to a limited depth and provide references to the details. In the first lecture we will introduce the entire flow of “DESIGN-VERIFICATION- TEST” using a simple example, in brief. Also, we will not go into the algorithms required to automate the steps, rather we will point the requirements of the algorithms.
Figure 1 illustrates a typical VLSI DESIGN-VERIFICATION-TEST flow. Step1: Specification Design In a typical VLSI flow, we start with system specifications, which is nothing but technical representation of design intent. To explain the flow, the following example will be used through this section. Example: Specification: out1=a+b; out2=c+d; where a,b,c,d are single bit inputs and out1,out2 are two bit outputs (sum and carry). Step 2: High level Synthesis High-level synthesis (HLS) algorithms are used to convert specifications into Register Transfer Level (RTL) circuits. HLS, sometimes referred to as architectural synthesis is an automated design procedure that interprets an algorithmic description of the design intent and creates hardware at RTL that implements that behavior [3]. The input to a HLS tool is design intent written in some high level hardware definition language like SystemC, System Verilog etc. The HLS tool first schedules the computations (required to meet the specifications) at different control steps. The computations scheduled at each control step contains operations which can be performed in a single clock cycle in the hardware. Following that, depending on availability of hardware units and time constraints, the scheduled computations (comprising instructions and variables) are allocated and binded to the hardware units like adders, multipliers, multiplexors, registers, wires etc. Example: In the example there are two operations (addition of single bit numbers) and none of them depend on each other. So both the operations can be scheduled in a single control step. However, if there are dependencies e.g., out1=a+b; out2=out1+d; then “out1=a+b;” is scheduled in 1st^ control step whereas “out2=out1+d;” is scheduled in 2nd^ control step. Figure 2 illustrates scheduling of the operations of the example. Now depending on availability of hardware resources and time constraints the scheduled operators and variables are allocated and binded to hardware units. Let
there be one adder and two registers in the library. So the two operations (addition) of the example, even if scheduled in one control step, cannot be allocated to the single adder. Similarly, the four variables cannot be allocated to two registers. In the running example with the given resource constraints, the two operations can be done in two control steps: Step 1- variable a is allocated to Register1, variable b is allocated to Register2 and operation “out1=Register1+Register2;” is allocated to adder; Step 2- variable c is allocated to Register1, variable d is allocated to Register2 and operation “out2=Register1+Register2;” is allocated to adder. Figure 3 illustrates allocation and binding (of variables and operations) for the running example when there is one adder and two registers in the library.
a b^ c^ d
out1 (^) out Figure 2. Scheduling of the operations for the example
a b
out1 c^ d
out
1 bit adder "out1=a+b"
a b
Register1 Register
out
1 bit adder "out2=c+d"
c d
Register1 Register
out
Figure 3. Allocation of operators and variables to hardware units ( 1 adder + 2 Registers)
adder
Register1 Register
out out
Mux Mux
a (^) c (^) b d control
Figure 5. Block diagram with control modules added after allocation and binding
The HLS tool generates output comprising, (i) operations-variables allocated- binded to hardware units and (ii) control modules. The output of HLS tool is called Register Transfer Level (RTL) circuit because data flow, data operations and control flow are captured between registers. After HLS, RTL circuits are transformed into logic gate level implementation; the step is called logic synthesis. Before the staring of logic synthesis, one needs to verify if the RTL is equivalent to the specifications. In the running example, we can verify by applying all possible input conditions of a,b,c,d (along with control , if RTL is as per Figure 5) to the RTL and checking if out1 and out2 are as expected. However, if the RTL has about hundreds of inputs then exercising all possible inputs is impossible because of the exponential complexity (i.e., if there are n inputs then all possible input combinations are 2 n ). So we need to have formal verification methods which verify equivalence of RTL with input specifications. Broadly speaking, for formal verification we need to model the RTL circuit and the specifications using some formal modeling techniques and verify that both of them are equivalent. In other words, equivalence is determined without applying inputs. Figure 6 illustrates
Control and Data Flow Diagram (CDFG) [4], a formal modeling, to capture the RTL of Figure 5. Figure 7 illustrates Finite State Machine (FSM) [4] to model the control logic of the RTL of Figure 5. This example being very simple, we can see that both specifications and the model are equivalent. Formal techniques for checking equivalence can be found in [5] and will be elaborated in “VERIFICATION” section of the course. control
0 1
read a read^ b
+
write out
read c^ read^ d
+
write out
Figure 6. CDFG of the RTL circuit of Figure 5
s0 s
control=1/
control=0/ Figure 7. FSM for the control logic of RTL circuit shown in Figure 5
a
a
b
b
Out1(sum)
a b
Out1(carry)
Figure 8. Circuit after logic synthesis for the adder block (of Figure 5) Step 4: Backend Once the logic level output of the circuit is obtained we move to backend phase of the design process. Broadly speaking, in backend we start with a software version of the silicon die where the chip will be finally fabricated. In the process, we first make a broad plan regarding placement of gates, flip-flops etc. (output of logic synthesis) in appropriate places in the software representation of the chip; this process is called Floorplan. Following that, we decide on the exact locations in the die (software representation) where the circuit components are placed; this is called Placement. Once placement is done, we make the required interconnections (as given in the logic circuit) among the gates that are placed in exact positions in the die; this process is called routing. The main aim of Floorplan, Placement and Routing is to minimize silicon area, minimize signal delays, well distributed power flow etc., subject to accommodating all the components of the chip and adhere to the design check rules [7]. In this course we will not discuss the Backend phase of design flow; for details the reader is refereed to [7]. Again equivalence of output of Backend process should be established with logic design. In this process we extract the logic circuit from the placed and routed circuit in the die (software representation) and equivalence is verified against logic design (output of logic synthesis).
Step 5: Test Planning As discussed, in VLSI designs millions of transistors are packed into a single chip, thereby leading to manufacturing defects. So all chips need to be physically tested by providing input signals from a pattern generator and comparing responses using a logic analyzer. As in the case of verification, testing by applying all possible input combinations is prohibitive, due to curse of dimensionality problem. The testing problem is more time hungry than verification because all chips need to be tested while only “one” design is to be verified. Testing by applying all possible input combinations is called exhaustive functional testing, which is avoided because of prohibitive time requirements. Testing is therefore done based on “structure” of the circuit and is called structural testing. In structural testing we first decide on set of faults that can occur, called Fault Models; stuck-at, bridging etc. are some well known fault models. Then we apply only those inputs which are required to validate that faults (as per fault model) are not present. It has been shown in [9] that number of patterns required to perform structural testing is exponentially lower than that required for exhaustive functional testing. In Test Planning step, given a logic level circuit and fault model, we generate patterns, which when applied to a circuit determines that no fault from the fault model exists in the circuit. Now we will illustrate test planning for the adder module of the example (Figure
- assuming that fault model is “stuck-at”. In “stuck-at” fault model each line of the circuit is assumed to have two types of faults i.e., s-a-0 and s-a-0. So if there are n lines in a circuit then in all there can be 2n stuck-at faults in the circuit. However, in the fault model it is assumed that only one stuck-at fault can occur at a time. In test planning we need to find input patterns which can determine that none of the stuck-at faults are present. In the circuit of Figure 8 as there are 12 lines (9 lines in circuit for “sum” and 3 lines in the circuit for “carry”), there can be 24 stuck-at faults. We take one fault at a time and determine an input pattern that can verify the absence of the fault. Here we will illustrate for only one fault and the same holds for all the other 23 faults. Let there be a stuck-at-0 fault in the output of one AND gate (shown in Figure 9) of the circuit for “sum”. Now to we
layout exceeds the area limit. In such a case, in order to fit the architecture into the allowable chip area, the HLS design process must be repeated. Thus, it is very important to feed forward low-level information to higher levels (bottom up) as early as possible. Further, details and integrities of the steps are also avoided. For example, there are some faults which cannot be tested by any pattern. For such cases, we need to put additional circuitry to make it testable called Design for Testability (DFT). The respective modules in this course will elaborate on each of these aspects.
The breakup of the modules in this course is as follows:
Design Module I: Introduction Lecture I: Introduction to Digital VLSI Design Flow Lecture II: High Level Design Representation Lecture III: Transformations for High Level Synthesis
Module II: Scheduling, Allocation and Binding Lecture I: Introduction to HLS: Scheduling, Allocation and Binding Problem Lecture II and III: Scheduling Algorithms Lecture IV: Binding and Allocation Algorithms . Module III: Logic Optimization and Synthesis Lecture I,II and III: Two level Boolean Logic Synthesis Lecture IV: Heuristic Minimization of Two-Level Circuits Lecture V: Finite State Machine Synthesis Lecture VI: Multilevel Implementation
Verification Module - IV: Binary Decision Diagram Lecture-I: Binary Decision Diagram: Introduction and construction Lecture-II: Ordered Binary Decision Diagram Lecture-III: Operations on Ordered Binary Decision Diagram Lecture-IV: Ordered Binary Decision Diagram for Sequential Circuits
Module - V: Temporal Logic Lecture-I: Introduction and Basic Operations on Temporal Logic Lecture-II: Syntax and Semantics of CLT Lecture-III: Equivalence between CTL Formulas
Module-VI: Model Checking Lecture-I: Verification Techniques Lecture-II, III and IV: Model Checking Algorithm Lecture-V: Symbolic Model Checking
Test Module VII: Introduction to Digital Testing Lecture-I: Introduction to Digital VLSI Testing Lecture-II: Functional and Structural Testing Lecture-III: Fault Equivalence
Module VIII: Fault Simulation and Testability Measures Lecture-I, II and III: Fault Simulation Lecture-IV: Testability Measures (SCOAP)
References [1]. John P. Uyemura, , “CMOS Logic Circuit Design”, Kluwer Academic Publishers, 1 st^ Edition, 1999 [2]. Stephen M. Trimberger, “Introduction to CAD for VLSI”, Kluwer Academic Publishers, 1st^ Edition, 1987 [3]. , Daniel D. Gajski and Loganath Ramachandran, “Introduction to High-Level Synthesis”, IEEE Design and. Test, volume 11,No, 4,1994, pp 44—54. [4]. Daniel D. Gajski, Nikil D. Dutt, Allen C-H Wu, Steve Y-L Lin, “High-Level Synthesis: Introduction to Chip and System Design”, Kluwer Academic Publishers, 1st^ Edition, 1992 [5]. Jr., Edmund M. Clarke, Orna Grumberg and Doron A Peled, “Model checking”, MIT Press, 1 st^ Edition, 1999. [6]. Giovanni De Micheli, “Synthesis and Optimization of Digital Circuits”, McGraw- Hill Higher Education, 1st^ Edition, 1994 [7]. Naveed A. Sherwani, “Algorithms for VLSI Physical Design Automation”, Kluwer Academic Publishers, 2 nd^ Edition, 1995 [8]. M. Abramovici, M.A. Breuer, and A.D. Friedman. Digital Systems Testing and Testable Design. Wiley-IEEE Press, 1994.
Module-I
Lecture-II
High Level Design Representation
1. Introduction
As discussed in the last lecture, almost all steps of VLSI design are automated. Any automated procedure requires that input data being provided is in some predefined format. Also, the models used to represent the inputs and transformations (changes of the input) should be efficient for execution of the procedure. For example, in case of High Level Synthesis (HLS) the input specifications are generally in some Hardware Definition Language (HDSs) like Verilog [1], VHDL [2], System C [3] etc. The HDL specifications are represented using several modeling paradigms like Control and Data Flow Diagram (CDFG) [4], DeJong’s hybrid flow graph [5], SSIM flow graph [6], Finite state machine with data [7] etc., which are suitable for scheduling, allocation and binding procedures. Sometimes timing constrains (on execution of steps) are also given in the specifications, which are modeled by the above paradigms, however, with timing parameter included e.g., CDFG with timing, DF with timing and CF with timing.
In this lecture, we will discuss CDFG paradigm for modeling of high-level hardware descriptions (given in Verilog). CDFG is one of the most widely used modeling paradigm and the others mentioned above are not much different; for details of other paradigms the reader may look into the respective references.
0 1
-
read B read^ C
x
+
read D
write A
>
0
END (^1)
B
B2 (^) B
B
B B
B
B B
C
Figure 2. CDFG for the Verilog HDL in Figure 1
The CDFG for Verilog HDL (Figure 1) is shown in Figure 2. In Figure 1 it may be noted that there are three input variables (B,C and D) which must be read from input lines to registers. So corresponding to reading of each variable in registers we have a storage nodes; B1,B2 and B3 are storage nodes (Figure 2). In the Verilog code there is a one time computation “initial begin A: = B * C + D; end”. For this computation we see that there are 2 sub-computations, namely “*” and “+”. So we have two
operational nodes, B4 and B5 for “*” and “+”, respectively. The edge B 1, B 4
corresponds to transfer of value of B, which gets changed (i.e., new value read) due to
processing (reading) in B1. The edge B 4, B 5 corresponds to transfer of values (B
and C to “BC”), which get changed due to processing (“”) in B4. After the
computation “initial begin A: = B * C + D; end”, the value is stored in A; this is captured by storage node B6. B7 is the operational node that checks 0 with A; output is 0 if A 0 and 1, otherwise. The output of B7 (carried by edge B 7, C 1 ) controls
the control node C1. B 7, C 1 is the control flow edge, which corresponds to the
condition (A>0) required for execution/exit of the while loop. Node C1 is a control node responsible for deciding data flow direction after the condition “A>0” is
checked at B7. If value transferred by B 7, C 1 is 0 then the loops exits at B8, else
computation “A=A-1” is done at B9 and the loop continues. Now we discuss in brief, CDFGs for some other frequently used constructs of HDLs. Figure 3 illustrates CDFG for “case” statement in Verilog. This is similar to if-then statement; however, we have an edge for all the cases of the case statement in the control node.
1 2.............................n
B1 B2^ Bn Figure 3. CDFG for “case” statement in Verilog
F T
>
B
B
C
i (Variable) Constant
B
Figure 4. CDFG for “for loop” in Verilog
