IntermediateQuestion 40 of 60Source: Synopsys IC Compiler II Tool Commands: check_mv_design; Synopsys IC Compiler II Multivoltage User Guide: Checking the Design for Power Violations and Reporting Multivoltage Paths

How do you read a `check_mv_design` report and triage what it finds?

From PDVerse Low-Power Physical Design Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

check_mv_design (ICC2) prints one section per rule group, from power domain and supply rules through strategy rules to cell rules, with each message followed by an MV-080 total for that message ID. Triage from the top: supply and domain problems cascade into everything below, so fix those first, then strategy conflicts, then individual cells. For any cell or path it flags, report_mv_path (ICC2) tells you why a cell was inserted, associated or rejected.

Decision tree from a check_mv_design (ICC2) report: supply and domain rules (MV-011 supply net with no driver, MV-022 unconnected supply port, UPF-049 unknown PG type) lead to fixing the UPF supplies first; strategy rules lead to editing set_isolation or set_level_shifter; cell rules (MV-071 isolation cell not associated) lead to report_mv_path -cell; MV-097 biasing violations lead to the biasing constraints. — Technical Reference DiagramHow do you read a `check_mv_design` report and triage what it finds?

Technical Explanation

Sections: power domain, supply net, supply port, isolation / level shifter / retention / power switch strategy, repeater, terminal boundary, then cell rules.
Each message ends with an ID and an MV-080 total; MV-011 (supply net with no driver) is an error, MV-022 (unconnected supply port) a warning.
Scope: the default run excludes PG net and PG connection checks; add -pg_netlist or -all (ICC2).
-max_message_count defaults to 20 per message type, so set it to all before you trust a count.
Cell rule example: MV-071 means an isolation cell is not associated with any strategy; report_mv_path -cell (ICC2) shows why.
MV-097 reports forward or reverse biasing violations, and only once you allow biasing with set_power_domain_constraints (ICC2).
Level shifter strategies with -rule or -no_shift (UPF) that block insertion turn errors into warnings, so read warnings too.

# [ICC2]  icc2_shell
check_mv_design -all -max_message_count all
check_mv_design -isolation -level_shifter -objects [get_pins U_COP/dout]
report_mv_path -cell U_COP/DATA_UPF_ISO
report_mv_path -level_shifter -net cop_dout

What To Check

The run includes PG checks (-all or -pg_netlist) and uses an unlimited message count.
Supply and domain sections are clean before you spend time on strategy or cell messages.
Every warning is either fixed or explained, not only the errors.
Each remaining cell message has a report_mv_path (ICC2) explanation.

Command Checks & Actions

ICC2 (icc2_shell)check_mv_design -all -max_message_count all

Runs every MV rule, including PG checks, with no message cap.

ICC2 (icc2_shell)check_mv_design -isolation -level_shifter -objects [get_pins U_COP/dout]

Rechecks isolation and level shifting only on paths through one pin.

ICC2 (icc2_shell)report_mv_path -cell U_COP/DATA_UPF_ISO

Explains a flagged MV cell: strategy, supplies, driver and loads.

ICC2 (icc2_shell)report_mv_path -level_shifter -net cop_dout

Shows the level shifter path and the voltage shifting situation on one net.

Healthy, Suspicious & Hard-stop Results

Healthy (illustrative): All sections read No errors or warnings in a -all -max_message_count all run.
Suspicious (illustrative): Only warnings remain, such as MV-022 on a spare supply port, each with a written reason.
Hard stop: Any MV-011 supply net with no valid driver, or isolation cells flagged MV-071 on outputs of a switchable domain.

Common Mistake

The Trap: Fixing cell-level messages first because they are the longest part of the report.

Many of them come from one supply or strategy error higher up, such as a supply net with no driver.
You patch symptoms one by one, and the next run shows new ones until the root supply problem is fixed.

What The Interviewer Is Testing

Can read the report structure and message totals.
Triages from supplies down to cells.
Knows the default scope and message cap of the command.

Follow-up Question & Model Response

"The report says zero violations, but simulation shows a floating clamp. How?"

Candidate Model Response: First check what you ran. A default check_mv_design (ICC2) skips PG net and PG connection checks, so an isolation cell whose backup pin sits on the switched rail passes. Rerun with -pg_netlist or -all (ICC2). Also check the message cap: with the default 20 per type, you may have read a truncated report.

Practical Example

Design Scenario: (illustrative, message text as documented) A run on MYCHIP after create_mv_cells (ICC2) shows UPF-049 (cannot derive PG type for supply net vddx), MV-011 (vddx has no valid driver), two MV-022 on U11/vdd089 and 14 MV-071 isolation-cell messages. The team fixes the UPF: vddx gets its supply port connection and PG type. On rerun, MV-011 and UPF-049 are gone. report_mv_path -cell (ICC2) on the MV-071 cells shows they were inserted under an isolation strategy that was later renamed, so the team reruns create_mv_cells (ICC2) and all 14 associate with iso_cop_out.

Low-Power & UPF Handbook