Syn Abc

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.
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
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
Introduction
So youre 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 lets 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, youll 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.
HDL Files Generation
Compile
Setup Libraries
Generate Reports
Reading Files
Write 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, youll 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 youre 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 isnt 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 vendors 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 builtin 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? Im 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.
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.
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
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 Input Formats When to use? Design libraries Generics Architecture read_file Command All Formats Netlists, precompiled designs, and so forth Cannot store analyzed results except in design library WORK Cannot pass parameters (must use directives in HDL) Cant specify architecture to be elaborated analyze / elaborate Commands VHDL, Verilog Synthesize VHDL or Verilog Can store analyzed results in specified design libraries Allows you to set parameter values on the elaborate command line Allows you to specify architecture to be 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
Lets 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 lets 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. Youll 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 youll 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 dont 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. Heres 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 youll want to tell Design Compiler about things it doesnt 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 cant 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 designs 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 dont have the .lib file, here is an example of how to use the report_lib command. Continuing with our Read Verilog Example, lets 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 doesnt 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: 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. ... Name
17
Wire Load Models

I find wire load models a confusing concept because I think in ones and zeros 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. Lets 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 doesnt 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
Dont 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 cant 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, theyre 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. Heres 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
Lets review. Youve specified libraries and read in the HDL code. Youve told Design Compiler about the chips operating conditions and wire load models. And youve specified system interface requirements. Whats missing? Well, we havent indicated what clock speed the chip will be running at nor what size the chip should be. Well 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 create_clock Description 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 set_propagated_clock set_clock_uncertainty set_input_delay set_output_delay set_max_delay
Use these commands to tell Design Compiler about the clock delay. Used to specify the timing requirements for input ports relative to the clock period. Used to specify the timing requirements for output ports relative to the clock period. Can be used to define maximum delay for combinational paths. (This is a timing exception command.) Can be use to define minimum delay for combinational paths. (This is a timing exception command.) Use this command to specify false paths. (This is a timing exception command.) Use this command to specify multicycle paths. (This is a timing exception command.)
set_min_delay
set_false_path set_multicycle_path
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. Lets 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] Lets 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 SYSCLK CLK Q QN
DIVIDE
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
3ns Source Latency Orgin of clock 1ns Network Latency
Q QN
CLK
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

Lets go through a quick example. The figure below is the circuit that we need to constrain. After reading in the file, well set the clock constraints then review the clocks using the report_clock command.
in1 D clk1 CLK Q QN clk_2
D CLK
Q QN
out1
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 youll 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 dont 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 dont use this command the tool will assume an input port clock and pick a clock period. Lets look at an example.
External Logic ASIC
D CLK
clk
Q QN
M delay
N delay
D CLK
Q QN
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. Heres an example.
External Logic ASIC
D CLK
clk T clk-q
Q QN
S delay
T delay
D CLK
Q QN
Ts
T setup 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. Lets look at an example for an asynchronous path.
TOP Block_A Block_B A B
D
CLKA
Q QN
D CLK
Q QN
CLK
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. Lets go through an adder example.
32
a_reg a(63:0) D CLK b(63:0) D CLK Q QN Q QN <60ns c_reg D CLK Q QN c(63:0)
b_reg
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 wont 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 designs 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. Lets 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 D clk3 Q

2.5ns
data_out Q D Q
A
3.0ns
CLK clk1 clk2
CLK
CLK
CLK
clk4
CLK
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 rclk clki
clk_in
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 doesnt take into account the clock inversion. Heres what you need to do.
36
U2
D clk1
clk2
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 time clk2 1 0 2 5 3 10 4 15 5 20 6 25
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 youve 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
Synthesis ABCs Part 2
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.
Table of Contents
INTRODUCTION ............................................................................ 4 BASIC SYNTHESIS FLOW ......................................................... 4 QUICK REVIEW ............................................................................. 5 GREAT COMPILES....................................................................... 6
COMPILE STRATEGIES ...................................................................................................... 7 Top-Down ................................................................................................................... 8 Bottom-Up Compile .................................................................................................... 9 Compile for Timing ................................................................................................... 12 Compile for Area....................................................................................................... 12 Compile for Runtime ................................................................................................. 13
HELPFUL REPORT GENERATION ........................................ 13

REPORTING VIOLATIONS ................................................................................................ 13 Big Violation ............................................................................................................. 13 Small Violation.......................................................................................................... 15 REPORT_TIMING ............................................................................................................. 15 Timing Paths ............................................................................................................. 15 Delay Calculation ..................................................................................................... 16 Default Options......................................................................................................... 17 Options to and -from............................................................................................... 19 -path full_clock ......................................................................................................... 21 -input_pins ................................................................................................................ 22 -delay max_rise......................................................................................................... 26 -net/-cap/-tran ........................................................................................................... 27 -max_paths, -nworst.................................................................................................. 28
IMPORTANT OUTPUT FILES .................................................. 33

WRITE COMMAND ......................................................................................................... 33 write_test_protocol ................................................................................................... 34
CONCLUSION .............................................................................. 34
TABLE OF FIGURES
Figure 1: Basic Synthesis Flow...................................................................................... 5 Figure 2: Top Down Design Flow .................................................................................. 9 Figure 3: Bottom-Up Script ........................................................................................... 11 Figure 4: Timing Paths .................................................................................................. 16 Figure 5: Path Groups ................................................................................................... 31
Introduction
Welcome to Part 2 of the Synthesis ABCs. In Part 1 you learned how to set up libraries, read in files, and generate constraints. In Part 2, well cover how to compile, generate reports, and write out necessary files. The goal of both papers is to help you get a clearer picture of how to do synthesis and to provide you with a starting point. Examples and figures are sprinkled throughout to aid in your understanding.
Basic Synthesis Flow

