Synopsys Design Constraints (SDC)

What is SDC?

SDC is a format that is used to specify the design intent, which includes timing, power and area constraints for a design. The information specified in design constraints is operating conditions, wire load models, system interface, design rule constraints, timing constraints, timing exceptions, area constraints, multi-voltage & power optimization constraints and logic assignments. Design constraints will have all the object access commands. Objects can be design, clock, port, pin, cell, net, library, etc. This format is used by different EDA tools to synthesize and analyze a design. SDC is based on the tool command language.

Background of SDC

Normally we simulate a design in an ideal state, where there are no input/output delay. But in real life that is not the case. There are always delays and other constraints that have an effect on the performance of a design or chip. If testing was done in these ideal conditions and the designs passed the simulation, they might fail drastically if real life user case scenarios.

Why we need SDC?

As I have said before, simulating in the ideal case in not an answer. So, we need a system to make a design perform like realistic situation. So, designers like us can understand the chip behavior and optimize the timing, power and other necessary constraints if needed.

SDC Design Constraints

There are several SDC design constraints inside the SDC file. These constraints include header information’s like version and units, operating conditions, system interfaces and design rule constraints like setting maximum fanout, timing constraints like input/output delay, clock latency, clock generation and timing exceptions like setting multicycle paths and false paths. We will now look into these a bit more deeply. 

Syntaxes: Header

set_sdc_version
    example: set_sdc_version 2.1

The statement set sdc_version specifies the version of the SDC file. it could be 2.1, 2.0, 1.9 or more older.

set_units [-time ns] [-resistance Kohm] [-capacitance pF] [=voltage V] [-current mA]
    example: set_units -time 5 -resistance 100 -capacitance 50 -voltage 5 -current 2

Units of various quantities like time, resistance, capacitance, voltage, current, and power can be specified using set_unit command. We can set multiple units using a single set_units command.

Setting the version and unit is an optional thing to do. So, some SDC files might not contain these commands.

Syntaxes: System Interface

set_driving_cell [-lib_cell cell_name] [-pin pin_name] [-from_pin pin_name]
    example: set_driving_cell -lib_cell AND2 -pin Z -from_pin B {I2}

The command set_driving_cell specifies the drive characteristics of input or inout ports that are driven by the cells in the technology library. These commands associate a library pin with input ports so that delay calculation can be accurately modelled. From the example we can see, we are setting the driving cell of pin Z using the library cell of AND2 and it is from the pin B. And while doing synthesis, if it specifies some driving cell for input ports, and we will also get these in the SDC from synthesis.

set_load [[pin_load] [-wire_load]]
    example: set_load -pin_load 0.001 [get_ports {port[10]}]

The set_load command sets the load attributes on the specified ports and the nets in the current design. Unit of load value will be the unit of capacitance specified in the unit defined in this file. set_driving_cell and set_load are commands to make sure that the interface of the block will not cause transition or capacitance violations when connected to external circuitry in a chip.

Syntaxes: Design Rule Constraints

set_max_fanout fanout_value [object_list]
    example: set_max_fanout 5 [get_potrts {port[10]}]

Now we will see the most important and commonly used design rule constraint syntaxes. The command set_max_fanout is set to a specific input port and/or design. The maximum fanout of an output measure its load driving capacity. This info is present in the .lib file. It is the greatest number of inputs of gates to which the output can be safely connected. If the sum of the fanout loads is more than the max_fanout_value, then we need to make changes to our design by adding a buffer or any other way. Here is an example, 

The max_fanout is set to be 20. 
Total fanout from driving pin X is: 1 + 1 + 2 + 3 = 7, which is less than the max_fanout value. So there will be no violations.
Suppose the output fanout has changed to 20. Now the total fanout from driving pin X will be: 1 + 1 + 2 + 20 = 24, which is greater than max_fanout. So, a violation will occur.
Similarly in the previous case, if the max_fanout was set to 6, then there would also be violations.

So, what is the significance of this parameter? Typically, manufacturers define the max input current for a particular cell at each logic level. So, fanout of a cell A is the max no of input that can be connected to an output of the cell before the current requirement by any of the input exceeds the current that can be delivered by the output while maintaining the correct logic level.

set_max_transition value [object_list]
    example: set_max_transition 2.5 [get_ports IN]

Maximum transition time is set by the set_max_transition command which is a design rule and set to clock port or design is set to a specific input port and/or design.

Syntaxes: Timing Constraints

