What does a low-power static checker like VC LP verify, and at which stages?

Short Answer

A low-power static checker such as VC LP reads the design and the UPF and proves, without simulation, that the power intent is consistent and that the netlist implements it. You run check_lp (VCLP) by stage: -stage upf for the power intent, -stage design for the netlist, and -stage pg once the netlist carries power and ground pins. You then read report_violations -app LP (VCLP) and waive only what you can justify.

Technical Explanation

• UPF stage: checks the UPF against the design, for example an off driver feeding an on receiver with no isolation strategy.
• Design stage: checks the netlist against the UPF, for example a crossing that needs a level shifter but has none.
• PG stage: checks power and ground connections, such as a shifter input pin on the wrong supply. Skip it if the netlist has no PG connections.
• When to run what: run upf and design stages post-synthesis and all three post-route; check_lp -stage all (VCLP) runs them together.
• Reading results: the report groups violations by severity, stage and tag, such as LS_STRATEGY_MISSING at UPF, ISO_INST_MISSING at Design, PG_PIN_UNCONN at PG.
• Waivers: waive_lp -add (VCLP) marks violations matched by tag, stage, severity or filter, with a comment. It can match more than the report showed.
• Why static: it checks every crossing structurally, where simulation only checks the sequences your tests happen to drive.

# [VC LP]  vc_static_shell
set_app_var search_path {. ./libs}
set_app_var link_library {std_tt.db lp_cells_tt.db}
read_file -format verilog -netlist mychip_route.pg.v -top MYCHIP
read_upf mychip.upf
check_lp -stage upf
check_lp -stage design
check_lp -stage pg
report_violations -app LP -verbose -file report_lp.txt
waive_lp -add W_TIE_OUT -tag ISO_INST_MISSING -comment {spare output tied off, reviewed}
save_session mychip_lp

What To Check

• The UPF stage is clean before you chase netlist violations.
• Every Design and PG error is fixed or waived with a reviewed comment.
• The post-route run really read the PG netlist and ran the PG stage.
• Each waiver matches only the objects you meant.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Zero errors at UPF, Design and PG stages, with two named waivers that each carry a comment.
• Suspicious (illustrative): The post-route report has no PG-stage entries at all: the PG netlist was not read or the stage was skipped.
• Hard stop: ISO_INST_MISSING errors at Design on PD_COP outputs: crossings that need isolation have no isolation cell in the netlist.

What The Interviewer Is Testing

• Can you map each check stage to the design data it needs?
• Do you treat a waiver as a reviewed engineering decision?

Follow-up Question & Model Response

"Why run the UPF stage again post-route when the UPF has not changed?"

Candidate Model Response: Because the design has changed, and design changes can expose new UPF inconsistencies. A scan port punched after the UPF was written, or a restructured block, creates a crossing the strategies never covered. The VC LP guide notes that skipping the UPF stage misses no errors, but it makes it hard to see that the best fix is in the UPF. Running all three stages keeps the diagnosis pointed at the right file.