Basic of Timing Analysis in Physical Design

What is Timing Analysis??

Before we start anything at least we should know what exactly we mean by Timing Analysis. Why these days it’s so important?

There are a couple of reasons for performing timing analysis.

• We want to verify whether our circuit meet all of its timing requirements (Timing Constraints)
• There are 3 types of design constraints- timing, power, area. During designing there is a trade-offs between speed, area, power, and runtime according to the constraints set by the designer. However, a chip must meet the timing constraints in order to operate at the intended clock rate, so timing is the most important design constraint. 
• We want to make sure that circuit is properly designed and can work properly for all combinations of components over the entire specified operating environment. "Every Time".
• Timing analysis can also help with component selection. 
• An example is when you are trying to determine what memory device speed, you should use with a microprocessor. Using a memory device that is too slow may not work in the circuit (or would degrade performance by introducing wait states), and using one that is too fast will likely cost more than it needs to.

So I can say Timing analysis is the methodical analysis of a digital circuit to determine if the timing constraints imposed by components or interfaces are met. Typically, this means that you are trying to prove that all set-up, hold, and pulse-width times are being met.

Note: Timing analysis is integral part of ASIC/VLSI design flow. Anything else can be compromised but not timing!

Types of Timing Analysis:

There are 2 type of Timing Analysis-

• Static Timing Analysis:
• Checks static delay requirements of the circuit without any input or output vectors.
• Dynamic Timing Analysis.
• verifies functionality of the design by applying input vectors and checking for correct output vectors

Basic Of Timing Analysis:

The basis of all timing analysis is the clock and the sequential component (here we will discuss with the help of Flip-flop) . Following are few of the things related to clock and flip-flop which we usually wants to take care during Timing analysis.

Clock related:

• It must be well understood parametrically and glitch-free.
• Timing analysis must ensure that any clocks that are generated by the logic are clean, are of bounded period and duty cycle, and of a known phase relationship to other clock signals of interest.
• The clock must, for both high and low phases, meet the minimum pulse width requirements.
• Certain circuits, such as PLLs, may have other requirements such as maximum jitter. As the clock speeds increase, jitter becomes an increasingly important parameter.
• When "passing" data from one clock edge to the other, ensure that the worst-case duty cycle is used for the calculation. A frequent source of error is the analyst assuming that every clock will have a 50% duty cycle.

Flip-Flop related:

• All of the flip-flops parameters are always met. The only exception to this is when synchronizers are used to synchronize asynchronous signals
• For asynchronous presets and clears, there are two basic parameters that must be met.
• All setup and hold times are met for the earliest/latest arrival times for the clock.
• Setup times are generally calculated by designers and suitable margins can be demonstrated under test. Hold times, however, are frequently not calculated by designers.
• When passing data from one clock domain to another, ensure that there is either known phase relationships which will guarantee meeting setup and hold times or that the circuits are properly synchronized

Now Lets talk about Each type of Timing analysis One by one in the next few blogs.

Tuesday, February 22, 2011

Clock Reconvergence Pessimism (CRP) basic

Full Form :

CRP : Clock Reconvergence Pessimism.

What is CRP (Clock Reconvergence Pessimism)?

As the "convergence" means (dictionary) "the occurrence of two or more things coming together". So we can assume that its also related to 2 clock path coming together. (Please refer the another blog for understanding the Clock path- Static Timing Analysis Basic: Part1 "Timing Paths")

Now lets assume 2 flip-flop circuit as shown in the figure.

Clock Reconvergence Pessimism

As you can see that flop share a common clock but are placed physically at the different places in the same die. Or in other way you can say that Launch clock path and capture clock path (Please refer Static Timing Analysis Basic: Part1 "Timing Paths" for defination of Launch and Capture Clock path)  share a common segment in the clock tree till the point know as "common point" (in above fig you can see that "common point" is written as "The clock path common to both flops till this point"). The 2 clock path diverse from that point.

As we know that every cell has two type of delay as a part of its specification, "Max Delay" and "Min delay". There are several scenario in the design where we use either max delay or min delay of a particular cell. Such as best case analysis (BC), worst case (WC) analysis, OCV (on chip variation) analysis during timing analysis.

