Cadence Cmds: Legacy / CUI

Details
Last Updated: Saturday, 27 May 2023 05:07
Published: Friday, 14 April 2023 17:38
Hits: 800

Cadence Commands: Legacy Vs Stylus CUI mode

In the past, Cadence had different cmds for their synthesis tools, timing tools and PnR tools. This caused lots of confusion and inefficiency. So, they moved to Stylus CUI (common user interface) around 2015, which tries to use common cmds across all tools. Now, all tools for Synthesis (Genus), PnR (Innovus) and Timing (Tempus) use same cmds which make it easier to port scripts across tools, as well get consistent behaviour across tools for same cmds. NOTE that cmds in Cadence tools are different than cmds in Synopsys tools, even though the name of the cmd might be the same. The arguments of these cmds may be different as well as their behaviour.

FlowKit:

We'll look at the common cmds here, and then look at speciifc cmds in the respective tool section. Before that, let's look at the "FlowKit" that Cadence provides that auto generates scripts for all their flows, which make it easier to get started. We don't have to write our own scripts from scratch, and they have configs, and other hooks to modify scripts as needed.

From within any of the Cadence tool. run this "FlowKit" cmd to auto generate all scripts.

genus_shell:/> write_flow_template => writes the scripts for tools as genus, innovus, Tempus, etc. If you specify dir as scripts, then following are the files generated (llok on Cadence site for all options):

  • Master File: scripts/run_flow.tcl is the master file generated,
  • Step Files: step files are in in scripts/flow/common_steps.tcl, genus_steps.tcl, innovus_steps.tcl, tempus_steps.tcl
  • Template/Config files are in scripts/flow_config.template, design_config.template, genus_config.template, innovus_config.template, tempus_config.template, etc.

Invoking tools:

New tools can be invoked in either legacy mode or in newer CUI mode (as of 2015). Newer CUI mode is the default. However in the new mode, legacy scripts written for older designs won't work. So, a "legacy_ui" switch was added when starting the tool, that would bring up the tool in "legacy mode'. On the shell, it will show "legacy_*>" to indicate that it is invoked in legacy mode. i.e when bringing up Genus, for CUI mode, it will show "genus :/>", while in legacy mode, it will show "legacy_genus :/>". Similarly fort other tools. To test UI mode type, type cmd "is_common_ui_mode" which should shows 0 if in legacy mode and 1 if in CUI mode. Even if we bring the tool in one mode, we can change it to other mode permanently by changing the attribute "common_ui" to true (to change from legacy to CUI) and to false (to change from CUI to legacy). See below steps on how to do it:

 

Started In Legacy mode: Type" genus -legacy_ui" on cmdline. It brings up the tool with "legacy_genus :/>"

legacy_genus :/> is_common_ui_mode => shows "0" implying it's in legacy mode now.

legacy_genus :/> set_attribute common_ui true / => sets mode to CUI

genus@root:> is_common_ui_mode => shows "1" implying it's in CUI mode now. Also, the shell changes from legacy_genus to genus indicating it's in CUI mode.

 

Started In CUI mode: Type" genus" on cmdline. It brings up the tool with "genus@root:>"

genus@root:> is_common_ui_mode => shows "1" implying it's in CUI mode now.

genus@root:> set_db common_ui false / => sets mode to Legacy. NOTE: cmd "set_attribute" is no longer valid as it's not supported in CUI, so use "set_db" instead

legacy_genus :/> is_common_ui_mode => shows "0" implying it's in Legacy mode now. Also, the shell changes from genus to legacy_genus indicating it's in Legacy mode.

 

Gui mode:

Type gui_show on shell to bring up GUI window from within the tool to see the design in graphics form.

Help / Man:

type "help cmd_name" or "man cmd_name" and it will show the details of the cmd. Also, partial cmd name as "help *lib*" will show all cmds with lib in the name. Typing first few letters of cmd followed by a tab shows all possible cmds starting with those letters.

ex: help report_timing => shows man page for report_timing.

Legacy mode:

We saw above how to bring up any tool in legacy mode by using switch "-legacy_ui". Few highlights of CUI mode:

