Design Compiler Tutorial


RTL synthesis is an automated design task in which high-level design descriptions written in Hardware Description Languages (such as VHDL, Verilog, or SystemVerilog) are transformed into gate-level netlists. Gate-level netlist is basically a circuit implementation of the design made of library components (both combinational and sequential cells) available in the technology library and their interconnections. The netlist is generated by the synthesis tool according to the constraints set by the designer. Figure 1 below shows an overview of the synthesis.


FIGURE 1: An overview of the synthesis.

Design Compiler is RTL Synthesis tool by Synopsys. It supports UNIX platforms and is installed on Institute's computer systems (see here for available versions on each platform: mustatikli/ linux). Design Compiler is not supported on Windows platform.

This tutorial is intended for users with no previous experience with Design Compiler. It introduces you how to set up the synthesis tool and the basic tasks of logic synthesis with Design Compiler: analyzing and elaborating the design, setting constraints, optimizing the design, analyzing the results, and saving generated netlists. Specifically, this tutorial considers only synchronous systems and basic synthesis tasks. Subjects as asynchronous systems or advanced synthesis techniques will not be discussed. In addition to Design Compiler, this tutorial introduces the basics of the Design Compiler GUI (called Design Vision).

This tutorial includes several examples written in VHDL but, excluding a few commands using VHDL specific command options, all information shown here can also be applied with designs written in Verilog or SystemVerilog. This tutorial was made by using Design Compiler version 2007.03 SP2 on Linux.

Note: the Y Foundation (i.e. versions starting from version 2007.03) introduced some important changes in Synopsys Desing Compiler tool:

Therefore, this tutorial and its examples consider only Design Compiler running in XG mode using DCTCL command language even though older tools are still available and installed on Institute's computer systems.


In order to use Design Compiler, you must set up your environment correctly. This includes setting up a few variables, files, and licensing information and can be done by sourcing the scripts shown below.


First, check this link to find out the available versions of synthesis tools currently installed on Linux machines. Then, initialize the tool by running the respective source script. You should always select the latest version available unless you have a reason to use an older version.

$ source /share/tktprog/synopsys/syn-2007.03-SP2/


First, check this link (mustatikli) to find out the available versions of synthesis tools currently installed on Solaris machine. Then, initialize the tool by running the respective source script. On Solaris platform you may use either 32-bit or 64-bit binaries. You should always select the latest version available unless you have a reason to use an older version.

$ source /opt/synopsys/syn-2007.03-SP2/

After sourcing the given script you should see a message similar to the one below (the actual message may differ depending on the tool version and platform) indicating that the source script was read and your environment set up correctly:

                       SYNOPSYS Synthesis Tools
               version 2007.03-SP2 (32 bit binaries)
 -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
There is no /tmp/synopsys_cache directory... creating a new one.
NOTE: By default, Design Compiler is now starting in XG mode. If you
      want to revert back to DB mode, please use:
      dc_shell-t -db_mode OR dc_shell -tcl_mode -db_mode
RTFM: synopsys_help &
      read man pages: man <command_name>
      eg. man set_clock_uncertainty
Ensure that your .synopsys_dc.setup etc. is valid for this version.

Project Setup

Instructions for setting up a project directory and Design Compiler setup file for your project.

Directory Structure

In order to keep your project data well-organized and safe, it is recommended to store files in each project into a separate project directory. The following example proposes one possible directory structure for small projects.

The example below includes an optional simulation directory (SIM/) for ModelSim which is not needed in these exercises but is shown as an example of what sort of subdirectories might be needed in real projects.

<PROJECT>/  -- project directory
   .synopsys_dc.setup  -- Synopsys Design Compiler initialization file
   modelsim.ini        -- ModelSim initialization file
   SRC/  -- HDL source files
   SYN/  -- synthesis subdirectory
      DDC/      -- Design Compiler database
      NETLIST/  -- mapped Verilog/VHDL netlists
      RPT/      -- reports
      SCR/      -- synthesis scripts
      WORK/     -- intermediate files from synthesis tool
   SIM/  -- simulation subdirectory (not needed in these examples)
      SCR/      -- simulation scripts
      WORK/     -- ModelSim work directory

You may copy the directory structure shown above and use it as such, modify it as you like, or create your own directory structure according to your needs for your own projects. Whichever way you choose do, keep in mind that consistent and simple directory structure helps you to reuse your code from different projects and to automate some tasks in the design flow.

Note that unless otherwise stated, the examples in this tutorial assume that the directory structure described above is used.

Setup file .synopsys_dc.setup

The .synopsys_dc.setup file is the setup file for Synopsys' Design Compiler. Setup file is used for initializing design parameters and variables, declare design libraries, and so on. Shortly, the setup file defines the behavior of the tool and is required for setting the tool up correctly. The commands in this file are executed when Design Compiler is invoked. There are three different locations from where this file is searched for:

  1. The Synopsys root directory (<SYNOPSYS>/admin/setup/) for system-wide settings
  2. Your home directory ($HOME/) for user-defined settings
  3. The current working directory ($PWD/) for design-specific settings

The files are read in the order shown above. Settings in user-specific setup file override the settings from system-wide setup file and settings in design-specific setup file overrides settings from both system-wide and user-specific setup file. You should have at least design-specific setup file for each of your projects.

Example setup file

The following shows an example of a minimal setup file using dctcl syntax. The example setup file has also been adapted to use the directory structure described above:

# Minimal .synopsys_dc.setup file

# Define the UMC L180 GII library
set UMC /share/tktprog/IC/umc
set L180_GII ${UMC}/L180_GII/core/UMCL18G212D3_1.0/design_compiler

# Define the libraries and search path
set search_path [concat $search_path ./SRC ./SYN/SCR ${L180_GII}]
set target_library ${L180_GII}/umcl18g212t3_tc_180V_25C.db
set synthetic_library dw_foundation.sldb
set link_library [concat "*" $target_library $synthetic_library]
set symbol_library ${L180_GII}/umcl18g212t3.sdb

define_design_lib WORK -path ./SYN/WORK

The example file does the following:

