IntermediateQuestion 28 of 112

Explain the voltage precedence ladder. Why does it exist?

From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide

By Tabish Iqbal, who has 9+ years of VLSI Physical Design experience

Short Answer

It's the fixed tie-breaker order the tool uses when several mechanisms could each set the voltage on the same object — from a named-port override at the top down to the library's default voltage map at the bottom. A more specific, explicitly targeted setting always wins over a broad default.

Voltage precedence ladder as a vertical stack of eight rungs from named-port driver/receiver supply at top to library voltage_map default at bottom — Technical Reference DiagramExplain the voltage precedence ladder. Why does it exist?

Technical Reference DiagramExplain the voltage precedence ladder. Why does it exist?

Technical Explanation

In a multivoltage design, 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.

The rungs, highest to lowest: -driver_supply/-receiver_supply (SDC) on a named port; the same options on an element; set_related_supply_net (SDC); the domain's primary supply; set_voltage (SDC) on a PG pin, which needs a signal-integrity license; set_voltage on a supply net; set_operating_conditions (SDC); and last, the library's voltage_map default.
The organizing rule: the more specific the target and the more explicitly you named it, the higher it sits on the ladder — a port-level setting outranks an element-level one, which outranks a supply-net assignment, which outranks the domain default.
Why the ladder exists at all: without a fixed order, behavior would depend on which command happened to run last rather than on intent. The ladder makes the outcome predictable and repeatable regardless of command order.
Why it's also a debug tool: when a path times at a voltage you didn't expect, you walk down the ladder from the top, checking which rung actually touches that pin — the first one that does is the setting in effect.

Common Mistake

The Trap: assuming the last voltage-setting command written in the SDC is the one that applies.

A designer adds a set_operating_conditions (SDC) override near the bottom of the file expecting it to take effect for a port, without realizing an earlier, higher-precedence -driver_supply setting on that exact port still wins.
The path continues timing at the higher-precedence voltage, and the mismatch looks like a tool bug rather than the ladder working as designed.

Follow-up Question & Model Response

If report_timing shows a path using a voltage you didn't expect, what's the fastest way to find out which mechanism actually set it?

Candidate Model Response: Start at the top of the ladder and check each rung against the specific pin in question — is there a -driver_supply or -receiver_supply override on that exact port, then an element-level one, then a set_related_supply_net assignment, and so on down to the library default. The first rung that actually targets the object is the one in effect, since everything below it is overridden. Running report_power_pin_info (PT) shows the resolved voltage on the cell's PG pins, and report_timing -voltage (PT) shows it on signal pins, which is quicker than scanning the whole SDC file top to bottom for every possible voltage command.

Practical Example

A level-shifter output port LS_OUT sits in a domain whose primary supply is set to 0.9V via set_related_supply_net. A separate line elsewhere in the SDC adds set_port_attributes -elements {LS_OUT} -receiver_supply VDD_HIGH (SDC) targeting that same port directly. Because a named-port -receiver_supply setting outranks a set_related_supply_net assignment on the ladder, the port times against VDD_HIGH's voltage, not the domain's 0.9V default, even though the domain-level command appears later in the file.

Complete STA Handbook