Synthesis Flow

Synthesis is a complex task consisting of many phases and requires various inputs in order to produce a functionally correct netlist. The following chapter presents the basic synthesis flow with Synopsys Design Compiler. It assumes that you have a synthesizable and functionally correct HDL description available.



Synthesis Overview

Synthesis with Design Compiler include the following main tasks: reading in the design, setting constraints, optimizing the design, analyzing the results and saving the design database. These tasks are described below:



Reading in the design

The first task in synthesis is to read the design into Design Compiler memory. Reading in an HDL design description consist of two tasks: analyzing and elaborating the description. The analysis command (analyze) performs the following tasks:


Reads the HDL source and checks it for syntactical errors

Creates HDL library objects in an HDL-independent intermediate format and saves these intermediate files in a specified location (./SYN/WORK/ in this tutorial).

If the analysis reports errors, they must be fixed, and the design reanalyzed before continuing.
The elaboration command (elaborate) does e.g. the following:
Translates the design into a technology-independent design (GTECH) from the intermediate files produced during analysis

Allows changing of parameter values (generics) defined in the source code

Replaces the HDL arithmetic operators in the code with DesignWare components

Automatically executes the link command, which resolves design references

Note: check the elaboration reports carefully to see the number and the type of memory elements Design Compiler thinks it should infer and whether you agree with it or not. Badly modeled hardware description may result as excessive or wrong type of memory elements inferred.

At this point, if the elaboration completed successfully, the design is represented in GTECH format, which is an internal, equation-based, technology-independent design format.

Constraining the design

The next task is to set the design constraints. Constraints are the instructions that the designer gives to Design Compiler. They define what the synthesis tool can or cannot do with the design or how the tool behaves. Usually this information can be derived from the various design specifications (e.g. from timing specification).

There are basically two types of design constraints
Design Rule Constraints

Design rules constraints are implicit constraints which means that they are defined by the ASIC vendor in technology library. By specifying the technology library that Design Compiler should use, you also specify all design rules in that library. You cannot discard or override these rules.

Optimization Constraints

Optimization constraints are explicit constraints (set by the designer). They describe the design goals (area, timing, and so on) the designer has set for the design and work as instructions for the Design Compiler how to perform synthesis.

Design rule constraints comprise:


Maximum transition time
Longest time allowed for a driving pin of a net to change its logic value
Maximum fanout
Maximum fanout for a driving pin
Maximum (and minimum) capacitance
The maximum (and minimum) total capacitive load that an output pin can drive. The total capacitance comprises of load pin capacitance and interconnect capacitances.

Cell degradation

Some technology libraries contain cell degradation tables. The cell degradation tables list the maximum capacitance that can be driven by a cell as a function of the transition times at the inputs of the cell.

The optimization constraints comprise timing and maximum area constraints. The most common timing constraints include:

System clock definition and clock delays

Clock constraints are the most important constraints in your ASIC design. The clock signal is the synchronization signal that controls the operation of the system. The clock signal also defines the timing requirements for all paths in the design. Most of the other timing constraints are related to the clock signal.

Multicycle paths

A multicycle path is an exception to the default single cycle timing requirement of paths. That is, on a multicycle path the signal requires more than a single clock cycle to propagate from the path startpoint to the path endpoint.

Input and output delays

Input and output delays constrain external path delays at the boundaries of a design. Input delay is used to model the path delay from external inputs to the first registers in the design. Output delay constrain the path from the last register to the outputs of the design.

Minimum and maximum path delays

Minimum and maximum path delays allow constraining paths individually and setting specific timing constraints on those paths.

Input transition and output load capacitance

These constraints can be used to constrain the input slew rate and output capacitance on input and output pins.

False paths

A false path is a path that cannot propagate a signal. For example, a path that is not activated by any combination of inputs is a false path.

Note that Design Compiler tries to meet both design rule and optimization constraints but design rule constraints always have precedence over the optimization constraints. This means that Design Compiler can violate optimization constraints if necessary to avoid violating design rule constraints.

Examples that follow show how to set these constraints.
Defining Design Environment