Sets the search_path
If a file is referenced just by its name (directory path not specified) then Design Compiler searches the file from the directories specified by the search_path variable. For example, in this case the search order is: the current directory (.), Synopsys installation directories <SYNOPSYS>/libraries/syn, <SYNOPSYS>/dw/syn_ver, and <SYNOPSYS>/dw/sim_ver, and finally the directories ./SRC and ./SYN/SCR in the project directory and the UMC technology library directory.
Sets the target_library
The target library variable defines the technology library that Design Compiler uses to build the circuit. That is, during technology mapping phase Design Compiler selects components from the library specified with the target library variable to build the gate-level netlist. In this example, we are using the UMC L180 GII library which can be found from the ${L180_GII} directory.
Sets the synthetic_library
The synthetic library variable specifies the synthetic or DesignWare libraries. These synthetic libraries are technology-independent, microarchitecture-level design libraries providing implementations for various IP blocks. The standard.sldb synthetic library which is automatically included contains basic implementations for the built-in HDL operators (adders, subtractors, comparators etc). The dw_foundation library which is shown in the example includes DesignWare Building Block IP Libraries DW01, DW02, DW03, DW04, DW05, DW06, and DW07. These libraries provide more advanced implementations for the built-in operators to improve performance. They also include implementations for more complex arithmetic operators such as MAC, SOP, and vector adders. Other DesignWare libraries include e.g. building blocks for DSP (FIR and IIR filters), memories, advanced math functions, microcontrollers and so on. If additional synthetic libraries are defined with the synthetic_library variable, they must also be included in the link_library variable.
Sets the link_library
The link library variable is used to resolve design references. That is, Design Compiler must connect all the library components and designs it references. This step is called linking the design or resolving references.
Sets the symbol_library
Symbol library defines the schematic symbols for components in technology library. These symbols are needed for drawing design schematics.
Sets the path to work library
This command maps a design library to a directory. Design Compiler uses this directory to store intermediate represenstations of the design it generates during synthesis.

Note that since the search path variable defines directories ${L180_GII} and <SYNOPSYS>/libraries/syn, we can reference the UMC technology library and dw_foundation library just by their name.

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:

If the analysis reports errors, they must be fixed, and the design reanalyzed before continuing.

The elaboration command (elaborate) does e.g. the following:

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 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 StructuringAfter Structuring
P = ax + ay + cP = aI + c
Q = x + y + zQ = I + z
I = x + y
Structuring is usually recommended for designs with regular structured logic.
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:

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.


This section illustrates the synthesis flow and some of the tasks described above with a few examples.

Note that you may get different results from synthesis depending on the platform and version used. These examples were made with the version Z-2007.03-SP2 running on Linux.

Modular Ripple Carry Adder

The first example is a simple Ripple Carry Adder (RCA). This example illustrates the basic synthesis flow: reading the design, setting constraints, optimizing the design, reporting and analyzing, and saving the design.

RCA Design Structure

This adder has modular structure as illustrated in pictures below. Figure 2 shows the gate-level structure of the Half Adder (HA) module, which is composed of two gates, AND and exclusive OR. This design is described in file ha.vhd.

Half Adder Module

FIGURE 2: Half Adder Module

The Full Adder (FA) module is composed of two instances of Half Adders and single OR gate as shown in Figure 3. This design is described in file fa.vhd.

Full Adder Module

FIGURE 3: Full Adder Module

The Ripple Carry Adder (RCA) design is generic instantiation of Full Adder Modules as shown in Figure 4. The RCA design is described in file rca.vhd.

Ripple Carry Adder

FIGURE 4: 4-bit Ripple Carry Adder

The last part of the design instantiates the RCA design using bus width of 4 bits. The design also registers the output of the adder as shown in Figure 5. The carry in (CI) bit of the RCA is connected low (0) and the carry out (CI) bit is the most significant bit (MSB) of the output bus. This design is described in file adder.vhd.


FIGURE 5: An adder block using the above RCA design for the '+'-operator. The Reset and Clock signals have been omitted for clarity.

This example uses the directory structure described earlier in section Directory Structure. Create a directory structure as described and copy the following files (SRC/ha.vhd, SRC/fa.vhd, SRC/rca.vhd, SRC/adder.vhd) into the directory SRC/. Copy also the .synopsys_dc.setup file into your project root directory.

Initialize Design Compiler as shown in section Initialization and invoke the Design Compiler GUI:

$ design_vision

Note that there is no ampersand (&) at the end of the command. In a moment, you should see a screen similar to the one below:

Design Compiler

Design Compiler GUI (aka Design Vision).

The Hierarchy Browser displays information about the design in textual form. The Hierarchy Browser is divided into two panes: instance tree (left) and objects list (right). The instance tree displays the design's hierarchy and the objects list information about the objects in current instance.

The Console views display information between the designer and the synthesis tool (commands entered by the designer and messages resulting the commands). Commands can be entered in Console Command Line (or from menubar menus and toolbar buttons).

Note that only some of the most common commands can be entered by using the Design Compiler GUI menubars and buttons. All commands can always be executed by writing them into the console. Therefore, in this tutorial we will mostly write the commands into the console. At the end of the synthesis, we will create a synthesis script file from commands that were executed during this example. This synthesis script file can then be used in subsequent synthesis runs.

