Chapter 7

ASIC Implementation and Verification Flow

A design flow encompassing industry standard layout tools and verification
practices was used to develop all the proposed designs and all the conventional
designs used for comparison in this research.

The designs started with writing Verilog

HDL code. The code is then verified for the functionality before converting into gate
level netlist. The netlists were verified using formal verification techniques and then
imported to the place and route tool. The parasitic resistances and capacitances were
then extracted from the layouts and used to back-annotate the netlist for delay analysis
and power simulations.

Scripting language tcl were used to automate often repeated

tasks and streamline information extraction. A detailed overview of the tools and the
process

used for layout,

parasitic

extraction, delay simulation,

and power

simulation is given the following sections.

7.1 DESIGN FLOW

Primary tools from Cadence Design Systems, Inc., form the mainstay of
the design environment.

Figure 7.1 illustrates the design and tool flow for the

development and verification of the designs used in this research. The first important
step is design specification. Based on the specification, the design is developed using
Verilog HDL code and the verified behavior of the design is then converted into gate
level netlist using RTL Compiler. All the normal flops in the design are replaced with
scan flops for DFT purpose in scan insertion. The functional equivalence of the scan
inserted gate-level Verilog netlist is verified using Encounter Conformal Equivalency
Checking.

The verified designs are then placed and routed using NanoPlace and

NanoRoute of the Encounter platform.

Parasitic extraction is performed using

Encounters native RC extraction program.

The static timing analysis (STA) tool,

Encounters Common Timing Engine, uses this parasitic information to determine path
delays. The parasitic data is also used for the power simulations by Cadences
Virtuoso UltraSim.
94

Design Specification

HDL Coding

Netlist Generation

Scan Insertion

Functional Verification

Timing Driven Placement

Timing Driven Route

RC Extraction

STA

Power Analysis

Functional Verification

Figure 7.1: Design and Tool Flow

95

7.1.1 SCAN INSERTION

Replaced all the flops with scan flops in the design and connected them to form a
chain to improve the testability. An example of scan inserted design structure is shown in
Figure 6.5. The practice of inserting scan cells into a design requires careful planning due
to the many circuit modifications. So care must be taken in order not to disrupt the
normal functionality of the circuit.
During the scan chain implementation, we have ensured that the below mentioned
set of scan design rules (Cheung (1996)) were achieved to:

1) All the flops must be controllable and observable,

2) All the reset must be controllable,
3) All the clock must be controllable,
4) During shift operation, the set/reset must be inactive.

After implementing the scan chain in a design, the DFT Rule Check (DRC) is run
to check whether design rules are violated.

7.1.2 FORMAL EQUIVALENCE VERIFICATION

Formal equivalence verification is proving the correctness of intended design
functions using formal methods of mathematics. Equivalence checking uses formal
techniques to determine whether two forms of a design i.e. before synthesis and
after synthesis are functionally equivalent. This verification method does not require test
vectors.
In this research the formal verification was performed using Cadences Encounter
Conformal Equivalence.

The verification flow is illustrated in Figure 7.2. The

Conformal Ultra tool has capability for verifying complex datapath logic. So it was added
to extend the logic equivalence checking capability for complex datapaths.

96

Verilog RTL

Gate Level Netlist

Standard Cell Lib

Constraints & Parameters

Mapping

Analyze Design

Modify The Design

Compare

Diagnose

Mis-Compare?

Done

Figure 7.2: Formal Verification Flow

97

7.1.3 FLOORPLANNING
Cadences Encounter platform was used for floor-planning the designs in this
research. It provides initial feedback that evaluates architectural decisions, estimates chip
areas, and estimates delay and congestion caused by wiring. To build a floorplan, a
minimal set of constraints and parameters should be specified in a configuration file as
follows,

1. Filename and path of design netlist