create_clock [-period value] [-name clock_name] [-waveform edge_list]
    example: create_clock -name "CLK" -period 30 -waveform [12 27]

Timing constraints are the single most important constraints in any SDC. In this part basically, we set clocks definition, clock group, clock latency, clock uncertainty, clock transition, input delay, output delay, timing derates etc. The create_clock command creates a clock object in the current design. This command defines the specified source object as the clock source. From the example we can see, if we use this command, it will generate a clock like this, where the period is 30 and there is a transition from 12 to 27.

create_generated_clock [=multiply_by factor] [-source source]
    example: create_generated_clock -multiplied_by 3 -source CLK

The create_generated_clock command creates a generated clock object. A pin or port could be specified for the generated clock object. Generated clock follows the master clock, so whenever the master clock changes generated clock will change automatically. A generated clock can be created as a frequency-divided clock, a frequency multiplied clock, an edge divided clock or an inverted clock.

group_path [-name group_name] [-weight value] [-to list]
    example: group_path -name "group1" -weight 2.0 -to {CLK1A CLK1B}

Groups are a set of paths or endpoints for the cost function calculations. The group enables us to specify a set of paths to optimize even though there may be a larger violation in other groups. When endpoints have specified all paths leading to those end paths are grouped. The create_clock command automatically creates a group for the new clock with a weight of 1.0 and named the same as the clock name. We can change the weight and the destination later using the group_path command.

set_clock_uncertainty [-setup] [-hold] [-max_rise] [-max_fall] [-min_rise] [-min_fall]
    example: set_clock_uncertainty -setup 0.5 [get_clocks clk1]
                         set_clock_uncertainty -max_rise 0.12 [get_clocks clk1]
                         set_clock_uncertainty -min_fall 0.12 [get_clocks clk1]

After defining the clock, to take care of variance in the clock network, clock uncertainty is added. It adds some margin of error into the system to account for variance in the clock network caused by non-ideality of clock network and clock source itself. It specifies either inter-clock uncertainty or simple uncertainty. It sets uncertainty to the worst skew expected to the endpoints or between the clock domains.

set_clock_latency value [delay_object_list]
    example: set_clock_latency 2.35 [get_pins ABC]

Clock latency specifies the amount of delay for a clock signal reaching to the clock pin of a sequential element from the clock source pin. There are two types of clock latency one is network latency (default) and other is source latency (by using the -source option). Clock network latency is the time taken by the clock signal to propagate from the clock definition point to the clock pin of a register. Whereas source latency is the time taken by a clock signal to propagate from actual-ideal waveform origin point to the clock definition point in the design. Source delay is also called an insertion delay.

set_input_delay value [-clock clock_name]
    example: set_input_delay -max 1.35 -clock clk1 {ain bin}

Input delay defines the time requirements of an input port with respect to clock edge. Input ports are assumed to have zero input delay if it is not specified. The delay value to be specified is the delay between the start point and the object on which set_input_delay is being set relative to the clock edge. 

set_output_delay value [-clock clock_name]
    example: set_output_value 1.7 -clock [get_clocks CLK1] [all_outputs]

set_output_delay command sets output delay requirements on an output port with respect to the clock edge. Output ports are assumed to have zero output delay if it is not specified.

Syntaxes: Timing Exceptions

set_multicycle_path path_mutiply_value [-from point_A] [-to point_B]
    example: set_multicycle_path 2 -from A -to B

A multicycle path is an exception of the default single-cycle timing requirement path. In a multicycle path, signal requires more than one single clock cycle to propagate from the start point to the endpoint of the path. This command specifies the number of cycles the data path must have for setup or hold check. The following command will set a constraint of two cycles path from source point A to endpoint B.

set_false_path -from [get_clocks clock1] -to [get_clocks clock2]
    example: set_false_path -from [get_clocks clock1] -to [get_clocks clock2]
                         set_false path -from [get_ports port1] 

A false path is a path that can’t propagate a signal. For example, a path that never activates by any combination of inputs is a false path. False paths should be disabled for timing analysis. The SDC command set_false_path is used to define the false paths. False paths will be excluded for timing analysis. However not specifying any valid false path can make the tool try to fix bogus violations and go over nard or area and runtime. So, before starting, we need to know which clocks are synchronous to each other, and which clocks aren’t.

So, that's it for SDC!

References: vlsi-expert, vlsitutorials, signoffsemi, teamvlsi

Post a Comment

0 Comments