Lets 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, youll 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 the Synthesis ABCs Part 1 and Part 2 papers. 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.
HDL Files Generation
Compile
Setup Libraries
Generate Reports
Reading Files
Write Files
Building Constraints
Figure 1: Basic Synthesis Flow
Quick Review
Before discussing compile, lets quickly review what you learned in Part 1. The first step is to spend some time collecting information on coding guidelines even if you arent writing the code. The reason you want to do this is to aid with synthesis because there are times when it is necessary to rewrite the code. Knowing a few guidelines can help you accomplish this more quickly. The following resources will be helpful:. LEDA Code checker Fat-Free HDL SolvNet article #006606 Synopsys reference manuals.
Libraries need to be defined before reading in your code. The link_library, target_library, symbol_library, and synthetic_library variables need to be set to define your libraries. Typically these variable definitions are located in your .synopsys_dc.setup file. You can read in your code by using the analyze/elaborate or read_file commands. These commands behave differently so you should review
Part 1 to see the differences. Another good resource is the man pages for the commands. Once the code has been read in, you need to set constraints. Several constraints need to be written. For example, Design Environment Constraints Operating Conditions Wire Load Models
Timing and Area Constraints Timing Clocks I/O Timing Exceptions Area Design Rules
If any of this quick review is not clear, review key sections in Part 1 of the Synthesis ABCs.
Great Compiles
Once constraints have been defined, youre ready to optimize the design. The optimization process consists of three steps. 1. Architectural The architectural optimization, sometimes called high-level synthesis, works on the HDL code. Optimization is based on the constraints you set and on HDL coding style. This phase includes tasks such as sharing common subexpressions, sharing resources, and selecting DesgnWare components. These tasks, with the exception of DesignWare selection, occur on an unmapped design. After this optimization, the design is represented as GTECH library parts. 2. Logic Level The logic-level optimization is broken into two processes: structuring and flattening. Both of these processes work on a GTECH design. I like to think of this process as Boolean equation manipulation. a. Structuring Optimization during this phase is influenced by the constraints you set. This process adds intermediate variables and 6
logic structure to a design that can help reduce area. Design Compiler searches for subfunctions that can be factored out and evaluates these factors based on the size of the factor and number of times the factor appears in the design. Design Compiler turns the subfunctions that reduce the logic most into intermediate variables and factors them out of the design equations.
b. Flattening Here the goal is to convert combinational logic paths
into a sum-of-products representation. This conversion is independent of constraints. During this process, Design Compiler removes all intermediate variables from a design. This process increases CPU time and can increase area. 3. Gate Level It is during gate-level optimization that you have actual gates. This optimization has four processes: mapping, delay optimization, design rule fixing, and area optimization. a. Mapping This optimization phase uses gates from the specified library to generate the gate-level implementation of the design. b. Delay Optimization During this step, Design Compiler tries to fix delay violations that were introduced in the mapping phase. Design rule violations or area constraints are not addressed in this step. c. Design Rule Fixing The goal is to correct any design rule violations that were introduced by inserting buffers or resizing existing cells. Design Compiler tries to fix these violations without affecting timing and area results. d. Area Optimization The final step is to meet area constraints. By default, Design Compiler does not allow area recovery to introduce design rule or delay constraint violations to meet the area constraint. Logic- and gate-level optimizations are performed by using the compiler command. Compile stops when all the constraints have been met, Design Compiler reaches a point of diminishing returns, or the user interrupts compile. When the compile stops, you have a gate-level presentation of your design. At this point, you should write out a Synopsys database (.db) file. How to do this is discussed in section called Important Output Files.
Compile Strategies
The two most popular compile strategies are top-down or bottom-up. Other strategies include compile for timing, area, and runtime. Because several
SolvNet articles are available that discuss each of these strategies in detail, they will be discussed only briefly here.
Top-Down
The limiting factors for top-down complies are available memory and time. A general guideline is that if the compile takes longer than a day, you should consider breaking the design into smaller blocks. Here are the advantages of doing this: Push-button approach Automatically takes care of inter-block dependencies. Fewer scripts to write and maintain. The scripts are easier to understand and migrate to other designs. Design Compiler sees across the hierarchy and accurately computes the delays, loads, fanout, and so on.
Top-Down Flow Figure 2 shows an example of a top-down flow and script. The uniquify command used in the flow removes multiply-instantiated hierarchy in the current design by creating a unique design for each cell instance.
Top Down Flow Read in entire design Script # read in the entire design read -f verilog E.v read -f verilog D.v read -f verilog C.v read -f verilog B.v read -f verilog A.v read -f verilog TOP.v current_design TOP link # resolve multiple references uniquify #apply constraints and attributes source constraints.con # compile the design compile
Resolve multiple instances of any design references.
Apply Constraints
Compile
Figure 2: Top Down Design Flow
Bottom-Up Compile
You should use a bottom-up approach for larger designs. Here are some advantages: Requires less memory. Compiles large designs by using the divide-and-conquer approach Quickly identifies the critical paths for possible recoding.
Bottom-Up Flow A bottom-up flow requires a lot more time than a top-down approach. Here are the required steps, including suggested steps to follow if timing is not met: 1. Generate a default constraint file and subdesign-specific constraint files. The default constraint file should include global constraints, such as the
clock information and the drive and load estimates. The subdesignspecific constraint files reflect the time budget allocated to the subblocks. 2. Compile the subdesigns independently. 3. Read in the top-level design and any compiled subdesigns not already in memory. 4. Set the current design to the top-level design, link the design, and apply the top-level constraints. If the design meets its constraints, congratulations you can stop here. Otherwise, continue with the following steps. 5. Apply the characterize command to the cell instance with the worst violations. The characterize command captures information about the environment of specific cell instances, and assigns the information as attributes on the design to which the cells are linked. 6. Use write_script to save the characterized information for the cell. You can then use this script to re-create the new attribute values when you are recompiling the cells referenced subdesign. The write_script command writes Design Compiler commands to save the current settings. 7. Use remove_design -all to remove all designs from memory. The remove_design command acts like its name. It removes the design. 8. Read in the RTL design of the previously characterized cell. Recompiling the RTL design instead of the cells mapped design usually leads to better optimization. 9. Set current_design to the characterized cells subdesign and recompile, using the saved script of characterization data. 10. Read in all other compiled subdesigns. 11. Link the current subdesign. 12. Choose another subdesign, and repeat steps 3 through 9 until you have recompiled all subdesigns, using their actual environments.
10
Figure 3 shows an example script. The side in purple is the portion of the script you would need if you had timing violations.
Bottom-Up Script
set all_blocks {E,D,C,B,A} #compile each subblock independently foreach (block, all_blocks) { #read in block set block_source block + ".v" read_file -format verilog block_source current_design block link uniquify #apply global attributes and constraints source constraints.con #apply block attributes and constraints set block_script block + ".con" source block_script #compile the block compile } #read in entire compiled design read_file -format verilog TOP.v current_design TOP link write -hierarchy -output first_pass.db #apply top-level constraints source constraints.con source top_level.con #check for violations report_constraint
# characterize all instances in the design set all_instances {U1,U2,U2/U3,U2/U4,U2/U5} characterize -constraint all_instances # save characterize information foreach (block, all_blocks) { current_design block set char_block_script block + ".wscr" write_script > char_block_script } # recompile each block foreach (block, all_blocks) { # clear memory remove_design -all # read in previously characterized subblock set block_source block + ".v" read -format verilog block_source # recompile subblock current_design block link uniquify #apply global attributes and constraints source defaults.con # apply characterization constraints ser char_block_script block + ".wscr" include char_block_script # apply block attributes and constraints set block_script block + ".con" source block_script # recompile the block compile }
Figure 3: Bottom-Up Script
11
Compile for Timing