Virtual dir structure: Most confusing feature in Legacy mode is the existence of a virtual dir. This Virtual dir is used by the tool to store various design data. This dir structure is same as in Linux, where top level dir is "/". Inside this, we have subdir as "designs", "object_types", "libraries", etc. These are called containers, and they can be present at any level. All these containers which are part of virtual dir/subdir contain objects and their attributes. The objects belong to object types such as designs, instances, clocks, ports, etc. Attributes are properties of these objects that affect synthesis and opt of these objects.
Path format: To see path of flops under hier-inst, this is what is reported => /designs/m1/instances_hier/m2/instances_seq/my_flop (It shows the full dir path with containers, not easy to know where what is stored)
Most linux cmds work in this virtual dir. Instead of working on Linux dir, they work on Cadence virtual design dir. Let's look at some of these cmds:
  • ls: Just like unix cmd, it lists dir contents. ex: ls / => shows subdir for root dir as shown below. This is the virtual dir that Legacy mode has. It keeps all design, lib, tech, etc info inside it.
    • designs => contains design contents. Here you'll see subdir for top level design (as I_top), and within that dir for as nets, ports_in, ports_out, power, timing, instances_hier, subdesigns etc. As an example, if you  do "ls /designs/I_top/ports_in/", it will show all i/p ports of the top level design. Similarly "ls /designs/I_top/subdesigns/" will show all lower level modules in I_top which is the top level design.
    • libraries =>
    • hdl_libraries      
    • object_types => This has all object types (i.e pin, net, etc) and their attributes under /object_types/<obj_type>/attributes/<attr>, i.e /object_types/pin/attributes/max_capacitance
    • tech        
    • commands          
    • flows         
    • messages    
  • find: Just like unix cmd, it finds the required object of given type and pattern. This is THE most IMPORTANT CMD to find anything in the database relating to design, lib, etc. Since all related stuff is in their respective subdir, just doing a vanilla find in any of these dir works.
    • syntax: find <virtual dir to start searching from> -<object_type> <pattern> => For pattern type, default is glob. regexp is also available
      • ex: find /libraries -libcell DFF2* => Here it finds all libcell object type which match the pattern "DFF2*", starting from dir /libraries in the virtual dir.
  • filter: filter is used to narrow the results.
    • syntax: filter <attribute on the object> <value of the attribute> <list of objects>
      • ex: filter avoid false [vfind /libraries -libcell DFF2*] => attribute name is "avoid" with a value "false" (i.e this returns a list of cells DFF2* that are not avoided)
  • rm: remove or delete design objects.
    • ex: rm /designs/* => removes everything in designs
  • history: history works as native "linux" history cmd, and shows all cmds run before this in the current shell. The reason history cmd doesn't have lhistory is because history cmd is not needed in virtual dir, and so it's usage is retained as native linux cmd.

 All linux cmds have been remapped to "l" prefix followed by the linux cmd.

  • lls: This is the real "linux ls" cmd that lists all files in linux dir. ex: lls dir1/ => list all files/subdir inside <dir1>
  • lpwd: shows current linux dir
  • lfind: Real linux "find" cmd. Finds given file in said dir

We always are in "/" virtual dir when we start the tool, so the shell shows ": />" in legacy mode to indicate it's in virtual dir "/". If we cd into some other virtual dir, it will show that dir at prompt. i.e legacy_genus:/designs/m1/instances_hier/m2>

 

Stylus CUI Mode:

We saw above that by default any tool comes up in CUI mode. Few highlights of CUI mode:

Virtual dir structure:  Virtual dir structure from legacy is changed, and a different dir structure corresponding to design hier itself is maintained. All intermediate containers have been dropped. (instances_hier etc.). A 'object type' string prefixes all object pathnames with a ':' (colon) separating the type-prefix from the object pathname. Path name= <obj type>:<name>. This is known as Dual Port Object (DPO) notation

Path format: To see path of flops under hier-inst, this is what is reported => inst:m1/m2/my_flop (It shows the design hier path with no containers, intuitive as that is how RTL hier is)

So, many of previous legacy "linux alike" cmds are no longer valid. Native linux cmds are supported for Linux filesystem. So, "ls" works as "Linux ls" cmd. If you want to list contents of virtual dir, you have to use "vls" which is "virtual ls". All virtual linux cmds here work in Legacy mode too (i.e ls and vls both work same way in legacy mode).

  • vcd => cd into virtual dir, similar to cd of legacy ui. Similarly "vls" list contents of virtual dir, similar to ls of legacy ui, vpwd, etc.
  • cd => linux "cd" cmd. works on linux file system. Similarly for ls, pwd, etc.
  • find => this is linux "find" cmd. Equiv "find" for objects in CUI mode is "get_db".
  • mv/rm => These are linux cmds. Equiv cmds for objects in CUI mode are "rename_obj", "delete_obj", etc.
    • delete_obj [get_db designs] => deletes everything in designs.

CUI mode shows prompt differently than in Legacy mode. It shows @root instead of "/". If we cd into some other virtual dir, it shows design instance hier., i.e We always are in "/" virtual dir when we start the tool, so the shell shows ": />" in legacy mode to indicate it's in virtual dir "/". If we cd into some other virtual dir, it will show that dir at prompt. i.e genus@hinst:m1/m2>

Differences between Legacy and CUI mode commands:

Objects and Attributes:

Many of the cmds that we see in Synopsys PT for accessing objects and their attr are same in Legacy mode, but slightly different in CUI mode.

Objects are same as what we discussed under PT section. Valid objects are design, port , cell, pin, net , lib, lib_cell, lib_pin, and clock. Each of these objects may have multiple attribute. However attributes defined on objects differ in Cadence tools.

As an ex, each gate may have 100's of attributes as gate_name, size, pins, delay_arcs, lib_name, etc. These objects are further put into several class as ports, cells, nets, pins, clocks, etc. Most commands operate on these objects.

1. Use db cmds to access tool objects: get_db, set_db

2.

 

Genus is the synthesis tool that supports CUI. It's supposed to replace Cadence RC (RTL Compiler), which is the older synthesis tool. Most of the cmds and flow are same as RC. However there are some differences in cmds, etc. So, genus provides 2 modes: a legacy mode, which allows older scripts written for RC to still work in Genus. Then there is newer native mode where new cmds for CUI work in Genus, and legacy cmds from RC may not work anymore. We should move to newer Genus cmds.