synthesis: Cadence Genus

Details
Last Updated: Tuesday, 05 December 2023 12:51
Published: Wednesday, 17 February 2021 21:04
Hits: 6597

Genus:

Genus is the latest Synthesis tool from Cadence released somewhere around 2015. Before that RC (RTL Compiler) was the Synthesis tool from Cadence. Genus supposedly has better correlation with PnR and Timing tools from Cadence, as some of the engines that are used in those tools are used over here in Genus.

Legacy Vs CUI mode:

Genus uses CUI mode by default. Below are some diff b/w DC and Genus cmds:

DC Command
Genus Command
Notes
get_attribute get_property Most of DC "attribute" cmds have corresponding "property" cmds in Genus.
define_user_attribute define_attribute Other Cadence tools (Innovus/Tempus) use define_property (as expected), but surprisingly Genus doesn't support this, it has its own different define_attribute instead.
list_attributes list_property Genus. Tempus and Innovus all use list_property
set_user_attribute set_attribute Again, Genus uses "attribute" instead of "property". Here the argument order is different than in DC, objects need to come last in Genus
alias alias alias A B C works for DC but should be alias A "B C" for Genus. only double quote. Single quote doesn't work
report_path_group report_timing -cost_group * path group doesn't have a separate cmd in Genus
set_path_margin set_path_adjust  
get_cells, get_net, get_pins, get_lib_cells get_cells, get_net, get_pins, get_lib_cells same as DC (these are SDC cmds)
remove_designs * delete_obj /designs/* Genus has virtual linux style dir structure
read_verilog read_netlist same as DC
current_design Itop current_Design Itop same as DC
report_timing report_timing same as DC (these are SDC cmds)
set_false_path, set_multicycle_path, set_case_analysis, .. set_false_path, set_multicycle_path, set_case_analysis, .. same as DC (these are SDC cmds)
     
 SDC cmds are partially supported in genus.
Genus help:
On genus shell, 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.
-------

Genus flow:

It's same flow as RC.

run Genus: script run.tcl

LEGACY MODE: genus -legacy_ui -f tcl/run.tcl -log /logs/top.log => prompt shows as genus@root:>

CUI MODE: genus -f tcl/run.tcl -log /logs/top.log => prompt shows as legacy_genus :/>

NOTE: Now you can use genus cmds on prompt. To see gui, type gui_show. (See section on "Cadence cmds" for details on CUI vs Legacy).

 

 

Steps:

1. Read Tech libs:

The default search path for libraries, scripts, and HDL files is the directory in which Genus is invoked. To specify non default path for library, set following attributes:

set_db lib_search_path

 

2. Read RTL:

3. elaborate => converts HDL rep into a netlist and performs High Level Opt (HLO). HLO here include Mux optimizations and Spasreness and redundancy opt

4. Read UPF, Timing constraints, DEF => UPF needs to be read only if there are multiple power domains in the design.

5. syn_gen => synthesize to generic gates. Performs data path and other HLO. Also does Mux opt, bit level opt, generic placer and physical buffering

6. syn_map => maps generic gates to tech gates. Does datapath arch selection, DP opt, Bit level opt, tech mapping, multibit opt and Timing/area CRR

7. syn_opt => performs bit level opt for area and timing

8. scan

9. syn_opt / iSpatial / Congestion prediction =>

 

Flow:

Clock cmds:

  • report_clocks => SDC cmd, uniform syntax
  • report_clock_gating => Reports clock-gating (CG) information for the design, and is useful to see all the statistics on where clk gating is not effectively applied.
    • report_clock_gating > clk_gating.rpt => This shows summarized info for # of CG (Genus vs Non-Genus), # of flops (Genus vs NonGenus gated/ungated), MultiBit Flops, etc. It reports # of leaf CG instances, followed by the # of Multi Stage CG (MSCG) instances (i.e where CG are NOT leaf CG anymore). MSCG has 2 options to indicate where should it cout from => from the flop or from the root.
      • -multi_stage_count_from_flop => this option counts from leaf flop, in which case Level 0 is the CG driving the flop, Level 1 is one level higher and so on.
      • -multi_stage_count_from_root => this other option is for counting from the root clk pin, in which case Level 1 is the top level of CG, level 2 is next lower level, until we get to the flop. NOTE: Here levels start from Level 0, while when counting from flop, we started with Level 1.
  • report_clock _tree_structure -out_file clks.rpt => This reports the clk tree hierarchy, which is very useful to see the whole clk tree structure. It shows different LEVELS of clk tree as L1, L2, etc. Start of a new level is determined if there is a clk gater, RTL instantiated gate, etc in design (i.e anything other than buffer and inverter, unless it's RTL instantiated buf/inv). There are many options to fine tune this report.
    • report_clock_tree_structure -show_sinks -clock_trees {clk1 clk2} => By default cmd shows the clk tree for all clks until the sink. These options show clk tree only for specified clks, with sinks included. NOTE: the same flops may appear under multiple clks, since 1 flop may be driven by multiple clks (depending on clk sdc file)
  • report