If your timing is critical, here are some things to consider. Ungroup unnecessary hierarchies Use the group_path command and virtual clocks to isolate input/output paths Use DC-Ultra and DesignWare Foundation
Compile for Area

If your design is area sensitive, check the following: 1. Understand your designs minimum area. You can find the designs minimum area by running simple compile mode with no clock or timing constrains. For example, set simple_compile_mode true compile 2. Ungroup smaller blocks to allow shared optimization across boundaries. 3. When area is critical, you should tell Design Compiler. You can do this by using the set_max_area area_constraint [-ignore_tns] command. The -ignore_tns option specifies that area is to be prioritized above total negative slack 4. Using the compile area_effort high or map_effort high commands enables the gate composition algorithm to further reduce the number of cells. 5. You can use the compile auto_ungroup area command to automatically ungroup small blocks during compile. 6. Try setting the compile_sequential_area_recovery variable to true to remap all sequential cells to try and recover area. 7. To reduce area, use Boolean structuring to take advantage of dont cares and redundancy by doing the following: set compile_new_boolean_structure true
12
8. To delete registers that have constraints on the outputs, do the following: set compile_seqmap_propagate_constraints true
Compile for Runtime

Is runtime your enemy? Here are some suggestions to improve runtime. Design hierarchy can impact synthesis runtime and QOR, so if possible ungroup unnecessary hierarchical instances. Check your timing and design rule constraints. Setting timing exceptions by using wildcards, for example, can impact runtime. Critical range setting can also impact runtime. Use Presto Verilog for elaboration to reduce runtime. Presto Verilog is on by default. Try using simple compile mode if you know your blocks will meet timing. Set simple_compile_mode true.
Helpful Report Generation