Lets consider that max delay and min delay of the common segment is as
Max delay=1.2ns
Min Delay=1.0ns.

Now, if during timing analysis a condition arise where you have to use max delay for one timing path and min delay for another timing path (such as during OCV analysis), you have to use 2 different values for a common path. But practically same set of cells can't be behave different for different clock path.

For example, for a setup check, it uses the maximum delay for the launch clock path (1.2ns + delay because of rest of the circuit in the launch path) and the minimum delay for the capture clock path (1.0ns + delay because of rest of the circuit in the launch path.

In a physical design, however, the cells along the common portion of the clock tree cannot simultaneously achieve their maximum and minimum delay values. Thus there will be a single value of delay to the common point that will be propagated to both the launching and capturing clock paths. This conflicts with our timing analysis method described above since we utilise two sets of delay values at the common point.

Therefore our timing report contains artificially introduced pessimism that is derived from our usage of max and min delay for the launching and capturing paths along this common portion of the clock network. The value of this pessimism, is the difference between max and min delay at the common point in the clock network.
 
The amount of pessimism due to this effect (in this example, 0.2 ns) is called "clock reconvergence pessimism".

Clock reconvergence pessimism = (maximum clock delay) - (minimum clock delay)


Note: Above situation is identical for hold checks also.
 
Similar type of situation can arise in different type of circuit also. Lets discuss one of that. Please see the following fig.

Schematic of a reconvergent clock

 
The two clock paths that feed into the multiplexer cannot be active at the same time, but an analysis could consider both the shorter and longer paths for one setup or hold check. This results in different launch and capture clock path delays and the consequent pessimism.

How to remove CRP ?

Automated correction of this inaccuracy is called clock reconvergence pessimism removal (CRPR). By default , most of the tools (EDA tools for timing calculation) disable this feature (automated correction). By you can enable this feature by setting one/more variables during timing analysis. Different Tools have different variable for this. For that please refer the USER GUIDE or MANUAL of corresponding tool.

Saturday, February 19, 2011

Different File Formats (file extensions)

There are different type of the files generated during a design cycle or data received by the library vendor/foundry. Few of them having specific extension. Just to know the extension, you can easily identity the type of content in that file.

I am listing down of the file extension. Please let me know if you find any extension is missing. I will add those later on.


File Extensions:

• *.v - Verilog source file. Normally it’s a source file your write. Design Compiler, and IC Compiler can use this format for the gate-level netlist.
• *.vg, .g.v - Verilog gate-level netlist file. Sometimes people use these file extension to differentiate source files and gate-level netlists.
• *.svf - Automated setup file. This file helps Formality process design changes caused by other tools used in the design flow. Formality uses this file to assist the compare point matching and verification process. This information facilitates alignment of compare points in the designs that you are verifying. For each automated setup file that you load, Formality processes the content and stores the information for use during the name-based compare point matching period.
•  *.ddc - Synopsys internal database format. This format is recommended by Synopsys to hand gate-level netlists.
•  *.vcd - Value Change Dump format. This format is used to save signal transition trace information. This format is in text format, therefore, the trace file in this format can get very large quickly. There are tools like vcd2vpd, vpd2vcd, and vcd2saif switch back and forth between different formats.
• *.vpd - VCD Plus. This is a proprietary compressed binary trace format from Synopsys. This file format is used to save signal transition trace information as well.
•  *.saif - Switching Activity Interchange Format. It’s another format to save signal transition trace information. SAIF files support signals and ports for monitoring as well as constructs such as generates, enumerated types, records, array of arrays, and integers.
•  *.tcl - Tool Command Language (Tcl) scripts. Tcl is used to drive Synopsys tools.
•  *.sdc - Synopsys Design Constraints. SDC is a Tcl-based format. All commands in an SDC file conform to the Tcl syntax rules. You use an SDC file to communicate the design intent, including timing and area requirements between EDA tools. An SDC file contains the following information: SDC version, SDC units, design constraints, and comments. 
•  *.lib - Technology Library source file. Technology libraries contain information about the characteristics and functions of each cell provided in a semiconductor vendor’s library. Semiconductor vendors maintain and distribute the technology libraries. In our case the vendor is Synopsys. Cell characteristics include information such as cell names, pin names, area, delay arcs, and pin loading. The technology library also defines the conditions that must be met for a functional design (for example, the maximum transition time for nets). These conditions are called design rule constraints. In addition to cell information and design rule constraints, technology libraries specify the operating conditions and wire load models specific to that technology.
•  *.db - Technology Library. This is a compiled version of *.lib in Synopsys database format.
•  *.plib - Physical Library source file. Physical libraries contain process information, and physical layout information of the cells. This information is required for floor planning, RC estimation and extraction, placement, and routing.
•  *.pdb - Physical Library. This is a compiled version of *.plib in Synopsys database format.
•  *.slib - Symbol Library source file. Symbol libraries contain definitions of the graphic symbols that represent library cells in the design schematics. Semiconductor vendors maintain and distribute the symbol libraries. Design Compiler uses symbol libraries to generate the design schematic. You must use Design Vision to view the design schematic. When you generate the design schematic, Design Compiler performs a one-to-one mapping of cells in the netlist to cells in the symbol library.
•  *.sdb - Symbol Library. This is a compiled version of *.slib in Synopsys database format.
•  *.sldb - DesignWare Library. This file contains information about DesignWare libraries.
•  *.def - Design Exchange Format. This format is often used in Cadence tools to represent physical layout. Synopsys tools normally use Milkyway format to save designs.
•  *.lef - Library Exchange Format. Standard cells are often saved in this format. Cadence tools also often use this format. Synopsys tools normally use Milkyway format for standard cells.
•  *.rpt - Reports. This is not a proprietary format, it’s just a text format which saves generated reports by the tools when you use the automated makefiles and scripts.
•  *.tf - Vendor Technology File. This file contains technology-specific information such as the names, characteristics (physical and electrical) for each metal layer, and design rules. These information are required to route a design.
•  *.itf - Interconnect Technology File. This file contains a description of the process crosssection and connectivity section. It also describes the thicknesses and physical attributes of the conductor and dielectric layers.
•  *.map - Mapping file. This file aligns names in the vendor technology file with the names in the process *.itf file.
•  *.tluplus - TLU+ file. These files are generated from the *.itf files. TLUPlus models are a set of models containing advanced process effects that can be used by the parasitic extractors in Synopsys place-and-route tools for modeling.
•  *.spef - Standard Parasitic Exchange Format. File format to save parasitic information extracted by the place and route tool.
•  *.sbpf - Synopsys Binary Parasitic Format. A Synopsys proprietary compressed binary format of the *.spef. Size of the file shrinks quite a bit using this format.
• *.mw( Milkyway database) The Milkyway database consists of libraries that contain information about your design. Libraries contain information about design cells, standard cells, macro cells, and so on. They contain physical descriptions, such as metal, diffusion, and polygon geometries. Libraries also contain logical information (functionality and timing characteristics) for every cell in the library. Finally, libraries contain technology information required for design and fabrication. Milkyway provides two types of libraries that you can use: reference libraries and design libraries. Reference libraries contain standard cells and hard or soft macro cells, which are typically created by vendors. Reference libraries contain physical information necessary for design implementation. Physical information includes the routing directions and the placement unit tile dimensions, which is the width and height of the smallest instance that can be placed. A design library contains a design cell. The design cell might contain references to multiple reference libraries (standard cells and macro cells). Also, a design library can be a reference library for another design library. The Milkyway library is stored as a UNIX directory with subdirectories, and every library is managed by the Milkyway Environment. The top-level directory name corresponds to the name of the Milkyway library. Library subdirectories are classified into different views containing the appropriate information relevant to the library cells or the designs. In a Milkyway library there are different views for each cell, for example, NOR1.CEL and NOR1.FRAM. This is unlike a .db formatted library where all the cells are in a single binary file. With a .db library, the entire library has to be read into memory. In the Milkyway Environment, the Synopsys tool loads the library data relevant to the design as needed, reducing memory usage. The most commonly used Milkyway views are CEL and FRAM. CEL is the full layout view, and FRAM is the abstract view for place and route operations.
•  simv - Compiled simulator. This is the output of vcs. In order to simulate, run the simulator by ./simv at the command line.
•  alib-52 - characterized target technology library. A pseudo library which has mappings from Boolean functional circuits to actual gates from the target library. This library provides Design Compiler with greater flexibility and a larger solution space to explore tradeoffs between area and delay during optimization.

Process Variation - Effects On Design, Different Types and Modelling

The Scaling down of Process technologies has increased the Process variations. Because of this delay variation increases and impact the frequency performance of the design. These things also impacted the TAT (Turn Around Time) and timing yields (The ration of chips that achieve the target Frequency).

As a design specification its important to Target a particular frequency and Yield. Means how many chip can perform with in the target frequency after fabrication). Designer have done a lot of things to achieve this and one of the way is "adding sufficient margin" for delay variation.

