Non SDC attributes

Attributes:

Attributes are NOT part of SDC.

Every object in design has multiple attributes assigned such as name, power, size, etc. Each object has attr type and it's value. What attributes a particular object will have depends on it's class (class may be design, port, cell, pin, net , lib, lib_cell, lib_pin, and clock), i.e a "cell" class may have it's attribute types as name, size, pins, etc, while a net may have it's attribute types as name, driver, receiver, etc. Many attributes are provided by default on different cell types (called as application attr). We can also define our own attributes on any object (known as user-defined attr). user defined attr are usually not needed for simple tasks (as appl attr are enough for most purposes). These attributes are helpful to sort objects based on similar or differing attributes.

Attributes are not standardized, and Synopsys/Cadence have different attributes for their objects. Attributes vary across tools too (i.e Synthesis and Timing tools may not have same attribute on an object even though both tools are from same company). So, none of the cmds involving setting or getting attributes are SDC cmds. You have to look thru Cadence/Synopsys tool manuals. Since there are so many attr, both Synopsys/Cadence have dedicated manual for all attributes for each tool.You should download and keep this manual handy at all times, as you need to work with attr all the times. Searching for them on Cadence/Synopsys website is very time consuming.

  • PT has a dedicated manual "PT variables and attributes" which list all such attr for all objects. Look in cell_attributes, pin_attributes, port_attributes, net_attributes, clock_attributes, etc in the manual for most important attr. "man" cmd with "_attributes" appended to the object class name shows details of that attr (ex: man design_attributes => shows info about design attr).
  • Genus has a dedicated manual "Genus Attribute reference for Legacy" as well as "Genus Attribute reference for CUI" manuals.
    • Genus Legacy:
      • help cmds for attr:
        • get_attribute -h => list all valid object types as net, pin, cell, pin, port, design, lib*, memory*, etc
        • get_attribute -h <attribute_name> <object_type>' will give you more information. Both 'attribute_name' and 'object_type' support the wildcard ('*') character for non-hidden attributes 
          • ex: get_attribute -h * net => reports all attr names for object type "net", such as basename, driver, load
      • get_attribute: To retrieve the value of an attribute on an object, use the get_attribute cmd above with no "-h" option
        • get_attribute attr_name object => ex:
      • set_attribute: To change the setting of an attribute on an object, use the following command:
        • set_attribute attr_name attr_value objects => ex:
      • Attr common to all objects:
        • obj_type <name_of_obj> => This returns the obj type of any object
        • name <name_of_obj> => returns obj name which is useful in get_db/set_db cmds
      • Attr for specific objects:
        • Pin: get_attribute capacitance [find /des*/design -port *] => find port cap for all the ports in design

Some common application attributes are:

  • full_name => Returns the complete name (string type) of the cell. For example, the full name cell U3 within cell U2 within cell U1 is U1/U2/U3.
  • base_name => Returns the leaf name (string type) of the cell. For example, the base_name of cell U1/U2/U3 is U3
  • ref_name => Returns the name of the design or library cell of which the cell is (or will be) an instantiation; also known as the reference name. for ex I_my_inv is an instance of an inverter from lib which is tsmc_INV_NOM_D2.
  • object_class =>Returns the class of the object, which may be "cell", "net", etc. You cannot set this attribute.
  • is_hierarchical => Returns true for hierarchical cells and false for leaf cells. This is helpful in finding leaf cells.
  • power attr as dynamic_power, leakage_power, glitch_power, internal_power, total_power, switching_power, etc

