SDC, MMMC and timing-environment qualification

3.1 Stage purpose

Multi-mode multi-corner (MMMC) analysis lets one session time a design in several operating modes and several process, voltage, temperature and interconnect conditions at once. Innovus builds it from a small set of objects, shown in Figure 4. A library set groups the Liberty files of one condition. An RC corner describes interconnect extraction, including temperature. A delay corner combines a library set with an RC corner, and can carry further settings such as operating condition and SI. A constraint mode groups the SDC files of one functional or test mode. An analysis view pairs one constraint mode with one delay corner. Finally, set_analysis_view chooses which views are active for setup and which for hold. A view fixes a mode and a corner. It does not fix the analysis type, OCV style, CPPR or derates, which are set separately and checked in T-07.

The purpose of this stage is not to make timing pass. It is to make timing mean something. Thus, a design with large negative slack can pass this chapter, and a design with zero violations can fail it.

3.2 Entry prerequisites

3.3 Relevant files and analysis context

The MMMC file, usually read through init_mmmc_file at import, holds the create commands. The SDC files belong to the constraint modes. Every report in this chapter must be run per view, or at least for every active view, and the view name recorded with the report. A report without a view name cannot be compared with anything.

Two properties of set_analysis_view deserve attention. It causes a full timing reset: interconnect parasitics, delays and slacks are recalculated. It is also not incremental. Each call must give the complete setup and hold lists, and optional settings such as leakage and dynamic views are reset if the call omits them. Changing an existing mode with update_constraint_mode resets timing, delay calculation and RC data in the same way. A check script should therefore read the active views and report them, not set them.

3.4 Checks and command cards

3.4.1 Pre-stage checks: is the environment complete?

report_analysis_views -type active
all_setup_analysis_views
all_hold_analysis_views
all_analysis_views
all_analysis_views -type inactive
check_instance_library_in_views

report_clocks -view <v>
report_clocks -uncertainty_table -view <v>

set timing_check_timing_report_all_checks true
set timing_report_check_timing_unconstrained_endpoints_due_to_constants true
check_timing -verbose -view <v> > <f>
check_timing -include_warning {clock_crossing missing_drive \
    multiple_clock const_collision} -view <v> > <f>

report_case_analysis -view <v>
report_inactive_arcs -view <v>
report_path_exceptions -ignored -view <v>

getAnalysisMode -analysisType -cppr -aocv -socv
report_timing_derate

3.4.2 Post-stage checks: what does the timing actually cover?

Figure 5 explains why zero WNS and TNS are not proof of a correctly constrained design. Worst negative slack and total negative slack are computed over the checks that have a required time. An unconstrained endpoint has no required time, an untested check has no valid arrival or reference, and an arc disabled by case analysis carries no path. None of them can produce negative slack. In a real report the groups can overlap: a register data pin with no clock is both an unconstrained endpoint and an untested check. Thus, every slack summary in this book is reported together with the coverage numbers from T-05.

report_analysis_coverage -verbose untested -sort reason -view <v> > <f>
report_analysis_coverage -view <v>
report_timing -unconstrained -max_paths 20 -view <v>

check_design -type timing -out_file <f>
report_constraint -all_violators \
    -drv_violation_type {max_transition max_capacitance max_fanout} -view <v>
report_timing -late -max_paths 10 -view <v>
timeDesign -prePlace -outDir <dir>

3.5 Required reports, artefacts and how to read them

check_timing -verbose -view func_slow                  ## all-checks global set
TIMING CHECK           STATUS     COUNT
clock_expected         clean          0
ideal_clock_waveform   reported      12      ## expected before CTS
loop                   clean          0
no_input_delay         reported       4
uncons_endpoint        reported     310

This excerpt lists every check type, so it shows what was covered. The twelve ideal_clock_waveform lines are expected before clock tree synthesis. Four inputs without input delay and 310 unconstrained endpoints are not expected in a functional mode, and they are exactly the 310 endpoints that a WNS summary would not mention. In such a case, the status of T-03 is HARD STOP, whatever the slack says.

3.6 Healthy, suspicious and hard-stop examples

3.7 Debugging, corrective action and reruns

Constraint problems should be fixed in the SDC that owns them, not by adding overriding commands later in the flow. An override in a later script makes the SDC and the analysis disagree, and the signoff tool will read the SDC, not the override. It is recommended to keep one SDC per mode as the single source, because both the implementation and signoff tools then see the same intent.

3.7.1 Worked example: clean-looking timing from incomplete constraints

Let us consider a block whose pre-placement summary reports WNS of 0.000 and TNS of 0.000 in the functional setup view. The first instinct is to call the constraints good. However, check_timing reports clock_expected and uncons_endpoint on the same registers, and report_analysis_coverage with -verbose untested shows 180 untested checks, 160 of them with reason no_endpoint_clock. Tracing one of them shows a register bank clocked from a divider output that has no create_generated_clock. The registers have no clock at their clock pin, so their setup checks never had a required time. After the generated clock is added, those 160 checks become tested, and twelve of them violate. The slack summary got worse, and the constraints got better. Thus, the order of checks in this chapter matters: coverage first, slack second.