Unit 4: ASIC Front-End Tools

Unit 4: ASIC Front-End Tools

Carlos Jesús Jiménez Fernández

Instituto de Microelectrónica de Sevilla / Universidad de Sevilla

October 2009

Outline:

• 6.1 Introduction.
• 6.2 Logic Synthesis with Design Compiler (Synopsys).
• 6.3 Static timing analysis with Primetime (Synopsys).
• 6.4 Power analysis with Design Power (Synopsys).
• 6.5 Formal verification.

1
 Unit 4: ASIC Front-End Tools

I. INTRODUCTION.

A mayor development in recent years has been the development of effective tools for
synthesis. Synthesis, a concept that has been around since the early days of digital logic design,
refers to the automatic generation of a logic circuit based on a high-level description of the
desired operation of the circuit. The output of logic synthesis is typically a netlist, which is a
description of all of the connections and components (logic gates or other devices) to be used
in a circuit. A subsequent tool can the use the netlist to fabricate (in the case of an ASIC) or
program (in the case of an FPGA) an integrated circuit chip.

II. LOGIC SYNTHESIS WITH DESIGN COMPILER (SYNOPSYS).

The Design Compiler tool is the core of the Synopsys synthesis products. Design
Compiler optimizes designs to provide the smallest and fastest logical representation of a given
function. It comprises tools that synthesize your HDL designs into optimized technology-
dependent, gate-level designs. It supports a wide range of flat and hierarchical design styles and
can optimize both combinational and sequential designs for speed, area, and power. Figure 1
shows a simplified overview of how Design Compiler fits into the design flow.

Figure 1: Design Compiler into the VLSI design flow.

You use Design Compiler for logic synthesis, which is the process of converting a design
description written in a hardware description language such as Verilog or VHDL into an
optimized gate-level netlist mapped to a specific technology library. The steps in the synthesis
process are as follows:

1) The input design files for Design Compiler are often written using a hardware
description language (HDL) such as Verilog or VHDL.

2) Design Compiler uses technology libraries, synthetic or DesignWare libraries, and

symbol libraries to implement synthesis and to display synthesis results

2
 Unit 4: ASIC Front-End Tools

graphically. During the synthesis process, Design Compiler translates the HDL
description to components extracted from the generic technology (GTECH) library
and DesignWare library. The GTECH library consists of basic logic gates and flip-
flops. The DesignWare library contains more complex cells such as adders and
comparators. Both the GTECH and DesignWare libraries are technology
independent, that is, they are not mapped to a specific technology library. Design
Compiler uses the symbol library to generate the design schematic.

3) After translating the HDL description to gates, Design Compiler optimizes and
maps the design to a specific technology library, known as the target library. The
process is constraint driven. Constraints are the designers specification of timing
and environmental restrictions under which synthesis is to be performed.

4) After the design is optimized, it is ready for test synthesis. Test synthesis is the
process by which designers can integrate test logic into a design during logic
synthesis. Test synthesis enables designers to ensure that a design is testable and
resolve any test issues early in the design cycle. The result of the logic synthesis
process is an optimized gate-level netlist, which is a list of circuit elements and their
interconnections.

5) After test synthesis, the design is ready for the place and route tools, which place
and interconnect cells in the design. Based on the physical routing, the designer can
back-annotate the design with actual interconnect delays; Design Compiler can
then resynthesize the design for more accurate timing analysis.

A. High-Level Design Flow

In a basic high-level design flow, Design Compiler is used in both the design exploration
stage and the final design implementation stage. In the exploratory stage, you use Design
Compiler to carry out a preliminary, or default, synthesis. In the design implementation stage,
you use the full power of Design Compiler to synthesize the design.

Using the design flow, you perform the following steps:

1) Start by writing an HDL description (Verilog or VHDL) of your design. Use good
coding practices to facilitate successful Design Compiler synthesis of the design.

2) Perform design exploration and functional simulation in parallel.

