Product Documentation
Mixed Signal (MS) Interoperability Guide
Product Version 22.13, Last Updated in July 2023

4

Design Data Preparation

4.1 Special Settings/Instructions To Enable the Mixed-Signal Flow

Cadence does not support a mixed signal flow that combines LEF and OpenAccess in the same flow. The flows used should be either entirely LEF-based or entirely OpenAccess. The OpenAccess flow has the advantage of full interoperability with Virtuoso, and enables many features such as floorplanning, routing constraint interoperability and Mixed Signal Static timing analysis. The instructions for starting Innovus in the OpenAccess mode are included in this section of the documentation.

4.2 Name Space Mapping in the OpenAccess Interoperable Flow

A name space refers to the conventions that a tool uses for denoting such things as bus notation, hierarchical delimiter, and so on. Given the nature of place-and-route (P&R) and custom tools, name space differences exist between Innovus and Virtuoso. While the Innovus name space is aligned with LEF/DEF, Virtuoso aligns to the C-level Database Access (CDBA) name space. Some examples of namespace differences:

Both Virtuoso and Innovus are capable of outputting the data in the name space format where the data is going to be consumed. For instance, when a DEF file is generated from the data inside Virtuoso, Virtuoso internally maps the CDBA name space to DEF while outputting the DEF file. Similarly, when a Verilog netlist is written from Virtuoso, the CDBA name space gets mapped to the Verilog name space by Virtuoso.

In the OpenAccess interoperable flow, the mapping of the name spaces happens automatically. When an OpenAccess design is saved in Innovus and later opened in Virtuoso, you DO NOT need to make any changes in the name space seen in Virtuoso. If the same cell view is edited and saved in Virtuoso, the next time that cell view is opened in Innovus, you will see the Innovus name space.

4.3 Converting an Existing LEF/DEF-based Design into OpenAccess

You may have a placed and routed Innovus design that you would like to convert to OpenAcess in order to exercise the many interoperability related features of OpenAccess or simply to run the Innovus flow in OpenAccess. Conversion to OpenAccess is possible only if an interoperable mixed-signal OpenAccess (MSOA) PDK has already been created for the particular technology and metal stack used by the design. To convert the Innovus design into OpenAccess, use the following steps:

  1. Restore the existing LEF/DEF-based design:
    restoreDesign PNRComplete.dat myDesign 
  2. Set the init_lef_file global variable to null to instruct Innovus that a LEF technology file will not be used in this session:
    set init_lef_file "" 
  3. Specify the OpenAccess technology and standard cell libraries and any OpenAccess macro libraries:
    set init_oa_ref_lib {techLib stdcellLib macroLib}
    In this example, techLib is the interoperable MSOA PDK, which has been created by merging some of the technology information found in a tech LEF with the base PDK used by Virtuoso, as explained in the "Implementing an Interoperable/MSOA PDK" section in the Technology Data Preparation chapter.
  4. Write out the LEF-equivalent information from the LEF/DEF-based design that was loaded into memory using restoreDesign in Step 1:
    write_lef_library before_conversion.lef
    The file created in this step can be compared to the LEF that will later be created from the OpenAcess representation of the same design. This step is highly recommended as it enables you to detect possible issues with the MSOA PDK, early in the flow. The write_lef_library command has an option for writing out only the technology information (using the -tech_only option) or the macro data (using the -macro_only option). Cadence recommends that both type of data in the LEF be compared; however, if you prefer to compare the DRC rules separately, the command could be run twice, with one option at a time, to create two different files that can later be used for comparison. Note that this command could have also been run directly after the restoreDesign command, because the setting of variables after restoreDesign does not change the LEF data seen by this command. 
  5. Save the design into an OpenAccess lib/cell/view format:
    saveDesign -cellview {myDesignLib myDesign PNRcomplete}
    In this example, myDesignLib is the OpenAccess design library that will contain the design data, the specific cell name is myDesign, and the name of the view is PNRcomplete. This step would have not been possible without the MSOA tech file that was loaded earlier using the set init_oa_ref_lib command in Step 3.

At this point, the LEF/DEF-based design has been saved the design into OpenAccess. Now, you need to make sure that the technology and macro information is the same between the LEF and OpenAccess versions of the design. To do so, you need to restore the converted OpenAccess design in a different session of Innovus and write out the equivalent LEF information so that you can compare it with the LEF written out to the before_conversion.lef file in Step 4. To restore the design in a different session, a cds.lib file needs to exist in the current working directory where Innvous is getting invoked. This file enables Innovus to find the directory where the design data is stored. The syntax of the cds.lib file could be as follows:

DEFINE myDesignLib /usr/A/myDesignLib
In this example, the /usr/A/myDesignLib directory will contain a directory named myDesign, which is the top-level cell name in the design.

