Synthesis ABCs Part 1

ABSTRACT The Synthesis ABCs white paper provides information on how to perform synthesis. Part 1 covers material such as basic synthesis flow, defining libraries, using setup files, reading files, using Presto, and timing and area constraints. Part 2 covers compile strategies, report generation, and writing files. Both papers discuss great commands like analyze, elaborate, read_file, report_timing, report_constraints, set_input_delay, set_output_delay, and compile. Defining libraries using the link_library and target_library variables is discussed along with a description of the .synopsys_dc.setup file. The read_vhdl, read_verilog, and variable hdlin_enable_presto commands are addressed. The compile and report_timing options are covered. Information on clock commands, including create_clock, create_generated_clock, set_clock_latency, set_propagated_clock, and set_clock_uncertainty , is provided. Examples and figures are included throughout the papers.

1

Table of Contents

INTRODUCTION............................................................................ 4

BASIC SYNTHESIS FLOW......................................................... 4

CORRECT INPUT FILES............................................................. 5

DEFINING LIBRARIES................................................................. 5

SYNOPSYS SETUP FILE ..................................................................................................... 6 Setup File Description ................................................................................................ 6

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

ANALYZE / ELABORATE VERSUS READ_FILE .................................................................... 7 analyze ........................................................................................................................ 7 Elaborate..................................................................................................................... 8 link Command ............................................................................................................. 9 read_file ...................................................................................................................... 9 Comparison............................................................................................................... 10

PRESTO ON VERSUS PRESTO OFF................................................................................... 10 Presto Variables........................................................................................................ 10

READ EXAMPLE.............................................................................................................. 11 hdlin_report_inferred_modules ................................................................................ 13 Generic Components................................................................................................. 14

FOCUSED CONSTRAINTS....................................................... 15

DESIGN ENVIRONMENT.................................................................................................. 15 Operating Conditions ............................................................................................... 15 Wire Load Models..................................................................................................... 18 Wire Load Model Example ....................................................................................... 19 System Interface ........................................................................................................ 21

CONSTRAINTS ................................................................................................................ 23 Timing ....................................................................................................................... 23 Area........................................................................................................................... 33 Design Rules ............................................................................................................. 33

UNUSUAL CLOCK CONSTRAINTS.................................................................................... 35

CONCLUSION.............................................................................. 37

2

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

3

Introduction So you’re new to Design Compiler and have been assigned to do the synthesis for the team. Where do you begin? Team members try to help by sending example scripts, but upon review the scripts seem to be written in a foreign language. All you want to know is how do I read in the files, what constraints do I need, and how do I generate reports. The goal of this paper is to provide you that information. The paper starts with the synthesis flow and ends with writing files. Everything in between. including reading files, preparing constraints, compiling, and report generation, is included. Part 1 discusses the flow through constraint generation. Part 2 picks up with compile techniques and ends with writing files.

Basic Synthesis Flow First let’s talk about the big picture. The big picture describes the steps you need to cover for synthesis. The first step is to specify what libraries you want to synthesize with. Libraries are provided from library vendors. Typically, your ASIC vendor will let you know which library to use. Next you need to read in the files. The different methods for reading in files will be covered along with comparisons of each. Once the files have been read, you need to set constraints. When the constraints have been defined, you’ll need to compile, analyze the results, and write out the synthesized netlist. Figure 1 shows a basic synthesis flow. An explanation for each box is provided in Parts 1 and 2 of Synthesis ABCs. The yellow boxes cover what you need to know about getting the design into Design Compiler and preparing the design for synthesis. The purple boxes cover how to compile the design, perform static timing analysis, and write out necessary files.

4

HDL FilesGeneration

SetupLibraries

ReadingFiles

BuildingConstraints

Compile

GenerateReports

Write Files

Figure 1: Basic Synthesis Flow