• In design exploration, use Design Compiler to (a) implement specific design
goals (design rules and optimization constraints) and (b) carry out a preliminary,
default synthesis (using only the Design Compiler default options).
• If design exploration fails to meet timing goals by more than 15 percent, modify
your design goals and constraints, or improve the HDL code. Then repeat both
design exploration and functional simulation.

3
 Unit 4: ASIC Front-End Tools

• In functional simulation, determine whether the design performs the desired

functions by using an appropriate simulation tool.
• If the design does not function as required, you must modify the HDL code and
repeat both design exploration and functional simulation.
• Continue performing design exploration and functional simulation until the
design is functioning correctly and is within 15 percent of the timing goals.

3) Perform design implementation synthesis by using Design Compiler to meet design

goals. After synthesizing the design into a gate-level netlist, verify that the design
meets your goals. If the design does not meet your goals, generate and analyze
various reports to determine the techniques you might use to correct the problems.

4) After the design meets functionality, timing, and other design goals, complete the
physical design (either in-house or by sending it to your semiconductor vendor).
Analyze the physical designs performance by using back-annotated data. If the
results do not meet design goals, return to step 3. If the results meet your design
goals, you are finished with the design cycle.

III. STATIC TIMING ANALYSIS WITH PRIMETIME (SYNOPSYS)

PrimeTime (PT) is a sign-off quality static timing analysis tool from Synopsys. Static
timing analysis or STA is without a doubt the most important step in the design flow. It
determines whether the design works at the required speed. PT analyses the timing delays in
the design and flags violation that must be corrected.

PT, similar to Design Compiler, provides a GUI interface along with the command-line
interface. The GUI interface contains various windows that help analyse the design graphically.
Although the GUI interface is a good starting point, most users quickly migrate to using the
command-line interface.

PrimeTime is a full-chip, gate-level static timing analysis tool that is an essential part of
the design and analysis flow for today large chip designs. PrimeTime exhaustively validates the
timing performance of a design by checking all possible paths for timing violations, without
using logic simulation or test vectors.

PT is a stand-alone tool that is not integrated under the Design Compiler suite of tools. It
is a separate tool, which works alongside Design Compiler. Both PT and Design Compiler have
consistent commands, generate similar reports, and support common file formats. In addition
PT can also generate timing assertions that Design Compiler can use for synthesis and
optimization. PT’s command-line interface is based on the industry standard language called
TCL. In contrast to Design Compiler’s internal STA engine, PT is faster, takes up less memory,
and has additional features.

4
 Unit 4: ASIC Front-End Tools

A. PrimeTime Features

PrimeTime is a full-chip, gate-level static timing analysis tool targeted for complex,
multimillion-gate designs. It offers a combination of speed, capacity, ease of use, and
compatibility with industry-standard data formats and workflows.

PrimeTime fits ideally into the Synopsys physical synthesis flow because it uses many of
the same libraries, databases, and commands as other Synopsys tools such as Design Compiler.
It can also operate as a stand-alone static timing analyser in other design flows. It accepts
design information in a wide range of industry standard formats, including gate-level netlists
in db, Verilog, VHDL, and EDIF formats; delay information in SDF format; parasitic data in
RSPF, DSPF, SPEF, and SBPF formats; and timing constraints in Synopsys Design Constraints
(SDC) format.

Figure 2 shows how PrimeTime is used in a typical synthesis flow. Starting from an RTL
(register transfer level) design description, a synthesis tool such as Design Compiler generates
a gate-level design description. PrimeTime reads this description and verifies the design timing
using information provided in the technology library.

If PrimeTime finds any timing violations, the design needs to be resynthesized using new
timing constraints (generated by PrimeTime) to fix the conditions that are causing the timing
errors. When the gate-level design is free of timing violations, the designer can proceed to
placement and routing. This produces a chip layout database from which accurate delay
information or detailed parasitic information can be extracted. This data, when back-annotated
on the design in PrimeTime, results in a layout-accurate timing analysis. A successful
validation of the circuit timing at this point leads to sign-off of the completed design.

Figure 2: PrimeTime into a typical synthesis flow.

5
 Unit 4: ASIC Front-End Tools

PrimeTime performs the following types of design checking:

