What are library-definition problems or UPF-to-library mismatches, and what command reconciles a cell's actual power pins with UPF's abstract model?

Short Answer

UPF talks about supply sets and strategies, while the library describes real PG pins, pin types and related-power attributes; a mismatch means the tool cannot connect one to the other. There is no single reconcile command: the Liberty PG attributes decide most of it, and for macro and top-level ports you override them with set_port_attributes -receiver_supply (UPF), its -driver_supply twin, or set_related_supply_net (UPF). report_mv_lib_cells and check_mv_design (ICC2) show where the two views disagree.

Technical Explanation

• PG pin type: Liberty marks each PG pin primary_power, backup_power and so on; a wrong type makes a dual-rail cell look single-rail.
• Related power pin: each signal pin names the PG pin that powers it; a wrong value gives the pin the wrong supply and false crossings.
• Unmapped cells: a strategy that maps to a cell outside the target library leaves GTECH cells behind; analyze_mv_feasibility -level_shifter -format html (ICC2) lists level-shifter failure reasons.
• Macro ports: for a hard macro input, -receiver_supply beats set_related_supply_net (UPF), which beats the Liberty related_power_port.
• Supply voltage: every supply net needs an operating voltage, or ICC2 issues UPF-057; check_mv_design -pg_netlist (ICC2) confirms it.
• Wrong file: map_retention_clamp_cell (ICC2) is not a UPF command, so placing it inside the UPF makes load_upf (ICC2) error.

# [UPF]  design.upf
set_port_attributes -ports {U_SRAM/CE} -receiver_supply SS_AON
# [ICC2]  icc2_shell
report_mv_lib_cells -verbose
check_mv_design -pg_netlist
check_mv_design -pg_pin
analyze_mv_feasibility -level_shifter -format html

What To Check

• report_mv_lib_cells shows the expected PG_TYPE for every power-management cell.
• Enable and data pins of isolation cells relate to the PG pins you expect.
• Every strategy maps to a usable cell in the target library.
• Hard-macro ports carry an explicit receiver or driver supply where Liberty is silent.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): All 14 multivoltage library cells report the expected PG types, and check_mv_design -pg_pin shows no errors.
• Suspicious (illustrative): A dual-rail buffer reports only a primary_power pin, so the tool treats it as single-rail.
• Hard stop: UPF-057 on a supply net, or load_upf stops on a command it does not recognise.

What The Interviewer Is Testing

• Do you separate library data problems from UPF problems?
• Do you know the port-supply priority order for hard macros?

Follow-up Question & Model Response

"A hard macro has no related_power_port on one input. What does the tool assume?"

Candidate Model Response: It walks the priority list for hard-macro inputs. First comes -receiver_supply on the HighConn side, then set_related_supply_net (UPF) there, then the Liberty related_power_port. With none of them present, the input has no defined receiving supply, so crossing checks cannot judge it. Add the receiver supply in the UPF instead of hoping the domain primary is right.