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.
Saturday, January 9, 2010
Subscribe to:
Post Comments (Atom)
Precisely what one would need to have an overview
ReplyDeleteGreat
Great blog.....Thanks a lot for sharing this blog.Synthesis is the process of translating the schematic and behavioural VHDL descriptions of the design into a low-level form suitable for the vendor place and route tools.Synthesis Design
ReplyDeleteThe synthesis engine first creates an intermediate VHDL description of the design, and then synthesizes this into EDIF.To know more info please go through this blog.
this is asking for password
DeleteIt is really very useful blog.Thanks for sharing it.
ReplyDeleteA very precise and excellent overview
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteReally informative blog.
ReplyDeletethanks
Really helpful thank you for taking the time to write this.
ReplyDeleteHey, It really is incredibly fantastic and informative website. Good to discover your site Very well article! I’m simply in love with it.
ReplyDeletemediumschap ontwikkelen
Detailed and descriptive articles written in this blog is really very helpful for me as well as for other who seeking such kind of knowledge. It is definitely going to become useful in coming future.
ReplyDeletemediumschap opleiding
creativity of writer is purely impressive. It has touched to the level of expertise with his writing. Everything is up to the mark. Written perfectly and I can use such information for my coming assignment.mediumschap ontwikkelen
ReplyDeleteHey, It really is incredibly fantastic and informative website. Good to discover your site Very well article! I’m simply in love with it.mediumschap opleiding
ReplyDeletevery well explained thank u so much.give some more information regarding the input files used during synthesis and what exactly those file contains.
ReplyDeletethank u
This comment has been removed by the author.
ReplyDeleteThank you very much to the author for this article, it is such a great article. It helps me understand more about knowledge easily.Công cụ Synthesis
ReplyDeleteNice Blog. Thanks for sharing
ReplyDeleteExploring the Role of Semiconductors in IoT and Smart Devices
What are the common approaches to ASIC Verification?
The Impact of ASICs on the Evolution of Satellite Technology
Understanding the differences between clock gating and power gating
Understanding the Chip Design Process