• Setup, hold, recovery, and removal constraints.

• User-specified data-to-data timing constraints.
• Clock-gating setup and hold constraints.
• Minimum period and minimum pulse width for clocks.
• Design rules (minimum/maximum transition time, capacitance, and fanout).
PrimeTime supports a wide range of advanced timing analysis features, including the
following:

• Multiple clocks and clock frequencies.

• Multicycle path timing exceptions.
• False path timing exceptions and automatic false path detection.
• Transparent latch analysis and time borrowing.
• Simultaneous minimum/maximum delay analysis for setup and hold constraints.
• Analysis with on-chip variation of process, voltage, and temperature (PVT)
conditions.
• Case analysis (analysis with constants or specific transitions applied to specified
inputs).
• Mode analysis (analysis with module-specific operating modes, such as read mode or
write mode for a RAM module).
• Bottleneck analysis (reporting of cells that cause the most timing violations).
• ECO analysis without modifying the original netlist, using inserted buffers, resized
cells, and modified nets.
• Analysis of crosstalk effects between physically adjacent nets using the PrimeTime SI
(signal integrity) option.
PrimeTime offers two command environments for timing analysis: pt_shell and the
graphical user interface (GUI). The pt_shell interface is a command-line and script-execution
environment based on the TCL programming language, suitable for programmed,
computation-intensive tasks. The GUI is a window-based, graphical environment suitable for
interactive analysis and for graphically visualizing design data and analysis results.

The GUI offers some visual analysis capabilities that are not available in pt_shell. For
example, you can view schematics of the design, display clock waveforms, and generate
histograms of analysis results such as path slack, net capacitance, and bottleneck cost. The
console window within the top-level window lets you enter commands and view the text
response, just like pt_shell.

6
 Unit 4: ASIC Front-End Tools

The PrimeTime static timing analysis tool is designed to work well with Design
Compiler. PrimeTime and Design Compiler are compatible in the following ways:

• They use the same technology libraries and read the same design data files in db and
ddc formats.
• They share many of the same commands, such as create_clock, set_input_delay, and
report_timing. Shared commands are identical or very similar in operation.
• They share the same delay calculation algorithms and generally produce identical
delay results.
• Timing reports generated by the two tools are very similar.
• PrimeTime can capture the timing environment of a synthesizable subcircuit and write
this timing environment as a series of Design Compiler commands. You can use the
resulting script in Design Compiler to define the timing constraints for synthesis or
logic optimization of the subcircuit.
• Existing timing analysis scripts written for Design Compiler in dcsh mode can be
translated into a form that can be run in PrimeTime. A script translation program called
transcript is provided with PrimeTime for this purpose.
• Both tools support the Synopsys Design Constraints (SDC) format for specifying
design intent, including the timing and area constraints for a design.
Although Design Compiler has its own built-in static timing analysis capability,
PrimeTime has better speed, capacity, and flexibility for static timing analysis, and offers many
features not supported by Design Compiler such as timing models, mode analysis, and internal
clocks.

B. Analysis Flow in PrimeTime.

To successfully perform timing analysis for a design, you need to do certain steps in the
proper order. A typical analysis session consists of the following steps:

1) Read in the design data (a gate-level netlist and associated technology libraries).

2) Constrain the design by specifying the clock characteristics, input timing

conditions, and output timing requirements.

3) Specify the environment and analysis conditions such as operating conditions, case
analysis settings, net delay models, and timing exceptions.

4) Check the design data and analysis setup parameters in preparation for a full timing
analysis.

5) Perform a full timing analysis and examine the results.

7
 Unit 4: ASIC Front-End Tools

C. Static Timing Analysis Overview.

Static timing analysis is a method of validating the timing performance of a design by

checking all possible paths for timing violations. PrimeTime checks for violations in the same
way that you would do it manually, but with much greater speed and accuracy.

To check a design for violations, PrimeTime breaks the design down into a set of timing
paths, calculates the signal propagation delay along each path, and checks for violations of
timing constraints inside the design and at the input/output interface.

