SDC - object access cmds

Details
Last Updated: Sunday, 22 December 2024 05:37
Published: Thursday, 15 October 2020 04:10
Hits: 1437

object access cmds:

There are lot of cmds in CAD tools to access objects. These functions in Synopsys/Cadence tools return a collection of objects. Ex of such cmds are get_*, all_* (i.e. all_clocks, get_ports, etc). All these cmds below which return a collection of objects have some common options that can be provided. Collection returned by these cmds may be parsed thru a for loop to access each object of the collection. These cmds/collections being part of SDC can be applied to both Synopsys/Cadence tools.

ex: foreach_in_coll myobj [get_cell .... ] { get_att $myobj clock ... } => Here each object of collection is accessed individually inside the loop.

NOTE: Not all cmds below may not have exactly the same syntax or the same behaviour across vendors, even though they are SDC cmds. I've explained the cmds and corresponding results below as per PrimeTime manual.

Syntax: Syntax of object access function is as shown below:

syntax: cmd <options> patterns => all options are optional

patterns => result of cmd is passed to the pattern filter. There it is compared against these patterns for match, and only matching items are returned. Patterns can be plain pattern, list or collections. Only one pattern argument is supported (i.e "get_cells a_1 b_2" will return error as there's more than 1 arg). Though you are not required to put quotes around patterns, it's good practise to put patterns in " ". This way you can provide more than 1 pattern ( get_cells "a_1 b_2" will work fine as quotes make that whole string as 1 arg). Wildcards * and ? are supported, where * matches 0 or more characters, whereas ? matches exactly 1 character. Note that these match only until separator "/" found, so *,? do not match by descending into the hierarchy. Ex: get_cells *cell1* will match only if cell1 is in top level, i.e matches abcell12, cell1, but won't match A/cell1 or A/cell12 or C/D/abcell12, etc. If we want to match a cell in module A/B, then we have to provide full path as "get_cells A/B/*cell1*" => This will go into hier A/B and look for *cell1* over there. However, it will still not descend hier, i.e it won't go to hier A/B/C to find cell1. If we want to go one level down, we can use something like this: "get_cells A/B/*/*cell1*" => This will descend 1 level down in hier from A/B, and in all those hier modules, it will search for cells *cell1", i.e it will find cells A/B/C/cell1, A/B/D/my_cell1, but not cell A/B/cell1 or A/B/C/E/cell12. So, we need the full hier of cell that we are looking for, i,e number of / in that hier should be known as * will not jump across /. Ex: get_cells *A*/I_cell will only look one hier down in *A* module (i.e I_A, A_tmp, I_A_B, etc). It won't look in tmp/A/I_cell  or A/B/I_cell as that will require crossing hier. Since they may become cumbersome for searching thru all of design as we may not know the leves of hier, option -hier (explained below) is provided which matches across hierarchy.

NOTE: get_cells "top/a_1 top/b_1" will work as it has full names of 2 cells. However, if we have multiple collections (instead of multiple names or patterns), then we have to combine all collections into 1 collection, before using it with the cmd (as collections are just pointers). ex: get_cells "$a_1 $b_1" will error out as both a_1 and b_1 are collections. We have to use cmd =>  get_cells [add_to_collection $a_1 $b_1] => Here $b_1 is added to $a_1 coll and that is passed as arg to get_cells, which works !!

options =>

  • -hier => this option allows us to search for patterns across hierarchy starting from current instance. It's similar to unix "find" cmd. However, we don't provide hier path in pattern, we just provide the final object name. Ex: get_cells -hier *cell1* will match cell1 across all hier, i.e A/cell1, A/cell12, etc. However, with this option, we cannot provide hier path as A/B/*cell1*. It will error out with "Error: Nothing matched". This is because just as "find" cmd, it looks for exact pattern match across all hier. The cell name in object database is cell1, and NOT A/B/cell1, even though cell1 exists in module A/B, and gets reported as A/B/cell1. So, it's important to understand the diff b/w patterns when using hier and when not using hier. When not using -hier, we can provide the full hier path to descend to, but when using hier, we can only provide the final net or cell name, but not the hier. "-hier" option matches any matching pattern at any hier. i.e mod12 will match A/mod12 even though A/mod12 has further modules inside it as A/mod12/B. If we want to limit our search to specific hier as A/B, we should use -filter option (-filter "full_name =~ */A/B/*"). There is no other way to do it.
    • IMP: However, what I've seen is that the pattern that you can provide when you use -hier option is dependent on the cmd itself. For ex: get_cells, get_pins and get_nets accept different kind of patterns when used with -hier. See in their respective cmd description below.
  • -regexp -nocase => These are used when more complex pattern matching is required. *,? match simple character, but if we want to match let's say 2 digits followed by 1 letter, then we need to use regular expression. -regexp allows us to use regular exp for matching (i.e \d+). using \d+ with -regexp will look for 1 or more decimal digits, but if we do not use -regexp, then it will look for \d+ in the objects returned for a match. By default, upper/small cases are matched. -nocase means case insensitive matching. Regexp is same as tcl regexp. Use rigid quoting with { } around patterns as in tcl regexp. If -filter option is used (explained below), then regexp also modifies filter operators to match regexp, instead of simple wildcard patterns. There are some interesting cases with regex. Ex below:
    • Ex 1: get_cells -regexp  {my_mod/m[0-9]+_sys/cpu/mem/a_m[0-9]+} => Here we enclosed the pattern in {...}. That way the pattern is only used by getcells cmd as a regex. Here it matches name "with numbers 0-9 in them. This is the most common and preferred way to use regex.
    • Ex 2: get_cells -regexp  my_mod/m[0-9]+_sys/cpu/mem/a_m[0-9]+ => Here we did NOT enclose the pattern in {...}. So, tcl interpretor interprets this pattern before the regex gets into picture. Since it has [..] which executes a tcl cmd, it starts executing [0-9] which it finds is an invalid cmd. So, we get error "Error: unknown command '0-9' (CMD-005)"
    • Ex 3: get_cells -regexp  my_mod/m\[0-9\]+_sys/cpu/mem/a_m\[0-9\]+ => It's same as above, except that we preceeded "[" with backslash metacharacter, which prevents "[" to be treated as a metacharacter but instead as a literal for tcl interpretor. So, the pattern passed to the regex is "my_mod/m[0-9]+_sys/cpu/mem/a_m[0-9]+" which is exactly what we achieved with curly braces in 1st ex above.
    • Ex 4: get_cells -regexp  {my_mod/m\[0-9\]+_sys/cpu/mem/a_m\[0-9\]+} => This is same as above, except that we added { ... }. Compared to 1st ex, the only diff is that we now have backslash "\" with "[", which should cause "[" to be treated as literal and not as metachar. So, this should not have found any cell, as there's no cells with names "...m[0-9]..". To my surprise, it gives exactly same answer as ex 1 above.
    • Above we proposed use of { ... } for regexp pattern. However, when we have var that need to be expanded than {..} become a problem, as the var to be substituted may have it's own curly braces. In such cases, we have to get rid of the curly braces used with regexp. See ex below.
      • Ex: get_cells -regexp  {${mod_name}/m[0-9]+_sys/cpu/mem/a_m[0-9]+} => This searches for "${mod_name}/m...". It didn't expand $mod_name with it's value. We get a warning/error "Warning: No cell objects matched '${mod_name}/m...". Even if we put backslashes as "\$\{mod_name\}" or $mod_name, it keeps giving the same error. The only way to resolve it is to get rid of the outer {...} that we used with regex. We also have to put "\" before [,] (as in Ex 3 above). Then tcl interpreter is able to expand ${mod_name} and also treat [..] correctly. So, the fixed version is "get_cells -regexp ${mod_name}/m\[0-9\]+_sys/cpu/mem/a_m\[0-9\]+"
  • -exact => This matches exactly the pattern, without even substituting simple *,?. This is helpful, when *,? are part of the name of object itself, and you do not want *,? to be used as wildcards
  • -filter <expression> => result returned is filtered against the criteria here.  expression should be put in "expr". This is different than pattern matching, as here we can match for object's attributes. If expr evaluates to true, result is returned. Filter operations are series of relations (relation is an attribute name compared with a value thru a relational operator) joined together with AND/OR operators. The relational operators are ==(equal), !=(not equal), =~(matches pattern), !=(doesn't match pattern), >, <, >=, <=. Existence operators are defined, undefined.
    • NOTE: =~ should be used for patterns while == is used for exact match. So, full_name == *reg* will exact match "*reg*" (won't consider * as special char, same as using option "-exact"), while full_name =~ *reg* will match for pattern "reg" (i.e my_reg, reg_1, etc will match).
    • ex: -filter {"is_hierarchical == true AND undefined(sdf) && full_name =~ *\/mod1\/*reg1*"} => matching patterns match across hier i.e "/",
    • ex: -filter "full_name =~ *mod1*reg1*" will match across hier as mod1/reg1 or names as mod2/mod1_reg1_3 etc. having backslash char before regular forward slash is not really reqd, i.e "full_name =~ */mod1/*reg1*" is equally valid syntax. curly braces is optional, but it helps to keep everything inside filter as 1 block. This way of filtering is very powerful as this is the only cmd that works to find a cell/net, etc across specific hier in a design, when you don't know the levels of hier.
  • -quiet => Suppresses warning and error messages if no objects match.  Syntax error messages are not suppressed. Should not use -quiet as it could hide some design issue.
  • -of_objects <objects> => we can also use shorthand -of instead of -of_objects. cmd applies only to these objects. Depending on the cmd, it will look for collection of cells, etc connected to these objects specified here (objects can be either names or collection of ports, pins, gates, etc). NOTE: This is the most important option to trace design.

Ex: get_cells * -filter "is_hierarchical == true" => same as filter_collection cmd above. This is more efficient as objects are filtered out even before they are included in collection.

A lot of commands in CAD tools returns collection, while lot of commands expect collections as arguments. Cmds that expect collections as arguments cannot be given patterns or names, or else they will error out.

Many of the above options can be used across multiple cmds in timing, synthesis and PnR tools. All options above can be used as args in below cmds.

 

 

1. DESIGN get_* cmds => get_cells, get_clocks, get_nets, get_designs, get_pins, get_ports. These cmds find these objects relative to the current instance (i.e current hierarchy) from the current design (i.e instances in design, not lib cells in design).

  • get_cells => useful to find all cells or particular matching cells in design. i.e find all flops, or gates with certain drive strength, etc. It reports all cells (i.e modules in design. they don't have to be leaf cells).
    • ex: get_cells top/cell1* => {"top/cell1", "top/cell12"} => this gets cells present in "top" module only. Doesn't match "A/top/cell1" as explained above.
    • ex: get_cells -hier * => gets a collection of all cells across all hier. -hier => traverse thru all hier, otherwise it searches only in curent hier and doesn't descend down. NOTE: it shows modules, etc too.
    • ex: get_cells -hier cell1* => {"top1/cell1", "top1/cell1", "top2/mod3/cell12", ...} => this gets cells matching cell1* across all hier of design. NOTE: we can't do "get_cells -hier top1/cell1*" as explained above in common section.
    • ex: get_cells -hier {U_and2 U_or2} => returns cell {"chip/mod1/U_and2", "chip/U_and2, "chip/U_or2"} => Here it looks for exact cell name match as there are no wild card char. We can provide multiple cell names in the list, and it will look for any of the matching ones.
    • ex: get_cells -hier cell1* -filter "full_name =~ *top2/mod3/*" => {"top2/mod3/cell12", "A/B/top2/mod3/C/cell1"} => Above -hier option doesn't allow us to select specific modules to look in for that cell. This is one of the ways to get all matching cells in a certain hier. This just searches for matching name in the full name of cell returned, and if it matches, it returns those cells (* are needed in full_name pattern, else exact names will be searched for). This is the most popular form of using get_cells cmd. i.e always use "full_name" filter cmd as it always works, and is less error prone than writing complex patterns.
    • ex: get_cells -hier -filter "full_name =~ *top2/mod3/*cell1*" => This has no search pattern for cells, so searches for all cells. However, the search is limited to filter expr "*top2/mod3/*cell1*".
    • Finding all leaf cells within all hier of design: This is tricky as there is no "-leaf" option (as in get_pins which has a -leaf option). By default, get_cells reports all modules/sub-modules along with leaf cells which is underirable. Using -filter "is_hierarchical == false" gets leaf cells only
      • get_cells -hier * -filter "is_hierarchical == false" => this returns a collection of all leaf cells across all hier.
    • Finding specific cells within all hier of design:
      • ex: get_cells -hier * -filter "ref_name =~ SDF*" => this returns a collection of all cells which have reference cell name starting with SDF (i.e scan data flops). Basically, it gets all scannable flops in design, across all hier.
    • Finding specific cells within a given hier of design:
      • ex: get_cells -hier * -filter "ref_name =~ *SYNC_LIB* && full_name =~ I_top/pad/u_pcie/*" => This gets all cell under hier "I_top/pad/u_pcie/" whose ref name has SYNC_LIB in it. This will find cells as I_top/pad/u_pcie/cell1, I_top/pad/u_pcie/mod2/cells2, etc. i.e anything within the hier mentioned.
    • Finding all instances of a given lib cell: Ex is under  "get_lib_cells" section below.
  • get_pins => used to find all pins in design. Pins are the names assigned to I/O ports of modules or pins of library cells. These same names are carried to pins of instances (i.e D pin of "MSFLOP" library cell is also named as D pin of "reg1" flop, which is an instance of MSFLOP). -leaf option is unique to "get_pins". It returns only leaf (non hier) pins. Hier boundaries are crossed automatically to find such pins, so -hier option is not allowed with -leaf option. The pins reported are 1 driver pin and multiple load pins. If -leaf is not used, then pin names of modules and then lower level modules are shown which is similar to a net name, and not of much use to us. -leaf option is widely used to find driver of a net. See ex below
    • ex: get_pins o*/CP => {"o_reg1/CP", "o_reg2/CP", "o_reg3/CP"} => same pattern style as in get_cells
    • ex: get_pins "chip/mod1/U_and2/*" => returns 3 pins {"chip/mod1/U_and2/A1", "chip/mod1/U_and2/A2", "chip/mod1/U_and2/ZN"}
    • ex: get_pins -hier A1 => errors out with "Error: Nothing matched". This should have matched as in above ex, we see there is a pin A1 on cell "chip/mod1/U_and2/A1". Similar "get_cells -hier cell1" gave us valid cell names. The reason is that pins are stored along with name of their cell as one enity, so just a pin name by itself won't match anything. So pin Z is actually I_and2/Z. So, we have to provide matching cell name to which the pin is attched to.
      • ex: get_pins -hier U_and2/A1 =>this returns valid pin {"chip/mod1/U_and2/A1"}. So, this matches our understanding that cell_name/pin_name is considered one entity for pins for pattern matching. "get_pins -hier *U_and2/A1" also returns correct results, as does "get_pins -hier *A1" or get_pins -hier */A1". This is because they all match object "U_and2/A1". The hier before the name of the cell (U_and2) doesn't matter as that is not considered for matching purpose. It's only the name of the immediate cell that the pin is attached to and the pin, that is considered. So, "get_pins -hier */U_and2/A1" or "get_pins -hier chip/mod1/U_and2/A1" returns error "Error: Nothing matched", as the pin object name is U_and2/A1, so any other pattern fails matching (even though "chip/mod1/U_and2/A1" pin exists. "get_pins -hier *U_and2*" matches all pins in all hier for cells *U_and2*, so top/I_U_and2/A1, top/I_U_and2_0/A2, U-and2/Z, etc will match.
      • ex: get_pins -hier *DATA[*] => Here DATA[*] is port of a lower level module. Ports of a module are considered as pins (Ports are ONLY top level input/output ports of design). So, this will report DATA[*] ports of all submodules. We may include the submodule name also, as part of pin, as the pin is attched to submodule. ex: get_pins -hier *module1/DATA[*] => returns Top/I_module1/DATA[0], I_top/.../module1/DATA[1], etc.
      • ex: get_pins -hier gate_or2/A1 -filter "full_name=~*top1*" => This is similar usage as in get_cells ex above. Matching with "full_name" allows us to select specific modules, here top1. This matches all pins in any module where the path contains "top1", i.e A/c_top11_m/gate_or2/A1 matches and is returned in results. This is useful in cases where we want pins only from a certain hier.
      • ex: get_pins -hier gate_or2/A1 -filter "full_name=~*" => This matches cell "gate_or2/A1" in any module in any hier. So, it's similar to "get_pins -hier gate_or2/A1". We could have also used *gate_or2/A1 which would have matched blah_gate_or2/A1, but we could not use */gate_or2/A1
    • get_pins -quiet -of_object $latch_coll -filter "full_name=~ */Q and defined(clocks)" => Here we are getting Q pins of all clocked latches in a collection. This is easy way to extract any pin of cells from a given cell collection.
  • get_nets => creates collection of nets.  Since the same net can have multiple names at different levels of hier, 3 additional options are provided to get the name of net in any way desired (i.e -top_net*, -segments and -boundary_type). "-boundary_type <type>" allows 3 options of lower, upper or both (lower returns lower level or net inside the hier block, upper returns higher level or net outside the hier block, while both returns both nets. -of_objects option is required when using "-boundary_type" option. By default, upper or higher level net is returned on a hier pin. See PT manual for more details on options.
    • ex: get_nets block1/NET* => {"block1/NET1QNX", "block1/NET2QNX"}
    • ex: get_nets top/*A/* => returns all nets in top/*A module (i.e top/MA/net1, top/NO_A/net2, etc)
    • ex: get_nets chip/mod1/U_and2/* => This errors out "Nothing matched" as leaf cells (i.e gates, IP or any lib cells) just have pins and no nets defined (assuming U_and2 is a lib cell i.e AND2_NOM_*).
    • get_nets -hier NET1* => gets NET1* net in any hier of design. So, -hier option in get_nets behaves same way as in "get_cells -hier" cmd.
    • get_nets -of_objects [get_pins $pin_collection] -top_net_of_hierarchical_group -segments => This returns top hier net name that all the specified pins are connected to. This is useful in correlating net names in gate level to net names in RTL, as top level net is most likely the same name in both RTL and gate. This is particularly helpful in tracing when certain pins in gate level have set_case of 0 or 1, and we want to trace that net in RTL.

NOTE: all 3 cmds above, get_cells, get_pins and get_nets when used with option "-of_objects" can be combined to navigate a design, and are very powerful for tracing connectivity in design. Given any object we can trace it's drivers or loads (i.e if we want to trace back connection of a net, we can find o/p pins connected to that net, then find cells for those pins, then continue this path recursively by finding i/p pins of that cell and nets connected to that pin, and find pins of other driving cell and keep on going back by using this option)

Get all pins of cell: get_pins -of [get_cells [get_attribute $cell full_name]] => Here we get pins of given cell.In short form, we can also write: get_pins -of [get_cells $cell]

Get all connected pins of a net: There are 2 ways: 1 shown under "PT - all cmd" section. That uses  "all_connected ... -leaf". The other option is one shown here using get_pins -of ... -leaf".

ex: get_pins -of_objects [get_nets top/net1]  -leaf => This returns output in form {"top/inv/Z", "top/and2/A", "mod2/phy/IN1"} where one of them is driver, others are all load pins. pins may be ports on PHY or BlackBox also (as ports of PHY/BlackBox are eventual driver or load pins). If we don't use -leaf option, then only pins at hier module level are shown.

  • Get Drivers only: If we restrict ourselves to driver only, we use option: -filter "pin_direction==out".
  • Get Loads only: To restrict ourselves to load only, we use option: -filter "pin_direction==in". 
  • Get cells instead of pins: If we want to find cells instead of pins, we just do get_cells -of [get_pins $pin_collection] where $pin_collection is collection of all pins we got above. Or we can directly write => get_cells -of [get_pins -of ... -leaf]. We can't get cells directly by using "get_cells -of_objects [get_nets top/net1]" => This will show next level cell which may be a module and NOT the leaf cell. So, we have to go thru finding leaf pins, and then find leaf cell names via that route.

Get all nets on a pin: set net_name [get_attribute [get_net [all_connected [get_pin $full_pin_name]]] full_name] => assigns collection of "net" object to "net_name"

Finding Object type: The above cmds can be used to find out if the given object is a cell, pin, port or net. (i.e if "get_cells obj_name != "", then that means it's a cell).

  • get_ports => displays all ports of current design or current instance. Ports are I/O ports of design at current level. This cmd doesn't have -hier option, as there are no ports at lower hierarchical level for a design.
  • get_clocks => creates collection of clocks. ex: set clock_list [get_clocks "PHI*" -filter "period==15"] =>
  • get_timing_arcs => Creates a collection of timing arcs. This is same as get_lib_timing_arcs explained below, except that here it reports arcs for cells in design. Arcs would be the same as those reported for lib cells by using get_lib_timing_arcs. This cmd is useful in situations where we want to see the arcs on instance itself, instead of trying to find the lib cell for that instance.
  • get_timing_paths => creates collection of paths for custom reporting. It has a lot of options, which are different than std options for get_* cmds above. Most of the options here are same as those for report_timing cmd, We most commonly use report_timing cmd to report paths satisfying certain criteria. However to automate doing any operations on these paths, it is not easy to work with report_timing. get_timing_paths allows us to do any kind of custom manipulation/reporting for any of the paths, and get any attribute of these paths (i.e slack, etc). Widely used when automating scripts for large designs to report paths.

 

 

2. LIB get_lib_* cmds: These cmds are same as 1 above, except they find this info from inside library (lib loaded into the CAD tool, irrespective of whether they are used or not), and not from design. -hier option is not supported for any of get_lib* cmd. We can use option -of <object_name> to get lib data of specified objects (this may be name of libcell in library, or instance name depending on the cmd) or just provide the pattern w/o -of, in which case it'll return the lib/lib_cells matching the pattern (direcly from .lib file)

  • get_libs => Creates a collection of libraries in memory whose name matches the pattern. These library are the names mentioned in .db files under "library(...)". "-of <lib_cell_name>" option provides the lib corresponding to given lib cell.
    • ex: get_libs => {"TSM_W_125_2.5V", "TSM_S_-25_3.6V", ...} => NOTE: lib names may also be with .db extension (depending on what's the name provided in library(...) of .db file). This .db doesn't mean it's the file name, it's still the name of library.
      • Cadence Genus: get_libs
    • get_libs -of */tsmc_INV_D2 => This will give us the library of tsmc_INV_D2 stdcell. o/p will be {"TSM_W_125_2.5V"} or whatever libs we have which have cell "tsmc_INV_D2" in them
    • ex: get_libs *S_-25* => This will list all libs matching this name. NOTE: libraries are listed in o/p, but we have to query the collection to display all libraries. To display all libs directly (for viewing purpose), use list_libs.
    • list_libs => lists all libs read into PT. This is output as a list, so easier to be read. No options provided except -only_used which lists only those libs that are linked to design. M=>max lib, m=>min lib, *=>main lib.
      • ex: list_libs -only_used => Lib1 /db/.../lib1_PVT.db: Lib1    Lib2 ...   and so on. So, it shows all libs along with paths, as well as which are min/max. So, more commonly used.
  •  get_lib_cells (or get_lib_cell) => Creates a collection of library cells from libraries in memory whose name matches the pattern. These lib cells are the ones with string "cell(<cell_name>) { ... }". This string is present within library section (shown in get_libs above) of .db file. It is similar to get_cells, except that it displays cell definition (cell library name), and not cell instances (instance name used in design). Usually get_cells cmd is used as an input to get_lib_cells cmd, so that it's in proper format.
    • ex: get_lib_cells CGP* =>  prints all cells starting with CGP for all libraries => o/p in DC/EDI = TSM_W_125_2.5_CTS.db/CGPT80    TSM_S_-40_3.6_CTS.db/CGPT80 ....
      • Sometimes "get_lib_cells *" says "no matching cells found" as it's looking for cells not inside .db files but at top hierarchy. In order to get cells inside .db lib, we have to specify the library name. See next example:
    • ex: get_lib_cells TSM_W*/CGP* => prints all cg cells in all libraries starting with TSM_W =>o/p is diff for Synopsys vs Cadence tools
      • o/p in DC/EDI = TSM_W_125_2.5_CTS.db/CGPT80 TSM_W_125_2.5_CTS.db/CGPT40 TSM_W_125_2.5_CTS.db/CGP80 TSM_W_125_2.5_CTS.db/CGP40,
      • o/p in RC = /libraries/TSM_W_125_2.5_CTS.db/libcells/CGP40 ...
    • ex: get_lib_cells */*myphy* => This shows all *myphy* cells in any library. 1st * refers to any library(...)
    • ex: get_lib_cell -of_object Top/abc/my_an2 => When we use -of, then we get lib_cell corresponding to that object (object should be a cell instance name). This shows the lib cell used for that gate instance. o/p is {"TSM_W_125_2.5_stdcell/AN2"}. This is very powerful cmd used in any design to find out which libcell is getting used for gates that are reported in timing paths. "-of" or "-of_objects" is required, else it errors out "nothing matched" as it's looking for lib cells with that name (in absence of -of, it becomes like ex 1 ,2 and 3 above). We can use quotes too for object, i.e "Top/abc/my_an2"
    • ex: get_lib_cells -of [get_cells -hier *phy*] => same as above, except here we used -hier option to look in all of design for that phy cell. This is helpful when we just know the instance name of the phy, but don't know where in design is it. get_cells gets the o/p in proper format to be passed to get_lib_cells.
    • Finding all instances of a given lib cell: ex: get_cells -of TSM_2.5/AN2 => This shows all cell instances in design which are using lib cell TSM_2.5/AN2. So, this is reverse of what we use get_lib_cells for. get_lib_cells gives lib_cell for a given instance, while get_cells gives all instances in design for a given lib cell.
  • get_lib_pins => Creates a collection of library cell pins from libraries in memory whose name matches the pattern. It is similar to get_pins, except that it displays cell library pins, and not cell instance pins.
    • ex: get_lib_pins -of_objects o_reg1/Q => returns {"misc_cmos/FD2/Q"} => this shows how lib pin is used by pin in netlist. As can be seen, it's same pin name "Q" in both lib cell and instantiated cell
    • ex: get_lib_pins misc_cmos/AN2/* => returns {"misc_cmos/AN2/A", "misc_cmos/AN2/B", "misc_cmos/AN2/Z"}. NOTE: /* is needed at end to get all pins. If we just do "get_lib_pins misc_cmos/AN2" then we'll get an error "can't find lib pin misc_cmos/AN2" since it's a cell and not a pin.
  • get_lib_nets => There is no counterpart of "get_nets" cmd above, for libcells, as lib cells don't have nets accessible inside them.
  • get_lib_timing_arcs => Creates a collection of library arcs. This is very important to check that all arcs present in .lib or .db are showing here correctly for all cells. Every arc reported here is an arc with "timing_type" under timing section of that pin. So, if we find that D pi of Flop has 8 arcs for D pin in .lib file, we should see 8 arcs in this collection under arcs for D pin. The options supported here slightly different from standard options above. They are -to, -from, -of_objects, -filter, -quiet.

Ex: Since get_* cmds give collections, we will need to process this collection to display attributes of interest. The below proc (taken from synopsys website) gets all relevant info from each arc to display it nicely. Attributes store the arc info. The various attributes of lib timing arcs are: from_lib_pin, to_lib_pin, sense, sdf_cond, mode, object_class (=lib_timing_arc for all lib arcs), is_disabled, is_user_disabled. sdf_conf and mode may not exist in all libraries, so comment them out if not needed (else you may see a lot of warnings)

proc show_lib_arcs {args} {
 set lib_arcs [eval [concat get_lib_timing_arcs $args]]
 echo [format "%15s %-15s %18s %18s %18s" "from_lib_pin" "to_lib_pin" "sense" "sdf_cond" "mode"]
 echo [format "%15s %-15s %18s %18s %18s" "------------" "----------" "-----" "--------" "-----"]
 foreach_in_collection lib_arc $lib_arcs {
  set fpin [get_attribute $lib_arc from_lib_pin]
  set tpin [get_attribute $lib_arc to_lib_pin]
  set sense [get_attribute $lib_arc sense]

  set is_disabled [get_attribute $lib_arc is_disabled]
  set sdf_cond [get_attribute $lib_arc sdf_cond]
  set mode [get_attribute $lib_arc mode]
  set from_lib_pin_name [get_attribute $fpin base_name]
  set to_lib_pin_name [get_attribute $tpin base_name]
  echo [format "%15s -> %-15s %18s %18s %18s %18s" $from_lib_pin_name $to_lib_pin_name $sense $sdf_cond $mode $is_disabled]
  }
}

pt_shell> get_lib_cell -of_object Top/u_SPI_PAD => {"tsm_1p6v_m25c/LOW_PAD_V"} => This gives the PAD cells being used in design.
pt_shell> show_lib_arc -of_objects tsm_1p6v_m25c/SDF_SVT => getting lib arcs for SVT flop. 2 arcs on D pin for setup/hold, 1 c2q arc for Q pin and 1 min_pulse_width arc for clk pin. "from_lib_pin" is the related_pin in the lib, while "to_lib_pin" is the real pin whose arc is defined wrt the related_pin.

   from_lib_pin to_lib_pin                   sense           sdf_cond              mode
   ------------          ----------                   -----               --------                    -----      
             CP -> D                    hold_clk_rise         cond1    etm => n such arcs if n diff sdf conditions and/or mode exist. "timing_type" is "hold_rising" on D pin (related_pin as CP) in .lib file
             CP -> D                   setup_clk_rise      ncond1     etm => timing_type : setup_rising
             CP -> CP              clock_pulse_width_high     cond2     etm => n such arcs if n diff sdf conditions and/or mode exist. timing_type : min_pulse_width, rise_constraint

            CP -> CP              clock_pulse_width_low     cond2     etm => timing_type : min_pulse_width, fall_constraint
             CP -> Q                      rising_edge  D==1'b1&&SE==1'b1     etm => It's "timing_sense : negative_unate" and "timing_type : rising_edge" in .lib. n such arcs if n diff sdf conditions and/or mode exist

pt_shell> show_lib_arc -of_objects tsm_1p6v_m25c/INV_LVT => getting lib arcs for LVT INV

   from_lib_pin to_lib_pin                   sense           sdf_cond              mode
   ------------          ----------                   -----               --------                    -----      

              I -> ZN                  negative_unate     n/a    n/a => Here sdf_cond and mode are not defined for inverter cell. There is only 1 arc for inv in .lib. It's "timing_sense : negative_unate" and "timing_type : combinational"

NOTE: see report_lib cmd below which are alternative cmds to display same info in user readable format.

 

 

report_* cmds:  Since get_* cmds above return collection, it's not easy to view them unless we write a prc to go thru the collection. So, we have corresponding report_* cmds to display the output in user readable format. option "-nosplit" is supported for all of these report_* cmds which makes these reports more readable. -nosplit prevents line splitting, so that it's easier to read and extract info by other tools.

3. Design report_* cmds: These are report cmds for corresponding design get_* cmds . report_cell and report_hierarchy are most used ones as they give info about all cells with references used.

  • report_cell => This cmd shows cell info like reference lib cell, library it comes from (doesn't show the path for library file though), area, min/max OC (operating conditions) used, rail voltage, etc. By default, it shows info for current design. However, we can specify a instance name to generate info for only that instance. Lib shown is the link_lib, while OC shown are from inside the link lib. However, sometimes lib shown may not be link lib, although OC shown may be from link_lib (this happens in PT DSLG scaling flow where multiple libs are loaded, look into that section). Few more report_cell_* cmds supported.
    • ex: report_cell => reports info of all cells in current design. It doesn't go down the hier. Most of the times, our "current_design" is top level, so it gives info for top level design and blocks/cells at top level
    • ex: report_cell I_top/X/an2 => It shows ref cell, library and Max/Min OC, etc for cell specified. More than 1 cell can be specified via double quotes "I_a/an2 I_3/Y/nr3 ...".
    • ex: report_cell -verbose -connections => shows all above info for current design + connections of pins of cells and pins/nets they connect to. So, the driver/load pins of other cells connecting to cells of current design are shown. 
  • report_reference => displays all references in the current design (to whatever current design is set to, it. It doesn't go down the hier. This doesn't have any more options (except for -nosplit). This cmd not used as "report_cell" already does more than what this cmd does. NOTE: equiv DC cmd "report_reference" has different syntax and allows -hier option. Look in DC note.
  • report_hierarchy -full => displays references for all leaf cells in the current design (It goes down the hier). So, this cmd very useful to see the whole hierarchy and ref cells being used at the lowest leaf cells. option -noleaf omits reference cell info for leaf cells.
  • report_design => Displays attributes of the current design. Very useful cmd to see all libs, op cond etc used for current design.
  • report_port => Displays summarized info (maxcap, maxload, maxfanout, drive res, i/p transition time, driving cell, i/o-o/p delay, etc) about all ports in the current design. Lots of options supported
  • report_net => Just as in report_port, it reports info about all nets in current design. Lots of options supported
  • report_clock => shows all clock info. Explained in "PT clk cmd" section. Few more report_clock_* cmds supported.

4. Lib report_* cmds: report_lib and report_lib_groups are the only 2 cmds supported here. These are report cmds for corresponding lib get_lib* cmds.  As mentioned above, the above get_* cmd is cumbersome cmd to use to display all arcs. An easier way is to use: report_lib.

  • report_lib lib_name => this displays all lib cells for that library (We provide the name listed in library section of .lib file). To get more info about few lib cells, provide names of cells too.
    • ex: report_lib TSM_W_5Vt {AN2_SVT OR2_ULVT} => reports detailed info about these 2 cells from named library. Omitting names of lib_cells, reports all cells.
    •  ex: report_lib -timing_arc tsm_1p6v_m25c {SDF_SVT} => To get details on timing or power arcs, use -timing_arcs (or -timing) or -power_arcs (or -power)

                            Arc                   Arc Pins
   Lib Cell  Attributes    #  Type/Sense      From        To         When
   ----------------------------------------------------------------------------
   SDF_SVT
                 s         0  hold_clk_rise   CP          D          !SE&SDI => multiple arcs may exist for multiple sdf conditions
                           2  setup_clk_rise  CP          D          !SE&SDI

                         12 clock_pulse_width_high      CP          CP         SE&SDI => for timing_type "min_pulse_width" rise constraint
                         27 clock_pulse_width_low       CP          CP          SE&SDI => for timing_type "min_pulse_width" fall constraint
                         31 rising_edge     CP          Q          !SE

 

  • ex: report_lib -timing TSM_W_150_1.75_CORE.db {DTB10 } => cell DTB10 is a flop and it has both PREZ/CLRZ with Q/QZ o/p
    Total 21 arcs below:
                                Arc                   Arc Pins
       Lib Cell  Attributes    #  Type/Sense      From        To         When
       ----------------------------------------------------------------------------
       DTB10         s     0  clock_pulse_width_low            => min_pulse_width_low on pin (CLK)
                                                  CLK         CLK
                               1  clock_pulse_width_high        => min_pulse_width_high on pin (CLK)
                                                  CLK         CLK
                               2  removal_rise_clk_rise        =>  removal_rising on pin=PREZ, related pin=CLK
                                                  CLK         PREZ    
                               3  recovery_rise_clk_rise          =>  recovery_rising on pin=PREZ, related pin=CLK
                                                  CLK         PREZ
                               4  hold_clk_rise   CLK         D     => hold_rising on pin=D, related pin=CLK
                               5  setup_clk_rise  CLK         D     => setup_rising on pin=D, related pin=CLK
                               6  removal_rise_clk_rise          => same as for PREZ pin
                                                  CLK         CLRZ
                               7  recovery_rise_clk_rise        => same as for PREZ pin
                                                  CLK         CLRZ
                               8  rising_edge     CLK         QZ    => rising_edge on pin=QZ, related pin=CLK
                               9  rising_edge     CLK         Q     => same as for QZ above
                               10 clock_pulse_width_low              => min_pulse_width_low on pin=PREZ
                                                  PREZ        PREZ
                               11 nonseq_hold_rise_clk_rise        => non_seq_hold_rising on pin PREZ, related pin=CLRZ
                                                  PREZ        CLRZ
                               12 nonseq_setup_rise_clk_rise    => non_seq_setup_rising on pin PREZ, related pin=CLRZ
                                                  PREZ        CLRZ
                               13 preset_high     PREZ        QZ    => preset type on pin QZ, related pin=PREZ (positive unate)
                               14 clear_low       PREZ        QZ    => clear type on pin QZ, related pin=PREZ (positive unate)
                               15 preset_low      PREZ        Q    => preset type on pin Q, related pin=PREZ (negative unate)
                               16 nonseq_hold_rise_clk_rise        => same as for PREZ pin
                                                  CLRZ        PREZ
                               17 nonseq_setup_rise_clk_rise    => same as for PREZ pin
                                                  CLRZ        PREZ
                               18 clock_pulse_width_low        => same as for PREZ pin
                                                  CLRZ        CLRZ
                               19 preset_low      CLRZ        QZ    => preset type on pin QZ, related pin=CLRZ (negative unate). same as 20 except it's on QZ pin
                               20 preset_high     CLRZ        Q    => preset type on pin Q, related pin=CLRZ (positive unate). Here, PREZ and CLRZ are both low, giving Q=0 (assuming CLRZ has higher priority). If CLRZ goes high, then Q goes high (due to PREZ being low)
                               21 clear_low       CLRZ        Q    => clear type on pin Q, related pin=CLRZ (positive unate)

 

5. misc report_* cmds: misc 100's of report_* cmds to report almost anything about design. Look in DC or PT manual for syntax of these cmds. Few imp ones:

  • report_timing => most useful cmd. It's explained under it's own section "PT report_timing cmd"
  • report_activity* => reports various activity
  • report_

6. attribute related cmds: These are report_attribute, get_attribute, etc. These are explained in "SDC" section.

more cmds: