Introduction

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.

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:

The tool supports only XG mode. Support for DB mode has been removed from the tool.

The tool supports only DCTCL command language. Support for DCSH command language has been removed from the 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.



                                          

Examples

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.

ha.vhd:
------------------------------------------------------------------------

-- Project: Design Compiler Tutorial
-- Author: Juha Pirttimäki
-- File: ha.vhd
-- Design: Half Adder
-----------------------------------------------------------------------
-- Description:
-- Half adder circuit
------------------------------------------------------------------------
-- File hierarchy:
-- ha.vhd
------------------------------------------------------------------------
-- Date By MODIFIED


-- 2010/1/9 prhtp Original
--------------------------------------------------------------


library ieee;
use ieee.std_logic_1164.all;
entity ha is
port (
a : in std_logic; -- input a
b : in std_logic; -- input b
s : out std_logic; -- sum bit
co : out std_logic -- carry bit
);
end ha;
architecture RTL of ha is
begin -- RTL
s <= a xor b;
co <= a and b;
end RTL;

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.

------------------------------------------------------------------------

-- Project: Design Compiler Tutorial
-- Author: Juha Pirttimäki
-- File: fa.vhd
-- Design: Full Adder
------------------------------------------------------------------------
-- Description:
-- Full adder circuit. This full adder instantiates two half adders (HA)
-- and a single OR gate.
------------------------------------------------------------------------
-- File hierarchy:
-- fa.vhd
-- + ha.vhd
------------------------------------------------------------------------
-- Date By MODIFIED
-- 2010/1/9 prthpns Original
------------------------------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;
entity fa is
port (
a : in std_logic; -- input bit a
b : in std_logic; -- input bit b
ci : in std_logic; -- carry in bit
s : out std_logic; -- sum bit
co : out std_logic -- carry out bit
);
end fa;
architecture RTL of fa is
-- Component and signal declarations
-- Half Adder
component ha
port (
a : in std_logic; -- input bit a
b : in std_logic; -- input bit b
s : out std_logic; -- sum bit
co : out std_logic -- carry out
);
end component;
-- Intermediate signals s_i, c1_i, c2_i
signal s_i : std_logic; -- interm. signal for ha_1 sum
signal c1_i : std_logic; -- interm. signal for ha_1 carry
signal c2_i : std_logic; -- interm. signal for ha_2 carry
begin -- RTL
i_ha_0: ha
port map (
a => a,
b => b,
s => s_i,
co => c1_i
);
i_ha_1: ha
port map (
a => ci,
b => s_i,
s => s,
co => c2_i
);
co <= c1_i or c2_i;
end RTL;

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.

adder.vhd

------------------------------------------------------------------------


-- Project: Design Compiler Tutorial

-- Author: Juha Pirttimäki

-- File: adder.vhd

-- Design: Generic Adder

------------------------------------------------------------------------

-- Description:

-- Generic adder circuit. This adder is an N bit instantation of the

-- RCA adder. The output of the circuit is registered.

-- NOTE: The carry in bit of the ripple carry adder is tied low. The

-- carry out bit is the Most Significant Bit (MSB; Nth bit) of the

-- output bus 's'.

------------------------------------------------------------------------

-- File hierarchy:

-- adder.vhd

-- + rca.vhd

-- + fa.vhd

-- + ha.vhd

------------------------------------------------------------------------

-- Date By MODIFIED

-- 2007/10/18 JP Original

------------------------------------------------------------------------



library ieee;

use ieee.std_logic_1164.all;



entity adder is



generic (

N : integer := 8 -- Bus width

);



port (

-- Global signals

rst_n : in std_logic; -- System reset

clk : in std_logic; -- System clock



-- I/O signals

a : in std_logic_vector(N-1 downto 0); -- input a

b : in std_logic_vector(N-1 downto 0); -- input b

s : out std_logic_vector(N downto 0) -- sum a+b

);



end adder;



architecture RTL of adder is



-- Component and Signal Declarations

component rca

generic (

N : integer -- Bus width

);

port (

a : in std_logic_vector(N-1 downto 0); -- input a

b : in std_logic_vector(N-1 downto 0); -- input b

ci : in std_logic; -- carry in

s : out std_logic_vector(N-1 downto 0); -- sum out

co : out std_logic -- carry out

);

end component;



-- Intermediate signal s_i

signal s_i : std_logic_vector(N downto 0);



begin -- RTL



i_rca: rca

generic map (

N => N

)

port map (

a => a,

b => b,

ci => '0',

s => s_i(N-1 downto 0),

co => s_i(N)

);



----------------------------------------------------------------------

-- purpose: Output s Registers

-- type : sequential

-- inputs : clk, rst_n

-- outputs: s

----------------------------------------------------------------------

outregs: process (clk, rst_n)

begin -- process outregs

if (rst_n = '0') then -- asynchronous reset (active low)

s <= (others => '0');

elsif (clk'event and clk = '1') then -- rising clock edge

s <= s_i;

end if;

end process outregs;



end RTL;



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:

 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.

                                                                                                                             contd.. next post

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.

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 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:

The Synopsys root directory (/admin/setup/) for system-wide settings

Your home directory ($HOME/) for user-defined settings

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 /libraries/syn, /dw/syn_ver, and /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.

Note that these libraries are tighly integrated into the Synopsys synthesis environment (i.e. they cannot be used with non-Synopsys synthesis tools).

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.

Note that in most cases the link library is the same as the target library.

The asterisk (*) in the link library variable tells that Design Compiler should first search the reference from the memory.

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 /libraries/syn, we can reference the UMC technology library and dw_foundation library just by their name.

Initialization

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.


Linux

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/syn.sh

Solaris

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/syn32.sh

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
eg. man set_clock_uncertainty
Ensure that your .synopsys_dc.setup etc. is valid for this version.
########################################################################