Design import and database sanity

2.1 Stage purpose

In the Legacy UI, a design is loaded by setting a group of Tcl global variables and then calling init_design. The globals name the Verilog netlist (init_verilog), the LEF files (init_lef_file), the MMMC view file (init_mmmc_file), the top cell (init_top_cell), and the power and ground net names (init_pwr_net, init_gnd_net). init_design can only be called when no design or library data is loaded yet, which is one more reason chapter 1 insists on a fresh session.

In the Common UI, the RAK lab loads the same kind of data as a sequence: read_mmmc, read_physical -lefs, elaborate_design -script, then init_design. The lab is a synthesis flow that starts from RTL, so it does not show how a gate-level netlist is read for place and route. That step is still to be confirmed.

init_design also creates a default floorplan: a square box at 70 percent utilisation, default rows and tracks taken from the technology LEF. These are placeholders, not an intended floorplan.

Import can succeed with problems inside it. A cell that has a LEF view but no timing model loads, places and routes, and simply has no delay. A module instantiated twice loads normally, and only fails later when an optimisation step needs to change one instance without the other. Thus, the import gate is about what the tool accepted with a warning, not about whether it stopped.

2.2 Entry prerequisites

2.3 Relevant files and analysis context

The inputs are the gate-level Verilog, technology and cell LEF, macro LEF abstracts, Liberty timing libraries referenced by the MMMC file, and the PG net names. Timing views are created at import, but timing correctness belongs to chapter 3. Here we only need the libraries to be bound.

Figure 3 shows a distinction that causes confusion at import. Logical connectivity is present as soon as the netlist is read: every connection the netlist states exists, and floating pins are what the checks look for. Power and ground pins belong to a net only after globalNetConnect ties them, because a gate-level netlist often leaves them implicit. Physical connectivity does not exist yet. Thus, an unrouted-net count from a physical check at this point is not a failure, while a dangling or multiply driven net in the logical checks is.

2.4 Checks and command cards

2.4.1 Pre-stage checks

Before init_design, the only checks are on the inputs themselves: the files exist, the LEF order is right, and the global variables point at the files the project configuration lists. These are script checks rather than Innovus checks, so they are not carded here. The import itself is a state-changing step and is shown for completeness.

set init_verilog   <netlist.v>
set init_lef_file  {<tech.lef> <cells.lef> <macros.lef>}
set init_mmmc_file <views.tcl>
set init_top_cell  <top>
set init_pwr_net   VDD
set init_gnd_net   VSS
init_design

2.4.2 Post-stage checks

check_design -type "library netlist" -out_file <f>
checkDesign -netlist -physicalLibrary -timingLibrary -powerGround \
    -noHtml -outfile <f>

checkNetlist -outfile <f>
checkUnique -verbose

reportNetStat
reportGateCount -stdCellOnly -outfile <f>
report_area -detail -out_file <f>
dbGet top.numInsts
dbGet top.terms.name

dbGet head.layers.extName
dbGet -p top.insts.pStatus fixed
dbGet top.insts.?

globalNetConnect VDD -type pgpin -pin VDD -all
checkDesign -netlist -physicalLibrary -timingLibrary -powerGround \
    -noHtml -outfile <f>

Notice that I-06 changes the database. That is deliberate: PG ties are part of preparing the design. In a check-only script, run only the checkDesign part and report what is unconnected.

2.5 Required reports, artefacts and how to read them

check_design, type library netlist                     ## illustrative excerpt
## simplified: the tool prints Severity, ID, Count, Summary
category   check               count
library    physical_only        2      ## cells with LEF, no .lib
library    logical_only         0
netlist    undriven             3
netlist    multiple_driver      0
netlist    unloaded            41
netlist    empty_modules        1

Let us read the excerpt line by line. Two physical-only cells could be fillers or tap cells, which have no timing by design, or two real cells whose .lib was never added. Only the out file with the cell names tells which. Three undriven nets need names: a tie-off left for the flow is acceptable, a floating input on a functional gate is not. Forty-one unloaded nets are often spare outputs and scan-out ends, but they are worth a quick scan. The empty module is a black box: it is acceptable only if it is on the exception list, otherwise a module definition is missing.

2.6 Healthy, suspicious and hard-stop examples

2.7 Debugging, corrective action and reruns

Import problems have their root cause in an input file, so the fix is always in the input or in the global variables that point at it. It is better to reload than to patch the database, because a patched database cannot be reproduced from its inputs, and chapter 16 requires exactly that reproduction.

2.7.1 Worked example: a macro with no timing model

Suppose check_design lists a cell PLL_TOP as physical-only, and the exception list does not mention it. The cell has a LEF abstract, so floorplanning and placement treat it normally. But with no Liberty model there are no timing arcs through it, so the paths it should carry are broken. checkDesign -timingLibrary does not check arcs; checkTimingLibrary does. In chapter 3, the endpoints it feeds would appear as unconstrained or untested in check_timing and report_analysis_coverage, and a timing summary would not show them at all. The fix is to add the PLL timing model to the library set in the MMMC file, or to add the cell to the exception list with an owner and a reason. Either way, the decision is recorded before the import gate closes.