2. Filename and path of standard cell library
3. Filename and path of the LEF
4. Filename and path of the timing constraints file
5. Target aspect ratio for layout height and width
6. Footprints for buffers and inverters
7. Filename for the pin I/O assignments
8. Target row utilization
9. The names of VDD and VSS pins

In this research, Verilog gate-level netlist was used for placement and route.
The timing file used for each standard cell library which represents the typical
performance at nominal voltage, temperature, and process corner. The LEF file is in
ASCII data format, used to describe the physical geometries of the process technology
and the standard cells.

The aspect ratio is specified using ratio of Height/Width. This

default value is 1.0. There is 0.95 aspect ratio used for the layouts height versus
width was given for each design. This means that each layout would take on an
almost square appearance. The Power and ground strips were configured to abut ground
with ground and power with power.

98

7.1.4 PLACEMENT AND ROUTING

The placement and routing process used in this research is based on the Timing
driven placement and route which provides the opportunity to realize optimized
layout of the cells in the designs critical path. Several iterations were performed by the
NanoPlace tool to determine an optimal placement based on,

1) The configuration of floorplan

2) Cell delays defined in timing libraries
3) The input clock period (timing delay) defined in the timing constraints file
4) Net delays extracted using RC extracted from trial routes.

Following cell placement, the filler cells are added as needed to extend power and ground
lines.
NanoRoute is an advanced digital routing tool which helps designers quickly
achieve concurrent timing, area, signal integrity, and manufacturability convergence
during digital implementation. It takes the same input information used by NanoPlace to
produce an optimized routed design.
in

designs

implementation,

In order to maintain control over the cells used

additional

buffering,

gate resizing, and logic

optimization were disabled during routing. The layout of the placed and routed design
for the 32-bit ECU is shown in Figure 7.3.

99

Figure 7.3: Layout of 32-bit ECU

7.1.5 PARASITIC RC EXTRACTION

It is a method of evaluating the parasitic effects in both the design and the wiring
interconnects. There are two modes of operation offered by the native RC extraction
tool within Encounter,

1) Default, and
2) Detailed
As per the Encounter User Guide (EncounterUser Guide (2008)), in default mode, the
nets geometry and the local wire density were considered for the calculated total
capacitance of each net. Here the coupling capacitance is not evaluated in the default
mode. In the detailed mode, the coupling capacitance is also calculated by considering
the actual geometries of adjacent nets on the adjacent metal layer and the same metal
layer when a complete capacitance table is provided. For this research, only the default
RC extraction is conducted.

100

7.1.6 STATIC TIMING ANALYSIS

It is a method of verifying the design in terms of timing. It does not require any
vectors applied at the input pins. This timing analysis starts with set of timing constraints,
timing libraries and extracted RC data to fine tune and debugs speed-limiting critical
paths. All timing analysis in this research were performed using Encounters Common
Timing Engine (CTE).

Figure 7.3 shows the basic configuration of CTE used for this

research. For each design, the 50 slowest path of timing data were reported.

RC Extraced
Data

Timing
Constraints

CTE

Worst Case
Paths (Top 50)

Figure 7.4: CTE Configuration

101

Timing library
(typical.lib)

7.1.7 POWER SIMULATION

In this research, the dynamic power analysis was done using Virtuoso UltraSim
with observing of the maximum, average and RMS currents and power consumed
by each design. Evaluating the leakage current is not possible using UltraSim and
the given standard cell libraries.

The Ultrasim configuration method is shown in

Figure 7.5.
The primary input file contains the required files path, such as the netlist, RC
parasitics for back-annotation (SPEF), and parameters of the process technology. The
test vector file includes stimulus values for the design as well as expected output values.

Test Vector
File

RC Parasitics
File (SPEF)

Process Tech
File

Netlist

Standard Cell
Libs

Ultrasim

Waveform file
(*.trn)

Measurement
Data (*.mto)

Figure 7.5: Ultrasim Configuration

102

Status Report
(*.log)