What happens when you dont meet timing and how do you know you have not met timing? Well address those questions plus more in this section.
Reporting Violations
A good starting point is to use the report_constraint all_violators command. This command reports all the constraints that have been violated in the design, which includes design rules, setup, hold, and area. When you generate a report, you should notice whether you have big or small violations. A 10 percent or less violation is considered small. Here is an example report.
Big Violation
Lets look at the following report. dc_shell-t> report_constraint -all Information: Updating design information... (UID-85) ****************************************
13
Report : constraint -all_violators Design : dff Version: 2003.06-2 Date : Fri Aug 15 06:56:21 2003 **************************************** max_delay/setup ('clk1' group) Required Actual Endpoint Path Delay Path Delay Slack ----------------------------------------------------------------out2 0.00 0.39 r -0.39 (VIOLATED) In this report we see that the require path delay is 0 ns and the actual path delay is 0.39 ns. What can we do? Running another compile might not help unless you change something. Here are some things to check. 1. Modify the constraints. You need to make sure your constraints are realistic. 2. Check the design partition. If possible, try to ungroup unnecessary subblocks. 3. Change the set_structure, compile_new_boolean_structure, or set_flatten options. a. Set_structure By default, Design Compiler structures your design. You can use this command to set various structure attributes on a design to determine how the designs are structured during compile. b. compile_new_boolean_structure When the compile_new_boolean_structure variable is set to true (the default is false), it turns on the new Boolean (non-algebraic) structure optimization in the structuring phase of compile. c. Set_flatten By default, Design Compiler does not flatten your design. You can use the set_flatten command to control this behavior. 4. Recompile using a higher effort. The compile map_effort [low | medium | high] command controls how hard Design Compiler works on the critical path during gate-level optimization.
14
a. Low shouldnt be used for production work or as starting point for other optimizations. b. Medium You should always start here (the default). Using medium effort typically produces good results. c. High Using a high effort activates additional algorithms. Be warnedthis is very CPU intensive. 5. Change the HDL source code. Sometimes it is necessary to change the HDL source code.
Small Violation
What about small violations? In addition to the techniques described above, try these options: Try an incremental compile. You can use the compile incremental_mapping command to do only a gate-level optimization, making it faster than a normal compile. The design is not taken back to a GTECH level and no logic-level optimization is done, but DesignWare implementations might be changed. Use incremental compile with a high map effort (compile inc map high). Using this command activates additional algorithms that can be helpful. Use set_critical_range and compile inc. If a critical range is used, Design Compiler works on more endpoints than just the most critical one. Therefore if the most critical endpoint cant be further improved, Design Compiler moves on to the next endpoint.
report_timing
The report_timing command is another useful tool for checking violations and timing of particular paths. If you look at all the options available for this command, they can be confusing. This section describes a few of the options and when you might use them. But before checking the options more closely, lets discuss timing paths and how delays are calculated.
Timing Paths
Timing analysis involves breaking a design down into sets of timing paths then calculating the delay for each path. There are four types of timing paths as seen in the following figure.
15
path 1 A CLK
ASIC
Q
path 3
Q
path 4
CLK
path 2
CLK
Figure 4: Timing Paths The four paths are Path 1 Primary input to D input of sequential cell. Path 2 Primary input to primary output. Path 3 Clock to D input of next sequential cell. Path 4 Clock to primary output.
Notice that each path has a startpoint and endpoint. Valid startpoints are input ports and clock pins of flip-flops of designs. Valid endpoints are output ports and all input pins except clock pins of sequential devices.
Delay Calculation
Timing reports are broken into two sections: one for calculating the data arrival time and the other for calculating the data required time. The end result, called slack, is the timing margin. A negative number indicates a violation. The slack calculations for setup and hold checks are different. Here are the formulas: Setup slack = data required time data arrival time Hold slack = data arrival time data required time
What about calculations for data arrival and required time? There are four basic timing paths. The data arrival and required times are calculated differently, depending on the type of path being looked at. Lets take a look. 1. Path from a primary input port to a sequential device. 16
a. Data arrival time = clock_latency + input_delay + cell/net_delay b. Data setup required time = clock_period + clock_latency -clock_uncertainty - cell_setup_time c. Data hold required time = clock_latency + clock_uncertainty +cell_hold_time 2. Path from a sequential device to a sequential device. a. Data arrival time = clock_latency + cell/net_delay b. Data setup required time = clock_period + clock_latency clock_uncertainty cell_setup_time c. Data hold requirement time = clock_latency + clock_uncertainty +cell_hold_time 3. Path from a sequential device to a primary output port. a. Data arrival time = clock_latency + cell/net_delay b. Data setup required time = clock_period + clock_latency -clock_uncertainty -output_delay c. Data hold required time = clock_latency + clock_uncertainty -output_delay 4. Path from a primary input port to a primary output port. a. Data arrival time = clock_latency + input_delay + cell/net_delay b. Data setup required time = clock_period + clock_latency -clock_uncertainty -output_delay c. Data hold required time = clock_latency + clock_uncertainty -output_delay
Default Options
Lets go through a report that is generated when no options are used. Notice that by default, a full path is reported, max delay is used, and one path is shown per path group.
17
When you see delay max, then you know this report is for a setup check. If the delay was set to min, then you would be seeing a hold time report. dc_shell-t> report_timing **************************************** Report : timing -path full -delay max -max_paths 1 Design : dff Version: 2003.06-2 Date : Wed Aug 20 13:07:29 2003 **************************************** Operating Conditions: Wire Load Model Mode: top Startpoint: out2_reg (rising edge-triggered flip-flop clocked by clk1) Endpoint: out2 (output port clocked by clk1) Path Group: clk1 Path Type: max Des/Clust/Port Wire Load Model -----------------------------------------------dff 05x05 class Library
Point Incr Path ----------------------------------------------------------clock clk1 (rise edge) 0.00 0.00 clock network delay (ideal) 0.00 0.00 out2_reg/CP (FD1S) 0.00 0.00 r out2_reg/Q (FD1S) 1.39 1.39 f out2 (out) 0.00 1.39 f data arrival time 1.39 clock clk1 (rise edge) 10.00 10.00 clock network delay (ideal) 0.00 10.00 clock uncertainty -1.00 9.00 output external delay -2.00 7.00 data required time 7.00 ----------------------------------------------------------data required time 7.00 data arrival time -1.39
18
----------------------------------------------------------slack (MET) 5.61 From this report you can find out information about what Operating Conditions are being used, which Library is used, and how the Wire Load Model Mode is set. Youll also want to observe the Startpoint, Endpoint, and Path Group. Remember valid startpoints are primary inputs and clock pins on sequential elements. Valid endpoints are all input pins except clock pins of sequential cells and primary output ports. Here is how the slack was calculated. This path is from a sequential device to a primary output port, so the calculation is as follows. 1. Data arrival time = clock_latency + cell/net_delay 1.39 = 0.0 + 1.39 2. Data Setup required time = clock_period + clock_latency -clock_uncertainty - output_delay 7.00 = 10.00 +0.00 1.00 2.00 3. Setup Slack = data required time data arrival time 5.61 = 7.00 1.39 Where did the clock uncertainty (-1.00) and output external delay (-2.00) come from? These constraints are set by using the set_clock_uncertainty and set_output_delay commands.
Options to and -from