In Process node above 90nm , the margins for the delay variations are small enough and their impact on the design can be eliminated but below 90nm increased Delay variation (because of Process variation) enlarge the margins in the circuit design. Because of this we have to overestimate delay in the design and which makes design work difficult (Increased the TAT of the design).

So its very important to understand that what are the delay variations?

Delay Variations are due to various type of process variations.

Type Of Process variation:

• Random Variation
• Occurs without regards to the location and patterns of the transistors with in the chip.
• E.g
• variation in transistor threshold voltage caused by density variations of impurities in the transistor material.
• Systematic variation
• Related to the location and patterns
• E.g
• Exposure pattern variation that occurred in lithography process.
• silicon surface flatness variations caused by layout pattern density variation during the CMP (Chemical Mechanical Planarization)
• Intra-die Or Within-die variation
• Variations between the elements in the same chip
• Inter-die Or Die-to-die variation.
• Variations between chips in the same wafer or in different wafers.

Part(a) is a type of  Random variation. Part(b) for Systematic variation and Part(c) for Die-to-die and within-die variations.

  

There are few more classification for the Process variations

• Front-end Variation
• Mainly refer to the variations present at the transistor level.
• The primary components of the front end variations
• transistor gate length
• gate width,
• gate oxide thickness,
• doping related variations. 
•  These physical variations cause changes in the electrical characteristics of the transistors which eventually lead to the variability in the circuit performance
• Back-end Variation.
• Refer to the variations on various levels of interconnecting metal and dielectric layers used to connect numerous devices to form the required logic gates