7.2 TEST GENERATION

The test generation task produced a set of test patterns to target stuck-at defects in
the proposed ECU. Generating effective test patterns efficiently for a digital circuit is
thus the goal of any Automatic Test Pattern Generation (ATPG) system. Encounter Test
tool from Cadence Design Systems, Inc., is one of the ATPG tools widely used in
industries for test generation (Encounter Test Modeling User Guide (2011)) . Figure 7.6
illustrates the test generation flow of the Encounter Test used in this research. Each of
these modules are elaborated below,

Build Model

Build Test Mode

Verify Test Structures

Build Fault Model

Create Tests

Write Vectors

Verify Test Vectors

Figure 7.6: Test Vector Generation Flow

103

7.2.1 BUILD MODEL

This step read the scan inserted ECU netlist & libraries and created an optimized
test model for ECU as shown in Figure 7.7. The test model contains the logical hierarchy
to facilitate design analysis. During the test synthesis flow, the scan chain is inserted into
the design. The ATPG tool builds the model using this scan inserted ECU netlist.

Technology Libs (*.v)

Verilog Netlist

Build Model

Optimized Test Model

Figure 7.7: Build Model Configuration

7.2.2 BUILD TEST MODE

A test mode is a specific test configuration of the design. The configuration
defines how the test structures are accessed and how clocking is controlled. Each
configuration is defined by the test function pins, clocking, and the current test
methodology. The build test mode configuration is shown in Figure 7.8. Based on the
configuration inputs, it builds the Full scan test modes for the proposed ECU.
The mode definition file (modedef) contains statements that characterize the test
mode, including:

1)

the type of tests expected to be generated (such as static, dynamic, or

signature based): Static was used in this work.

104

2)

the type of scan implemented in the test mode (such as General Scan
Design (GSD), LSSD (Level Sensitive Scan Design), or boundary
scan): GSD was used in this research.

3)

tester Description Rule (TDR) for the test mode (describes tester
capabilities and limitations)

4)

test functions pin assignments for the Primary Inputs and Primary
Outputs

The TDR file defines the capabilities of the manufacturing tester. The TDR can also
identify the tester features such as number of pins, size of scan buffer, tester termination
of outputs, and bidirectional pins. The assign file specifies test function pin assignments
for the build test mode. It identifies scan chains and compression structures. Other DFTrelated logic from the input files generates the required files for ATPG simulation.

TDR File

Modedef File

Assign File

Build Test Mode

Input files for ATPG

Simulation
Figure 7.8: Build Test Mode Configuration

105

7.2.3 VERIFY TEST STRUCTURES

Analyzes the design database report violations like,
1) Scan chain broken,
2) X-propagation,
3) Tri-State Contention, etc.

7.2.4 BUILD FAULT MODEL

A fault is the logical model equivalent of a physical defect, and a fault model is a
list of the faults to be considered in generating tests for the design. Encounter Test
supports Static, Dynamic faults, etc. The static faults are those that affect the timeindependent behavior of the design. Stuck-at fault is an example of a static fault.
Dynamic faults affect the time-dependent behavior of the design. Transition or delay fault
is an example of a dynamic fault. This research targeted only stuck-at fault in the
proposed ECU.

7.2.5 CREATE TESTS

Simulated the faults generated from build fault model for ECU and created the
test patterns with expected outputs. The create test flow for the proposed 64-bit Wallace,
Dadda and HPM based ECU are illustrated in Table 6.12, Table 6.13 and Table 6.14
respectively.
Basically the maximum test coverage that is expected for all digital logic is 100%
and minimum is 99.9%. But due to the design complexity, the tool may not be effective
in reaching the minimum expected coverage. This is clearly proved in case of the HPM
based ECU. The HPM multiplier has more regular structure than the Wallace multiplier
and Dadda multiplier and therefore, the HPM based ECU achieved a maximum test
coverage about 99.8%.

106