Some important attr for different classes are:

  • cell_attributes => apart from common appl attr, cell_attr as cell_type (is_memory_cell, is_pad_cell, is_sequential_cell (2 flavors: is_rise_edge_triggered, is_fall_edge_triggered), are also present. We also have lib_cell_attributes for lib_cells. Attr may differ b/w cells and lib_cells even though both refer to the same underlying cell. These may even differ from what's there in .lib file for that cell.
    • size_only => can be set to true or false. Returns true if the cell is protected from removal by the set_size_only command. When this attribute is set to true, the ECO fixing commands (fix_eco_drc, fix_eco_power, and fix_eco_timing) can resize the cell but not remove it. The cell can still be removed by the remove_cell command.
  • clock_attributes
  • design_attributes
  • lib_attributes =>
  • net_attributes =>
  • pin_attributes => also has lib_pin_attributes for lib pins of lib cells. Attr may differ b/w pins and lib_pins even though both refer to the same underlying pin. These may even differ from what's there in .lib file for that pin. An ex is capa
  • port_attributes
  • timng_path_attributes =>
  • timng_arc_attributes => also has lib_tiimng_arc_attributes
  • upf_attributes

Some attr are only specified for leaf cells (i.e flop, AND gate, etc instantiated in design), so we can't apply or retrieve pin attr on IO pins of a module. In such case, we'll get an error "no such attr found".

Attribute cmds from Synopsys PrimeTime: Below are some Important attribute cmds from Synopsys PT (other tools from Synopsys may not support these cmds):

1. list_attributes => shows alphabetically sorted list of all attr for all object class. It doesn't show the values for these attr for any instance, but attr name and their type (i.e attr max_capacitance, thier type as "float" and the properties as Application defined, user defined, etc). By default, it shows only user defined attr, but using -application shows application attr too. Since there are too many appl attr for all object classes combined (about 3K or so), we should limit to specific object class using -class option.

  • Cell Attributes: list_attributes -application -class cell -nosplit => shows all cell attr (both appl and user defined). -nosplit prevents line splitting, so that it's more readable when dumped into some other file. "cell" class has attr as full_name, area, ref_name, lib_cell, etc.
  • Lib Cell Attributes: list_attributes -application -class lib_cell -nosplit => Same as above, except that it shows attr for lib cells. These are the attr found in .lib for that cell. The names reported here may be different than what's reported in .lib file, i.e it may have attr is_physical in .lib, but PT may report attr as is_physsical_only in lib_cell attr (as PT uses it's std attr for lib_cell so that it's consistent)
  • Pin Attributes: list_attributes -application -class pin -nosplit => shows all pin attr as cell, case_value, user_case_value, constant_value, full_name, clocks, is_clock_pin, is_clock_network, etc. Some pin attr as case_value, clocks, etc are valid for pins of leaf cells only.
    • capacitance on pin: returns max/min cap of pin for rise/fall. Attr are: pin_capacitance_max/min_rise/fall, pin_capacitance_max/min (it's max/min of rise and fall). For o/p pins, this is usually 0, as output pins have almost 0 cap (as it's gate/src and gate/drn miller cap), while for i/p pin, it's the gate cap which is substantial. If we want to get all of the cap on that pin (including net cap + load cap), use attr: effective_capacitance_max/min. This refers to effective cap max_capacitance and min_capacitance that is seen on the pin. Max and min cap values will be very close here, as cap doesn't vary much with max/min conditions. min/max_capacitance attr refers to min/max cap allowed on that pin as per .lib file (mentioned as max/min_capacitance for that pin in .lib, NOT the cap values in index for cell delay). This is the drc value for max/min cap on that pin. One other set of attr also defined for drc: drc_constraining_max_capacitance = max cap allowed as per drc rules (specified in .lib), drc_actual_max_capacitance = actual max cap present on this pin that is going to be used for drc purpose, drc_max_capacitance_slack = drc slack for max cap which is (drc_constraining_max_capacitance  - drc_actual_max_capacitance)
    • delay: There are bunch of max/min_rise/fall_arrival/slack and max/min_arrival/slack that may be used to get timing path values.
    • transition on pin: returns max/min transition times on pin for rise/fall. Attr are: actual_rise/fall_transition_max/min, actual_transition_max/min (it's max/min of rise and fall). For i/p pins, there's also an attr "max_transition" that specifies the max_transition that's allowed on that pin as per .lib file (mentioned as max_transition for that pin in .lib). This is the drc value that's used for max transition on the pin. Similar to the cap values, one other set of attr also defined for drc: drc_constraining_max_transition = max tran allowed as per drc rules (specified in .lib), drc_actual_max_transition = actual max tran present on this pin that is going to be used for drc purpose, drc_max_transition_slack = drc slack for max tran which is (drc_constraining_max_transition  - drc_actual_max_transition)
    • net: This attr returns a collection that contains the net connected to this pin; this attribute is defined only if the pin is connected to a net.
    • cell: This attr returns a collection that contains the cell that this pin belongs to.
    • pin_direction: This attr specifies whether pin is "output" or "input" pin.
    • case_value: This attr is one of the most attr during debug of paths. It returns the user-specified logic value of the pin or port propagated from a case analysis or logic constant. This attribute is computed only for leaf pins.
    • constant_value: This attr returns the logic value of a pin tied to logic constant zero or one in the netlist.
    • full_name, disable_timing, fanout_load, is_clock_pin, is_Data_pin, is_clear_pin, is_async_pin, is_port, object_class,
  • Lib Pin Attributes: list_attributes -application -class lib_pin -nosplit => Same as above, except that it shows attr for lib pins. Again lib_pin attr in .lib may be diff than what's reported by PT, i.e attr "direction" in .lib is replaced by "pin_direction" attr in PT.
  • Net Attributes: list_attributes -application -class net -nosplit => shows all net attr as dont_touch, base_name, full_name, is_ideal, is_clock_network, leaf_drivers, leaf_loads, etc
  • Clock Attributes: list_attributes -application -class clock -nosplit => shows all clock attr as period, waveform, master clock, master pin, setup_uncertainty, hold_uncertainty, etc.

Other than list_attributes cmd, report_attribute and get_attribute are 2 other most common cmds:

2. report_attribute => reports all attr on list of objects, which can either be a collection or a pattern (pattern needs to define object class with -class option). Here we report actual values for any attr of an object. By default only user defined attr are displayed. To see application attr, add option -application.

NOTE: report_attribute in Design Compiler (DC) has very different syntax than one in PT. See DC section for that.

ex: report_attribute -application [get_pins chip/.../D] => This reports all user attr + appl attr on pin D of given flop

Design          Object             Type            Attribute Name          Value
----------------------------------------------------------------------------------------
chip            chip/../D          float    actual_fall_transition_max  0.028304 => and 100's of other attr such as temperature_max, is_ideal, is_clock_pin, etc.

ex: report_attribute -application -attribute case_value [get_pins -hier */SE] => reports only this attr "case_value" on SE pins of all objects in design. Since SE (shift En) pin only exists on scannable flops, it's reporting case value on SE pin of all scannable flops (mostly to debug when in scanshift mode). case_value reports attribute on pin as 0 or 1, not just due to set_case_analysis, but also due to tieoff, propagated constants, or other reasons. This attribute is computed only for leaf pins.

ex: report_attribute -application -attribute lib_pin [get_pins mod1/dfg/D] => returns "tsmc_NOM_125/SDF_FLOP/D". This returns name of std cell and name of liberty library where it's present. This can be applied to cells also to get attr "lib_cell".

3. get_attribute => gets value of a given attr type for speciifed object or collection of object.  get_att is used compared to report_att when we want to use it within a script to extract values. syntax is: get_attribute <options> object attr_name

return value is a list (if multiple objects specified) or a string (if single object specified). To force return value to be a list, use option: -value_list

ex: get_attribute [get_cells -hier *] ref_name => shows reference cells for all "cell" objects in design. This will show not only std cells, but also module defn names as those modules have "module defn" as their reference name

Tracing constant values on clock network or other nets: Below 2 cmds useful in figuring out why some nets/pins are showing off constant value. This info can be seen in "report_attr -application" cmd above, as all attr values for a given object are shown there too, but get_attribute can be used in scripts for processing. We can keep on getting i/p and o/p pins of drivers on the fanin and backtrace to see the original source of this constant value.

ex: get_attribute [get_pins abc/.../D1] case_value => Returns the user-specified logic value of the pin or port propagated from a set_case_analysis or logic constant in netlist itself. This attribute is computed only for leaf pins. If you try to use it on nets, you will get "no such attr defined".

ex: get_attribute [get_pins abc/.../D1] constant_value => shows case value on a pin due to constant in netlist. When used in conjunction with case_value, we can know whether constant value comes from tied off net in netlist or due to set_case_analysis.

This below cmd is also being used which shows "user_case_value" , though not sure how it's different from "case_value" attribute. FIXME ? I've very seldom seen this attribute defined for pins.

ex: get_attribute [get_pins abc/.../D1] user_case_value => Returns the user-specified logic value of a pin or port.

4. define_user_attribute => defines new user defined attr.

ex: define_user_attribute attr_ir1 -classes cell -type int => defines new attr "attr_ir1" on all cell type whose value is integer

5. set_user_attribute => once we define a user attr, we can set it's value.

ex: set_user_attribute [get_cells *] attr_ir1 30 => setts attr value to 30 for above defined attr

6. remove_user_attribute => we can remove user attr defined above on specific cells. We can't remove application attr which are inbuilt.

ex: remove_user_attribute [get_cells i1] attr_ir1 => This removes user defined attr only from cell i1.

 

 

Object acccess functions: SDC supports these object access cmds. These cmds are supported both in DC and PT with same syntax (although there are some variations). Look in both PT manual, and DC manual to make sure the syntax is the same. Most of these cmds, which have the same syntax as in PT are in STA PT cmd section: primetime-commands:

1. Design get_* cmds:  get_cells, get_nets, get_pins, get_ports, get_clocks. Look in STA PT cmd section.

2. LIB get_* cmds: get_libs, get_lib_cells, get_lib_pins. Look in STA PT cmd section.

3. Design report_* cmds:  Supported by synthesis tools, but not part of SDC. Lots of reporting cmds as report_*. Look in STA PT cmd section, as these report cmds are common across DC and PT. Few cmds which are important or different in DC are explained below.

I. report_attribute: This cmd in DC has very diff syntax than corresponding cmd in PT, although the o/p reported is in the same format as that of PT. Here, the cmd reports the attributes of specified objects. An object can be a cell, net, pin, port, instance, or design. report is always generated for whatever is set as current design.

syntax: report_attribute <options> <object_list> => If object list is specified, then all attr reported for that object. If object list is not specified, then all attr reported for all objects in current design, which match the options.

dc_shell> report_attribute => reports all attributes for all objects in curent design. i.e for all cells, pin, ports, nets and design. If we use option -net, -cell, -design, -port, -pin, -instance, -hierarchy, then it reports attr for only that object type. report_attribute is very large report, since it reports everything, but then it can be narrowed byy reporting attr for only cells for ex by running "report_attribute -cell" cmd.

dc_shell> report_attribute mod1/mod2/pin1 => This reports all attr for a given object. Most of the times, we want to know if a given object is pin, net, cell, etc. This cmd helps us find that out. In this cae, object is a pin, as reported below.

Design          Object             Type      Attribute Name            Value
---------------------------------------------------------------------------------------------
digtop     mod1/mod2/pin1    pin       psnmp_oname     M:mod1 M:mod2 L:pin1

II. report_design: This cmd common across DC/PT, but used very commonly in DC to see all libs, op cond etc used for current design.

III. report_reference: This cmd in DC has very diff syntax than corresponding cmd in PT, although the o/p reported is in the same format as that of PT. It supports option "hier" to include hier.

IV. report_area: This cmd only supported in DC. It lists area for cells. It supports option "hier" to include hier.

4. LIB report_* cmds: report_lib is the only cmd here. It displays information about the specified logic library, physical library, or symbol library. It has lots of options. Look in STA PT cmd section.

5. set_hierarchy_separator => starting from SDC 1.2, hierarchical names can be made non-ambiguous using the set_hierarchy_separator SDC command and/or the -hsc option available on the
get_cells, get_lib_cells, get_lib_pins, get_nets, and get_pins SDC object access commands.

 

sample sdc file generated by Syntheis/Timing Tools: DC/PT/Genus:

pt_shell> write_sdc design.sdc

design.sdc:

set sdc_version 2.1
set_units -time ns -capacitance pF -current mA -voltage V -resistance kOhm

set_operating_conditions -analysis_type on_chip_variation  -library [get_libs TSM_max.db:TSM_max}]

set_wire_load_model -min -library [get_libs {zero_wire_load}] -name zwlm

set_wire_load_model -max -library [get_libs {zero_wire_load}] -name zwlm
set_wire_load_mode top

#create all clks needed
create_clock -name debug_rosc_clk -period 1.207 -waveform { 0 0.6035 } [get_ports {PORT1}]\
set_propagated_clock [get_clocks {debug_rosc_clk}]

#clk uncertainty set
 set_clock_uncertainty -setup  0.10462 [get_clocks {debug_rosc_clk}]
 set_clock_uncertainty -hold  0.0155 [get_clocks {debug_rosc_clk}]

#clk gating checks specified for all clocks
set_clock_gating_check -rise -setup  0.1 [get_clocks {debug_rosc_clk}]
 set_clock_gating_check -fall -setup  0.1 [get_clocks {debug_rosc_clk}]
set_clock_gating_check -rise -hold  0.45 [get_clocks {debug_rosc_clk}]
set_clock_gating_check -fall -hold  0.45 [get_clocks {debug_rosc_clk}]

#generated clks => source pin and master clk specified

create_generated_clock .....

#set derate on all cells rise/fall, late/early. It's done for both clock and data for each cell in library.

set_timing_derate -increment -cell_delay -clock -rise -early -0.0026  [get_lib_cells  {TSM_MAX/AN2_HVT}]

set_timing_derate -increment -cell_delay -data  -rise -early -0.0214  [get_lib_cells  {TSM_MAX/AN2_HVT}]

#set clk groups

set_clock_groups -asynchronous -name clk_grp_clk1 -group [get_clocks {my_clk}] -group [get_clocks {debug_rosc_clk ...}] ...

group_path -name io_to_flop -from [get_ports {IN1 IN2 ...}]
group_path -name flop_to_io -to      [get_ports {OUT1 OUT2 ...}]

group_path -name io_to_io -from [get_ports {IN3 ..}] -to [get_ports {OUT3 ..}] 

set_sense -stop_propagation -clocks [get_clocks {nec_clk}] [get_pins {I_1/reg_56/Q4}]

set_min_delay  0 -to [get_pins {I_1/pin1_out}]
set_max_delay  10000 -to [get_pins {I_1/pin1_out}]

#set MCL, FP, set case analysis, set_disable_timing, etc

set_case_analysis 0 [get_pins {clkmux2_0/S}]

set_disable_timing  -from PI -to PO [get_cells {chip/u_CTRL0}]

#set IO delay

set_output_delay  -1.3 -clock [get_clocks {spi0_clk}] -clock_fall -min -add_delay -reference_pin [get_pins {TOP/I_SC/PAD}] [get_ports {SPI0_MOSI}]
set_input_delay  17.4 -clock [get_clocks {spi0_clk}] -max -reference_pin [get_pins {TOP/I_SC/PAD}] [get_ports {SEP_SPI0_MISO}]

set_data_check -fall_from [get_pins  {I_1/flop_0/D}] -fall_to [get_pins {I_2/flop_0/D}] -clock [get_clocks {my_clk}] -hold  5

set_load -pin_load  50 [get_ports {AOP_LSPMI_CS_TRIG_1}]

set_max_transition 0.46 [get_pins {design1/mod2/gate/A design1/mod2/gate/Y ... }

set_input_transition 0.2 [get_ports *]

 

Using SDC cmds in Cadence Synthesis tools:

Cadence Synthesis tool RC didn't support SDC cmds natively. However their older PnR tool called EDI did support the SDC cmds. Cadence newer Synthsis tool called Genus support almost all SDC cmds natively. Their PnR tool Innovus also supports most SDC cmds. The section below is written for Cadence Synthesis tool, RC, which isn't being used anymore since 2020. So, below section is obselete, but provided since I prepared the notes anyway.


All of these cmds are synopsys cmd, so they don't work directly in Cadence tools as RC (they do work in EDI). In RC, these cmds only work, if they are used in a file, and read via "read_sdc constraints.sdc" cmd. They also work if we precede them with dc::
ex in RC:
rc:/> dc::set_load -pin_load 4.1912 [dc::get_ports n_puc_sync]
rc:/> read_sdc -stop_on_errors constraint.sdc => reads sdc file and stops on errors
rc:/> echo $::dc::sdc_failed_commands > failed_sdc => reports all failed cmds when reading sdc

NOTE: Although set_operating_conditions, set_max_area, set_units, set_propagated_clock present in sdc gen by DC, are standard sdc cmds, but they are ignored by RC,VDI. cdns tools looks at timing library (in /db/.../synopsys/src/*.lib) for default units [time_unit : "1ns"; current_unit : "1mA"; voltage_unit : "1V"; capacitive_load_unit (1,pf); pulling_resistance_unit : "1kohm"; leakage_power_unit : "1pW";]. If the default unit is not specified, cdns sets default unit of time to ns and cap to pf. Upto this point it's same behaviour as snps tools. But then it muultiplies these values by appr factor to convert them to ps and ff, which are cdns tools units. ns and pf are snps tools units.

#get_attribute returns the value of an attribute on a list of design or library objects. It's supported in both cdns/snps tools, but they are native cmds for each vendor. DC get_attribute is not supported in RC (i.e dc::get_attribute in RC will give an error). RC get_attribute behaves differently than DC get_attribute.
DC: get_attribute <object_list> <attribute_name> => returns value in dc default units of ns,pf.
RC: get_attribute <attribute_name> <object_list> => order is reversed. returns value in rc default units of ps,ff.

ex: rc:/> get_attribute capacitance [find [find "MSL270_W_125_2.5_CORE.db" -libcell IV110] -libpin A] => get_attribute, which is an RC cmd, looks at pin cap which is "0.0049". since cap units are set to pf in the .lib file, it correctly infers the pin cap to be 0.0049pf. Now, it converts this to ff which is 4.9ff and returns the value as 4.9.

ex: rc:/> get_liberty_attribute capacitance [find [find "MSL270_W_125_2.5_CORE.db" -libcell IV110] -libpin A] => get_liberty_attribute, which is an RC cmd, but returns values in default units specified in .lib file. So, it returns the value as 0.0049 which is in pf, which is the default unit for cdns specified in .lib file.

ex: dc_shell> get_attribute [get_lib_pins {"MSL270_W_125_2.5_CORE.db/IV110/A"}] capacitance => returns cap value in default units as specified in .lib file, which is pf. So, it returns the value as 0.0049 which is in pf, same as get_liberty_attribute.

set_load in constraints.sdc file gets affected by this, as being an sdc cmd, it expects the i/p to be in snps default units of pf. So, when using set_load in cdns, it gets off by factor of 1000.
ex: rc:/> dc::set_load [get_attribute capacitance [find [find "MSL270_W_125_2.5_CORE.db" -libcell IV110] -libpin A]] [dc::all_outputs] => get_attribute being an rc cmd returns value in ff which is 4.9. set_load treats this as 4.9pf (pf is default for dc), and sets a load of 4.9pf on all outputs, which is incorrect (correct value should be 0.0049pf)

To fix this, do this in RC:
rc:/> set load_scaled [expr [get_attribute capacitance [find [find "MSL270_W_125_2.5_CORE.db" -libcell IV110] -libpin A]]/1000] => load_scaled gets a value of 4.9/1000 = 0.0049 which is in pf.
rc:/> dc::set_load load_scaled [dc::all_outputs] => correctly sets o/p cap to 0.0049pf.

#possible issue in some library: not sure if this is an issue, FIX it later.
In a hypothetical library, default Cap unit=0.00693pf in .lib file. "set_units" cmd of sdc generated by DC, multiplies it by appr units in set_units to get load in pf unit. However, when we run any CDNS tool using the same sdc file, it ignores set_units cmd, so it treats the SL load in set_load in units of pf. It seems that the default units specified in .lib files, are not used as default units for anything outside those .lib files, that's why the units in "set_load" aren't adjusted by appr factor. This is only a problem for lbc8, as default Cap unit=0.00693pf. This causes diff when we gen sdf file using PT or ETS as PT sees diff load on o/p pins than ETS, so o/p buf delays are diff. "create_delay_corner" in create_views.tcl file in vdio is the equiv of set_operating_conditions in synopsys sdc file.

#set_units: to set units for env. When generating this in sdc, DC sets these units of time to ns, cap to pf, res to kohm, voltage to V, current to mA, based on units in .lib file. When generating this in sdc, RC sets units of cap in ff and time in ps. set_units is used by snps tools, but not by cdns tools.
DC: set_units -time ns -resistance 1.641228e+02kOhm -capacitance 6.093000e-03pF -voltage V -current mA
RC: set_units -time 1000.0ps -capacitance 6093.0fF

#set_operating_conditions: ignored by cdns tools. See synthesis_DC.txt for details.
set_operating_conditions W_150_1.65 -library PML30_W_150_1.65_CORE.db

 

----------