Now at least we have a rough idea about the type of Variations. Now next question is what is the solution of these variations. If these variations are there then how can we take care about this. So regarding this Foundries and EDA companies had done a lot of experiments and they always come with better solutions. 

One best way is To MODEL these variation (mathematically) and implement it during the designing cycle.

Lets Talk about these one by one.

Systematic Variation's Modeling:

• Controlled not like Random variation modeling where every thing is distributed.
• Generally Geometry-dependent or layout-dependent.
• Modeling is based on practical models. These models are implemented mathematically using different Tables(matrix), equations and simulators.
• Few of the area/causes on the basis of which modeling methods are decided
• ETCH modelling.
• Conductor's Width and Spacing Dependent ETCH.
• Device Specific
• Conductor Thickness variation.
• Density dependent
• Width and spacing dependent.
• Dielectric coefficient dependent.
• Dielectric thickness variation.
• Trapezoidal Line Shape and width enlargement (Trap tangent modelling)
• Damage Modelling.
• The intra-die variations, or variations within the same chip, are modeled using a deterministic process and are well controlled.

Random Variation's Modelling.

• Distributed , across different dies or even wafers
• Random and independent in nature.
• Manimum and minimun variation for a given parameter is usually know, along with the type of distribution the parameter exhibits. Usually this information is provided by the foundry.
• Commonly, we use "Normal Gaussian Distribution" based on "Central Limit Theorem" for modelling random variation.
• Based on Probability of occurance of a particular variation.
• Assumption: Variation of a paramenter is independent of rest of the factors and none of them playing dominant role.
• Random variations are modelled through process corners, where max and min variations represented by +3sigma and -3sigma.
• Following parameters are modelled as Random variations
• Thickness of
• Conductor
• Dielectric
• Width of Conductor.
• Dielectric Constant.
• Inter-die variations, or the process variation from die to die or wafer to wafer, are assumed to be random, and therefore are generally modeled using a normal and/or uniform distribution.