The to and from options are quite handy when you know you want timing to a particular start or end point. When these options are used, the report will contain only the paths to the named pins, ports, or clocks. The default behavior is to report the longest path to an output port if the design doesnt have constraints. If the design does have timing constraints, then the default is to report the path with the worst slack within each path group. dc_shell-t> report_timing -to out1_reg/D **************************************** Report : timing
19
-path full -delay max -max_paths 1 Design : dff Version: 2003.06-2 Date : Wed Aug 20 13:15:28 2003 **************************************** Operating Conditions: Wire Load Model Mode: top Startpoint: in1 (input port clocked by clk1) Endpoint: out1_reg (rising edge-triggered flip-flop clocked by clk1) Path Group: clk1 Path Type: max Des/Clust/Port Wire Load Model Library -----------------------------------------------dff 05x05 class Point Incr Path ----------------------------------------------------------clock clk1 (rise edge) 0.00 0.00 clock network delay (ideal) 0.00 0.00 input external delay 1.00 1.00 f in1 (in) 0.00 1.00 f U6/Z (IBUF2) 0.84 1.84 f out1_reg/D (FD2) 0.00 1.84 f data arrival time 1.84 clock clk1 (rise edge) 10.00 10.00 clock network delay (ideal) 0.00 10.00 clock uncertainty -1.00 9.00 out1_reg/CP (FD2) 0.00 9.00 r library setup time -0.85 8.15 data required time 8.15 ----------------------------------------------------------data required time 8.15 data arrival time -1.84 ----------------------------------------------------------slack (MET) 6.31 The endpoint in the above timing diagram is the endpoint specified in the report_timing command.
20
-path full_clock
When you want to see the clock network, use the -path full_clock option. When you use this option, youll see the full clock paths for propagated clocks. To see the path, you need to propagate the clocks first before using this option. Here is an example. dc_shell-t> set_propagated_clock [get_clocks clk1] dc_shell-t> report_timing -path full_clock **************************************** Report : timing -path full_clock -delay max -max_paths 1 Design : dff Version: 2003.06-2 Date : Wed Aug 20 13:23:41 2003 **************************************** Operating Conditions: Wire Load Model Mode: top Startpoint: out2_reg (rising edge-triggered flip-flop clocked by clk1) Endpoint: out2 (output port clocked by clk1) Path Group: clk1 Path Type: max Des/Clust/Port Wire Load Model -----------------------------------------------dff 05x05 class Library
Point Incr ----------------------------------------------------------clock clk1 (rise edge) 0.00 clk1 (in) 0.00 U8/Z (IBUF2) 0.68 U2/Z (IBUF1) 0.85 out2_reg/CP (FD1S) 0.00 out2_reg/CP (FD1S) 0.00 out2_reg/Q (FD1S) 1.39 out2 (out) 0.00 data arrival time clock clk1 (rise edge) clock network delay (propagated) 10.00 0.00
Path 0.00 0.00 r 0.68 r 1.53 r 1.53 r 1.53 r 2.92 f 2.92 f 2.92 10.00 10.00
21
clock uncertainty -1.00 output external delay -2.00 data required time ----------------------------------------------------------data required time data arrival time ----------------------------------------------------------slack (MET)
9.00 7.00 7.00 7.00 -2.92 4.08
The set_propagated_clock command tells Design Compiler to propagate the delays through the clock network to determine latency at register clock pins. By looking at this report, you can see that the additional paths through buffers U8/Z (IBUF2) and U2/Z (IBUF1) have been included. Youll want to use this command after layout when your clock tree has been inserted. You can tell this report is for a full clock by looking at the header (-path full_clock). Notice that propagated is called out in parentheses beside clock network delay: clock network delay (propagated). This tells you that the clock has been propagated instead of using ideal clock. If the set_propagated_clock command has not been used, ideal clocking is assumed. Ideal clocking means that clock networks have a specified latency (from the set_clock_latency command) or zero latency (by default).
-input_pins
This useful option allows you to look at cell and net delays separately. Although using the -input_pins option can result in long reports, it is a good way to ensure that you have the correct pins when you use report_delay_calculation to collect additional information. The input_pins option tells Design Compiler to show input pins in the path report (the default is to show only output pins). In addition, this option shows the delays of the nets connected to these pins. For example, dc_shell-t> report_timing -to out1_reg/D -input_pins **************************************** Report : timing -path full -delay max -input_pins -max_paths 1 Design : dff
22
Version: 2003.06-2 Date : Wed Aug 20 13:17:04 2003 **************************************** Operating Conditions: Wire Load Model Mode: top Startpoint: in1 (input port clocked by clk1) Endpoint: out1_reg (rising edge-triggered flip-flop clocked by clk1) Path Group: clk1 Path Type: max Des/Clust/Port Wire Load Model -----------------------------------------------dff 05x05 class Library
Point Incr Path ----------------------------------------------------------clock clk1 (rise edge) 0.00 0.00 clock network delay (ideal) 0.00 0.00 input external delay 1.00 1.00 f in1 (in) 0.00 1.00 f U6/A (IBUF2) 0.00 1.00 f U6/Z (IBUF2) 0.84 1.84 f out1_reg/D (FD2) 0.00 1.84 f data arrival time 1.84 clock clk1 (rise edge) 10.00 10.00 clock network delay (ideal) 0.00 10.00 clock uncertainty -1.00 9.00 out1_reg/CP (FD2) 0.00 9.00 r library setup time -0.85 8.15 data required time 8.15 ----------------------------------------------------------data required time 8.15 data arrival time -1.84 ----------------------------------------------------------slack (MET) 6.31 If you look at the header of the report, you can see that -input_pins has been included. It is a good idea to check the header before analyzing a report so you know what youre looking at. In this report, you can see that the input signal (in1 (in)) passes through a buffer (U6/A (IBUF2)), and you can see the pins on the buffer (U6/Z (IBUF2)) to the D
23
pin of a flip-flop. How can this information be used? Lets assume the delay through the buffer is quite large and you want to know why. One way to find out is to use the report_delay_calculation command. report_delay_calculation The report_delay_calculation command displays the actual timing arc calculation delay for a cell or net. For example, dc_shell-t> report_delay_calculation -from U6/A -to U6/Z **************************************** Report : delay_calculation Design : dff Version: 2003.06-2 Date : Tue Aug 26 06:13:07 2003 **************************************** From pin: To pin: U6/A U6/Z
Operating Conditions: Wire Load Model Mode: top Design Wire Load Model Library -----------------------------------------------dff 05x05 class arc sense: positive_unate arc type: cell Input net transition times: Dt_rise = 0, Dt_fall = 0 Rise Delay computation: rise_intrinsic 0.48 + rise_slope * Dt_rise 0*0+ rise_resistance * (pin_cap + wire_cap) / driver_count 0.1443 * (1 + 0.39) / 1 -----------------------------------------Total 0.680577 Fall Delay computation: fall_intrinsic 0.77 + fall_slope * Dt_fall 0*0+ fall_resistance * (pin_cap + wire_cap) / driver_count
24
0.0523 * (1 + 0.39) / 1 -----------------------------------------Total 0.842697 Transition calculations rise_resistance * (pin_cap + wire_cap) / driver_count 0.1443 * (1 + 0.39) / 1 = 0.200577 fall_resistance * (pin_cap + wire_cap) / driver_count 0.0523 * (1 + 0.39) / 1 = 0.072697 The report_delay_calculation report contains a lot of information. This document will address only some of the information. For more information, see the SolvNet articles available on the web. You should verify that this is the correct report by checking the From pin and To pin entries. This is similar to a report_timing report, because you can see which Operating Conditions, Wire Load Model, and Library are used. The next section covers information about the arc sense, arc type, and the input net transition times. Youll find the information about how the delay was calculated in the computation sections. In the timing report, look at the delay that was used for the buffer: U6/Z (IBUF2) 0.84 1.84 f
The f stands for falling edge. With this knowledge, look back at the report_delay_calculation report and find the Fall Delay computation section. Notice that the calculated value is 0.842697. This matches the number used in report timing. The last sections describe how rise and fall Transition calculations are calculated. Where does all this data come from? The answer is, your library. If you have a .lib file, you can take a look at it and find the information shown when using report_delay_calculation.
25
-delay max_rise
You should usedelay max_rise/max_fall/min_rise/min_fall to see a specific path leading to a required transition. This option tells Design Compiler the path type at the endpoint. If this option is not used, the default is max. dc_shell-t> report_timing -delay max_rise **************************************** Report : timing -path full -delay max_rise -max_paths 1 Design : dff Version: 2003.06-2 Date : Wed Aug 20 13:18:21 2003 **************************************** Operating Conditions: Wire Load Model Mode: top Startpoint: out2_reg (rising edge-triggered flip-flop clocked by clk1) Endpoint: out2 (output port clocked by clk1) Path Group: clk1 Path Type: max Des/Clust/Port Wire Load Model -----------------------------------------------dff 05x05 class Library
Point Incr Path ----------------------------------------------------------clock clk1 (rise edge) 0.00 0.00 clock network delay (ideal) 0.00 0.00 out2_reg/CP (FD1S) 0.00 0.00 r out2_reg/Q (FD1S) 1.15 1.15 r out2 (out) 0.00 1.15 r data arrival time 1.15 clock clk1 (rise edge) 10.00 10.00 clock network delay (ideal) 0.00 10.00 clock uncertainty -1.00 9.00 output external delay -2.00 7.00 data required time 7.00 ----------------------------------------------------------data required time 7.00 data arrival time -1.15
26
----------------------------------------------------------slack (MET) 5.85 Notice again the header. This time a max_rise path is used. This report tells you what the maximum path is for a rising edge to the end point. You can see the r in the path.
-net/-cap/-tran
Sometimes you need information on nets. You can get this information by using the -net/-cap/-tran options. nets: This option tells Design Compiler to show nets in the path report. If you want to see the delays for the nets, use the input_pins option as well. -transition_time: This option shows the net transition time for each driving pin in the path. capacitance: Use this option when you want to see the total (lump) capacitance in the report. dc_shell-t> report_timing -net -trans -cap **************************************** Report : timing -path full -delay max -nets -max_paths 1 -transition_time -capacitance Design : dff Version: 2003.06-2 Date : Wed Aug 20 13:20:30 2003 **************************************** Operating Conditions: Wire Load Model Mode: top Startpoint: out2_reg (rising edge-triggered flip-flop clocked by clk1) Endpoint: out2 (output port clocked by clk1) Path Group: clk1 Path Type: max Des/Clust/Port Wire Load Model -----------------------------------------------Library
27
dff
05x05
class
Point Fanout Cap Trans Incr Path ------------------------------------------------------------------------------clock clk1 (rise edge) 0.00 0.00 clock network delay (ideal) 0.00 0.00 out2_reg/CP (FD1S) 0.00 0.00 0.00 r out2_reg/Q (FD1S) 0.02 1.39 1.39 f out2 (net) 1 0.39 0.00 1.39 f out2 (out) 0.02 0.00 1.39 f data arrival time 1.39 clock clk1 (rise edge) 10.00 10.00 clock network delay (ideal) 0.00 10.00 clock uncertainty -1.00 9.00 output external delay -2.00 7.00 data required time 7.00 ------------------------------------------------------------------------------data required time 7.00 data arrival time -1.39 ------------------------------------------------------------------------------slack (MET) 5.61 Did you see the header? How do you read this report? Ive aligned the columns, but in most cases they wont be aligned. Here are a couple of tips. The transition time is seen for each driving pin. The capacitance driven by the driver is displayed in a column preceding both incremental path delay and transition time (specified by -transition_time). Unless the nets option is used, capacitance is printed on the lines with nets rather than on the lines with driver pins. Look for the word net to see the nets in the report.
-max_paths, -nworst
Use the max_paths and nworst options to collect more information on the worst paths. max_paths: This option allows you to specify the number of paths to report per path group. The default is 1. nworst: This option allows you to specify the number of paths to report per endpoint. Notice the difference between these two options. One is for path groups and the other for endpoints. An endpoint is all input pins, except clock pins of D
28
sequential devices or primary output ports. If you use nworst 2 you will get multiple reports to the same endpoint. For example, dc_shell-t> report_timing -nworst 2 **************************************** Report : timing -path full -delay max -nworst 2 -max_paths 2 Design : dff Version: 2003.06-2 Date : Wed Aug 20 13:21:27 2003 **************************************** Operating Conditions: Wire Load Model Mode: top Startpoint: out2_reg (rising edge-triggered flip-flop clocked by clk1) Endpoint: out2 (output port clocked by clk1) Path Group: clk1 Path Type: max Des/Clust/Port Wire Load Model -----------------------------------------------dff 05x05 class Library
Point Incr Path ----------------------------------------------------------clock clk1 (rise edge) 0.00 0.00 clock network delay (ideal) 0.00 0.00 out2_reg/CP (FD1S) 0.00 0.00 r out2_reg/Q (FD1S) 1.39 1.39 f out2 (out) 0.00 1.39 f data arrival time 1.39 clock clk1 (rise edge) 10.00 10.00 clock network delay (ideal) 0.00 10.00 clock uncertainty -1.00 9.00 output external delay -2.00 7.00 data required time 7.00 ----------------------------------------------------------data required time 7.00 data arrival time -1.39 -----------------------------------------------------------
29
slack (MET)
5.61
Startpoint: out2_reg (rising edge-triggered flip-flop clocked by clk1) Endpoint: out2 (output port clocked by clk1) Path Group: clk1 Path Type: max Des/Clust/Port Wire Load Model -----------------------------------------------dff 05x05 class Library
Point Incr Path ----------------------------------------------------------clock clk1 (rise edge) 0.00 0.00 clock network delay (ideal) 0.00 0.00 out2_reg/CP (FD1S) 0.00 0.00 r out2_reg/Q (FD1S) 1.15 1.15 r out2 (out) 0.00 1.15 r data arrival time 1.15 clock clk1 (rise edge) 10.00 10.00 clock network delay (ideal) 0.00 10.00 clock uncertainty -1.00 9.00 output external delay -2.00 7.00 data required time 7.00 ----------------------------------------------------------data required time 7.00 data arrival time -1.15 ----------------------------------------------------------slack (MET) 5.85 Notice the same endpoint for both reports.
Path Groups Path groups are automatically created when the create_clock or group_path command is used. The default path group contains all paths not captured by a clock. You can use the report_path_group command to see which groups you have. Figure 5 shows how path groups are formed.
30
data_in
path1
path2
path3
data_out
CLK clk1 clk2

