You are on page 1of 37

Synthesis ABCs

Part 1

ABSTRACT
The Synthesis ABCs white paper provides information on how to perform
synthesis. Part 1 covers material such as basic synthesis flow, defining libraries,
using setup files, reading files, using Presto, and timing and area constraints.
Part 2 covers compile strategies, report generation, and writing files.

Both papers discuss great commands like analyze, elaborate, read_file,


report_timing, report_constraints, set_input_delay, set_output_delay, and
compile. Defining libraries using the link_library and target_library variables is
discussed along with a description of the .synopsys_dc.setup file. The
read_vhdl, read_verilog, and variable hdlin_enable_presto commands are
addressed. The compile and report_timing options are covered. Information on
clock commands, including create_clock, create_generated_clock,
set_clock_latency, set_propagated_clock, and set_clock_uncertainty , is
provided. Examples and figures are included throughout the papers.

1
Table of Contents

INTRODUCTION ............................................................................ 4
BASIC SYNTHESIS FLOW ......................................................... 4
CORRECT INPUT FILES ............................................................. 5
DEFINING LIBRARIES................................................................. 5
SYNOPSYS SETUP FILE ..................................................................................................... 6
Setup File Description ................................................................................................ 6
EFFICIENTLY READING FILES ................................................ 7
ANALYZE / ELABORATE VERSUS READ_FILE .................................................................... 7
analyze ........................................................................................................................ 7
Elaborate..................................................................................................................... 8
link Command ............................................................................................................. 9
read_file ...................................................................................................................... 9
Comparison............................................................................................................... 10
PRESTO ON VERSUS PRESTO OFF................................................................................... 10
Presto Variables........................................................................................................ 10
READ EXAMPLE .............................................................................................................. 11
hdlin_report_inferred_modules ................................................................................ 13
Generic Components................................................................................................. 14
FOCUSED CONSTRAINTS....................................................... 15
DESIGN ENVIRONMENT .................................................................................................. 15
Operating Conditions ............................................................................................... 15
Wire Load Models..................................................................................................... 18
Wire Load Model Example ....................................................................................... 19
System Interface ........................................................................................................ 21
CONSTRAINTS ................................................................................................................ 23
Timing ....................................................................................................................... 23
Area........................................................................................................................... 33
Design Rules ............................................................................................................. 33
UNUSUAL CLOCK CONSTRAINTS.................................................................................... 35
CONCLUSION .............................................................................. 37

2
TABLE OF FIGURES

Figure 1: Basic Synthesis Flow...................................................................................... 5


Figure 2: Analyze / Elaborate and Read_file Comparison ...................................... 10
Figure 3: Timing Constraint Commands..................................................................... 24
Figure 4: Divide-By-2 Clock.......................................................................................... 25
Figure 5: Clock Latency Example................................................................................ 26
Figure 6: Clock Definition Example ............................................................................. 27
Figure 7: set_input_delay Example ............................................................................. 29
Figure 8: set_output_delay Example .......................................................................... 30
Figure 9: Set_false_path Example .............................................................................. 32
Figure 10: Set_multicycle_path Example ................................................................... 33
Figure 11: Clock Constraint Example - 1.................................................................... 35
Figure 12: Clock Constraint Example - 2.................................................................... 36
Figure 13: Clock Constraint Example - 3.................................................................... 37
Figure 14: Clock Constraint Example -3 Timing Diagram ....................................... 37

3
Introduction
So you’re new to Design Compiler and have been assigned to do the synthesis
for the team. Where do you begin? Team members try to help by sending
example scripts, but upon review the scripts seem to be written in a foreign
language. All you want to know is how do I read in the files, what constraints do I
need, and how do I generate reports.

The goal of this paper is to provide you that information. The paper starts with
the synthesis flow and ends with writing files. Everything in between. including
reading files, preparing constraints, compiling, and report generation, is included.
Part 1 discusses the flow through constraint generation. Part 2 picks up with
compile techniques and ends with writing files.

Basic Synthesis Flow


First let’s talk about the big picture. The big picture describes the steps you need
to cover for synthesis. The first step is to specify what libraries you want to
synthesize with. Libraries are provided from library vendors. Typically, your
ASIC vendor will let you know which library to use.

Next you need to read in the files. The different methods for reading in files will
be covered along with comparisons of each. Once the files have been read, you
need to set constraints. When the constraints have been defined, you’ll need to
compile, analyze the results, and write out the synthesized netlist.

Figure 1 shows a basic synthesis flow. An explanation for each box is provided
in Parts 1 and 2 of Synthesis ABCs. The yellow boxes cover what you need to
know about getting the design into Design Compiler and preparing the design for
synthesis. The purple boxes cover how to compile the design, perform static
timing analysis, and write out necessary files.

4
HDL Files
Compile
Generation

Setup Generate
Libraries Reports

Reading
Write Files
Files

Building
Constraints

Figure 1: Basic Synthesis Flow

Correct Input Files


Usually the input files for Design Compiler are written in VHDL or Verilog. When
writing your HDL files, you’ll want to follow design partitioning and coding
guidelines to achieve the best synthesis results possible. Partitioning and coding
style directly affect the synthesis and optimization processes.