NOTE: There are lots of systematic variation, which are part of Random variation for lower technology node. Because as the chip size is decreases, Its very difficult to come-up a well defined equations/tables for few of the parameters. e.g thickness variation due to chemical mechanical polishing (CMP) or line width variation because of optical inaccuracies.

Note: Please refer the Corresponding Blog for the detail of specific variation/model types.

ETM (Extracted Timing Models) - More detail

Lets Talk about ETM models little more: Check the ETM(Extracted Timing Models)-Basic blog for basic idea.

Advantage of Extracted Timing models:

• Much smaller than the original netlist.
• significantly reduce the time needed to analyze a large design.
• Using a model in place of a netlist prevents a user from seeing the contents of the block.

Extraction Requirement:

To generate these models you should have 

• Block netlist.
• Technology Library
• Timing details of the block.

As I have mentioned previously in one of my blog that Extracted timing models creates a timing arc for each path (port to port or port to register or register to port) in the original design (block). As we know that delay  in a design is accurate for a range of operating condition , but in the ETM models delay data does not depend on any specific parameter's value (like input transition times, output capacitive loads, input arrival times, output required times etc) and that's the reason these models are know as "context independent" models(condition applied ## [:)]). But when you are using these models in your design for timing analysis, then delay value depends on these parameters. So in other word I can say that these models are functions of different parameters and not limited to a specific set of parameter's values.

Timing information of different parts of the design in the Extracted models:

Nets:

• Boundary nets: Preserves the boundary nets of the design. Since these are the nets which will interact with the outside world (when you are going to instantiate this in the other design), so proper/correct and original  information is necessary to avoid any  mismatching.
• Internal Nets: Delay values are extracted in the models as per the information provided during the extraction. Means if you provide the "wire load models" then it will contain the information as per that or if you will provide detailed parasitics (of these internal nets), it will contain that information.

Paths:

• Input to register: Extracted into equivalent setup arc and hold arc between these 2. 
• Setup arc = delay of the longest path + setup time of the register library cell.
• Hold arc = delay of the shortest path + hold times of the register library cell.
• Note: 
• calculation between the shortest and longest path is between a particular input to all registers clocked by the same clock
• These values are function of transition time of input signal and clock, so if you are using this block in some other clock frequency (different then the value you have used during generation of these models), then you can do it easily.
• Register to Input: Same as above.
• Input to output path: Extracted into 2 equivalent arc (one is for shortest path and other for longest path).
• Register to register: Not extracted
• Clock path: Delays and transition times of clock networks are reflected in the extracted model.

Noise Analysis using These models: 

By default these is no noise information is included in extracted models. If you want then you can use special command for including noise characteristics in the extracted models.

Other Information:

There are lot of other information present in the extracted timing models. For that you can refer PrimeTime User Guide.

## "Context independent" doesn't mean that you can operate these models for any set of conditions. Before a timing model is created, the internal logic of the block is checked for timing violations, subject to external conditions such as input delay and output delay. Once verified, the internal timing of the model is guaranteed to have no violations as long as the external conditions are within the ranges specified when the internal logic was checked.

## SO before using these blocks you should know the range of these blocks (know as scope of the block). You can generate the scope file containing all these information also and check that one before using this in your design.

## Information stored in the ETM is in the form of delay table (A 2x2 Matrix). These matrix specifies the arc delay value as a function of the input transition time and the output load capacitance. Interpolation and extrapolation are performed for calculating the values other then specified in the table. These models are accurate for the range of values specified in the table.

ETM (Extracted Timing Models) basics

Introduction:
In a design Once a block has met its timing constraints at the gate level, the detailed internal timing of the block is not needed for chip-level timing analysis. For that we can create/write a timing model for that block.

Timing Model of  the block

• Should completely model the full input/output timing characteristics without requiring the complete netlist of the block.
• Do not model every path in the block. Internal registerto register paths are generally discarded, as these paths can be analyzed at the block level using the complete gate-level netlist.

Synopsys has a tool named as PrimeTime and its most trusted and advanced timing sign-off solution for gate-level STA tool. Its accuracy is within 5% of SPICE.

Prime Time Provides following types of advance timing models.

• Interface Logic Models (ILM) for hierarchical static timing analysis and sign-off
• Extracted Timing Models (ETM) in .lib format for cell-based reusable IP and physical design flows
• Quick Timing Models (QTM) for top-down design

In this Blog we will discuss only about the ETM models basic. For More detail please refer "ETM (Extracted Timing Models) - More detail" blog.

ETM (Extracted Timing Models):-

• Block based model (.lib)
• Contents of block are hidden
• Original netlist replaced by model containing timing arcs for block interfaces.
• NLDM lookup tables are extracted for each of the timing arcs.
• These arcs whose delay are a function of input transition and output load. This makes ETM usable with different input transition times and different output loads.
• Multiple modes per model
• Single PVT per model
• Used for implementation (not sign-off) of IP models. Here the content are protected because the model contains abstracted timing information, without any netlist information.

ETM model Illustration:

Types Of ETMs:

There are 2 types of ETM avaliable-

• NetList
• Liberty library cell (.lib)

Note: Most frequent usages is the .lib cells. 

Developing of ETM Models:

Developing an ETM model in Primetime consists of three high level steps:

• Preparing for the ETM
• Creation of the ETM
• Verification of the ETM

ETM scripts example:

As such the flow of the script vary from design to design and company to company, but following example just give a rough idea about the commands for generating the ETM. I will suggest you to check the PrimeTime user-guide for more details.

• ETM creation :

############################################

# Template for ETM extract when using spef #
############################################
 
set BLOCK "blockname"
set NETLIST "blockname.v"
set SPEF "blockname.spef"
set SDC "blockname.sdc"
 
# Preserve unconnected nets
set svr_keep_unconnected_nets true
 
# set search_path and link_library
 
# Read and link netlist
read_verilog $NETLIST
current_design ${BLOCK}
link
#  for nets not annotated
set_wire_load_model -name B0.1X0.1
# Read spef
read_parasitics $SPEF
# Read constraints
read_sdc $SDC
set_propagated_clock [all_clocks]
 
 
# Define operating conditions
set_operating_conditions -library g65xp lsiW_090V_125C \
  -analysis_type on_chip_variation 
 
# Set extract_model variables
# Note: These should be considered example settings. Final variable
# settings ultimately depend on the specific design usage.
set extract_model_data_transition_limit 0.75
set extract_model_clock_transition_limit 0.75
set extract_model_capacitance_limit 1.0
set extract_model_num_clock_transition_points 7
set extract_model_num_data_transition_points 7
set extract_model_num_capacitance_points 7
set extract_model_use_conservative_current_slew true
set extract_model_enable_report_delay_calculation true
 
# to create an ETM model with propagated clocks:
set extract_model_with_clock_latency_arcs true
extract_model -output ${BLOCK} -format {db lib} \
 -library_cell -test_design
 
quit

############################################

ETM verification:    

############################################
# Template for ETM verification            #
############################################
 
set BLOCK "blockname"
set NETLIST "blockname.v"
set SDC "blockname.sdc"
set ETM_MODEL "${BLOCK}_lib.db"
set ETM_TEST  "${BLOCK}_test.db"
set ETM_CONST "${BLOCK}_constr.pt"
 
# Compute the interface timing of the netlist.
 
# Read in reference netlist design
read_verilog $NETLIST
current_design ${BLOCK}
link
set_wire_load_model -name B0.1X0.1
read_parasitics $SPEF
read_sdc ${SDC}
set_propagated_clock [all_clocks]
set_operating_conditions -library g65xp lsiW_090V_125C \
  -analysis_type on_chip_variation
write_interface_timing netlist_report.txt
 
 
# Compute the interface timing of the ETM model.
 
# Remove reference netlist and read in ETM model
remove_design -all
lappend link_path ${ETM_MODEL}
read_db ${ETM_TEST}
current_design ${BLOCK}_test
link
# set wire_load that has 0.0 cap loading
set_wire_load_model -name TSMC_CLN90G_WLM_0.0
## alternatively, use
#set_load -wire_load 0 *
read_sdc ${SDC}
set_propagated_clock [all_clocks]
source ${ETM_CONST}
write_interface_timing model_report.txt
 
# Compare the interface timing for the netlist vs ETM model.
 
compare_interface_timing -absolute_tolerance 0.1 \
 netlist_report.txt model_report.txt -output cmp.rpt
 
quit

#######################################################

Synopsys Design Constraints (SDC) Basics

Full form of SDC: - Synopsys Design Constraints.

What is SDC: - SDC is a format used to specify the design intent, including the timing, power and area constraints for a design. SDC is tcl based. 

Tool used this format: - DC (Design compiler, ICC (IC compiler), Prime Time (PT).

Information In the SDC: - There are mainly 4 type of the information.

1.     The SDC version (optional)

2.     The SDC units (optional)

3.     The Design Constraints

4.     Comments (Optional)

1.      SDC version:

Variable name:                sdc_version

E.g:-                               set sdc_version

Default Version:              1.9

2.     SDC units:

Command name:             set_units 

Description:                    using above command you can specify the units for capacitance, resistance, time, voltage, current, and power

E.g: 

set_units -capacitance cap_unit -resistance res_unit \

-time time_unit -voltage voltage_unit \

-current current_unit -power power_unit

3.     Design Constraints:

 You can specify design constraints using Synopsys constraints commands.

Type of information	Commands
Operating conditions	set_operating_conditions
Wire load models	set_wire_load_min_block_size set_wire_load_mode set_wire_load_model set_wire_load_selection_group
System interface	set_drive set_driving_cell set_fanout_load set_input_transition set_load set_port_fanout_number
Design rule constraints	set_max_capacitance set_max_fanout set_max_transition set_min_capacitance
Timing constraints	create_clock create_generated_clock group_path set_clock_gating_check set_clock_groups set_clock_latency set_clock_sense set_clock_transition set_clock_uncertainty set_data_check set_disable_timing set_ideal_latency set_ideal_network set_ideal_transition set_input_delay set_max_time_borrow set_output_delay set_propagated_clock set_resistance set_timing_derate
Timing exceptions	set_false_path set_max_delay set_min_delay set_multicycle_path
Area constraints	set_max_area
Multivoltage and power optimization constraints	create_voltage_area set_level_shifter_strategy set_level_shifter_threshold set_max_dynamic_power set_max_leakage_power
Logic assignments	set_case_analysis set_logic_dc set_logic_one set_logic_zero

Most of the constraint commands require a design object as a command argument.

Design Objects:

Design object	Access command	Description
design	current_design	A container for cells. A block.
clock1	get_clocks all_clocks	A clock in a design. All clocks in a design.
port	get_ports all_inputs all_outputs	An entry point to or exit point from a design. All entry points to a design. All exit points from a design.
cell	get_cells.	An instance of a design or library cell
pin	get_pins	An instance of a design port or library cell pin.
net	get_nets	A connection between cell pins and design ports
library	get_libs	A container for library cells
lib_cell	get_lib_cells	A primitive logic element.
lib_pin	get_lib_pins	An entry point to or exit point from a lib_cell.
register	all_registers	A sequential logic cell.

4.     Comments:

You can add comments to an SDC file either as complete lines or as fragments after a command. To identify a line as a comment, start the line with a pound sign (#).

E.g : # This is an SDC comment line.

To add a comment after a command, end the command using a semicolon, then precede the comment with a pound sign (#).

E.g: create_clock -period 10 [get_ports CLK]; # comment fragment

How to generate The SDC file Automatically:

Using Synopsys Tool like DC, ICC or PrimeTime you can generate the SDC. There may be slight variation between the generated SDC across the different tool.

Command for generation: - write_sdc

Validation of manually generated SDC files:- 

Command file: read_sdc -syntax_only