path4 path groups clk1 path1 clk2 path2
CLK
default path3 path4
Figure 5: Path Groups
Here is an example of how to use command report_path_group: dc_shell-t> report_path_group **************************************** Report : path_group Design : dff i. Version: 2003.06-2 Date : Tue Aug 26 07:42:16 2003 **************************************** Critical Group Name Weight Range -------------------------------------------------------------------------------**default** 1.00 0.00 clk1 1.00 0.00 Path Group clk1: -to clk1 In this example, you can see two path groups, one for the default and one for a clock clk1. Now when you use max_paths 2, youll get paths for the path group. In this example, the path group is clk1. dc_shell-t> report_timing -max_paths 2 31
**************************************** Report : timing -path full -delay max -max_paths 2 Design : dff Version: 2003.06-2 Date : Tue Aug 26 08:10:24 2003 **************************************** Operating Conditions: Wire Load Model Mode: top Startpoint: out2_reg (rising edge-triggered flip-flop clocked by clk1) Endpoint: out2 (output port clocked by clk1) Path Group: clk1 Path Type: max Des/Clust/Port Wire Load Model -----------------------------------------------dff 05x05 class Library
Point Incr Path ----------------------------------------------------------clock clk1 (rise edge) 0.00 0.00 clock network delay (ideal) 0.00 0.00 out2_reg/CP (FD1S) 0.00 0.00 r out2_reg/Q (FD1S) 1.39 1.39 f out2 (out) 0.00 1.39 f data arrival time 1.39 clock clk1 (rise edge) 10.00 10.00 clock network delay (ideal) 0.00 10.00 clock uncertainty -1.00 9.00 output external delay -2.00 7.00 data required time 7.00 ----------------------------------------------------------data required time 7.00 data arrival time -1.39 ----------------------------------------------------------slack (MET) 5.61 Startpoint: in2 (input port clocked by clk1) Endpoint: out2_reg (rising edge-triggered flip-flop clocked by clk1) Path Group: clk1
32
Path Type: max Des/Clust/Port Wire Load Model -----------------------------------------------dff 05x05 class Library
Point Incr Path ----------------------------------------------------------clock clk1 (rise edge) 0.00 0.00 clock network delay (ideal) 0.00 0.00 input external delay 1.00 1.00 f in2 (in) 0.00 1.00 f U7/Z (IBUF2) 0.84 1.84 f out2_reg/D (FD1S) 0.00 1.84 f data arrival time 1.84 clock clk1 (rise edge) 10.00 10.00 clock network delay (ideal) 0.00 10.00 clock uncertainty -1.00 9.00 out2_reg/CP (FD1S) 0.00 9.00 r library setup time -1.30 7.70 data required time 7.70 ----------------------------------------------------------data required time 7.70 data arrival time -1.84 ----------------------------------------------------------slack (MET) 5.86
Important Output Files

