Tool, project and session qualification

1.1 Stage purpose

Session qualification establishes the identity of a run. It answers four questions: is this the qualified Innovus release, is the session in the interface the scripts were written for, are the inputs and settings the ones the methodology requires, and can the result be traced back to a known checkpoint. None of these checks analyse the design data. However, a mistake here quietly invalidates everything downstream. A script written for the Legacy UI running in a Common UI session, or a session restored from an edited database, can produce reports that look normal and mean nothing.

Let us consider a common situation. A block is handed from one engineer to another as a saved database. The second engineer restores it, reruns timing, and gets a different worst slack. Before anyone debugs timing, the first question is whether the two sessions were the same release, with the same non-default settings, restored from the same unmodified database. In most cases the difference is found here, not in the design.

1.2 Entry prerequisites

1.3 Relevant files and analysis context

The files that matter at this stage are the startup script, the project configuration, the log file of the session, and, when work continues from an earlier step, the saved database. In the Legacy UI, saveDesign test writes a small file named test containing the restore command, and a directory test.dat holding the database. The usual convention is to name the save with an .enc suffix, so the directory becomes name.enc.dat and is restored with restoreDesign name.enc.dat top.

Two global variables protect provenance. restore_db_file_check defaults to true, and makes the restore fail if any file inside the saved directory was edited, renamed or deleted. restore_db_stop_at_design_in_memory defaults to 1, and stops a second restoreDesign in the same session. The reference explicitly recommends against restoring twice in one session, because settings from the first database might not be cleaned up. Thus, a qualification run should restore exactly once, in a fresh session, with both globals left at their defaults. Three further rules matter for a handoff. A database saved by a newer major version, meaning the first number, does not restore in an older tool. Relative paths in the saved globals expect the working directory of the saving session, unless setImportMode -syncRelativePath is true. The file check covers the files inside the saved directory, while external LEF, .lib and SDC files are referenced by full path or link unless saveDesign -libs was used, so record their revision as well. Preservation attributes from SDC and .lib files, such as dont_touch and dont_use, are applied at the first read and not again by restoreDesign, so the restored database is what holds them.

1.4 Checks and command cards

1.4.1 Pre-stage checks: before loading anything

Two checks run before any design data is loaded, because they decide whether the rest of the script is even the right script: the release and the interface.

getVersion
getVersion -major

innovus          ;# no -stylus option: Legacy UI
is_common_ui_mode

1.4.2 Post-stage checks: after the design is loaded or restored

Once a design is in memory, the session has a log, a message history and a set of mode settings. These are what we read next.

getLogFileName -fullPath
report_message
report_message -errors -count
report_message -suppressed

report_command_mode -non_default
report_command_mode -user

getMultiCpuUsage -localCpu
getLicenseStatus
report_resource -peak
report_disk -dir <run_dir>

restoreDesign <name>.enc.dat <top>
saveDesign <name>.enc
set restore_db_stop_at_design_in_memory 1   ;# default
set restore_db_file_check true             ;# default

1.5 Required reports, artefacts and how to read them

The output of this chapter is a short manifest rather than a long report. It is written by the qualification script and kept next to every report the run produces, so that any later number can be traced back to its session.

1.6 Healthy, suspicious and hard-stop examples

1.7 Debugging, corrective action and reruns

Most session problems are environment problems. The tool path, the module that sets it, and the startup options belong to the environment, so the fix belongs there too. It is better to fail the session early, before loading the design, than to add workarounds inside the Innovus script. A workaround inside the script makes the next run depend on the same mistake.

After any fix in this chapter, the rerun is always a fresh session. Nothing that depends on the session state can be partially rerun.

## Release and UI gate, Legacy UI session
## The qualified release string comes from the project configuration
set qual_build $::proj(qual_release)
set ver [getVersion]
if {$ver ne $qual_build} {
    puts "HARD STOP: release $ver differs from $qual_build"
}
if {[is_common_ui_mode]} {
    puts "HARD STOP: Legacy scripts sourced in a Common UI session"
}
puts "log: [getLogFileName -fullPath]"
## report_message -errors -count returns a list of {ID count} pairs
set errs [report_message -errors -count]
if {[llength $errs]} {
    puts "HARD STOP: errors after load: $errs"
}
puts "suppressed IDs: [report_message -suppressed]" 

The script only reports. It does not exit, change a setting or save anything, so it is safe to source at the start of any run. The qualified release is read from a project configuration array, named proj here as an illustration. In a real flow the gate decision is written to the manifest rather than only printed.

1.7.1 Worked example: a different worst slack after handoff

run A (handoff)                     run B (receiver)
release     <rel> build A           release     <rel> build B
UI mode     0 (Legacy)              UI mode     0 (Legacy)
restore     blk.enc.dat, 1 time     restore     blk.enc.dat, 2 times
non-default 14 options              non-default 16 options
setup WNS   -0.012                  setup WNS   -0.031

Let us read it in the order of this chapter. The builds differ, which is a warning at most. The UI is the same. However, run B restored twice in one session, which the reference advises against, and it has two extra non-default options. Before looking at any timing path, the receiver should restore once in a fresh session, diff the mode settings against the baseline, and only then compare slack. In such a situation, the remaining difference, if any, is a real difference and is worth debugging.