In a new Innovus session, perform the following steps:

  1. Restore the converted OpenAccess Design:
    restoreDesign -cellview {myDesignLib myDesign PNRcomplete}
  2. Write out the LEF information from the converted design:
    write_lef_library after_conversion.lef 
    This file will contain the LEF data created from the OpenAccess technology and macro information loaded in Innovus when the design is read in using the restoreDesign command.

Now, you can run the Unix diff command on the before_conversion.lef and after_conversion.lef files. If the conversion happened correctly, there will be no differences in the two files from a DRC point of view. The two files should also have the same set of macros.

The following differences in the two LEF files will not cause any problems when the design is run in Innovus:

If the routing and cut layers are the same between the two LEFs and the DRC rules match, the OpenAccess PDK is in sync with the LEF from a technology point of view.

4.3.1 Converting a LEF/DEF-based design into OpenAccess by using oaOut

You can use the oaOut command in Innovus to send the design data in the OpenAccess format to either Virtuoso or a third party tool capable of reading OpenAcess. For oaOut to work, you need to first create an interoperable MSOA PDK containing the design rules for the specific process used by the design. Follow steps 1 and 2 below to create the technology library to be used in this process:

  1. With the design loaded in Innovus, execute the following two commands:
    1. write_lef_library -tech_only TECH.lef
    2. write_lef_library -macro_only MACRO.lef
      (If the design has no macros, skip this step.)
  2. Run the lef2oacommand. lef2oa is a stand-alone UNIX command that is shipped with the Innovus software. You can found it in the Innovus hierarchy:
    1. lef2oa -useFoundryInnovus -lef TECH.lef -lib RapidPDK -techRefs BasePDK
    2. lef2oa -lef MACRO.lef -lib RapidPDK
      (If the design has no macros, skip this step.)
    3. lef2oa -lef stdcell.lef -lib RapidPDK
      (This will convert the std cell libraries to the OpenAccess format, referencing the technology library.)

    Here, RapidPDK is the name of the new tech file that will have all the technology information for both Innovus and Virtuoso. BasePDK is the technology file used to run the Virtuoso environment. The above process builds an Incremental Technology Database (ITDB) on top of the existing technology file for Virtuoso.
  3. Next, create an OpenAccess design library to hold the design data to be sent to Virtuoso by using the following command:
    1. createLib myDesignLib -referenceTech {RapidPDK}
  4. Now, use the oaOut command to convert the design to OpenAccess and save it in the design library that was created in the previous step:
    1. oaOut myDesignLib myRoutedDesign layout -refLibs RapidPDK
      (A cell view by the name of myRoutedDesign is created in the design library myDesignLib referencing the technology information in the RapidPDK.)

Note: Ensure that the UNITS in BasePDK and TECH.lef are the same. If the UNITS in the LEF file are 2000 and BasePDK has UNITS 1000, there might be errors in the migration to OA data. Some wire widths, begin and end extensions might be having a decimal precision that might not be supported on a lower UNITS value. The following error will be seen for such wires while saving the design to OpenAccess:

**ERROR: (IMPOAX-448): Could not save OA database: OA Exception: The width specified for segStyle must be an even number.

A sample script to find such wires/swires is provided below. You can modify the same as per your design.

Sample Script for swires

set ww [dbGet top.nets.swires]
foreach w ${ww} {
set box_sizey [dbGet ${w}.width]
set beginExt [dbGet ${w}.beginExt]
set endExt [dbGet ${w}.endExt]
set layer [dbGet ${w}.layer.name]
set netname [dbGet ${w}.net.name]
# Check
set check_width [expr int(1000.0*${box_sizey}/2.0) != (1000.0*${box_sizey}/2.0)]
set check_begExt [expr int(1000.0*${beginExt}) != (1000.0*${beginExt})]
set check_endExt [expr int(1000.0*${endExt}) != (1000.0*${endExt})]
set check [expr ${check_width} + ${check_begExt} + ${check_endExt}]
if {${check} > 0} {
puts "FAIL: ($check_width $check_begExt $check_endExt) ${netname} ${layer} ${box_sizey} [dbGet ${w}.box]"
}
}
This will flag the swires that will cause errors in migration to OpenAccess due to the difference in UNITS.

Note: You should run the same script for wires as well.

Sample result of above script
FAIL: (1 0 0) VDD M4 0.075 {336.7 63.035 341.1 63.11}
FAIL: (1 0 0) VDD M3 0.605 {308.85 117.42 309.455 121.82}
FAIL: (1 0 0) VSS M4 0.075 {343.0 63.035 347.4 63.11}
FAIL: (1 0 0) VSS M3 0.605 {308.85 123.72 309.455 128.12}

4.4 Migrating a LEF and Floorplan File-based Flow to OpenAccess

The main difference between the LEF-based flow and the OpenAccess flow is the use of OpenAccess libraries and cell views instead of the text-based LEF and floorplan files.