Lets review. Youve read in your HDL files and set your constraints, compile has completed, and youve started timing analysis. Whats next? You need to write out a few files.
Write Command
The write command has the following important options. format: Typically youll want to write out a .db, Verilog, and/or VHDL format. The advantage of the Verilog or VHDL formats is that they allow you to look at the code and see what you have. The disadvantage is that none of the constraints are kept. If you use the .db format, you cant see the file but design constraints are saved. It is best to write out both.
33
hierarchy: This option tells Design Compiler to write out all designs in the hierarchy. Dont forget this option. output: This option allows you to specify the file name for the output file. After a compile, you should write a couple of files. You can then use these files in other tools such as PrimeTime. For example, write format verilog hier o design_names_gates.v write format db hier o design_names_gates.db
write_test_protocol
If the plan is to next use TetraMAX, you need to use a variable named test_stil_netlist_format to specify what netlist format to use when you write out the stil file. Set this variable to match the netlist format of your design before issuing write_test_protocol so that the port names in the STIL protocol file match the port names in the netlist. For example, set test_stil_netlist_format verilog write -format verilog -hier -out optimal_scan_stitched_netlist.v write_test_protocol -format stil -out TMAX_protocol.spf
Conclusion
Congratulations. You have just learned the ABCs of synthesis. A lot of information was covered. The next step is to review what youve learned and look more closely at all of the commands. By using the figures and examples presented in this paper, you should be able to compile your design, generate timing reports, and write out important files.
34