You also need to describe the environment in which the design is supposed to operate. The design environment description includes:
Defining Operating Conditions

The operating conditions considers the variations in process, voltage, and temperature (PVT) ranges a design is expected to encounter. These variations are taken into consideration with operating condition specifications in the technology library. The cell and wire delays are scaled according to these conditions.

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.

Optimizing the Design

The following section presents the behavior of Design Compiler optimization step. The optimization step translates the HDL description into gate-level netlist using the cells available in the technology library. The optimization is done in several phases. In each optimization phase different optimization techniques are applied according to the design constraints. The following is somewhat simplified description of optimizations performed during synthesis.
DCUG; p. 266-->

Design Compiler performs optimizations on three levels: architectural, logic-level, and gate-level.


Architectural Optimizations

Architectural optimizations are high-level optimizations which are performed on the HDL description level. These optimizations include tasks such as:
Arithmetic Optimizations

Arithmetic optimization uses the rules of algebra to improve the implementation of the design. That is, Design Compiler may rearrange the operations in arithmetic expressions according to the constraints to minimize the area or timing.

Resource Sharing

Resource sharing tries to reduce the amount of hardware by sharing hardware resources with multiple operators in your HDL description. For example, single adder component may be shared with multiple addition operators in the HDL code. Without resource sharing each operator in your code will result as a separate HW component in the final circuitry.

Selecting DesignWare Implementations

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.

At this point, the design is represented by GTECH library parts (i.e. generic, technology-independent netlist).


Logic-level Optimizations

Logic-level optimizations are performed on GTECH netlist and consists of two processes: structuring and flattening.
Structuring

Structuring evaluates the design equations represented by the GTECH netlist and tries by using Boolean algebra to factor out common subexpressions in these equations. The subexpressions that have been identified and factored out can then be shared between the equations. For example, Before Structuring After Structuring

P = ax + ay + c P = aI + c

Q = x + y + z Q = I + z

I = x + y

Structuring is usually recommended for designs with regular structured logic.


Flattening

Flattening tries to convert logic into two-level, Sum-of-Products representation. Flattening produces fast logic (by minimizing the levels of logic between the inputs and outputs) at the expense of the area increase. Flattening is recommended for designs containing unstructured or random logic.

Gate-level Optimizations

Gate-level optimizations work on the technology-independent netlist and maps it to the library cells to produce a technology-specific gate-level netlist. Gate-level optimizations include the following processes:
Mapping

This process maps the cells from technology-independent netlist (GTECH) to the cells in library specified by the target_library variable.

Delay Optimization

Delay optimization fixes the timing violations introduced by mapping phase.

Design Rule Fixing

Design rule fixing fixes the design rule violations in the design. Basically this means that Design Compiler inserts buffers or resizes existing cells. Note that design rule fixing phase is allowed to break timing constraints.
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.

Note: the optimizations Design Compiler performs (or does not perform) depend on the constraints you set. Therefore, setting realistic constraints is one of the most important synthesis tasks.
Reporting and Analyzing the Design

Once the synthesis has been completed, you need to analyze the results. Design Compiler provides together with its graphical user interface (Design Vision) various means to debug the synthesized design. These include both textual reports that can be generated for different design objects and graphical views that help inspecting and visualizing the design.

There are basically two types of analysis methods and tools:

Generating reports for design object properties

Reporting commands generate textual reports for various design objects: timing and area, cells, clocks, ports, buses, pins, nets, hierarchy, resources, constraints in the design, and so on.

Visualizing design objects (Design Vision)

Some design objects and their properties can be analyzed graphically. You may examine for example the design schematic and explore the design structure, visualize critical and other timing paths in the design, generate histograms for various metrics and so on.

These methods and tools are used to verify that the design meets the goals set by the designer and described with design constraints. If the design does not meet a design goal then the analysis methods can help determining the cause of the problem.

Save Design

The final task in synthesis with Design Compiler is to save the synthesized design. The design can be saved in many formats but you should save for example the gate-level netlist (usually in Verilog) and/or the design database. Remember that by default, Design Compiler does not save anything when exiting.