Before proceeding with the example you need check that the tool has been set up correctly (i.e. the .synopsys_dc.setup file was read at the start up and there wasn't any problems with that). Our setup file merely sets the libraries that are required for synthesis and defines a library for work files.

Check libraries by selecting File -> Setup... from the menubar. This will open an Application Setup dialog box. In Application Setup check the values for target_library, link_library, symbol_library, and synthetic_library. They should be the same as in the setup file. The search_path should contain ./SRC, ./SYN/SCR, and ${L180_GII} directories in addition to default search path directories.

If the values for libraries or search path is something else then there was a problem with the setup file. In particular, if the values for libraries are your_library.db, your setup file was not read at all. In that case, the most probable reason is that the Design Vision was invoked in a wrong directory (Design Compiler/Vision searches for the setup file from the same directory it is invoked).

Check also that the design library is mapped correctly by writing the following command to the Console Command Line:

get_design_lib_path WORK

This should print the full path to the ./SYN/WORK/ library.

Reading in the Design

The first thing to do is to load the design into the Design Compiler memory. This task consists of two operations: analyzing and elaborating the design as described earlier (see the section Reading in the Design).

There are two commands for reading in the design: analyze and read_file. The read_file command is used with designs that are already in .ddc format so you should use the analyze command:

analyze -library WORK -format vhdl {./SRC/ha.vhd ./SRC/fa.vhd ./SRC/rca.vhd ./SRC/adder.vhd}

The same command can be found from the menubar (File -> Analyze...):

Analyze Designs Dialog Box

Analyze Designs Dialog Box

Select Add... and browse in to SRC directory in the file browser dialog and select your VHDL files. Check that Format is VHDL and Work library is WORK and click OK.

If there are syntactical errors or any non-synthesizable descriptions in your files the analysis will fail (and you need to fix them until you may proceed). In this case there shouldn't be any problems.

The next step is to elaborate the design:

elaborate ADDER -architecture RTL -library WORK -parameters "N=4"

The same command can be found from the menubar (File -> Elaborate...):

Elaborate Designs Dialog Box

Elaborate Designs Dialog Box

Check that Library is WORK, Design is ADDER(RTL), and in Parameters box set N to 4 and click OK.

Setting the parameter N to 4 overrides the default generic value (8) set in the file adder.vhd and creates a 4-bit RCA.

Always check the messages that Design Compiler generates in the console for each command you enter. For example, the elaboration command printed the following messages about the elaboration process:

design_vision-xg-t> elaborate ADDER -architecture RTL -library WORK -parameters "N=4"

Inferred memory devices in process
        in routine adder_N4 line 85 in file
|    Register Name    |   Type    | Width | Bus | MB | AR | AS | SR | SS | ST |
|        s_reg        | Flip-flop |   5   |  Y  | N  | Y  | N  | N  | N  | N  |
Presto compilation completed successfully.
Elaborated 1 design.
Current design is now 'adder_N4'.
Information: Building the design 'rca' instantiated from design 'adder_N4' with
        the parameters "N=4". (HDL-193)
Presto compilation completed successfully.
Information: Building the design 'fa'. (HDL-193)
Presto compilation completed successfully.
Information: Building the design 'ha'. (HDL-193)
Presto compilation completed successfully.
Current design is 'adder_N4'.

You should always check from the elaboration report what kind of memory devices (Type) Design Compiler wants to infer and the number (Width) of those devices. In this example, Design Compiler has decided to infer 5 flip-flops and that these registers are inferred for the process outregs in file adder.vhd. The number of registers and the type matches with what was expected for this design.

Sometimes Design Compiler wishes to infer latches from your description (latch in colunm Type in elaboration report). Latches may be intentional or unintentional. Consider latches as design errors in your description unless you know that latches should be inferred.

You may now also check the design structure by using the Hierarchy Browser or by creating a desing schematic for your design.

Hierarchy Browser

Hierarchy Browser. On the left-hand side is the instance tree which shows the design hierarchy. On the right-hand side is the objects list which shows information about the selected instance.

The design schematic can be generated with the 'Create Design Schematic' button (Create Design Schematic Button) in the toolbar. The schematic is generated for the instance currently selected in the instance tree (or top level design by default). The following four figures display the design's structure after elaboration. You may move up and down in the design hierarchy e.g. by double clicking the instance in the design schematic, by using the toolbar buttons, or by using the Hierarchy Browser (select an instance, right-click the mouse and select the Schematic View).

Note that the following figures represents the design structure as it was understood and extracted by Design Compiler from your HDL design description. You should verify that Design Compiler did actually understand correctly what you intended. This extracted design structure will be the starting point for the optimizations but it does not necessarily represent the final design structure. Also note that the design is currently represented in an intermediate form using GTECH cells. These cells are used internally by Design Compiler and will be replaced with the actual library cells at the end of synthesis, during technology mapping phase, as explained here.


The RCA adder design structure after elaboration. The i_rca is the RCA adder instance and s_reg are the output registers. Compare this schematic with this figure.

GTECH RCA Instance

The RCA Adder Instance. The i_fas are Full Adder Modules. Compare this schema with this figure.

GTECH FA Instance

The Full Adder Instance. The i_has are Half Adder Modules. Compare this schema with this figure.

GTECH HA Instance

The Half Adder Module. Compare this schema with this figure.

The design is now read into the Design Compiler memory. It was analyzed for the syntactical errors and non-synthesizable structures and prepared for synthesis by the analyze and elaborate commands. However, it is still possible that there are some problems with the design. To check the design consistency, we need to run the check_design command on the design:

check_design -multiple_designs

This will produce the following messages:

design_vision-xg-t> check_design -multiple_designs
Warning: In design 'adder_N4', a pin on submodule 'i_rca' is connected to logic 1 or logic 0. (LINT-32)
   Pin 'ci' is connected to logic 0. 
Information: Design 'fa' is instantiated 4 times. (LINT-45)
         Cell 'i_rca/i_fa_0' in design 'adder_N4' 
         Cell 'i_rca/i_fa_1' in design 'adder_N4' 
         Cell 'i_rca/i_fa_2' in design 'adder_N4' 
         Cell 'i_rca/i_fa_3' in design 'adder_N4' 
Information: Design 'ha' is instantiated 8 times. (LINT-45)
         Cell 'i_rca/i_fa_0/i_ha_0' in design 'adder_N4' 
         Cell 'i_rca/i_fa_0/i_ha_1' in design 'adder_N4' 
         Cell 'i_rca/i_fa_1/i_ha_0' in design 'adder_N4' 
         Cell 'i_rca/i_fa_1/i_ha_1' in design 'adder_N4' 
         Cell 'i_rca/i_fa_2/i_ha_0' in design 'adder_N4' 
         Cell 'i_rca/i_fa_2/i_ha_1' in design 'adder_N4' 
         Cell 'i_rca/i_fa_3/i_ha_0' in design 'adder_N4' 
         Cell 'i_rca/i_fa_3/i_ha_1' in design 'adder_N4' 

The check_design command checks the internal representation of the current design and issues error, warning, and informative messages about the design to indicate potential design problems. In this example, the check_design command indicates that the design instantiates design fa four times and the design ha eight times which is how the design is described. It also issues a warning that there is a pin that has been permanently connected to ground or supply voltage (the input pin ci of the module rca in file adder.vhd). The ci pin is the carry in bit for the adder and it was intentionally connected to the logic 0 so we can ignore this warning.

Saving the Elaborated Design

It is recommended to save the design every now and then as the synthesis proceeds. In this case we will save the elaborated design into a Design Compiler database. This saved database is like a checkpoint in which we may return should the tool crash or if we make an unrecoverable mistake later in the synthesis flow (remember, there is no undo command in Design Vision/Design Compiler...).

Use the write_file command to write the elaborated design into a Design Compiler database:

 write_file -format ddc -hierarchy -output ./SYN/DDC/adder_N4_elab.ddc

The same command can also be found from the Menubar (File -> Save As...):

Save As Dialog Box

Save As Dialog Box. Check that Format is DDC (ddc), select the directory (SYN/DDC), Save all designs in hierarchy is checked and set the file name as adder_N4_elab. Then click Save.

We will need this elaborated design later.

Setting the Constraints

Next, we will set the design constraints and define the design environment. This is the most important step in synthesis and should be made with care. The quality of the synthesis results depends on the constraints you set. Normally, design constraints are extracted from various design specifications (timing, architecture, block, etc.).

Design Constraints

Design constraints are the instructions for the synthesis tool how to do the synthesis. The constraints guides the operation of the synthesizer in the process of optimizing the design for example by allowing or preventing operations, or by describing an objective that must be met and so on. In general, contraints describe your design goals to the synthesizer and what the synthesizer can or cannot do with the design to meet your design goals.

The most important design constraint for a synchronous design is the system clock. The constraints to model the behavior of the system clock and the clock network are clock period, clock uncertainty, clock latency, and clock transition time.

The time at which the clock pulse repeats itself.
Clock uncertainty can be used to model the variation of the clock propagation times in the different branches of the clock tree. This variation is due to different lengths of these branches (clock skew) but uncertainty can also be used to model clock jitter (variation in clock period length).
Clock latency models the time it takes the clock signal to propagate from the clock source to the clock capture point (register clock pins).
Transition time
Clock transition time can be used to model the time it takes a clock signal to change state.

In this example, we will model the clock and the clock network with the following properties: 4 ns period (50/50 pulse ratio), 0.1 ns uncertainty, and 0.2 ns latency.

create_clock -name "clk" -period 4 -waveform {0 2} {clk}
set_clock_uncertainty 0.1 clk
set_clock_latency 0.2 clk
set_clock_transition 0.1 clk
set_dont_touch_network clk

The clock signal can also be created by selecting the clock pin (clk) in the design schematic and then selecting Attributes -> Specify Clock... from the menubar:

Specify Clock Dialog Box

Specify Clock Dialog Box. Check that Clock name is clk, Period is 4 and set the rising (0) and falling (2) edges of the clock. Check that Don't touch network is checked. Then click Apply to see the clock waveform and OK.

Note that since this is still a pre-layout design we also had to set the set_dont_touch_network attribute on the clock network. Setting this attribute prevents Design Compiler from modifying the cells or nets in the clock network or from inserting buffers on the clock network. This is needed since usually physical layout data is required for clock tree synthesis (CTS).

Reset net is another High-Fanout Net (HFN) that should be balanced by a backend tool. Therefore, we need to tell Design Compiler that it should rather ignore than try to fix possible timing/DRC violations on the reset net. Enter the commands:

set_dont_touch rst_n
set_ideal_network rst_n

Next, we need to define the system interface and I/O timing. For system interface, we need to provide information about the logic that is driving the inputs and the capacitive loads connected on the output ports. For I/O timing, we need to tell specify when signals arrive on the inputs in our block. Usually, signals do not arrive simultaneously to the input ports due to routing and other reasons but at different times. For outputs, we need to specify how much time is needed so that the signals from output port have enough time to travel to the next block. In order to set these constraints, you should have detailed information about the system interface.

In this example, we will assume that the system has the interface shown below. Signals of the input port A are driven by a flip-flop whereas the signals in input port B are driven by some logic which also causes some delay before the signals arrive on the input port B. Similarly, the signals from the output port Z go through some logic causing delay before captured at the register data input.

System Interface

System Interface and Timing.

First, we will describe the system interface. That is, we will specify the logic that is driving the cells connected to the input ports in our system. We also need to specify the loads on output ports.

In this example we will assume that the input port a is connected directly into the output pin (Q) of a flip-flop (HDDFFPB1) in the previous block as shown in the figure above. For bus b there is some logic between the flip-flop and the input port pins. We will assume that this logic contains inverters (HDINVD1) which will be the driving cells for the input port b pins. On the output s we will assume that the load connected to the output ports equals the load of the input data pin (D) of a flip-flop (HDDFFPB1).

set_driving_cell -library umcl18g212t3_tc_180V_25C -lib_cell HDDFFPB1 -pin Q [get_ports a]
set_driving_cell -library umcl18g212t3_tc_180V_25C -lib_cell HDINVD1 -pin Z [get_ports b]
set_load [load_of umcl18g212t3_tc_180V_25C/HDDFFPB1/D] [get_ports s]

Note: the following warnings will be shown to you when setting the driving cells:

design_vision-xg-t> set_driving_cell -library umcl18g212t3_tc_180V_25C -lib_cell HDDFFPB1 -pin Q [get_ports a]
Warning: Design rule attributes from the driving cell will be
        set on the port. (UID-401)
Warning: Design rule attributes from the driving cell will be
        set on the port. (UID-401)
Warning: Design rule attributes from the driving cell will be
        set on the port. (UID-401)
Warning: Design rule attributes from the driving cell will be
        set on the port. (UID-401)
design_vision-xg-t> set_driving_cell -library umcl18g212t3_tc_180V_25C -lib_cell HDINVD1 -pin Z [get_ports b]
Warning: Design rule attributes from the driving cell will be
        set on the port. (UID-401)
Warning: Design rule attributes from the driving cell will be
        set on the port. (UID-401)
Warning: Design rule attributes from the driving cell will be
        set on the port. (UID-401)
Warning: Design rule attributes from the driving cell will be
        set on the port. (UID-401)

These are just to notify you that the design rule attributes attached to the driving cells will be considered when optimizing the design.

The above commands specify the system interface requirements. Next we have to describe the interface timing requirements.

The set_input_delay command specifies how much time is used by the external logic before signal arrives to the input of our system. This external delay is subtracted from the clock period and the margin specifies how much time is left for the internal logic.

The output paths must be constrained in a similar fashion. You must specify how much time is needed by the external block before the signal is captured at the path end point. Use the command set_output_delay for setting the delay constraint on the output paths.

set_input_delay 0.67 [get_ports b] -clock clk
set_output_delay 0.5 [get_ports s] -clock clk

In this example there are no timing exceptions such as false paths or multicycle paths.

The final design constraint we set is the maximum area for our design.

set_max_area 1000

Define the Design Environment

The design environment defines the environment in which the design is expected to operate. Design environment includes parameters such as operating conditions (specify variations in temperature, voltage, and manufacturing process), wire load models (WLM; used to specify the effect of the interconnects on the timing and area), and system interface charasteristics (input drives, I/O loads, and fanout loads).

set_operating_condition -lib umcl18g212t3_tc_180V_25C TYPICAL
set_wire_load_model -lib umcl18g212t3_tc_180V_25C -name "suggested_10K"
set_wire_load_mode top

The above illustrates the basic constraints that should be set on each design. But, before moving on to the optimization step, we will put together what has been done so far and create a command script file from the above commands. Script files are text files that contain sequences of Design Compiler commands and variables.

So, we will create a file called constraints.tcl containing the commands for constraining our design. You may do this by selecting the History tab under the Console window and selecting the Save Contents As ... button. Save the command file in the directory ./SYN/SCR/. You may have to edit the file if there are commands you don't want to run (typos, commands related to schematic like zooming, or the like). Your script file should look like this. This script file will be used later in the optimization step.

Optimizing the Design

Now that the design is constrained it is ready for the synthesis. In the following sections we will do several synthesis runs using this design to illustrate different synthesis techniques and their effects on the results. The first synthesis run is a default synthesis which does not apply any special optimizations and which will be used as a reference for the other synthesis runs.

The design is optimized by running the command compile. The compile command performs the logic-level and gate-level optimizations on the design.


The same command can be found from the menubar (Design -> Compile Design):

Compile Design Dialog

Compile Design Dialog.

Since this is quite small design and no special optimizations were used, the compilation should complete pretty fast. You should see the following results if you regenerate the schematics for the design:

Compiled Adder Design

Compiled Adder Design. Compare this schematic with these figures: block schema elaborated design. Note that the large block named HDTIELO in the schematic is VSS tieoff cell. This cell connects the input ci through a resistive device to the VSS supply.

Compiled RCA Design

Compiled RCA module. Compare this schematic with these figures: block schema elaborated design

Compiled FA Design

Compiled Full Adder module. Compare this figure with these figures: block schema elaborated design

Compiled HA Design

Compiled Half Adder module. Compare this figure with these figures: block schema elaborated design

These schematics match quite accurately the structure of our HDL design descripion. Note that now the design is finally mapped to actual technology library cells. Also note that the synthesis task is not over yet, but we must analyze the results to see if there are problems or not.

Design Analysis and Reporting

Before continuing the optimizations, we will look at how to analyze the synthesis results. There are many things that a designer wants to check from the synthesized design, but this tutorial will only present the most basic analysis tasks.

Reporting Violations

When we start analyzing a synthesized design it is a good starting point to get first an overall idea about the results and comparing these results with the expectations. If the design does not meet our expectations we can do a more detailed analysis to find out what went wrong and what can be done to fix the problems.

To get an first idea about our design, we need to get some general statistics like timing, design rule violations, area, structure, and so on from it. The report_qor command provides lots of information which may pinpoint the possible design problems and what areas in our design need more detailed analyses:

Note: we will save some of these reports into the ./SYN/RPT directory so that reports can be examined later (for example, for comparing the results from different synthesis runs). The reporting commands that can be found from the menubar include an option to print the report on both Console and file. For the reporting commands that you must enter manually you may use the standard UNIX file I/O operators (i.e. > and >>).

report_qor > ./SYN/RPT/report_qor_default.txt
design_vision-xg-t> report_qor
Information: Updating design information... (UID-85)
Report : qor
Design : adder_N4
Version: Z-2007.03-SP2
Date   : Tue Nov 13 11:40:48 2007

  Timing Path Group 'clk'
  Levels of Logic:               9.00
  Critical Path Length:          1.52
  Critical Path Slack:           1.69
  Critical Path Clk Period:      4.00
  Total Negative Slack:          0.00
  No. of Violating Paths:        0.00
  No. of Hold Violations:        5.00

  Cell Count
  Hierarchical Cell Count:         13
  Hierarchical Port Count:         66
  Leaf Cell Count:                 26

  Combinational Area:      367.715008
  Noncombinational Area:   274.174995
  Net Area:                  0.000000
  Cell Area:               641.890015
  Design Area:             641.890003

  Design Rules
  Total Number of Nets:            36
  Nets With Violations:             0


  Compile CPU Statistics
  Resource Sharing:              0.00
  Logic Optimization:            0.52
  Mapping Optimization:          1.18
  Overall Compile Time:          8.09

The above report does not indicate any major problems in our design. The only violations that are reported are few hold time violations. Also the Levels of Logic shows a bit high number (9) but the design does not have timing problems so it is not a big problem. Overall, this is a fairly good result.

Since there weren't any major problems we may now try to get more information about those hold time violations and other possible design problems.

The report_constraint command provides constraint-related information about the current design. With the -all_violators option this command gives us a summary of all of the optimization and design rule constraint violations in our design. This is a good starting point for the design analysis.

report_constraint -all_violators

The same command can also be found from menubar (Design -> Report Constraints...). Check that Show all violators button is checked.

This will produce the following report:

design_vision-xg-t> report_constraint -all_violators
Report : constraint
Design : adder_N4
Version: Z-2007.03-SP2
Date   : Tue Nov 13 11:42:21 2007

   min_delay/hold ('clk' group)

                             Required        Actual
   Endpoint                 Path Delay     Path Delay        Slack
   s_reg[4]/D                   0.26           0.21 r        -0.05  (VIOLATED)
   s_reg[0]/D                   0.31           0.27 f        -0.04  (VIOLATED)
   s_reg[1]/D                   0.31           0.27 f        -0.04  (VIOLATED)
   s_reg[2]/D                   0.31           0.27 f        -0.04  (VIOLATED)
   s_reg[3]/D                   0.31           0.27 f        -0.04  (VIOLATED)

This report also shows that there are only hold time violations. Hold time violations basically mean that signals arrive too fast at the path endpoints. Removing hold-time violations involves inserting delays on the violating signal paths. Hold-time violations can be fixed straight away by using Design Compiler commands or fixing can also be postponed at a later date. Usually, hold-time fixing should be considered only after scan insertion has been performed because that can in many cases fix small hold-time violations. Hold time fixing can also be postponed until initial placement and routing has been performed in which case more accurate delay numbers are available for timing analysis (compared to the estimations which pre-layout timing analysis uses).

The following example shows how hold-time violations can be fixed within Design Compiler if necessary (you may try these, but note that in this tutorial we consider these violations small and they would be fixed later as described above):

set_fix_hold clk
compile -only_design_rule -incremental_mapping

The set_fix_hold command informs the compile command to fix the hold time violations. The compile command option -only_design_rule specifies that the compile command should fix only design rule violations before exiting (no mapping optimizations done). The -incremental_mapping option specifies that only incremental improvements to the gate structure should be attempted. These options should speed up the compilation process.

Running these commands and regenerating the constraint report as shown above show that Design Compiler removed the hold time violations by inserting buffers on the signal paths.

Timing Analysis

Next thing we can check is timing for our design. The report_timing command provides timing-related information on the current design. By default, the report_timing command displays information on the critical path or the timing path with the maximum delay.

report_timing > ./SYN/RPT/report_timing_default.txt

This produces the following report (assuming that no hold-time fixing is performed):

design_vision-xg-t> report_timing
Report : timing
        -path full
        -delay max
        -max_paths 1
Design : adder_N4
Version: Z-2007.03-SP2
Date   : Tue Nov 13 11:46:02 2007

Operating Conditions: TYPICAL   Library: umcl18g212t3_tc_180V_25C
Wire Load Model Mode: top

  Startpoint: b[0] (input port clocked by clk)
  Endpoint: s_reg[4] (rising edge-triggered flip-flop clocked by clk)
  Path Group: clk
  Path Type: max

  Des/Clust/Port     Wire Load Model       Library
  adder_N4           suggested_10K         umcl18g212t3_tc_180V_25C

  Point                                                   Incr       Path
  clock clk (rise edge)                                   0.00       0.00
  clock network delay (ideal)                             0.20       0.20
  input external delay                                    0.67       0.87 r
  b[0] (in)                                               0.04       0.91 r
  i_rca/b[0] (rca_N4)                                     0.00       0.91 r
  i_rca/i_fa_0/b (fa_0)                                   0.00       0.91 r
  i_rca/i_fa_0/i_ha_0/b (ha_0)                            0.00       0.91 r
  i_rca/i_fa_0/i_ha_0/U1/Z (HDEXOR2D2)                    0.15       1.06 f
  i_rca/i_fa_0/i_ha_0/s (ha_0)                            0.00       1.06 f
  i_rca/i_fa_0/i_ha_1/b (ha_7)                            0.00       1.06 f
  i_rca/i_fa_0/i_ha_1/U2/Z (HDAND2D1)                     0.11       1.18 f
  i_rca/i_fa_0/i_ha_1/co (ha_7)                           0.00       1.18 f
  i_rca/i_fa_0/U1/Z (HDOR2D1)                             0.20       1.38 f
  i_rca/i_fa_0/co (fa_0)                                  0.00       1.38 f
  i_rca/i_fa_1/ci (fa_3)                                  0.00       1.38 f
  i_rca/i_fa_1/i_ha_1/a (ha_5)                            0.00       1.38 f
  i_rca/i_fa_1/i_ha_1/U2/Z (HDAND2D1)                     0.14       1.52 f
  i_rca/i_fa_1/i_ha_1/co (ha_5)                           0.00       1.52 f
  i_rca/i_fa_1/U1/Z (HDOR2D1)                             0.20       1.73 f
  i_rca/i_fa_1/co (fa_3)                                  0.00       1.73 f
  i_rca/i_fa_2/ci (fa_2)                                  0.00       1.73 f
  i_rca/i_fa_2/i_ha_1/a (ha_3)                            0.00       1.73 f
  i_rca/i_fa_2/i_ha_1/U2/Z (HDAND2D1)                     0.14       1.86 f
  i_rca/i_fa_2/i_ha_1/co (ha_3)                           0.00       1.86 f
  i_rca/i_fa_2/U1/Z (HDOR2D1)                             0.20       2.07 f
  i_rca/i_fa_2/co (fa_2)                                  0.00       2.07 f
  i_rca/i_fa_3/ci (fa_1)                                  0.00       2.07 f
  i_rca/i_fa_3/i_ha_1/a (ha_1)                            0.00       2.07 f
  i_rca/i_fa_3/i_ha_1/U2/Z (HDAND2D1)                     0.14       2.21 f
  i_rca/i_fa_3/i_ha_1/co (ha_1)                           0.00       2.21 f
  i_rca/i_fa_3/U1/Z (HDOR2D1)                             0.18       2.39 f
  i_rca/i_fa_3/co (fa_1)                                  0.00       2.39 f
  i_rca/co (rca_N4)                                       0.00       2.39 f
  s_reg[4]/D (HDDFFRPQ1)                                  0.00       2.39 f
  data arrival time                                                  2.39

  clock clk (rise edge)                                   4.00       4.00
  clock network delay (ideal)                             0.20       4.20
  clock uncertainty                                      -0.10       4.10
  s_reg[4]/CK (HDDFFRPQ1)                                 0.00       4.10 r
  library setup time                                     -0.02       4.08
  data required time                                                 4.08
  data required time                                                 4.08
  data arrival time                                                 -2.39
  slack (MET)                                                        1.69

The delay report shows delay calculation in two sections: the first section for data arrival time calculation and the second for data required time calculation. The data arrival time is the time required for signal to travel from path start point to a path end point. The data required time is the maximum time a signal has for traveling that path. The difference of data required time and data arrival time is called slack or timing margin of the path. If slack is negative, there is a timing violation on that path. The timing margin for our design (1.69 ns) is pretty good compared to the clock period (4 ns). This means that our clock constraint is not too tight.

From the data arrival calculation we can see the path for our critical path: the path starts from the input pin b[0] and ends at the register data input pin s_reg[4]/D. In between are shown all the cells on the path. Examining this path reveals that the critical path goes through all full adders in the design which is exactly what we can expect from a Ripple Carry Adder. That also explains why the Levels of Logic had fairly big number above.

This same path can also be examined graphically in different ways. We can, for example, highlight the critical path on the schematic or we can use the schematic view tools to display selected paths on the design.

To highlight the critical path, select Highlight -> Critical Path from the menubar. Compare these figures with the timing report shown above.

Critical Path

Critical Path

Critical Path

Critical Path

The above figures showed critical as it goes in the design hierarchy. If you want to examine the full path at a glance, you need to select and load it into a new schematic window as follows:

Select Schematic -> New Path Schematic View -> Of Paths From/Through/To ...

You should see the path below which shows the critical path from the path start point (b[0]) to path end point (s_reg[4]/D) in a single view.

Critical path of the Adder design. The red diamonds mark hierarchical boundaries in the design structure.

You may also analyze the timing of your design visually with histogram views. Endpoint Slack displays the slack of each endpoint for your design. Path Slack histogram displays the slack for a selected path(s) in design. The histogram views can be used e.g. to analyze the distribution of timing slack values in the design. You may generate slack histograms by selecting Timing -> Endpoint Slack... or Timing -> Path Slack... from the menubar.

Endpoint Slack Dialog Path Slack Dialog

Endpoint Slack Dialog

Path Slack Dialog

Endpoint Slack Histogram. On the left hand side the distribution of slack values for setup delays (Delay type max) are shown. On the right hand side paths and the endpoint slacks in the selected bin are shown. Path Slack histogram view is identical to this.

In addition to Path Slack and Endpoint Slack histograms, you may also create a similar view for Net Capacitances (Timing -> Net Capacitance... in menubar).

Now we know how we can do basic timing analysis on our design. The following section explains how to analyze the design structure.

Structure Analysis

Design schematics are the easiest method of analysing the design structure, but the reporting commands can provide additional information on the design and its structure.

Design's area is one of the primary interests of synthesis results. The report_area command displays information on design's area.

report_area > ./SYN/RPT/report_area_default.txt

This produces the following report:

design_vision-xg-t> report_area
Report : area
Design : adder_N4
Version: Z-2007.03-SP2
Date   : Tue Nov 13 12:12:03 2007

Library(s) Used:

    umcl18g212t3_tc_180V_25C (File: /share/tktprog/IC/umc/L180_GII/core/UMCL18G212D3_1.0/design_compiler/umcl18g212t3_tc_180V_25C.db)

Number of ports:               15
Number of nets:                21
Number of cells:                7
Number of references:           3

Combinational area:        367.715008
Noncombinational area:     274.174995
Net Interconnect area:      undefined  (Wire load has zero net area)

Total cell area:           641.890015
Total area:                 undefined

The above report simply displays the total area of the design. The total area is the sum of three factors: combinational, noncombinational, and net interconnect area. The area due to logic cells in design is shown by the combinational (basic logic gates like ANDs, ORs, and the like) and the noncombinational (registers) factors. The third factor affecting the area (net interconnect area) is due to the wires connecting these cells. In this library the wire load models do not include area information (Wire load has zero net area) so the Net Interconnect area (and therefore Total area) is left undefined.

NOTE: the area is given in library units. Library unit is some measurable unit (for example µm², number of equivalent AND-gates, or something else) that the library vendor has decided to use. This unit is library specific unit and needs to be verified from the library documentation if not known. In the UMC library we are using the unit for area is µm².

If we want to know more about how the area is divided within the design's hierarchical structure we can use the -hierarchy option:

design_vision-xg-t> report_area -hierarchy
Report : area
Design : adder_N4
Version: Z-2007.03-SP2
Date   : Tue Nov 13 12:13:19 2007

Library(s) Used:

    umcl18g212t3_tc_180V_25C (File: /share/tktprog/IC/umc/L180_GII/core/UMCL18G212D3_1.0/design_compiler/umcl18g212t3_tc_180V_25C.db)

Number of ports:               15
Number of nets:                21
Number of cells:                7
Number of references:           3

Combinational area:        367.715008
Noncombinational area:     274.174995
Net Interconnect area:      undefined  (Wire load has zero net area)

Total cell area:           641.890015
Total area:                 undefined

Hierarchical area distribution

                                  Global cell area          Local cell area
                                  ------------------  --------------------------- 
Hierarchical cell                 Absolute   Percent  Combi-    Noncombi-  Black
                                  Total      Total    national  national   boxes   Design
--------------------------------  ---------  -------  --------  ---------  ------  ---------
adder_N4                           641.8899    100.0    6.4510   274.1750  0.0000  adder_N4
i_rca                              361.2640     56.3    0.0000     0.0000  0.0000  rca_N4
i_rca/i_fa_0                        90.3160     14.1   12.9020     0.0000  0.0000  fa_0
i_rca/i_fa_0/i_ha_0                 38.7070      6.0   38.7070     0.0000  0.0000  ha_0
i_rca/i_fa_0/i_ha_1                 38.7070      6.0   38.7070     0.0000  0.0000  ha_7
i_rca/i_fa_1                        90.3160     14.1   12.9020     0.0000  0.0000  fa_3
i_rca/i_fa_1/i_ha_0                 38.7070      6.0   38.7070     0.0000  0.0000  ha_6
i_rca/i_fa_1/i_ha_1                 38.7070      6.0   38.7070     0.0000  0.0000  ha_5
i_rca/i_fa_2                        90.3160     14.1   12.9020     0.0000  0.0000  fa_2
i_rca/i_fa_2/i_ha_0                 38.7070      6.0   38.7070     0.0000  0.0000  ha_4
i_rca/i_fa_2/i_ha_1                 38.7070      6.0   38.7070     0.0000  0.0000  ha_3
i_rca/i_fa_3                        90.3160     14.1   12.9020     0.0000  0.0000  fa_1
i_rca/i_fa_3/i_ha_0                 38.7070      6.0   38.7070     0.0000  0.0000  ha_2
i_rca/i_fa_3/i_ha_1                 38.7070      6.0   38.7070     0.0000  0.0000  ha_1
--------------------------------  ---------  -------  --------  ---------  ------  ---------
Total                                                 367.7150   274.1750  0.0000

Note in the previous report that the area of cell i_rca is reported to be 361.2640 µm², but area for both combinational and noncombinational cells is 0. This is because the cell i_rca is purely hierarchical cell. Also note the small rounding errors in the report.

If you want to know details about cells in some instance (e.g. the cells in the instance i_fa_0) you need to use the report_reference command:

current_instance i_rca/i_fa_0
report_reference -hierarchy
design_vision-xg-t> current_instance
Current instance is the top-level of design 'adder_N4'.
design_vision-xg-t> current_instance i_rca/i_fa_0
Current instance is '/adder_N4/i_rca/i_fa_0'.
design_vision-xg-t> report_reference -hierarchy
Report : reference
Design : adder_N4/i_rca/i_fa_0 (fa_0)
Version: Z-2007.03-SP2
Date   : Tue Nov 13 12:16:10 2007

    b - black box (unknown)
   bo - allows boundary optimization
    d - dont_touch
   mo - map_only
    h - hierarchical
    n - noncombinational
    r - removable
    s - synthetic operator
    u - contains unmapped logic

Reference          Library       Unit Area   Count    Total Area   Attributes
HDOR2D1            umcl18g212t3_tc_180V_25C
                                 12.902000       1     12.902000  
ha_0                             38.707001       1     38.707001  h
ha_7                             38.707001       1     38.707001  h
Total 3 references                                     90.316002

Design: ha_0 
Reference          Library       Unit Area   Count    Total Area   Attributes
HDAND2D1           umcl18g212t3_tc_180V_25C
                                 12.902000       1     12.902000  
HDEXOR2D2          umcl18g212t3_tc_180V_25C
                                 25.805000       1     25.805000  
Total 2 references                                     38.707001

Design: ha_7 
Reference          Library       Unit Area   Count    Total Area   Attributes
HDAND2D1           umcl18g212t3_tc_180V_25C
                                 12.902000       1     12.902000  
HDEXOR2D2          umcl18g212t3_tc_180V_25C
                                 25.805000       1     25.805000  
Total 2 references                                     38.707001
design_vision-xg-t> current_instance
Current instance is the top-level of design 'adder_N4'.

The example above also shows how to move in the design hierarchy by using the current_instance command.

Synthesis Results

The above reports and schematics show that synthesis produced the hardware corresponding our HDL description. These reports also did not indicate any major design violations in the synthesized design.

From the above results we may create the following table:

Noncombinational Area/µm²274.17
Combinational Area/µm²367.71
Total Area/µm²641.89
Critical Path Slack/ns1.69
Total Negative Slack/ns0.0
Levels of Logic9
Leaf Cell Count26

In the following sections some design optimization techniques will be presented and applied to our design. Then the results will be compared with the results of the default synthesis shown above.

Saving the Design

Finally, the design has been synthesized. The last thing to do is to save necessary files from the synthesis. This is necessary because Design Compiler/Design Vision does not save your design when exiting.

What should be saved from the synthesis depends on your synthesis flow requirements. Anyway, you should save at least the following two items: the compiled design database and the Verilog/VHDL netlist of your design.

write_file -format ddc -hierarchy -output ./SYN/DDC/adder_N4_default_compiled.ddc
write_file -format verilog -hierarchy -output ./SYN/NETLIST/adder_N4_default_compiled.v

The compiled database is needed if you need to come back and fix something in your design. The Verilog/VHDL (usually Verilog) netlist is needed as an input for the backend flow.

Sometimes it is also required to write other files like Synopsys Design Constraints (SDC) format file and/or Standard Delay Format (SDF) back-annotation file (depending on your flow requirements):

write_sdc ./SYN/SCR/adder_N4_default.sdc
write_sdf ./SYN/SCR/adder_N4_default.sdf

Optimizations: Grouping and Ungrouping

The previous example showed how to perform a fairly simple synthesis with a small design. The most common synthesis tasks were covered and explained how they are performed with Synopsys Design Compiler. The ensuing design structure analysis revealed that synthesis tool had created gate-level netlist for the design that literally matched with our original HDL design description.

However, the adder example used above is also an example of badly written HDL for synthesis. Yes, it does simulate correctly and it does synthesize correctly too, there's no problem with that. The problem with the HDL description used in the example above is how the hardware is described. There are a couple of design flaws from the synthesis point of view:

In order to know why the listed items are problematic for synthesis, you need to know that when optimizing the design, Design Compiler operates only within a single block at a time. This means that if your design has very small partitions, they actually prevent Design Compiler from performing optimizations on your design. The above design is an exterme example of such design because each partition contain only a single cell (full adders) or two cells (half adders).

You may always rewrite your code to fix your problems, but if don't have a chance for that, you need to manipulate the hierarchy described in the HDL description. This chapter presents how you may create (group) or remove (ungroup) levels of hierarchy in Design Compiler using the previous adder as an example.

So, reset the Design Compiler and load the compiled design (adder_N4_default_compiled.ddc) into Design Compiler's memory (hope that you did save it earlier):

remove_design -all
read_file -format ddc ./SYN/DDC/adder_N4_default_compiled.ddc

Example 1: Ungrouping Full Adders

In the first example we will remove (ungroup) the hierarchy inside the Full Adder cells i_rca/i_fa_{0|1|2|3}. In order to remove the hierarchy you need to know the names of the hierarchical cells you want to remove. You can check the names from the design schematic or manually with the command get_cells. The following commands are equivalent:

ungroup { i_rca/i_fa_0/i_ha_0 i_rca/i_fa_0/i_ha_1 \
          i_rca/i_fa_1/i_ha_0 i_rca/i_fa_1/i_ha_1 \
          i_rca/i_fa_2/i_ha_0 i_rca/i_fa_2/i_ha_1 \
          i_rca/i_fa_3/i_ha_0 i_rca/i_fa_3/i_ha_1 }
ungroup { i_rca/i_fa_*/i_ha_* }
ungroup [ get_cells i_rca/i_fa_*/* -filter "is_hierarchical == true" ]

In the first command we will list individually the cells that we want to ungroup. We know the cell names (i_ha_0 and i_ha_1) by looking at the design schematics. Since the current level is adder_N4 we also need to provide the full path (i_rca/i_fa_{0|1|2|3}) to these cells. The backslash (\) divides the command to multiple lines. The second example uses the standard wildcard characters (*) to match the names of the cells.

In the third example we use Design Compiler's own commands to determine the hierarchical cell names for us. This approach is more usable for automatic synthesis scripts. First, we will determine all the cells on the hierarchy level i_rca/i_fa_*/ with the command get_cells i_rca/i_fa_*/*. This returns us a collection containing all cells on that level ({i_rca/i_fa_0/i_ha_0 i_rca/i_fa_0/i_ha_1 i_rca/i_fa_0/U1 i_rca/i_fa_1/i_ha_0 i_rca/i_fa_1/i_ha_1 i_rca/i_fa_1/U1 i_rca/i_fa_2/i_ha_0 i_rca/i_fa_2/i_ha_1 i_rca/i_fa_2/U1 i_rca/i_fa_3/i_ha_0 i_rca/i_fa_3/i_ha_1 i_rca/i_fa_3/U1}). This collection includes, however, also U1 cells (HDOR2D1 i.e. 2 input OR gates). This gate is not a hierarchical cell and cannot be ungrouped so we need to remove them from the collection. To remove this cell from the collection we use the get_cell command option -filter "is_hierarchical == true". Hierarchical cells have the attribute is_hierarchical set to true. This will return a collection from which U1 cells are removed and which can be given as an argument to the ungroup command.

Now the i_rca/i_fa_* cells should look something like this:

Ungrouped Full Adder

Full Adder ungrouped. Compare this with the original Full Adder schematic.

So far we have only modified the design structure. You may check i.e. how the outputs of the commands report_reference -hierarchy or report_area -hierarchy have changed. Next, we need to reoptimize the new design. To reoptimize the design, we just recompile it:


Examining the new design schematics reveals that Design Compiler has made significant changes to the ungrouped Full Adder design:

Ungrouped and Compiled Full Adder

Ungrouped and Compiled Full Adder. Note that the size of the drawing symbol in design schematic does not represent the actual size of the device. In fact, the cell U2 (HDAO22DL) is smaller than cells U1 and U3 (HDEXOR2D2).

Running e.g. the report_reference -hierarchy command indicates that this optimization has indeed reduced the area (the following excerpt includes only Full Adder 0):

design_vision-xg-t> report_reference -hierarchy
Information: Updating design information... (UID-85)
Report : reference
Design : adder_N4
Version: Z-2007.03-SP2
Date   : Thu Nov 22 16:38:51 2007

    b - black box (unknown)
   bo - allows boundary optimization
    d - dont_touch
   mo - map_only
    h - hierarchical
    n - noncombinational
    r - removable
    s - synthetic operator
    u - contains unmapped logic

Reference          Library       Unit Area   Count    Total Area   Attributes
HDDFFRPQ1          umcl18g212t3_tc_180V_25C
                                 54.834999       5    274.174995  n
HDTIELO            umcl18g212t3_tc_180V_25C
                                  6.451000       1      6.451000  
rca_N4                          296.756004       1    296.756004  h
Total 3 references                                    577.382000

Design: rca_N4 
Reference          Library       Unit Area   Count    Total Area   Attributes
fa_0                             74.189001       1     74.189001  h
fa_1                             74.189001       1     74.189001  h
fa_2                             74.189001       1     74.189001  h
fa_3                             74.189001       1     74.189001  h
Total 4 references                                    296.756004

Design: fa_0 
Reference          Library       Unit Area   Count    Total Area   Attributes
HDAO22DL           umcl18g212t3_tc_180V_25C
                                 22.579000       1     22.579000  
HDEXOR2D2          umcl18g212t3_tc_180V_25C
                                 25.805000       2     51.610001  
Total 2 references                                     74.189001

Compare the area of Full Adders reported with earlier reports (e.g. here). You may also check what other reporting commands (e.g. report_qor, report_timing, etc) can tell you about the new design. You should see that there are fewer levels of logic, timing has improved, and a small improvement in hold time violations, too.

From the results we may fill the synthesis results table:

DefaultUngroup FAs
Noncombinational Area/µm²274.17 274.17
Combinational Area/µm²367.71 303.20
Total Area/µm²641.89 577.38
Critical Path Slack/ns1.692.01
Total Negative Slack/ns0.0 0.0
Levels of Logic95
Leaf Cell Count2618

Example 2: Grouping

The previous example showed how to remove hierarchy on a design. This brief example shows how to add a level of hierarchy into your design.

First, lets remove the current design and load again the original compiled design (adder_N4_default_compiled.ddc):

remove_design -all
read_file -format ddc ./SYN/DDC/adder_N4_default_compiled.ddc

For the sake of an example let's group the flip-flops in a separate level of hierarchy:

group -design_name my_registers { s_reg* }

This will create a new level of hierarchy for the registers with the name my_registers as shown below:

Registers grouped into a separate level of hierarchy