Syn Abc

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Syn Abc

Uploaded by

Copyright:

Available Formats

Synthesis ABCs Part 1

EFFICIENTLY READING FILES ................................................ 7

Basic Synthesis Flow

HDL Files Generation

Figure 1: Basic Synthesis Flow

Correct Input Files

Synopsys Setup File

Setup File Description

Efficiently Reading Files

analyze / elaborate Versus read_file

Figure 2: Analyze / Elaborate and Read_file Comparison

Presto On Versus Presto Off

Wire Load Models

Wire Load Model Example

set_clock_latency set_propagated_clock set_clock_uncertainty set_input_delay set_output_delay set_max_delay

Figure 3: Timing Constraint Commands

Figure 4: Divide-By-2 Clock

Clock Latency and Uncertainty

Clock Definition Point

Clock Definition Example

in1 D clk1 CLK Q QN clk_2

Figure 6: Clock Definition Example

External Logic ASIC

Figure 7: set_input_delay Example

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

Unusual Clock Constraints

TOP data_in D clk3 Q

CLK clk1 clk2

Figure 11: Clock Constraint Example - 1

TOP PLL clki rclk clki

Synthesis ABCs Part 2

HELPFUL REPORT GENERATION ........................................ 13

IMPORTANT OUTPUT FILES .................................................. 33

Basic Synthesis Flow

HDL Files Generation

Figure 1: Basic Synthesis Flow

Resolve multiple instances of any design references.

Figure 2: Top Down Design Flow

Figure 3: Bottom-Up Script

Compile for Timing

Compile for Area

Compile for Runtime

Helpful Report Generation

Options to and -from

9.00 7.00 7.00 7.00 -2.92 4.08

CLK clk1 clk2

default path3 path4

Figure 5: Path Groups

Important Output Files

You might also like