Correct Input Files Usually the input files for Design Compiler are written in VHDL or Verilog. When writing your HDL files, you’ll want to follow design partitioning and coding guidelines to achieve the best synthesis results possible. Partitioning and coding style directly affect the synthesis and optimization processes. Before writing any code, invest some time collecting coding guideline resources. See the Synopsys manuals HDL Compiler for VHDL Reference Manual and HDL Compiler (Presto Verilog) Reference Manual. Also see the white paper available on SolvNet called Fat-Free HDL (#006606) that contains guidelines along with other coding guideline articles. Another option is to look into using code checkers. One checker is called LEDA. The LEDA tool is a programmable HDL checker that verifies that HDL code complies with design rule and coding-style guidelines. Even if you’re not writing the HDL code, it is still a good idea to understand coding guidelines. This will allow you to quickly determine if a problem is in synthesis or in the code.

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

5

libraries to use when synthesizing your HDL code to gates. There are different types of libraries with different definitions. For example, the link and target libraries are technology libraries that define the semiconductor vendor’s set of cells and related information, such as cell names, cell pin names, delay arcs, pin loading, design rules, and operating conditions. Another type of library is called the synthetic or DesignWare library. This library is where your adders, multipliers, and so on come from. You do not need to specify the standard synthetic library, standard.sldb, which implements the built-in HDL operators; Design Compiler automatically uses this library. If you are using additional DesignWare libraries, you must specify these libraries by using the synthetic_library variable (for optimization purposes) and the link_library variable (for cell resolution purposes). To specify the link, target, symbol, and synthetic libraries you use the link_library, target_library, symbol_library, and synthetic_library variables. These libraries are normally placed in a setup file named .synopsys_dc.setup.

Synopsys Setup File Here is an example of a setup file using a class library. A discussion of the file follows. # This is a Tcl-s script # works for DC-SH, Design Vision, as well as for DC-Tcl define_design_lib work -path ./work set link_library {* ./class.db dw01.sldb dw02.sldb dw_foundation.sldb} set target_library {./class.db} set symbol_library {./class.sdb ./class.slib} set search_path [list ./ ../LIB /remote/release/2003.03-2/libraries/syn] set synthetic_library [list dw01.sldb dw02.sldb dw_foundation.sldb]

Setup File Description • The file has been written in Tcl-s. Both dctcl and dcsh modes of

dc_shell understand Tcl-s.

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

• The define_design_lib command tells Design Compiler where you want intermediate files written. This command is discussed in more detail later.

• The set link_library command specifies the list of design files and

libraries used during linking. The asterisk (*) shown in the line tells

6

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

• The set target_library command specifies the list of technology libraries

of components to be used when compiling a design.

• The set symbol_library command specifies the symbol libraries to use during schematic generation.

• The set search_path command allows you to tell Design Compiler what

directories it should search in to find files.

• The set synthetic_library command specifies a list of synthetic libraries to use when compiling.

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

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

analyze The analyze command does the following:

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

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

• Creates HDL library objects in an intermediate format.

7

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

define_design_lib work -path ./work

VHDL Intermediate Files The intermediate files include .syn, .st, and .mr.

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

• *.st files store intermediate results.

• *.mr files stores most recent analyzed architecture for an entity. It holds the names of the architectures used with an entity declaration.

Presto-Verilog Intermediate Files When Presto is on, the default, the intermediate files include .pvl and .mr.

• *.pvl files store intermediate results

• *.mr files store module references.

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

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

• *.mr files store module references.

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

Elaborate The elaborate command does the following:

• Translates the design into its GTECH representation.

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

• Allows VHDL architecture selection.

8

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

• Performs link automatically.

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

read_file The read_file command does the following:

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

• It does not create any intermediate files for Verilog.

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

• It does not execute the link command automatically.

• Reads several different formats.

read_file Formats The read_file command can read the following formats:

• db - Synopsys internal database format (the default)

• edif - Electronic Design Interchange format equation Synopsys equation format

• lsi - LSI Logic Corporation netlist format

• mif - Mentor intermediate netlist format

• pla - Berkeley (Espresso) PLA format

• st - Synopsys State Table format

• tdl - Tegas Design Language (TDL) netlist format

9

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

• VHDL - IEEE Standard VHDL

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

Comparison The following figure shows a comparison between the two commands. Comparison read_file Command analyze / elaborate Commands Input Formats All Formats VHDL, Verilog When to use? Netlists, precompiled

designs, and so forth Synthesize VHDL or Verilog

Design libraries

Cannot store analyzed results except in design library WORK

Can store analyzed results in specified design libraries

Generics Cannot pass parameters (must use directives in HDL)

Allows you to set parameter values on the elaborate command line

Architecture Can’t specify architecture to be elaborated

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 Let’s go through an example so you can see what happens when you read in the design. In this example, the command read_verilog is used to read in the Verilog HDL code. The design consists of two sequential flip-flops. Shown below is a copy of the Verilog HDL code used for this example. module dff (in1, in2, clk1, clk2, out1, out2, reset_n); input in1, in2, clk1, reset_n, clk2; output out1, out2; reg out1, out2; always @ (posedge clk1 or negedge reset_n) begin if (reset_n == 0) out1 <= 1'b0; else out1 <= in1; end always @ ( clk1) begin if (reset_n ==0) out2 <= 1'b0; else out2 <= in2; end endmodule Now let’s read the file into Design Compiler. Items of interest have been highlighted.

11

dc_shell-t> read_verilog dff.v Loading verilog file '/remote/scfs6/terrib/projects/testcase/tutoral/dff.v' Detecting input file type automatically (-rtl or -netlist). Reading with Presto HDL Compiler (equivalent to -rtl option). Running PRESTO HDLC Loading db file '/remote/release/2003.06/libraries/syn/standard.sldb' Loading db file '/remote/release/2003.03-2/libraries/syn/dw01.sldb' Loading db file '/remote/release/2003.03-2/libraries/syn/dw02.sldb' Loading db file '/remote/release/2003.03-2/libraries/syn/dw_foundation.sldb' Loading db file '/remote/release/2003.06/libraries/syn/gtech.db' Loading db file '/remote/scfs6/terrib/projects/testcase/tutoral/class.db' Compiling source file /remote/scfs6/terrib/projects/testcase/tutoral/dff.v Inferred memory devices in process in routine dff line 11 in file '/remote/scfs6/terrib/projects/testcase/tutoral/dff.v'. ============================================================= | Register Name | Type | Width | Bus | MB | AR | AS | SR | SS | ST | ============================================================= | out1_reg | Flip-flop | 1 | N | N | Y | N | N | N | N | ============================================================= Inferred memory devices in process in routine dff line 20 in file '/remote/scfs6/terrib/projects/testcase/tutoral/dff.v'. ============================================================= | Register Name | Type | Width | Bus | MB | AR | AS | SR | SS | ST | ============================================================= | out2_reg | Flip-flop | 1 | N | N | N | N | N | N | N | ============================================================= Presto compilation completed successfully. Current design is now '/remote/scfs6/terrib/projects/testcase/tutoral/dff.db:dff' dff Notice that in this example the command read_verilog was used to read in the HDL code. To tell if Presto is turned on or not, look for a line similar to this: Running PRESTO HDLC. You’ll want to examine the lines that start with loading db. This will tell you what libraries are being loaded. If you have sequential elements in your design, look at the section called Inferred memory devices in process. There will be tables showing the size and type of your sequential elements. Check to see if a flip-flop or a latch was inferred.

12

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

hdlin_report_inferred_modules If you need additional information on registers, you might want to set variable hdlin_report_inferred_modules to verbose. Using this variable you’ll get detailed information on elements. Here is an example. dc_shell-t> set hdlin_report_inferred_modules verbose verbose dc_shell-t> read_verilog dff.v . . Inferred memory devices in process in routine dff line 13 in file '/remote/scfs6/terrib/projects/testcase/tutoral/dff.v'. ============================================================= | Register Name | Type | Width | Bus | MB | AR | AS | SR | SS | ST | ============================================================= | out1_reg | Flip-flop | 1 | N | N | Y | N | N | N | N | ============================================================= Inferred memory devices in process in routine dff line 22 in file '/remote/scfs6/terrib/projects/testcase/tutoral/dff.v'. ============================================================= | Register Name | Type | Width | Bus | MB | AR | AS | SR | SS | ST | ============================================================= | out2_reg | Flip-flop | 1 | N | N | N | N | N | N | N | ============================================================= Sequential Cell (out1_reg) Cell Type: Flip-Flop Multibit Attribute: N Clock: clk_buf2 Async Clear: reset_n' Async Set: 0 Async Load: 0 Sync Clear: 0 Sync Set: 0 Sync Toggle: 0 Sync Load: 1

13

Sequential Cell (out2_reg) Cell Type: Flip-Flop Multibit Attribute: N Clock: clk_buf2 Async Clear: 0 Async Set: 0 Async Load: 0 Sync Clear: 0 Sync Set: 0 Sync Toggle: 0 Sync Load: 1 Do you see the additional information you can get with this variable?

Generic Components When you read in the HDL code, you have an unmapped design, meaning that you don’t have gates. Instead you have generic components called GTECH for combinational logic and SEQGEN for sequential logic. You can see this by executing the report_cell command. Here’s an example: dc_shell-t> report_cell Information: Updating design information... (UID-85) Allocating blocks in 'dff' **************************************** Report : cell Design : dff Version: 2003.06 Date : Wed Jul 9 07:29:05 2003 **************************************** Attributes: b - black box (unknown) c - control logic h - hierarchical n - noncombinational r - removable s - synthetic operator u - contains unmapped logic Cell Reference Library Area Attributes -------------------------------------------------------------------------------- B_0 GTECH_BUF gtech 0.000000 c, u C18 *SELECT_OP_2.1_2.1_1 0.000000 s, u

14

I_0 GTECH_NOT gtech 0.000000 u I_1 GTECH_NOT gtech 0.000000 c, u out1_reg **SEQGEN** 0.000000 n, u out2_reg **SEQGEN** 0.000000 n, u -------------------------------------------------------------------------------- Total 6 cells 0.000000 It is during the compile process that you will have gates.

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

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

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

• Temperature – Temperature variation on a chip is a fact of life and can’t be avoided. The effects on performance caused by temperature fluctuations are usually handled as linear scaling effects, but some submicron silicon processes require nonlinear calculations.

• Voltage – Having the design’s supply voltage vary from the ideal value

during day-to-day operation is normal. Often a complex calculation (using a shift in threshold voltages) is used, but a simple linear scaling factor is also used for logic-level performance calculations.

• Process - This variation accounts for deviations in the semiconductor

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

15

Operating Condition Example Most libraries have default settings for operating conditions. To see what the default conditions are you can use report_lib command, or if you have the .lib file you can take a look at it in UNIX. Assuming you don’t have the .lib file, here is an example of how to use the report_lib command. Continuing with our “Read Verilog Example,” let’s see what libraries are loaded into memory using the list_libs command. dc_shell-t> list_libs Logical Libraries: ------------------------------------------------------------------------- Library File Path ------- ---- ---- standard.sldb standard.sldb /remote/release/2003.06/libraries/syn dw01.sldb dw01.sldb /remote/release/2003.03-2/libraries/syn dw02.sldb dw02.sldb /remote/release/2003.03-2/libraries/syn dw_foundation.sldb dw_foundation.sldb /remote/release/2003.03-2/libraries/syn gtech gtech.db /remote/release/2003.06/libraries/syn class class.db /remote/scfs6/terrib/projects/testcase/tutoral Looking at this list we can find the name of our library ‘class’. Now do a report_lib to see what the default operating conditions are. dc_shell-t> report_lib class **************************************** Report : library Library: class Version: 2003.06 Date : Tue Jul 15 06:22:47 2003 **************************************** . . Operating Conditions: Name Library Calc_mode Process Temp Volt Interconnect Model ---------------------------------------------------------------------------- WCCOM class 1.50 70.00 4.75 worst_case_tree WCIND class 1.50 85.00 4.75 worst_case_tree WCMIL class 1.50 125.00 4.50 worst_case_tree . . .

16

From this report, you can see what the operating conditions are for Worst Case Commercial (WCCOM), Worst Case Industrial (WCIND), and Worst Case Military (WCMIL). Normally you would let Design Compiler use the operating conditions specified in the library as the default. If your library doesn’t have operating conditions or you want to specify explicit operating conditions, which supersede the default library conditions, you can use set_operating_conditions command as shown below.

dc_shell-t> set_operating_conditions WCCOM -lib class Using operating conditions 'WCCOM' found in library 'class'.

It is always a good idea to check your constraints by using the report_design command. dc_shell-t> report_design **************************************** Report : design Design : dff Version: 2003.06 Date : Tue Jul 15 06:48:43 2003 **************************************** . . . Operating Conditions: Name Library Calc_mode Process Temp Volt Interconnect Model ---------------------------------------------------------------------------- WCCOM class 1.50 70.00 4.75 worst_case_tree . . . If you had run report_design prior to setting the operating conditions, you would see that no operating conditions have been specified as shown: . . . Operating Conditions: No operating conditions specified. . . .

17

Wire Load Models I find wire load model’s a confusing concept because I think in one’s and zero’s not resistance and capacitance. But in any case, wire load modeling allows you to estimate the effect of wire length and fanout on the resistance, capacitance, and area of nets. Design Compiler uses these values to calculate wire delays and design speeds. Where do the wire load models come from? Normally the semiconductor vendors will develop the models. If back-annotated wire delays are not available, Design Compiler uses these wire load models to estimate net wire lengths and delays. To determine which model to use, Design Compiler uses the following factors:

• User specification.

• Automatic selection based on design area.

• Default specification in the technology library.

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

• User specification.

• Default specification in the technology library.

• Default mode in Design Compiler

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

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

• Enclosed – Design Compiler uses the wire load model of the smallest

design that fully encloses the net. Use enclosed mode if the design has similar logical and physical hierarchies.

18

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

Wire Load Model Example Now that you know what a wire load model is, how can you tell what you have? Using the report_lib command again, you can find out this information. dc_shell-t> report_lib class **************************************** Report : library Library: class Version: 2003.06 Date : Thu Jul 17 11:53:48 2003 **************************************** Wire Loading Model: Name : 05x05 Location : class Resistance : 0 Capacitance : 1 Area : 0 Slope : 0.186 Fanout Length Points Average Cap Std Deviation -------------------------------------------------------------- 1 0.39 Name : 10x10 Location : class Resistance : 0 Capacitance : 1 Area : 0 Slope : 0.311 Fanout Length Points Average Cap Std Deviation -------------------------------------------------------------- 1 0.53 Name : 20x20 Location : class Resistance : 0 Capacitance : 1 Area : 0 Slope : 0.547

19

Fanout Length Points Average Cap Std Deviation -------------------------------------------------------------- 1 0.86 Wire Loading Model Selection Group: Name : class Selection Wire load name min area max area ------------------------------------------- 0.00 1000.00 05x05 1000.00 2000.00 10x10 2000.00 3000.00 20x20 Wire Loading Model Mode: top. Wire Loading Model Selection Group: class. This report provides a lot of information. Let’s take a look at what it is telling you.

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

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

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

• The Wire Loading Model Mode section identifies the default wire load

mode. If the library doesn’t have a default, then Design Compiler will use the top mode.

• The Wire Loading Model Selection Group section tells which wire load

models will be user for specific areas. If you need to change the wire load model or mode you can use commands set_wire_load_model and set_wire_load_mode, respectively. Here is an example: dc_shell-t> set_wire_load_model -name "10x10" Design dff: Using wire_load model '10x10' found in library 'class'. dc_shell-t> set_wire_load_mode enclosed

20

Don’t forget to use the report_design command to see the changes. Notice the highlighted areas. dc_shell-t> report_design **************************************** Report : design Design : dff Version: 2003.06 Date : Thu Jul 17 12:13:11 2003 **************************************** Wire Loading Model: Selected manually by the user. Name : 10x10 Location : class Resistance : 0 Capacitance : 1 Area : 0 Slope : 0.311 Fanout Length Points Average Cap Std Deviation -------------------------------------------------------------- 1 0.53 . . . Wire Loading Model Mode: enclosed.

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

• Drive characteristics for input ports (input drive strength)

• Loads on input and output ports (capacitive load)

• Fanout loads on output ports

21

Input Drive Strength By default, Design Compiler assumes zero drive resistance on input ports, meaning infinite drive strength. To avoid this unrealistic approach, you can place a driving cell on the input ports that will cause Design Compiler to calculate the actual (nonzero) transition time on the input signal as though the specified library cell was driving it. You can do this by using the set_driving_cell command. This command allows you to select a realistic external cell driving the input ports. For example:

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

Capacitive Load In order for Design Compiler to accurately calculate the timing of an output circuit, you need to tell Design Compiler what the total capacitance driven by the output cells will be. This needs to be done because, by default, the tool assumes that the external load on the ports is zero. This information helps Design Compiler select the correct cell drive strength of an output pad and helps model the transition delay on input pads. You can use the set_load command to specify the external capacitive load on ports (inputs or outputs). You may specify a constant value or use the load_of command to specify the external load as the pin load of a cell in your technology library. Here are some examples.

• Constant value is specified.

set_load 5 [get_ports out1]

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

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

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

22

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

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

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

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

• Clocks

• I/O timing requirements

• Combinational path delay requirements

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

Command Description create_clock Use to generate a clock and define the period and

waveform. create_generated_clock Use to define a generated clock in relation to a source

clock.

23

set_clock_latency set_propagated_clock set_clock_uncertainty

Use these commands to tell Design Compiler about the clock delay.

set_input_delay Used to specify the timing requirements for input ports relative to the clock period.

set_output_delay

Used to specify the timing requirements for output ports relative to the clock period.

set_max_delay

Can be used to define maximum delay for combinational paths. (This is a timing exception command.)

set_min_delay

Can be use to define minimum delay for combinational paths. (This is a timing exception command.)

set_false_path

Use this command to specify false paths. (This is a timing exception command.)

set_multicycle_path

Use this command to specify multicycle paths. (This is a timing exception command.)

Figure 3: Timing Constraint Commands

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

create_clock –period 10 [get_ports clk1] The first command tells Design Compiler you have clock with a period of 10. Because the –name option was not used, the clock gets the same name as the clock source in this case, clk1. The clock will also have a 50 percent duty cycle because a waveform was not specified. This example creates a clock named clk2_in with a period of 10.0, a rise at 5.0, and a fall at 9.5:

24

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

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

U4D Q

CLK QNSYSCLK

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.

ASIC

D Q

CLK QN1nsNetwork Latency

3nsSource Latency

Orgin of clock

Clock DefinitionPoint

Figure 5: Clock Latency Example Here is an example of how to use the set_clock_latency command:

set_clock_latency 1 [get_clocks CLK] set_clock_latency –source 3 [get_clocks CLK]

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

26

command is that propagated clocks will calculate network latency. The total latency to the register will be the source + network latency. Here is an example of how to use the set_propagated_clock command:

set_propagated_clock [get_clocks CLK]

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

D Q

CLK QNclk1

clk_2

D Q

CLK QN

in1 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 you’ll get. dc_shell-t> report_clocks -skew **************************************** Report : clock_skew Design : divide_by2 Version: 2003.06-2 Date : Mon Aug 4 06:47:19 2003 ****************************************

Rise Fall Min Rise Min fall Uncertainty

Object Delay Delay Delay Delay Plus Minus --------------------------------------------------------------------------- clk1 1.00 1.00 1.00 1.00 0.50 0.50 Max Source Latency Min Source Latency

28

Early Early Late Late Early Early Late Late Object Rise Fall Rise Fall Rise Fall Rise Fall ------------------------------------------------------------------------- clk1 3.00 3.00 3.00 3.00 3.00 3.00 3.00 3.00 By using this report you can check to see if the set_clock_uncertainty and set_clock_latency commands were used correctly. Looking at rise delay, fall delay and so on, we see a delay of 1ns. This delay came from the command set_clock_latency 1 [get_clocks clk1]. Clock uncertainty is 0.5 and source latency is 3.0 ns. These delay values match the commands that were used: set_clock_uncertainty 0.5 [get_clocks clk1] and set_clock_latency -source 3 [get_clocks clk1].

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

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

ASIC

D Q

CLK QN

M delay D Q

CLK QN

N delay

clk

External Logic

T clk-q T m T nT setup

A

Figure 7: set_input_delay Example

29

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

• create_clock –period 20 [get_ports clk]

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

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

ASIC

D Q

CLK QN

T delayD Q

CLK QN

S delay

External Logic

T setupT tT sT clk-q

clk

B

Figure 8: set_output_delay Example

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

• create_clock –period 20 [get_ports clk]

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

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

30

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

set_max_delay 10.0 -to {Y}

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

set_min_delay 4.0 -from {A1 A2} -to Z5 Both of these commands (set_max_delay and set_min_delay) can be used to override Design Compiler calculated timing requirements. For example, for a path starting from a register at time 20 and arriving at a register where the next active edge of the clock is at 35, Design Compiler would automatically calculate the maximum path length as shown:

(35 - 20) - (library setup time of register at endpoint) However, if a set_max_delay of 10 were applied to this path, Design Compiler would calculate the max_path length as follows:

10 - (the library setup time of a register) This overrides the original calculated maximum path length. Similarly, the calculated minimum path length is equivalent to the library hold time for the register at the endpoint, but a set_min_delay that is greater than that would require that Design Compiler insert delays to meet the specification. You can use the report_timing_requirements command to see the maximum and minimum constraints.

31

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

TOP

Block_BBlock_A

D Q

CLK QN

A D Q

CLK QN

BCLKA

CLKB

Figure 9: Set_false_path Example

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

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

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

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

32

D Q

CLK QN

D Q

CLK QN

+ D Q

CLK QN

a(63:0)

b(63:0)

c(63:0)

clk

<60ns

a_reg

b_reg

c_reg

Figure 10: Set_multicycle_path Example

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

create_clock –period [get_clocks clk]

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

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

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

set_max_area 100

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

33

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

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

set_max_capacitance 2.0 [get_ports test]

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

set_max_transition 3.0 [get_ports example]

Set_max_fanout The maximum fanout load for a net is the maximum number of loads the net can drive. Design Compiler attempts to ensure that the sum of the fanout_load attributes for input pins on nets driven by the specified ports or all nets in the specified design is less than the given value set in the set_max_fanout command. The fanout load value does not represent capacitance; it represents the weighted numerical contribution to the total fanout load. Let’s say you have two inverters (inv1a1 and inv1a27). You can find the fanout_load attribute for each of these by Using the get_attribute command.

get_attribute tech_lib/inv1a1/A fanout_load

get_attribute tech_lib/inv1a27/A fanout_load Assume these commands return 0.25 and 3.00, respectively. Now if you have the following

Set_max_fanout 6 [get_ports in1]

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

34

Unusual Clock Constraints This section goes through a few examples of how you would write constraints for different types of circuits. For this example the clock periods are clk1 = 30, clk2 = 20, clk3 = 10, and clk4 = 15. Skew for clk1 is 0.35 and clk2 is 0.40. Network delay is 0.5 and 0.6 for clk1 and clk2. Transition delay is 1.0 for both clk1 and clk2. Clocks clk3 and clk4 are asynchronous to design top.

TOP

AD Q

CLK

D Q

CLK

data_in data_out

clk3

clk1clk2

clk4

2.5ns D Q

CLK

D Q

CLK

3.0ns D Q

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

clkiclk_in

PLL clkirclk

Figure 12: Clock Constraint Example - 2 #Create clocks create_clock -period 20.0 -name clk_in [get_pins PLL/rclk] #Create Generated Clock for PLL create_generated_clock -name clk1 -source clk_in -multiply_by 1 [get_pins PLL/clki] What happens when you need to divide a clock by 2 and have a negative clock as the master? When you use the create_generated_clock command, Design Compiler looks at the master clock and does the necessary divide by taking into account the clock waveform you specified with create_clock. If you used create_clock for clk1 and waveform is {0 5 10} and then divided-by 2 , the waveform created using create_generated_clock would be {0 10 20}. The tool doesn’t take into account the clock inversion. Here’s what you need to do.

36

D Q

CLKclk1

clk2U2

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 2 3 4 5 6

0 5 10 15 20 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 you’ve learned and dig deeper into the commands. Using the figures and examples, you should be able to set up your libraries, read in you files, and write constraints.

37