Explain the voltage precedence ladder. Why does it exist?
From PDVerse PrimeTime STA Interview Guide · pdVerse Mentor Guide
Ten-second Interview Answer
It is the deterministic tie-breaker among the many mechanisms that can set a voltage on the same object, ordered so that the more specific and explicitly named a setting is, the higher it wins - a targeted override always beats a broad default.
Complete Technical Explanation
Several different mechanisms can each claim to set the voltage on one object, so the tool needs a fixed order to decide which one actually applies. From highest to lowest the rungs are: -driver or -receiver_supply on named ports; the same options on elements; set_related_supply_net; the domain's primary supply; set_voltage on a PG pin, which needs an SI license; set_voltage on a supply net; set_operating_conditions; and finally the library voltage_map default. Read down that list and the organising principle is clear: the more specific the target and the more explicitly you named it, the higher it sits. A voltage you set on a named port outranks one you set on an element, which outranks a related-supply-net assignment, which outranks the domain's primary supply, and everything above outranks the broad set_operating_conditions and the library default at the bottom. The ladder exists so that behaviour is predictable rather than order-of-command dependent - a targeted override you wrote for one port always beats the broad default that covers everything, and it does so deterministically every run. That predictability is what makes the ladder a debug tool as well as a rule: when a path times at the wrong voltage, you walk down the ladder to the highest rung that touches the pin in question, and that is what is setting it.
In Pd / Signoff
You use this in multivoltage signoff when a path's delays look wrong for the domain it sits in. Rather than guessing, you walk the ladder against that pin - checking for a -driver or -receiver_supply on the port, then set_related_supply_net, then the domain primary supply, then set_voltage and set_operating_conditions - and the highest rung that touches the pin is the answer. That decides whether the fix is a constraint change or a UPF issue.
Common Trap
Assuming the last voltage command you wrote wins, or that a broad set_operating_conditions overrides earlier per-port settings. It does not - it sits near the bottom of the ladder, above only the library voltage_map default, so a -driver or -receiver_supply on a named port silently outranks it no matter what order the commands were issued in.
Expect Next
A path times at the wrong voltage - how would you walk the ladder to find what is actually setting it?
Topic And Primetime Commands
Multivoltage / Supply Network. set_voltage, set_related_supply_net, set_operating_conditionsKeep building interview depth
Continue practising STA
Continue learning free
Get a practical low-power chapter
Receive the existing “Low Power and Multivoltage Fundamentals” PDF chapter and its download link by email.
Continue practising