Another way to perform timing analysis is to use dynamic simulation, which determines
the full behaviour of the circuit for a given set of input stimulus vectors. Compared with
dynamic simulation, static timing analysis is much faster because it is not necessary to simulate
the logical operation of the circuit. It is also more thorough because it checks all timing paths,
not just the logical conditions that are sensitized by a particular set of test vectors. However,
static timing analysis can only check the timing, not the functionality, of a circuit design.

IV. POWER ANALYSIS WITH DESIGN POWER (SYNOPSYS).

Power Compiler is part of Synopsys’s Design Compiler synthesis family. It performs both
RTL and gate-level power optimization and gate-level power analysis. By applying Power
Compiler’s various power reduction techniques, including clock-gating, operand isolation,
multivoltage leakage power optimization, and gate-level power optimization (GLPO), you can
achieve power savings, and area and timing optimization in the front-end synthesis domain.

A. Power Compiler Methodology.

With the increasing popularity of portable-oriented applications, low-power designs have

become crucial elements for product success. Most especially, the static power (leakage power)
consumption concern is more pronounced when the technology is smaller than 90nm in the
ultra-deep sub-micron domain.

Power Compiler provides the following optimization features to address the issues the IC
designers are facing:

• Leakage power/static power optimization:

- Multi-Vth power optimization.
- Power gating.
• Dynamic power:
- Clock-gating insertion techniques: discrete components, integrated clock-gating
cells, generic integrated clock-gating cells.
- Operand isolation.
- Gate-level power optimization.

8
 Unit 4: ASIC Front-End Tools

• Multi-voltage support.
Power Compiler provides a complete methodology for low-power designs.

The power optimization technology optimizes your design for power consumption. It
computes average power consumption based on the activity of the nets in your design. You can
perform power optimization of your design at the:

• Register transfer level using clock gating and operand isolation techniques.
• Gate level power optimization including leakage optimization using cell libraries with
multi-voltage threshold voltages.
• Gate level dynamic power optimization, through simulation and back annotation of
switching activity.
The power analysis technology analyzes your design for power consumption. Working in
conjunction with Design Compiler or Physical Compiler, Power Compiler provides
simultaneous optimization for timing, power, and area. You can perform power analysis of your
design at the:

• Register transfer level using RTL simulation.

• Gate level using RTL or gate-level simulation.

B. Power Optimization Technology.

You can optimize your design for power using the following capabilities:

• RTL clock gating.

• Operand isolation.
• Gate-level multi-Vth and dynamic power optimization.
RTL clock gating is the most effective power optimization feature provided by Power
Compiler. This is a high-level optimization technique that can save a significant amount of
power by adding clock gates to registers that are not always enabled and with synchronous
load-enable or explicit feedback loops. This greatly reduces the power consumption of the
design by reducing switching activity on the clock inputs to registers and eliminating the
multiplexers. It also results in a lower area consumption for your design.

The operand isolation feature could significantly reduce the power dissipation of a data-
path intensive design at the cost of a slight increase in area and delay. With operand isolation,
the inputs of the data-path operators are held stable whenever the output is not used.

RTL clock gating and operand isolation optimize for dynamic power and can be applied
simultaneously on a design.

9
 Unit 4: ASIC Front-End Tools

When a gate-level power optimization constraint is set in the design, by default, Power
Compiler performs optimization to meet the constraints for design rule checking, timing,
power and area in that order of priority.

C. Power Analysis Technology.

Power Compiler analyzes your design for net switching power, cell internal power, and
leakage power and enables you to perform power analysis of your design at two different levels
of abstraction: register transfer level and Gate-level.

Gate-level power analysis uses switching activity (SAIF) from RTL or gate-level
simulation or user-annotation. When analyzing a gate-level design, Power Compiler requires a
gate-level netlist and some form of switching activity for the netlist. Power Compiler enables
you to capture the switching activity of primary inputs, primary outputs, and outputs of
sequential elements during RTL simulation. After you annotate the captured activity on design
elements, Power Compiler propagates switching activity through the unannotated portions of
your design.