Before writing any code, invest some time collecting coding guideline resources.
See the Synopsys manuals HDL Compiler for VHDL Reference Manual and HDL
Compiler (Presto Verilog) Reference Manual. Also see the white paper available
on SolvNet called Fat-Free HDL (#006606) that contains guidelines along with
other coding guideline articles.

Another option is to look into using code checkers. One checker is called LEDA.
The LEDA tool is a programmable HDL checker that verifies that HDL code
complies with design rule and coding-style guidelines.

Even if you’re not writing the HDL code, it is still a good idea to understand
coding guidelines. This will allow you to quickly determine if a problem is in
synthesis or in the code.

Defining Libraries
For most people libraries are not an interesting topic, but every tool needs them
and Design compiler isn’t any different. You need to tell Design Compiler what

5
libraries to use when synthesizing your HDL code to gates. There are different
types of libraries with different definitions. For example, the link and target
libraries are technology libraries that define the semiconductor vendor’s set of
cells and related information, such as cell names, cell pin names, delay arcs, pin
loading, design rules, and operating conditions.

Another type of library is called the synthetic or DesignWare library. This library
is where your adders, multipliers, and so on come from. You do not need to
specify the standard synthetic library, standard.sldb, which implements the built-
in HDL operators; Design Compiler automatically uses this library. If you are
using additional DesignWare libraries, you must specify these libraries by using
the synthetic_library variable (for optimization purposes) and the link_library
variable (for cell resolution purposes).

To specify the link, target, symbol, and synthetic libraries you use the link_library,
target_library, symbol_library, and synthetic_library variables. These libraries are
normally placed in a setup file named .synopsys_dc.setup.

Synopsys Setup File


Here is an example of a setup file using a class library. A discussion of the file
follows.

# This is a Tcl-s script


# works for DC-SH, Design Vision, as well as for DC-Tcl

define_design_lib work -path ./work


set link_library {* ./class.db dw01.sldb dw02.sldb dw_foundation.sldb}
set target_library {./class.db}
set symbol_library {./class.sdb ./class.slib}

set search_path [list ./ ../LIB /remote/release/2003.03-2/libraries/syn]


set synthetic_library [list dw01.sldb dw02.sldb dw_foundation.sldb]

Setup File Description


• The file has been written in Tcl-s. Both dctcl and dcsh modes of
dc_shell understand Tcl-s.

• The lines starting with a pound sign (#) are comments.

• The define_design_lib command tells Design Compiler where you want


intermediate files written. This command is discussed in more detail
later.

• The set link_library command specifies the list of design files and
libraries used during linking. The asterisk (*) shown in the line tells

6
Design Compiler that the link command is to search all the designs
loaded in dc_shell while trying to resolve references. You should
always have this entry.

• The set target_library command specifies the list of technology libraries


of components to be used when compiling a design.

• The set symbol_library command specifies the symbol libraries to use


during schematic generation.

• The set search_path command allows you to tell Design Compiler what
directories it should search in to find files.

• The set synthetic_library command specifies a list of synthetic libraries


to use when compiling.

Efficiently Reading Files


One would think the easiest part of synthesis is to read in the HDL files. Wrong!
Why are there so many methods? I’m not really sure. But it is no mystery
reading files can be a source of confusion. And what about Presto? Should it be
on or off? What is presto anyway? The next few sections will cover these topics
with the final section going through an example.

analyze / elaborate Versus read_file


There are two methods to read files into Design Compiler. One is to use the
analyze/elaborate commands; the other is to use the command read_file. This
section describes how the commands work and includes a comparison between
the two.

analyze
The analyze command does the following:

• Reads an HDL source file and performs HDL syntax checking and
Synopsys rule checking.

• Checks file for errors without building generic logic for the design.

• Creates HDL library objects in an intermediate format.

7
• Stores the intermediate files in a location specified by you with the
define_design_lib command. For example:

define_design_lib work -path ./work

VHDL Intermediate Files


The intermediate files include .syn, .st, and .mr.

• *.syn files are binary files used by the elaborate command.

• *.st files store intermediate results.

• *.mr files stores most recent analyzed architecture for an entity. It


holds the names of the architectures used with an entity declaration.

Presto-Verilog Intermediate Files


When Presto is on, the default, the intermediate files include .pvl and .mr.

• *.pvl files store intermediate results

• *.mr files store module references.

Verilog Intermediate Files


When Presto is off, the intermediate files include %verilog.syn, .mr, and
%verilog_verilog.syn.

• %verilog.syn files are binary files used by the elaborate command.

• *.mr files store module references.

• %verilog_verilog.syn are binary files used by the elaborate command.

Elaborate
The elaborate command does the following:

• Translates the design into its GTECH representation.

• Allows changing of parameter values defined in the source code.

• Allows VHDL architecture selection.

8
• Replaces the HDL arithmetic operators in the code with DesignWare
components.

• Performs link automatically.

link Command
The link command is needed to locate all the designs and library components
and connects (links) them to the current design. Once this is done the design is
complete.

read_file
The read_file command does the following:

• Performs the same operations as analyze and elaborate in one step.

• It does not create any intermediate files for Verilog.

• Creates .mr and .st intermediate files for VHDL.

• It does not execute the link command automatically.

• Reads several different formats.

read_file Formats
The read_file command can read the following formats:

• db - Synopsys internal database format (the default)

• edif - Electronic Design Interchange format equation Synopsys


equation format

• lsi - LSI Logic Corporation netlist format

• mif - Mentor intermediate netlist format

• pla - Berkeley (Espresso) PLA format

• st - Synopsys State Table format

• tdl - Tegas Design Language (TDL) netlist format

9
• verilog - Cadence Design Systems, Inc. Hardware Description
Language

• VHDL - IEEE Standard VHDL

read_vhdl and read_verilog


The read_vhdl and read_verilog commands are derived from read_file –format
VHDL and read_file –format verilog, respectively.

Comparison
The following figure shows a comparison between the two commands.

Comparison read_file Command analyze / elaborate Commands


Input Formats All Formats VHDL, Verilog
When to use? Netlists, precompiled Synthesize VHDL or Verilog
designs, and so forth
Design Cannot store analyzed Can store analyzed results in
libraries results except in specified design libraries
design library WORK
Generics Cannot pass Allows you to set parameter
parameters (must use values on the elaborate command
directives in HDL) line
Architecture Can’t specify Allows you to specify architecture
architecture to be to be elaborated
elaborated

Figure 2: Analyze / Elaborate and Read_file Comparison

Presto On Versus Presto Off


Presto is an enhanced HDL reader. In most cases you will want to leave Presto
on because the HDL reader offers increased elaboration speed, increased
capacity, additional language construct support, and better quality of results. For
additional information, see the HDL Compiler (Presto Verilog) Reference Manual.
You can find the reference manual on the Web or on a SOLD CD.

Presto Variables
There are a couple of variables that control the Presto HDL reader. Brief
descriptions are shown below.

10
hdlin_enable_presto
This variable controls whether the two commands read and analyze use Presto
HDL Compiler for Verilog input files. When set to true (the default), the
commands use Presto HDL Compiler.

hdlin_enable_presto_for_vhdl
This variable is available as beta starting with version 2003.03. When set to true,
the read and analyze commands use the Presto HDL Compiler for VHDL input
files. The default is false.

read Example
Let’s go through an example so you can see what happens when you read in the
design. In this example, the command read_verilog is used to read in the Verilog
HDL code. The design consists of two sequential flip-flops.

Shown below is a copy of the Verilog HDL code used for this example.

module dff (in1, in2, clk1, clk2, out1, out2, reset_n);


input in1, in2, clk1, reset_n, clk2;
output out1, out2;
reg out1, out2;

always @ (posedge clk1 or negedge reset_n)


begin
if (reset_n == 0)
out1 <= 1'b0;
else
out1 <= in1;
end

always @ ( clk1)
begin
if (reset_n ==0)
out2 <= 1'b0;
else
out2 <= in2;
end
endmodule

Now let’s read the file into Design Compiler. Items of interest have been
highlighted.

11
dc_shell-t> read_verilog dff.v
Loading verilog file '/remote/scfs6/terrib/projects/testcase/tutoral/dff.v'
Detecting input file type automatically (-rtl or -netlist).
Reading with Presto HDL Compiler (equivalent to -rtl option).
Running PRESTO HDLC
Loading db file '/remote/release/2003.06/libraries/syn/standard.sldb'
Loading db file '/remote/release/2003.03-2/libraries/syn/dw01.sldb'
Loading db file '/remote/release/2003.03-2/libraries/syn/dw02.sldb'
Loading db file '/remote/release/2003.03-2/libraries/syn/dw_foundation.sldb'
Loading db file '/remote/release/2003.06/libraries/syn/gtech.db'
Loading db file '/remote/scfs6/terrib/projects/testcase/tutoral/class.db'
Compiling source file /remote/scfs6/terrib/projects/testcase/tutoral/dff.v

Inferred memory devices in process


in routine dff line 11 in file
'/remote/scfs6/terrib/projects/testcase/tutoral/dff.v'.
=============================================================
| Register Name | Type | Width | Bus | MB | AR | AS | SR | SS | ST |
=============================================================
| out1_reg | Flip-flop | 1 | N | N | Y | N | N | N | N |
=============================================================

Inferred memory devices in process


in routine dff line 20 in file
'/remote/scfs6/terrib/projects/testcase/tutoral/dff.v'.
=============================================================
| Register Name | Type | Width | Bus | MB | AR | AS | SR | SS | ST |
=============================================================
| out2_reg | Flip-flop | 1 | N | N | N | N | N | N | N |
=============================================================
Presto compilation completed successfully.
Current design is now '/remote/scfs6/terrib/projects/testcase/tutoral/dff.db:dff'
dff

Notice that in this example the command read_verilog was used to read in the
HDL code. To tell if Presto is turned on or not, look for a line similar to this:
Running PRESTO HDLC.

You’ll want to examine the lines that start with loading db. This will tell you what
libraries are being loaded.

If you have sequential elements in your design, look at the section called Inferred
memory devices in process. There will be tables showing the size and type of
your sequential elements. Check to see if a flip-flop or a latch was inferred.

12
The last item to note is the Current design. The current design will be set to the
last file read into Design Compiler. It is good practice to always set the current
design using the current_design command before executing any other
commands.

hdlin_report_inferred_modules
If you need additional information on registers, you might want to set variable
hdlin_report_inferred_modules to verbose. Using this variable you’ll get detailed
information on elements. Here is an example.

dc_shell-t> set hdlin_report_inferred_modules verbose


verbose
dc_shell-t> read_verilog dff.v
.
.

Inferred memory devices in process


in routine dff line 13 in file
'/remote/scfs6/terrib/projects/testcase/tutoral/dff.v'.
=============================================================
| Register Name | Type | Width | Bus | MB | AR | AS | SR | SS | ST |
=============================================================
| out1_reg | Flip-flop | 1 | N | N | Y | N | N | N | N |
=============================================================

Inferred memory devices in process


in routine dff line 22 in file
'/remote/scfs6/terrib/projects/testcase/tutoral/dff.v'.
=============================================================
| Register Name | Type | Width | Bus | MB | AR | AS | SR | SS | ST |
=============================================================
| out2_reg | Flip-flop | 1 | N | N | N | N | N | N | N |
=============================================================

Sequential Cell (out1_reg)


Cell Type: Flip-Flop
Multibit Attribute: N
Clock: clk_buf2
Async Clear: reset_n'
Async Set: 0
Async Load: 0
Sync Clear: 0
Sync Set: 0
Sync Toggle: 0
Sync Load: 1

13
Sequential Cell (out2_reg)
Cell Type: Flip-Flop
Multibit Attribute: N
Clock: clk_buf2
Async Clear: 0
Async Set: 0
Async Load: 0
Sync Clear: 0
Sync Set: 0
Sync Toggle: 0
Sync Load: 1

Do you see the additional information you can get with this variable?

Generic Components
When you read in the HDL code, you have an unmapped design, meaning that
you don’t have gates. Instead you have generic components called GTECH for
combinational logic and SEQGEN for sequential logic. You can see this by
executing the report_cell command. Here’s an example:

dc_shell-t> report_cell
Information: Updating design information... (UID-85)
Allocating blocks in 'dff'

****************************************
Report : cell
Design : dff
Version: 2003.06
Date : Wed Jul 9 07:29:05 2003
****************************************

Attributes:
b - black box (unknown)
c - control logic
h - hierarchical
n - noncombinational
r - removable
s - synthetic operator
u - contains unmapped logic

Cell Reference Library Area Attributes


--------------------------------------------------------------------------------
B_0 GTECH_BUF gtech 0.000000 c, u
C18 *SELECT_OP_2.1_2.1_1 0.000000 s, u

14
I_0 GTECH_NOT gtech 0.000000 u
I_1 GTECH_NOT gtech 0.000000 c, u
out1_reg **SEQGEN** 0.000000 n, u
out2_reg **SEQGEN** 0.000000 n, u
--------------------------------------------------------------------------------
Total 6 cells 0.000000

It is during the compile process that you will have gates.

Focused Constraints
Now that your design has been read into memory you need to define the design
environment and constraints. For the design environment you’ll want to tell
Design Compiler about things it doesn’t know anything about, such as what
operating conditions the chip will see, which wire load models should be used,
and system interface requirements. In addition Design Compiler needs to know
about area and timing constraints.

Design Environment
The design environment constraints consist of operating conditions, wire load
models, and system interface requirements. All areas are covered below.

Operating Conditions
The operating conditions consist of temperature, voltage, and process. The
effects each of these can have on the chip need to be considered during
synthesis and timing analysis. During timing analysis, Design Compiler must
consider the worst-case and best-case scenarios for the expected variations in
the temperature, voltage, and process factors. Here is a brief description of
each.

• Temperature – Temperature variation on a chip is a fact of life and


can’t be avoided. The effects on performance caused by temperature
fluctuations are usually handled as linear scaling effects, but some
submicron silicon processes require nonlinear calculations.

• Voltage – Having the design’s supply voltage vary from the ideal value
during day-to-day operation is normal. Often a complex calculation
(using a shift in threshold voltages) is used, but a simple linear scaling
factor is also used for logic-level performance calculations.

• Process - This variation accounts for deviations in the semiconductor


fabrication process. Usually process variation is treated as a
percentage variation in the performance calculation.

15
Operating Condition Example
Most libraries have default settings for operating conditions. To see what the
default conditions are you can use report_lib command, or if you have the .lib file
you can take a look at it in UNIX. Assuming you don’t have the .lib file, here is an
example of how to use the report_lib command.

Continuing with our “Read Verilog Example,” let’s see what libraries are loaded
into memory using the list_libs command.

dc_shell-t> list_libs
Logical Libraries:
-------------------------------------------------------------------------
Library File Path
------- ---- ----
standard.sldb standard.sldb /remote/release/2003.06/libraries/syn
dw01.sldb dw01.sldb /remote/release/2003.03-2/libraries/syn
dw02.sldb dw02.sldb /remote/release/2003.03-2/libraries/syn
dw_foundation.sldb dw_foundation.sldb /remote/release/2003.03-2/libraries/syn
gtech gtech.db /remote/release/2003.06/libraries/syn
class class.db /remote/scfs6/terrib/projects/testcase/tutoral

Looking at this list we can find the name of our library ‘class’. Now do a report_lib
to see what the default operating conditions are.

dc_shell-t> report_lib class

****************************************
Report : library
Library: class
Version: 2003.06
Date : Tue Jul 15 06:22:47 2003
****************************************
..
Operating Conditions:
Name Library Calc_mode Process Temp Volt Interconnect Model
----------------------------------------------------------------------------
WCCOM class 1.50 70.00 4.75 worst_case_tree
WCIND class 1.50 85.00 4.75 worst_case_tree
WCMIL class 1.50 125.00 4.50 worst_case_tree

...

16
From this report, you can see what the operating conditions are for Worst Case
Commercial (WCCOM), Worst Case Industrial (WCIND), and Worst Case Military
(WCMIL).

Normally you would let Design Compiler use the operating conditions specified in
the library as the default. If your library doesn’t have operating conditions or you
want to specify explicit operating conditions, which supersede the default library
conditions, you can use set_operating_conditions command as shown below.

dc_shell-t> set_operating_conditions WCCOM -lib class


Using operating conditions 'WCCOM' found in library 'class'.

It is always a good idea to check your constraints by using the report_design


command.

dc_shell-t> report_design
****************************************
Report : design
Design : dff
Version: 2003.06
Date : Tue Jul 15 06:48:43 2003
****************************************

...
Operating Conditions:

Name Library Calc_mode Process


Temp Volt Interconnect Model
----------------------------------------------------------------------------
WCCOM class 1.50 70.00 4.75 worst_case_tree

...

If you had run report_design prior to setting the operating conditions, you would
see that no operating conditions have been specified as shown:

...
Operating Conditions:

No operating conditions specified.


...

17
Wire Load Models
I find wire load model’s a confusing concept because I think in one’s and zero’s
not resistance and capacitance. But in any case, wire load modeling allows you
to estimate the effect of wire length and fanout on the resistance, capacitance,
and area of nets. Design Compiler uses these values to calculate wire delays
and design speeds.

Where do the wire load models come from? Normally the semiconductor
vendors will develop the models. If back-annotated wire delays are not available,
Design Compiler uses these wire load models to estimate net wire lengths and
delays. To determine which model to use, Design Compiler uses the following
factors:
• User specification.

• Automatic selection based on design area.

• Default specification in the technology library.

Hierarchical designs provide an additional challenge because Design Compiler


must also determine which wire load model to use for nets that cross hierarchical
boundaries. Design Compiler determines the wire load model for cross-hierarchy
nets based on one of the following factors:

• User specification.

• Default specification in the technology library.

• Default mode in Design Compiler

Hierarchical Wire Load Models


Design Compiler supports several modes for determining which wire load model
to use for nets that cross hierarchical boundaries. The modes Design Compiler
supports include top, enclosed, and segmented.

• Top – In this mode, Design Compiler models nets as if the design has
no hierarchy and uses the wire load model specified for the top level of
the design hierarchy for all nets in a design and its subdesigns.

• Enclosed – Design Compiler uses the wire load model of the smallest
design that fully encloses the net. Use enclosed mode if the design has
similar logical and physical hierarchies.

18
• Segmented – Design Compiler determines the wire load model of each
segment of a net by using the design encompassing the segment. Use
segmented mode if the wire load models in your technology file have
been characterized with net segments.

Wire Load Model Example


Now that you know what a wire load model is, how can you tell what you have?
Using the report_lib command again, you can find out this information.

dc_shell-t> report_lib class

****************************************
Report : library
Library: class
Version: 2003.06
Date : Thu Jul 17 11:53:48 2003
****************************************
Wire Loading Model:

Name : 05x05
Location : class
Resistance : 0
Capacitance : 1
Area : 0
Slope : 0.186
Fanout Length Points Average Cap Std Deviation
--------------------------------------------------------------
1 0.39

Name : 10x10
Location : class
Resistance : 0
Capacitance : 1
Area : 0
Slope : 0.311
Fanout Length Points Average Cap Std Deviation
--------------------------------------------------------------
1 0.53

Name : 20x20
Location : class
Resistance : 0
Capacitance : 1
Area : 0
Slope : 0.547

19
Fanout Length Points Average Cap Std Deviation
--------------------------------------------------------------
1 0.86

Wire Loading Model Selection Group:

Name : class

Selection Wire load name


min area max area
-------------------------------------------
0.00 1000.00 05x05
1000.00 2000.00 10x10
2000.00 3000.00 20x20

Wire Loading Model Mode: top.

Wire Loading Model Selection Group: class.

This report provides a lot of information. Let’s take a look at what it is telling you.

• The Wire Loading Model section tells you what wire load models are
available.

• When the Wire Loading Model Selection Group section is available,


this indicates that the library supports automatic area-based wire load
model selection.

• The Wire Loading Model Mode section identifies the default wire load
mode. If the library doesn’t have a default, then Design Compiler will
use the top mode.

• The Wire Loading Model Selection Group section tells which wire load
models will be user for specific areas.

If you need to change the wire load model or mode you can use commands
set_wire_load_model and set_wire_load_mode, respectively. Here is an
example:

dc_shell-t> set_wire_load_model -name "10x10"


Design dff: Using wire_load model '10x10' found in library 'class'.

dc_shell-t> set_wire_load_mode enclosed

20
Don’t forget to use the report_design command to see the changes. Notice the
highlighted areas.

dc_shell-t> report_design

****************************************
Report : design
Design : dff
Version: 2003.06
Date : Thu Jul 17 12:13:11 2003
****************************************
Wire Loading Model:

Selected manually by the user.

Name : 10x10
Location : class
Resistance : 0
Capacitance : 1
Area : 0
Slope : 0.311
Fanout Length Points Average Cap Std Deviation
--------------------------------------------------------------
1 0.53
...

Wire Loading Model Mode: enclosed.

System Interface
When constraining a design for synthesis; you need to tell Design Compiler
about items that are missing. In this case, all of the outside logic that will be
driving your ASIC or receiving signals from your ASIC is unknown. You have to
provide this information. Here are some of the items that need to be provided:

• Drive characteristics for input ports (input drive strength)

• Loads on input and output ports (capacitive load)

• Fanout loads on output ports

21
Input Drive Strength
By default, Design Compiler assumes zero drive resistance on input ports,
meaning infinite drive strength. To avoid this unrealistic approach, you can place
a driving cell on the input ports that will cause Design Compiler to calculate the
actual (nonzero) transition time on the input signal as though the specified library
cell was driving it.

You can do this by using the set_driving_cell command. This command allows
you to select a realistic external cell driving the input ports. For example:

set_driving_cell –lib_cell FD1 –pin Q [get_ports IN1]

If for some reason the input port drive capability can’t be modeled with a cell in
the technology library, you can use the set_drive and set_input_transition
commands. Together these commands can represent the drive resistance of the
top-level ports; however, they’re not as accurate for nonlinear models as the
set_driving_cell command is.

Capacitive Load
In order for Design Compiler to accurately calculate the timing of an output
circuit, you need to tell Design Compiler what the total capacitance driven by the
output cells will be. This needs to be done because, by default, the tool assumes
that the external load on the ports is zero. This information helps Design
Compiler select the correct cell drive strength of an output pad and helps model
the transition delay on input pads.

You can use the set_load command to specify the external capacitive load on
ports (inputs or outputs). You may specify a constant value or use the load_of
command to specify the external load as the pin load of a cell in your technology
library. Here are some examples.

• Constant value is specified.

set_load 5 [get_ports out1]

• Use load_of lib/cell/pin to place load of a gate form the technology


library on a port.

set_load [load_of my_lib/AN2/A] [get_ports out1]

set_load [expr [load_of my_lib/inv1a0/A] * 3] [get_ports out1]

22
Output Fanout Load
Take a look at the loads your outputs will be driving. You can model these loads
by using the set_fanout_load command. Using this command, Design Compiler
will try to make sure that the sum of the fanout load on the output port plus the
fanout load of cells connected to the output port driver is less than the maximum
fanout limit of the library, library cell, and design. Here’s an example:

set_fanout_load 4 [get_port out1]

Important: Fanout load is not the same as load in Design Compiler. Fanout load
is a unitless value that represents a numerical contribution to the total fanout.
Load is a capacitance value. Design Compiler uses fanout load primarily to
measure the fanout presented by each input pin. An input pin normally has a
fanout load of 1, but it can have a higher value.

Constraints
Let’s review. You’ve specified libraries and read in the HDL code. You’ve told
Design Compiler about the chip’s operating conditions and wire load models. And
you’ve specified system interface requirements. What’s missing? Well, we
haven’t indicated what clock speed the chip will be running at nor what size the
chip should be. We’ll address those now.

Timing
To accurately set up timing constraints, you need to tell Design Compiler about
the following:

• Clocks

• I/O timing requirements

• Combinational path delay requirements

• Timing exceptions

Figure 3 shows the commands you need to use for creating timing constraints.
These commands are discussed in more detail in the following sections.

Command Description
create_clock Use to generate a clock and define the period and
waveform.
create_generated_clock Use to define a generated clock in relation to a source
clock.

23
set_clock_latency Use these commands to tell Design Compiler about
set_propagated_clock the clock delay.
set_clock_uncertainty
set_input_delay Used to specify the timing requirements for input ports
relative to the clock period.
set_output_delay Used to specify the timing requirements for output
ports relative to the clock period.
set_max_delay Can be used to define maximum delay for
combinational paths.

(This is a timing exception command.)


set_min_delay Can be use to define minimum delay for combinational
paths.

(This is a timing exception command.)


set_false_path Use this command to specify false paths.

(This is a timing exception command.)


set_multicycle_path Use this command to specify multicycle paths.

(This is a timing exception command.)

Figure 3: Timing Constraint Commands

Clock Definition
The first constraint you need to be concerned with is defining all of your clocks.
Design Compiler needs to know what the source is for the clock and clock period.
In addition, you may want to include information such as the clocks duty cycle,
offset/skew, and clock name. To define a clock you use the command
create_clock. If you have an internally generated clock use the command
create_generated_clock. Let’s go through a few examples.

create_clock example

create_clock –period 10 [get_ports clk1]

The first command tells Design Compiler you have clock with a period of 10.
Because the –name option was not used, the clock gets the same name as the
clock source in this case, clk1. The clock will also have a 50 percent duty cycle
because a waveform was not specified.

This example creates a clock named clk2_in with a period of 10.0, a rise at 5.0,
and a fall at 9.5:

24
Create_clock –name clk2_in –period 10 –waveform {5.0 9.5} [get_ports
clk2]

Let’s say you have a divide-by-two clock generator as shown in the following
figure. Here is an example of how to constrain it.

U4
D Q DIVIDE

SYSCLK CLK QN

Figure 4: Divide-By-2 Clock

The following example creates a divide-by-2 clock. The clock name is DIVIDE,
and the source for the clock is SYSCLK.

create_generated_clock –name DIVIDE –source SYSCLK \


divide_by 2 [get_pins U4/Q]

Clock Latency and Uncertainty


What about clock latency and uncertainty? By default Design Compiler assumes
that clock networks are ideal (no delays). To change this behavior, you need to
use commands set_clock_latency and set_clock_uncertainty.

Uncertainty accounts for varying delays between the clock network branches.
There are two types of uncertainty: simple and interclock. Simple uncertainty
means that setup uncertainty and hold uncertainty applies to all paths to the
endpoint. Interclock uncertainty allows you to specify different skew between
various clock domains. The recommendation is to set the uncertainty to the worst
skew expected to the endpoint or between the clock domains. You can always
increase the value to account for additional margin for setup and hold.

This example specifies that all paths leading to registers or ports clocked by CLK
have setup uncertainty of 0.65 and hold uncertainty of 0.45.

set_clock_uncertainty -setup 0.65 [get_clocks CLK]

set_clock_uncertainty -hold 0.45 [get_clocks CLK]

25
Here is an example that specifies uncertainties between two clock domains.

set_clock_uncertainty 0.4 -from PHI1 -to PHI1

set_clock_uncertainty 0.4 -from PHI2 -to PHI2

set_clock_uncertainty 1.1 -from PHI1 -to PHI2

set_clock_uncertainty 1.1 -from PHI2 -to PHI1

Clock latency is the propagation time from the actual clock origin to the clock
definition point in the design. There are two types of clock latency: network and
source. Clock network latency is the time it takes a clock signal to propagate
from the clock definition point to a register clock pin. Clock source latency is the
time it takes for a clock signal to propagate from its actual waveform origin point
to the clock definition point in the design. Clock source latency in normally used
to model off-chip clock latency. The following figure shows the difference
between the two.

Clock Definition
Point ASIC

D Q

3ns 1ns CLK QN


Source Latency Network Latency
Orgin of clock

Figure 5: Clock Latency Example

Here is an example of how to use the set_clock_latency command:

set_clock_latency 1 [get_clocks CLK]

set_clock_latency –source 3 [get_clocks CLK]

set_propagated_clock
The set_propagated_clock command specifies that delays be propagated
through the clock network to determine latency at register clock pins. This
command should be used for post_route analysis. The benefit of using this

26
command is that propagated clocks will calculate network latency. The total
latency to the register will be the source + network latency.

Here is an example of how to use the set_propagated_clock command:

set_propagated_clock [get_clocks CLK]

Clock Definition –Example


Let’s go through a quick example. The figure below is the circuit that we need to
constrain. After reading in the file, we’ll set the clock constraints then review the
clocks using the report_clock command.

in1 out1
D Q
clk_2
D Q CLK QN

clk1 CLK QN

Figure 6: Clock Definition Example

dc_shell-t> create_clock -p 10 clk1

set_clock_uncertainty 0.5 [get_clocks clk1]

set_clock_latency 1 [get_clocks clk1]

set_clock_latency -source 3 [get_clocks clk1]

create_generated_clock -name clk_2 -source clk1 -divide_by 2 [get_pins


clk_2_reg/Q]

dc_shell-t> report_clocks
Information: Updating design information... (UID-85)

****************************************
Report : clocks
Design : divide_by2
Version: 2003.06-2
Date : Mon Aug 4 06:45:45 2003

27
****************************************

Attributes:
d - dont_touch_network
f - fix_hold
p - propagated_clock
G - generated_clock

Clock Period Waveform Attrs Sources


--------------------------------------------------------------------------
clk1 10.00 {0 5} d {clk1}
clk_2 20.00 {0 10} G {clk_2_reg/Q}
--------------------------------------------------------------------------

Generated Master Generated Waveform


Clock Source Source Modification
-------------------------------------------------------------------------
clk_2 clk1 {clk_2_reg/Q} divide_by(2)
-------------------------------------------------------------------------

Looking at the report generated using report_clock, you can see the clock names
clk1 and clk_2. The d and G indicate dont_touch_network and generated_clock
attributes have been set.

Additional information is provided for the generated clock such as the source and
type of waveform.

Now if you use report_clocks –skew, here is what you’ll get.

dc_shell-t> report_clocks -skew

****************************************
Report : clock_skew
Design : divide_by2
Version: 2003.06-2
Date : Mon Aug 4 06:47:19 2003
****************************************

Rise Fall Min Rise Min fall Uncertainty


Object Delay Delay Delay Delay Plus Minus
---------------------------------------------------------------------------
clk1 1.00 1.00 1.00 1.00 0.50 0.50

Max Source Latency Min Source Latency

28
Early Early Late Late Early Early Late Late
Object Rise Fall Rise Fall Rise Fall Rise Fall
-------------------------------------------------------------------------
clk1 3.00 3.00 3.00 3.00 3.00 3.00 3.00 3.00

By using this report you can check to see if the set_clock_uncertainty and
set_clock_latency commands were used correctly. Looking at rise delay, fall
delay and so on, we see a delay of 1ns. This delay came from the
command set_clock_latency 1 [get_clocks clk1].

Clock uncertainty is 0.5 and source latency is 3.0 ns. These delay values match
the commands that were used: set_clock_uncertainty 0.5 [get_clocks clk1] and
set_clock_latency -source 3 [get_clocks clk1].

I/O Timing Requirements


What about inputs and outputs? If you don’t constrain inputs and outputs,
Design Compiler assumes the signal arrives at the input ports at time 0 and does
not constrain any paths that end at an output port. The set_input_delay and
set_output_delay commands are used to constrain input and output ports.

Set_input_delay
The set_input_delay command is used to specify how much time is used by
external logic. Design Compiler then calculates how much time is left for the
internal logic. If you don’t’ use this command the tool will assume an input port
clock and pick a clock period. Let’s look at an example.

External Logic

ASIC
A
N delay D Q
D Q M delay

CLK QN
CLK QN
clk

T clk-q Tm Tn
T setup

Figure 7: set_input_delay Example

29
The delay for the external logic will be Tclk-q + Tm. The time remaining for
internal logic is Tn + Tsetup. So if Tclk-q + Tm = 7.4 ns, the clock period is 20ns,
and the flop has a 1 ns setup requirement, what is the maximum delay for Tn?
The calculation will be as shown. 20 ns – 7.4 ns – 1 ns = 11.6 ns. Here is what
the constraints would look like.

• create_clock –period 20 [get_ports clk]

• set_input_delay –max 7.4 –clock clk [get_ports A]

set_output_delay
The set_output_delay command is used to constrain the output paths. You need
to specify how much time the external log needs; then Design Compiler
calculates how much time is left for the internal logic. Here’s an example.
External Logic

ASIC

D Q B
S delay T delay D Q

CLK QN
CLK QN

clk
T setup
T clk-q Ts Tt

Figure 8: set_output_delay Example


The external delay equals Tsetup + Tt. The internal delay is Tclk-q + Ts. If the
external delay is 7 ns, Tclk-q is 1.0 ns, and the clock period is 20 ns, what is the
value of Ts? Ts would be 20 ns – 7 ns – 1 ns = 12 ns. Here is what the
constraints would look like:

• create_clock –period 20 [get_ports clk]

• set_output_delay –max 7.0 –clock clk [get_ports B]

Combinational path delay requirements


Now that our clocks have been defined and inputs and outputs are constrained,
what do we need to do for combinational paths? To constrain a purely
combinational path, you can use the set_max_delay and set_min_delay
commands.

30
Set_max_delay
The set_max_delay command allows you to specify the maximum path length for
any startpoint to any endpoint. Design Compiler will try to make the path less
than the delay value you set. For example if you want to optimize the design so
that any delay path to a port named Y is less than10, you would do the following:

set_max_delay 10.0 -to {Y}

Set_min_delay
The set_min_delay command allows you to specify the minimum path delay. If a
path violates the requirement given in a set_min_delay command, Design
Compiler adds delay to fix the violation if maximum delay cost is not increased.
For example if you want to specify that all paths from A1 and A2 to Z5 must be
greater than 4.0, here is what you would do.

set_min_delay 4.0 -from {A1 A2} -to Z5

Both of these commands (set_max_delay and set_min_delay) can be used to


override Design Compiler calculated timing requirements. For example, for a
path starting from a register at time 20 and arriving at a register where the next
active edge of the clock is at 35, Design Compiler would automatically calculate
the maximum path length as shown:

(35 - 20) - (library setup time of register at endpoint)

However, if a set_max_delay of 10 were applied to this path, Design Compiler


would calculate the max_path length as follows:

10 - (the library setup time of a register)

This overrides the original calculated maximum path length. Similarly, the
calculated minimum path length is equivalent to the library hold time for the
register at the endpoint, but a set_min_delay that is greater than that would
require that Design Compiler insert delays to meet the specification.

You can use the report_timing_requirements command to see the maximum and
minimum constraints.

31
Exceptions
Almost every design has exceptions. Exceptions can be false paths or multicycle
paths. The set_false_path command can be used to tell Design Compiler to
ignore the timing constraints on certain paths. This command is useful for
constraining asynchronous paths and logically false paths. Let’s look at an
example for an asynchronous path.

TOP

Block_A Block_B

D Q A D Q
B
CLKA

CLK QN CLK QN

CLKB

Figure 9: Set_false_path Example

In this example CLKA and CLKB are asynchronous to each other, so how do we
constrain it? First you want to define the clocks using create_clock, then tell
Design Compiler not to optimize logic crossing the clock domains by using
set_false_path.

• set_false_path –from [get_clocks CLKA] –to [get_clocks CLKB]

• set_false_path –from [get_clocks CLKB] -to [get_clocks CLKA]

Set_multicycle_path
The set_multicycle_path command is used to tell Design Compiler that you need
longer than a single clock cycle for a path. Using this command you can specify
how many clocks you will need. Let’s go through an adder example.

32
a_reg
D Q
a(63:0) <60ns
c_reg
CLK QN + D Q c(63:0)
b_reg
b(63:0) D Q CLK QN

CLK QN
clk

Figure 10: Set_multicycle_path Example


In this example the adder will take 6 clock cycles to finish. Here is how you
would constrain this circuit.

create_clock –period [get_clocks clk]

set_multicycle_path 6 –setup –to [get_pins c_reg[*]/D]

Important: The default hold check is always performed on the clock edge before
the setup check. In this example, the hold check would occur at 50ns.

Area
Area is another topic that needs to be covered. Design Compiler will perform
minimal area optimizations unless an area constraint is set. By using the
set_max_area command, you can constrain area.

Most designers set zero max area constraint. With the exception of runtime, this
won’t have any negative effect. Another option that may reduce runtime and
provide good quality of results is to set your maximum area to around 90 percent
of the minimum area. You can find the design’s minimum area by running simple
compile mode with no clock or timing constrains (set simple_compile_mode true;
compile). Here is an example of how to use the set_max_area command.

set_max_area 100

Design Rules
Your library vendor may impose design rules that restrict how many cells are
connected to one another based on capacitance, transition, and fanout. You

33
can override these rules using these commands: set_max_capacitance,
set_max_transition, and set_max_fanout.

Set_max_capacitance
If you need to control capacitance, you can use the set_max_capacitance
command. Using this command Design Compiler will try to make sure that the
capacitance value for a net is less than the value specified. The maximum value
for a net is defined as the least of the maximum capacitance values of the cell
pins and design ports on that net. Here is how you would use it.

set_max_capacitance 2.0 [get_ports test]

Set_max_transition
The transition time of a net is the time required for its driving pin to change logic
values. This time is based on the library data. For the nonlinear delay model
(NLDM), output transition time is a function of input transition and output load. If
you need to change this value, use the set_max_transition command.

set_max_transition 3.0 [get_ports example]

Set_max_fanout
The maximum fanout load for a net is the maximum number of loads
the net can drive. Design Compiler attempts to ensure that the sum of the
fanout_load attributes for input pins on nets driven by the specified ports or all
nets in the specified design is less than the given value set in the
set_max_fanout command.

The fanout load value does not represent capacitance; it represents the weighted
numerical contribution to the total fanout load. Let’s say you have two inverters
(inv1a1 and inv1a27). You can find the fanout_load attribute for each of these by
Using the get_attribute command.

get_attribute tech_lib/inv1a1/A fanout_load

get_attribute tech_lib/inv1a27/A fanout_load

Assume these commands return 0.25 and 3.00, respectively. Now if you have
the following

Set_max_fanout 6 [get_ports in1]

Design compiler can load port in1 with 6/.25 = 24 inv1a1 cells but can only load
port in1 with 6/3 = 2 inv1a27 cells.

34
Unusual Clock Constraints
This section goes through a few examples of how you would write constraints for
different types of circuits.

For this example the clock periods are clk1 = 30, clk2 = 20, clk3 = 10, and clk4 =
15. Skew for clk1 is 0.35 and clk2 is 0.40. Network delay is 0.5 and 0.6 for clk1
and clk2. Transition delay is 1.0 for both clk1 and clk2. Clocks clk3 and clk4 are
asynchronous to design top.

TOP
data_in data_out
D Q 2.5ns D Q
D Q D Q A D Q 3.0ns

clk3 CLK
CLK CLK CLK CLK clk4

clk1
clk2

Figure 11: Clock Constraint Example - 1

#Create clocks
create_clock –period 30 [get_ports clk1]
create_clock –period 20 [get_ports clk2]

#Generate virtual clocks for clk3 and clk4


create_clock –period 10 –name clk3
create_clock –period 15 –name clk4

#Constrain uncertainty, transition, and latency


set_clock_uncertainty 0.35 [get_clocks clk1]
set_clock_uncertainty 0.40 [get_clocks clk2]

set_clock_transition 1.0 [get_clocks “clk1 clk2”]

set_clock_latency 0.5 [get_clocks clk1]


set_clock_latency 0.6 [get_clocks clk2]

#Constrain inputs and outputs


set_input_delay 2.5 –clock clk3 [get_ports data_in]

35
set_output_delay 3.0 –clock clk4 [get_clocks data_out]

#Exceptions
set_false_path –from “clk3 clk4” –to “clk1 clk2”
set_false_path –from “clk1 clk2” –to “clk3 clk4”

The next example shows how to create a clock when you have a PLL. Because
Design Compiler treats the PLL as a black box, you will want to use
create_generated_clock on the output. The advantage of doing this is when you
propagate the clock created at the input clock pin of the clock that is also the
source clock, the tool will calculate the latency of the generated clock
automatically.

TOP
PLL
clki clki
clk_in rclk

Figure 12: Clock Constraint Example - 2

#Create clocks
create_clock -period 20.0 -name clk_in [get_pins PLL/rclk]

#Create Generated Clock for PLL


create_generated_clock -name clk1 -source clk_in -multiply_by 1 [get_pins
PLL/clki]

What happens when you need to divide a clock by 2 and have a negative clock
as the master? When you use the create_generated_clock command, Design
Compiler looks at the master clock and does the necessary divide by taking into
account the clock waveform you specified with create_clock. If you used
create_clock for clk1 and waveform is {0 5 10} and then divided-by 2 , the
waveform created using create_generated_clock would be {0 10 20}. The tool
doesn’t take into account the clock inversion. Here’s what you need to do.

36
U2
D Q clk2

clk1
CLK

Figure 13: Clock Constraint Example - 3

#Create clk
create_clock –period 10 [get_ports clk1]

#Create Generated Clock


create_generated_clock –name clk2 –source clk1 –edges {2 4 6} [get_pins U2/Q]

clk1

edges 1 2 3 4 5 6

time 0 5 10 15 20 25

clk2

Figure 14: Clock Constraint Example -3 Timing Diagram

Using the –edges option you can achieve the required edges with the
create_generated_clock command.

Conclusion
Congratulations, you have finished Part 1 of Synthesis ABCs. A lot of ground
was covered and there is more to come. Before continuing with Part 2, review
what you’ve learned and dig deeper into the commands. Using the figures and
examples, you should be able to set up your libraries, read in you files, and write
constraints.

37