Following are the steps to migrate a LEF and Floorplan file-based flow to OpenAccess:

  1. Create OpenAccess technology and cell libraries that would be compatible for use in Innovus and Virtuoso. You can do so by creating an Incremental Technology Data Base (ITDB) structure for the interoperable OpenAccess libraries. You will need to have Virtuoso in your path settings.
    1. Create an OpenAccess technology library for the technology LEF file using lef2oa.
      lef2oa –lef tech.lef –lib techLib –libPath refLibs
      This creates the LEFDefaultRouteSpec constraint group in the technology library. The LEFDefaultRouteSpec constraint group has all the technology information needed by Innovus. 
      This also creates the display.drf file with the color and stipple patterns for the layers to be used in the dfII environment.
    2. Import the MACRO LEF files in a new ITDB with the techLib as the reference for the technology.
      lef2oa –lef stdcells.lef –lib cellsLib –techRefs techLib –libPath refLibs
      This creates the cell library with the OpenAccess abstract views for the cells while referring the technology information from the techLib.
    3. As lef2oa does not create bus information in the abstracts, you need to create the bus information in these abstracts using verilogAnnotate:
      verilogAnnotate –verilog stdcells.v –refLibs cellsLib –refViews abstract
      This creates the bus and the bus term order, ascending or descending, in the OpenAccess cell views.
      You will need the verilog stubs for the cells to be used for verilogAnnotate. You can use oa2verilog to create the verilog stubs in case you do not have them readily available.
  2. Next, create an OpenAccess view for the text floorplan file. There can be two approaches for the above:
    • Use defOut from the LEF-based Innovus database after the .fp file has been loaded and then use def2oa to create an OpenAccess cellview with the floorplan information.
      defOut -routing from_innovus.def
      def2oa –def from_innovus.def –lib designLib –cell top –view floorplan –techrefs techLib
      This creates an OpenAccess design library with the top cell and the initial seed floorplan view.
    • Save OpenAccess directly from Innovus after loading the .fp file:
      saveDesign -cellview {designLib top floorplan}
      The OpenAccess floorplan view cannot be saved from data created using LEF-based libraries. The LEF libraries must be converted to OpenAccess form and the design reloaded using those OpenAccess libraries.
  3. Finally, if you are using the Innovus Foundation Flow, you need to modify some variables in the setup.tcl file:
    1. Add the following variables in setup.tcl so that the OpenAccess data is read in for the technology, cells, and the floorplan:
      • set vars(dbs_format) oa
      • set vars(oa_abstract_name) abstract
      • set vars(oa_layout_name) layout
      • set vars(oa_design_lib) designLib
      • set vars(oa_ref_lib) macroLib
      • set vars(oa_fp) "designLib top floorplan"
    2. Unset the following variables or remove them from setup.tcl to do away with the text LEF and floorplan files:
      • set vars (fp_file) top.fp
      • set vars (lef_files) “”
    After the setup.tcl file has been modified as mentioned above, the rest of the scripts and supporting files in the foundation flow can be used as it is for all the flow steps.

4.5 Running Innovus in the OpenAccess Mode

In this mode, Innovus needs to use the common PDK described in the previous sections of this document. No LEFs are needed for Innovus to operate in the OpenAccess mode, because both the technology data as well as the standard cell data can be represented in OpenAccess. The design connectivity needed for Innovus in the mixed signal flow could be read from either a Verilog netlist or an OpenAccess database generated in Virtuoso XL. In Virtuoso XL, the Generate From Source command creates a layout view which has the connectivity information in the original  schematics.

In typical mixed signal designs, there may be one or more digital blocks that need to get implemented. If the top level of the design is represented as schematics in Virtuoso, the digital blocks in the design are represented as soft blocks and typically come with Verilog Netlist created from Synthesis. In these cases, Innovus needs to be initialized using the Verilog netlist of the particular block, and later in the flow, the floorplan of the block created in Virtuoso could be read into Innovus using the command oaIn. This flow is referred to as Analog on Top.

In another commonly practiced flow, the entire design (captured as an OpenAccess cellview in Virtuoso) is brought into Innovus for either co-design, analysis, or ECO. In that flow, Innovus can be initialized with the OpenAccess database created by Virtuoso XL, and there is no need to have a Verilog netlist for the top level of the design. This flow is referred to as Mixed Signal on Top.

4.5.1 Initializing Innovus for Implementing a Digital Block in OpenAccess

The following setting can be used to initialize Innovus for implementing a digital block in OpenAccess. Note that these settings must be made once Innovus is invoked.

set init_abstract_view abstract

set init_layout_view layout