Using power analysis by way of switching activity from RTL simulation provides a much
faster turnaround than analysis using switching activity by way of gate-level simulation. If you
require more accuracy during the later stages of design development, you can annotate some
or all of the nets of your design with switching activity from full-timing gate-level simulation.

D. Switching Activity.

Cell internal power and net toggling clearly have a direct effect on the dynamic power of
a design. To report or optimize dynamic power, Power Compiler needs toggle information for
the design. This information is called switching activity.

Power Compiler models switching activity in terms of static probability and toggle rate.

• Static probability (SP0 or SP1) is the probability that a signal is at a certain logic state
and is expressed as a number between 0 and 1. You can calculate the static probability
during simulation by comparing the time a signal is at a certain logic state to the total
time of simulation. For example, if SP1 = 0.70, the signal is at logic 1 state 70 percent
of the time. Synopsys power tools use SP1 when modeling switching activity.
• Toggle rate is the number of logic-0-to-logic-1 and logic-1-to-logic-0 transitions of a
design object (for example, net, pin, or port) per unit of time. The toggle rate is denoted
by TR.
Before power analysis, annotate the switching activity on some or all design objects by
using the read_saif, annotate_activity or set_switching_activity commands. If you annotate
some design objects, Power Compiler analysis runs zero-delay simulation to propagate
computed switching activity through the rest of the design before completing power analysis.

10
 Unit 4: ASIC Front-End Tools

To increase the accuracy of power analysis, complete the following steps:

• Annotate state- and path-dependent switching activity on pins.

• Annotate state-dependent static probability on cells that have a state-dependent
leakage power model.

E. Methodology and Data Flow.

Figure 3 presents a methodology for power and the flow of data between process steps or
tools. The gray shaded box indicates the process steps that occur within the Design Compiler
dc_shell. Arrows indicate the movement of data between process steps, tools, and files. In most
cases, the data movement is controlled by one or more smaller steps involving user commands.
Dotted arrows indicate optional steps in this power methodology.

Figure 3: Power optimized design flow.

The power methodology starts with your RTL design and finishes with a power-
optimized gate-level netlist including any iterations you find necessary.

You can use Power Compiler to analyze the gate-level netlist produced by Design
Compiler or the power-optimized netlist produced by Power Compiler.

F. Simulation.

Most of the steps in the flow occur within the Design Compiler dc_shell. However, Figure
3 shows that simulation, which takes place outside the dc_shell environment, is part of the
power methodology.

Simulation generates information about the switching activity of the design and creates a
file containing the information. This file is called a back-annotation file. The back-annotation
file can contain switching activity from RTL simulation or from gate-level simulation.

11
 Unit 4: ASIC Front-End Tools

Using the read_saif command, you instruct Synopsys power tools to read the back-
annotation file and annotate the information onto your gate-level design.

During power analysis, Power Compiler uses the annotated switching activity to evaluate
the power consumption of your design. During power optimization, Power Compiler uses the
annotated switching activity to make optimization decisions about your design.

During RTL simulation, your back-annotation file is created by use of a file containing
directives that determine which design elements to trace during simulation. The trace file of
directives is called a forward-annotation file.

Gate-level simulation can also use a library forward-annotation file (not shown in Figure
3). The forward-annotation file for gate-level simulation contains different information than the
RTL forward-annotation file. The gate-level forward-annotation file contains information from
the technology library about cells with state- and path-dependent power models. The gate-level
forward-annotation file is created by using the lib2saif command.

During analysis and optimization, Synopsys power tools use information in your
technology library. To optimize or analyze dynamic power and leakage power, your technology
library must be characterized for internal power. To optimize or analyze static power, your
technology library must be characterized for leakage power.

V. FORMAL VERIFICATION.

Formal verification techniques perform validation of a design using mathematical

methods without the need for technological considerations, such as timing and physical effects.
They check for logical functions of a design by comparing it against the reference design.

A number of EDA tool vendors have developed the formal verification tools. Synopsys
also introduced to the market its own formal verification tool called Formality.

A. Introduction to Formality.

Formality is an application that uses formal techniques to prove or disprove the functional
equivalence of two designs or two cell libraries. For example, you can use Formality to
compare a gate-level netlist to its register transfer level (RTL) source or to a modified version
of that gate-level netlist. After the comparison, Formality reports whether the two designs or
cell libraries are functionally equivalent. The Formality tool can significantly reduce your
design cycle by providing an alternative to simulation for regression testing.

The techniques Formality uses are static and do not require simulation vectors.
Consequently, for design verification you only need to provide a functionally correct, or golden
design (called the reference design), and a modified version of the design (called the

12
 Unit 4: ASIC Front-End Tools

implementation). By comparing the implementation against the reference design, you can
determine whether the implementation is functionally equivalent to the reference design. Cell
library verification is similar except that each cell in the implementation library is compared
against each cell in the reference library one cell at a time.

Today design methodology requires regression testing at several points in the design
process. Currently, traditional simulation tools, such as event-driven and cycle-based
simulators, handle this regression testing. However, as designs become larger and more
complex and require more simulation vectors, regression testing with traditional simulation
tools becomes a bottleneck in the design flow. The bottleneck is caused by these factors:

• Large numbers of simulation vectors are needed to provide confidence that the design
meets the required specifications.
• Logic simulators must process more events for each stimulus vector because of
increased design size and complexity.
• More vectors and larger design sizes cause increased memory swapping, slowing
down performance.
Formality fits well within established electronic design automation (EDA)
methodologies used to create large-scale designs, because it can replace the traditional
simulation tools used for regression testing. This replacement, combined with the continued
use of static timing analysis tools, gives you two distinct advantages: significantly reduced
verification times and complete verification.

Reduced verification times occur because Formality requires no input vectors. Reducing
gate-level simulation time means you can spend more time verifying the initial golden RTL
design to get better functional coverage. Formality maintains that coverage through all
subsequent regressions.

Complete verification, the second advantage, means 100 percent equivalence over the
entire vector space. Complete verification is significant because you no longer have to
compromise the subset of vectors for gate-level simulation.

The following list summarizes the Formality features:

• Proves two designs or cell libraries are functionally equivalent, faster than verification
using event-driven simulators.
• Provides complete verification (not vector-dependent).
• Performs RTL-to-RTL, RTL-to-gate, and gate-to-gate design verifications.
• Performs Verilog-to-DB, Verilog-to-Verilog, DB-to-DB, Verilog-to-SPICE, and DB-
to-SPICE cell library verifications.
• Offers diagnostic capabilities to help you locate and correct functional discrepancies
between designs.

13
 Unit 4: ASIC Front-End Tools

• Reads EDIF netlists and Synopsys internal (.db or .ddc) formats.

• Reads synthesizable SystemVerilog, Verilog, and VHDL.
• Performs automatic hierarchical verification.
• Uses existing Synopsys Design Compiler technology libraries.
• Saves and restores designs and verification sessions.
• Offers a graphical user interface (GUI) and a shell command-line interface (fm_shell).
• Verifies a wide range of design transforms or modifications, including pipeline
retiming and reencoded finite state machines.
• Offers schematic views and isolated cone of logic views that support location of
design discrepancies.

B. Formality in the design flow.

For design verification, Formality fits into a design process exactly the same way a logic
simulator fits when it is used for regression testing. Specifically, any time you make a
nonfunctional change to a design, you can use Formality to prove that the implementation is
still functionally equivalent to the reference.

After proving the implementation is equivalent to the reference design, you can use the
implementation as the reference design for the next regression test. By establishing the most
recent design as the reference design throughout your design process, you minimize the overall
verification time. A reduction in time occurs because structurally similar designs can be
compared faster than structurally dissimilar designs.

Figure 4 shows the incremental usage model that best suits the design flow using
Formality. The box with the bold border represents Formality.

Figure 4: Incremental usage of Formality.

14
 Unit 4: ASIC Front-End Tools

Figure 5 shows how Formality fits into a typical ASIC verification methodology. In
Figure 5, ovals represent data and boxes represent processes. Boxes with bold borders represent
verification using Formality.

Figure 5: Formality into the ASIC verification methodology.

15