set init_oa_ref_lib {lib1 lib2 lib3}   #These are the OpenAccess reference libraries used in the design. lib1 could be the OpenAccess library containing the technology information, lib2 could be the OpenAccess standard cell library, and lib3 could be the OpenAccess reference library that is referencing the technology information in lib1, but has additional Vias not present in lib1. Note that the first library (in this example, lib1) is the source of the technology information for Innovus. It is also acceptable for the first library to either attach or reference the library that contains the actual technology information. For example, if the first library is a standard cell library that either references or attaches the library containing the technology information, the standard cell library is allowed to be the first library listed in the set init_oa_ref_lib setting. Users typically include the standard cell library and the pad cell library in set init_oa_ref_lib, but not the IP block libraries. 

set init_oa_search_lib {lib1 lib2}   #The libraries listed here are loaded only if the design has cell references that do not exist in the libraries specified by set init_oa_ref_lib. You may have several macro libraries, but some designs may have macros instantiated from only one of these libraries. In this case, you do not want Innovus to load many libraries that are not actually needed by it. Instead, the tool loads only the libraries it needs based on whether the macro is instantiated. Note that this setting is meant for use only when Innovus is being initialized with a Verilog Netlist. 

set init_verilog <name of the Verilog netlist representing the digital block being implemented in Innovus>

In addition, if the PDK you have been given is a Rapid MSOA PDK with multiple foundry_innovus constraint groups, you need to specify the following settings so as to select the correct foundry_innovus constraint group, along with the correct LEFDefaultRouteSpec and LEFSpecialRouteSpec:

set init_oa_foundry_rule <name of the foundry_innovus constraint Group>

set init_oa_default_rule <name of the LEFDefaultRouteSpec>

set init_oa_special_rule <name of the special Route Spec>

Some of the other common settings to start Innovus (not directly related to OpenAccess) are:

set init_mmmc_file "name of the Multi Mode Multi Corner file used for running analysis in the Innovus implementation flow"

set init_pwr_net {name of the power net in the design}

set init_gnd_net {name of the power net in the design}

set init_design_uniquify {true}

4.5.2 Initializing Innovus with the OpenAccess Database of a Design Created in Virtuoso XL

The following setting can be used to initialize Innovus when the OpenAccess database of a design created in Virtuoso XL is brought into Innovus for the first time. Note that these settings must be made once Innovus is invoked.

set init_design_netlisttype {OA}   #This tells Innovus to get the needed connectivity from the OpenAccess database, instead of a Verilog netlist.

set init_oa_design_lib {design_lib}  #This tells Innovus the OpenAccess design library that contains the cellview representing the top level of the design. 

set init_oa_design_cell {cellview}  #This tells Innovus the name of the OpenAccess cellview representing the top level of the design.

set init_oa_design_view {layout}   #This needs to be set to the name of the view containing the full layout of the cell. 

set init_oa_ref_lib {lib1 lib2 lib3}   #These are the OpenAccess reference libraries used in the design. lib1 could be the OpenAccess standard cell library, lib2 could be the OpenAccess library containing the technology information, and lib3 could be the OpenAccess reference library that is referencing the technology information in lib2, but has additional vias not present in lib2.

In addition, if the PDK you have been given is a Rapid MSOA PDK with multiple foundry_innovus constraint groups, you need to specify the following settings so as to select the correct foundry_innovus constraint group, along with the correct LEFDefaultRouteSpec and LEFSpecialRouteSpec:

set init_oa_foundry_rule <name of the foundry_innovus constraint Group>

set init_oa_default_rule <name of the LEFDefaultRouteSpec>

set init_oa_special_rule <name of the special Route Spec>

Some of the other common settings to start Innovus and not directly related to OA are:

set init_mmmc_file "name of the Multi Mode Multi Corner file used for running analysis in the Innovus implementation flow"

set init_pwr_net {name of the power net in the design}

set init_gnd_net {name of the power net in the design}

set init_design_uniquify {true}

4.6 Interoperability of Constraint Groups and Non-Default Rules between Virtuoso and Innovus

Innovus uses the following guidelines while reading constraint groups (the physical DRC rules) from the OpenAccess database for using them as non-default rules within the same Innovus session:

You can obtain a list of non-default rules using the dbGet head.rules command in Innovus.

Note: If any constraint inside a constraint group has a name starting with ms, Innovus treats that group as a mixed-signal constraint group and that group is read as a mixed-signal routing rule.

Note: You can confirm the non-default rule by writing the DEF file from an Innovus session, which has the complete definition of non-default rules and the nets using these non-default rules.

4.6.0.1 Example

- CLK ( PIN CLK )
+ SHIELDNET VSS
+ NONDEFAULTRULE doublewidth ;

For more information about non-default rules in DEF, see the DEF Syntax chapter in the LEF/DEF Language Reference.

4.7 Generic Guidelines To Run the Netlist-Driven Mixed-Signal Flow

Consider the following guidelines before running the netlist-driven mixed-signal flow:




 ⠀
X