supply0 and supply1 Nets in Verilog

Chapter 5 · Section 5.1.6 · Data & Variables

1. The Engineering Problem

A junior engineer is writing the top-level instantiation of a 64-bit register file. The register file has 64 enable bits, but the current design only uses 16 of them — the other 48 are supposed to be permanently disabled. The straightforward instantiation:

reg_file u_rf (
    .clk      (clk),
    .rst_n    (rst_n),
    .wr_en    ({48'b0, wr_en_low16}),   // upper 48 bits hard-coded to 0
    .wr_data  (wr_data),
    .rd_data  (rd_data)
);

The 48'b0 constant works — the upper 48 bits will read 0 for the entire simulation. But lint flags the line: "constant net driving a port; consider explicit tie cell." The synthesis tool produces working gates, but the post-synthesis netlist shows 48 separate wires each driven by a 1'b0 constant, each routed individually through the floorplan, each consuming a small amount of metal area. The design-review feedback: "Use proper tie-off cells instead of constant nets — the synthesis tool will use the standard-cell library's TIE0 cell once and route a single net to all 48 sinks."

The Verilog language has a cleaner expression of the same intent — the supply0 net type:

supply0 gnd_tie;       // electrically tied to GND, supply strength
supply1 vdd_tie;       // electrically tied to VDD, supply strength
 
reg_file u_rf (
    .clk      (clk),
    .rst_n    (rst_n),
    .wr_en    ({{48{gnd_tie}}, wr_en_low16}),  // 48 bits at GND
    .wr_data  (wr_data),
    .rd_data  (rd_data)
);

The supply0 net is electrically 0 at the strongest possible strength (supply0, rank 7). The synthesis tool recognises the keyword and uses the foundry's TIE0 standard cell — a single instance whose output is shared across all 48 sinks. The lint warning is gone. The netlist is one tie cell instead of forty-eight, and the power-aware flows (UPF / CPF) see the rail tie as a documented connection to the chip's GND plane, not as a logic constant.

This page is about the supply0 and supply1 net types — what they declare, why they synthesise cleanly when every other strength-aware net type does not, and the use cases (rail-tie modelling, unused-input handling, UPF / CPF power domain crossings) that make them genuinely useful in modern flows.

2. Why supply0 / supply1 Exist

Every CMOS gate's behaviour depends on its connection to VDD (the supply rail) and GND (the ground rail). The PMOS network's source connects to VDD; the NMOS network's source connects to GND. Without those connections, no gate would work — and yet for most of Verilog's modelling abstraction, the rails are invisible. A wire doesn't know whether the gate it drives is connected to VDD or to a 1.8 V supply or to a different power domain entirely.

For the most part, this invisibility is fine — the gate-level behaviour is captured by the standard-cell library's timing model, not by the RTL. But four cases need the rails to be visible in the RTL itself:

1. Unused-input tie-offs. A module port that is permanently connected to a constant value should be tied to the rail, not driven by a logic constant. The synthesis tool generates better gates from a rail tie than from a constant assignment.
2. Multi-power-domain designs. A chip with multiple power domains (e.g. an always-on domain at 0.9 V and a high-performance domain at 1.0 V) needs the RTL to declare which rail each net belongs to. UPF and CPF flows use supply0 / supply1 as the building blocks for power-domain modelling.
3. Library-cell power pins. A standard cell's Verilog model declares its VDD / VSS pins as supply1 / supply0. The synthesis tool maps these to the chip's power planes at integration time.
4. Switch-level modelling. A pmos or nmos switch primitive (Chapter 12) needs an explicit source connection to the rail. Declaring the rails as supply0 / supply1 makes the switch's source-drain semantics correct under the strength lattice.

In all four cases, the language needs a way to say: "this net is electrically tied to the chip's power or ground rail." The chosen mechanism is the supply0 / supply1 net type — a net with no explicit drivers, whose value is fixed at 0 or 1 at supply strength. The supply strength (rank 7) is the strongest possible on the IEEE 1364 lattice — nothing else in the design can override it, exactly as nothing in real silicon can pull VDD to GND without a destructive short.

3. Mental Model

The mental-model has three consequences:

• No drivers, no resolution. A supply0 net has exactly one driver (the implicit rail tie), and its value is fixed at compile time. The resolution function never runs on a supply0 / supply1 net because there is nothing to resolve. The strength annotation supply0 / supply1 is part of the net's declaration; the simulator presents the value directly.
• supply strength is unbreakable. Adding an explicit driver to a supply0 net is undefined behaviour in the IEEE 1364 spec — most simulators ignore the explicit driver (the supply strength wins), but some simulators flag it as a warning or error. The right discipline: never write assign supply_net = anything;. The keyword is the value.
• Synthesis-perfect. Every modern synthesis tool maps supply0 / supply1 to the foundry's tie cells (TIE0 / TIE1) and routes them to the chip's power planes during placement. This is the only net type in the strength-aware family that synthesises everywhere with no rewrite, no warning, and no surprise.

4. The Resolution Function

A supply0 net's resolved value is always 0 at strength supply0 (rank 7).

A supply1 net's resolved value is always 1 at strength supply1 (rank 7).

Neither value can change during simulation. There is no driver list to walk, no resolution function to run, no event to wake the simulator. The net's value is a compile-time constant.

If the design writes an assign statement that targets a supply0 / supply1 net, the IEEE 1364 spec considers the behaviour undefined:

The right discipline: never write an assign to a supply net. The keyword is the constant. If you need to drive a logic constant somewhere, declare a regular wire and use an explicit assign — supply0 / supply1 are reserved for rail ties.

5. Syntax

`default_nettype none
 
// <supply0 | supply1> [range] name;
 
supply0 gnd_tie;            // scalar GND tie
supply1 vdd_tie;            // scalar VDD tie
 
supply0 [7:0] gnd_byte;     // 8-bit all-zero bus
supply1 [3:0] vdd_nibble;   // 4-bit all-one bus
 
supply0 [WIDTH-1:0] gnd_bus; // parametrised width
 
// signed is legal but pointless — value is constant
// no continuous-assign shorthand allowed (no `assign` legal)
// no strength specifier (strength is fixed at supply)
// no `signed` for anything meaningful
 
// Top-level pad model
module pad_vdd (output supply1 vdd_pad);   // VDD pad port
endmodule

Three syntax constraints:

• No strength specifier. A supply0 (strong0, highz1) net; is illegal — the strength is fixed at supply by the net type. Any explicit strength annotation is a syntax error.
• No continuous-assign shorthand. supply0 net = 1'b1; is illegal — the supply value is part of the keyword, not specified by an assignment. The closest legal form is to declare the net and let the implicit rail-tie do the work.
• signed is legal but redundant. A supply0 net's value is always 0 regardless of signedness; the signed modifier affects the interpretation in arithmetic operators (e.g., signed_supply0 + 1 might extend differently), but the net value itself is unchanged.

5.1 Vector supply nets

A supply0 [7:0] gnd_byte; declares an 8-bit bus where every bit is 0 at supply0 strength. There is no per-bit variation — every bit carries the same constant value. The bus is functionally equivalent to a 8'b0000_0000 constant but synthesises to a single tie cell with the output fanned out to all sinks, not eight separate tie cells.

The same applies to supply1 vectors — every bit is 1 at supply1 strength.

5.2 Implicit declaration via default_nettype

`default_nettype supply0 or `default_nettype supply1 is technically legal but never seen in practice. Making every undeclared net default to a power-rail tie would mean every signal in the file is electrically tied to VDD or GND — which would short the design and produce a useless netlist. Always use `default_nettype none (or, for the most-conservative codebases, `default_nettype wire). The supply nets are explicit declarations only.

6. Visual Explanation

Three figures cover the supply0 / supply1 role in a design.

6.1 Visual A — supply nets as rail ties

The conceptual picture. Two nets, both declared with no explicit drivers; the synthesis tool ties them directly to the chip's VDD and GND planes. Every consumer in the design that reads these nets sees the constant value at unbreakable strength.

6.2 Visual B — unbreakable strength

The strength lattice in action. A supply1 at rank 7 wins against every other driver — even a strong0 (rank 6) cannot override it. Adding any explicit driver to a supply net either fails (Xcelium error) or is silently ignored (VCS / Questa warning).

6.3 Visual C — tie-cell synthesis mapping

The synthesis story. A supply0 net in RTL maps to a TIE0 standard cell in the netlist. A supply1 net maps to a TIE1 standard cell. Each tie cell drives all the sinks of the net through normal routing; the synthesis tool ensures every sink is reached.

7. Unused-Input Tie-Off Example

The most common production use. A peripheral IP module has 64 inputs, but only 16 are connected on this revision. The other 48 must be tied to a defined value to avoid floating-gate issues at the gate level.

`default_nettype none
 
module peripheral_wrapper (
    input  wire        clk,
    input  wire        rst_n,
    input  wire [15:0] used_inputs,        // only 16 of the 64 are used
    output wire [31:0] data_out
);
    // Tie nets for unused inputs.  supply0 = GND tie (constant 0).
    supply0 gnd_tie;
 
    // The peripheral has a 64-bit input port; we drive 48 bits from the
    // GND tie and 16 bits from the actual signal.
    peripheral_64 u_periph (
        .clk      (clk),
        .rst_n    (rst_n),
        .inputs   ({{48{gnd_tie}}, used_inputs}),   // 48 bits tied to 0
        .data_out (data_out)
    );
endmodule

The 48 unused-input bits all read 0 at supply0 strength. The synthesis tool sees the {48{gnd_tie}} replication and the supply0 net type, and produces:

• One TIE0 cell instance — a single standard-cell library tie-off that produces a logical 0 at minimal area.
• 48-way fanout from TIE0's output — routing to all 48 input pins of the peripheral_64 module's inputs port.
• No constant-net synthesis warnings — the synthesis tool understands the rail-tie intent.

Compare against the literal-constant pattern:

// Less-good — generates 48 separate constants, possibly 48 tie cells
.inputs ({48'b0, used_inputs}),

Functionally identical, but the synthesis tool typically generates more tie cells (one per bit, depending on the tool and tech) and adds lint warnings about "constant net driving a port." The supply0 keyword expresses the intent in a way every synthesis tool understands.

7.1 When to use supply0 vs a regular constant

The general rule: use supply0 / supply1 when the constant is electrically a rail tie. Use a regular constant literal (1'b0, 1'b1) when the constant is algorithmic.

• "All 48 unused input bits go to GND" → supply0 (rail tie).
• "The reset value of this register is 8'h00" → regular constant (algorithmic).
• "Tie all bits of the dec ignore mask to 1" → supply1 (rail tie).
• "The default address for boot is 32'h0000_0000" → regular constant (algorithmic).

The litmus test: would you describe this as "the signal is connected to the supply rail" or as "the signal carries a particular value"? Rail connection → supply net. Particular value → constant literal.

8. Library Cell Power-Pin Example

A typical standard cell's Verilog model declares its VDD and VSS pins as supply nets. This is the canonical use that survives in every production library.

`default_nettype none
 
module inverter_cell (
    input  wire       a,
    output wire       y,
    inout  supply1    vdd,           // VDD power pin
    inout  supply0    vss            // VSS / GND power pin
);
    // The cell's logical function — modelled at switch level using
    // the rail-tied supply nets as the source connections.
    //
    // PMOS: drain=y, gate=a, source=vdd (pulls y HIGH when a=0)
    // NMOS: drain=y, gate=a, source=vss (pulls y LOW  when a=1)
    pmos p1 (y, vdd, a);
    nmos n1 (y, vss, a);
endmodule

The supply1 vdd and supply0 vss declarations on the inout ports tell the synthesis tool that these are power-pin connections. At integration time, the chip's VDD and VSS power planes are routed to these ports — the synthesis tool generates the routing as part of the power-grid synthesis pass, separately from the signal-routing pass.

The pmos and nmos switch primitives (Chapter 12) reference the supply nets as their source connections. The PMOS pulls its drain HIGH when the gate input is 0 — the source vdd provides the 1 value to be passed. The NMOS pulls its drain LOW when the gate input is 1 — the source vss provides the 0 value to be passed. Without the supply nets, the switch primitives would have no source to draw from, and the cell model would not work.

This pattern is specific to switch-level cell models — the Verilog files inside a foundry's standard-cell library. Regular RTL never uses pmos / nmos primitives; the synthesis tool replaces every assign y = ~a; with a library cell instance (an INV_X1 cell, for instance), and the cell's internal switch-level model is hidden from the user.

9. UPF / CPF Power-Domain Modelling

The modern use of supply0 / supply1 is in multi-power-domain designs where different parts of the chip run at different voltages or can be independently powered down. The UPF (Unified Power Format) and CPF (Common Power Format) standards declare power domains, isolation cells, level shifters, and retention cells as RTL constructs — and the supply nets are the building blocks.

A simplified UPF-style modelling:

`default_nettype none
 
// Power domain A — always-on, 0.9 V
supply1 vdd_a;
supply0 vss_a;
 
// Power domain B — switchable, 1.0 V
supply1 vdd_b;
supply0 vss_b;
 
// Level shifter — translates a signal from domain A to domain B
module level_shifter (
    input  wire    in_a,        // signal in domain A
    output wire    out_b,       // signal in domain B
    inout  supply1 vdd_a_port,  // domain A supply
    inout  supply0 vss_a_port,  // domain A ground
    inout  supply1 vdd_b_port,  // domain B supply
    inout  supply0 vss_b_port   // domain B ground
);
    // The level shifter's logic — multiplied through the
    // appropriate power domain at gate level.
    assign out_b = in_a;
endmodule

The four supply nets declare the two power domains. The level shifter has explicit power-domain ports on both sides, allowing the placement-and-routing tool to verify that the cell is correctly placed between the two domains and that the supply connections are routed to the right planes.

UPF / CPF flows are typically not part of the RTL author's daily concern — they appear in the floorplan, the power-intent file, and the synthesis constraint scripts. But the foundation is the supply0 / supply1 net type. Without these keywords, multi-domain modelling at the RTL layer would require ad-hoc conventions that no two tools agree on.

10. Tie-Off Best Practices

The general pattern for unused-input tie-offs in production RTL:

`default_nettype none
 
module wrapper (
    input  wire [WIDTH-1:0] data_in,
    output wire [WIDTH-1:0] data_out
);
    // Declare tie nets once at module scope, reuse everywhere needed.
    supply0 gnd_tie;
    supply1 vdd_tie;
 
    // Use the tie nets in port lists wherever a constant is needed.
    inner_block u_inner (
        .data_in           (data_in),
        .unused_enable     (gnd_tie),         // permanently disabled
        .reserved_for_v2   (gnd_tie),         // tied for now
        .test_mode         (gnd_tie),         // production: 0
        .alt_clock_sel     (gnd_tie),         // use primary clock
        .high_perf_mode    (vdd_tie),         // production: 1
        .data_out          (data_out)
    );
endmodule

The discipline:

• One pair per module. Declare gnd_tie and vdd_tie once at module scope. Reuse them everywhere a tie-off is needed within the module.
• Name by intent. gnd_tie reads more clearly than tie_lo or s0 — anyone reading the module knows it's a GND-rail tie.
• Tie on the producer side, not the consumer side. The u_inner instance declares its unused_enable port as wire; the parent module ties it to gnd_tie. Don't change the inner module's port declaration to supply0 — that would force every parent module to route to a rail, which is not always what's wanted.
• Don't use supply nets for algorithmic constants. Reset values, default addresses, magic numbers — these are algorithmic constants. Use literal values (1'b0, 8'h00) and let the synthesis tool decide whether to tie or not.

11. Simulation Behavior

The simulator handles supply0 / supply1 nets specially: their values are set at compile time and never change. There are no events to schedule, no resolution function to run, no driver list to walk.

When a downstream consumer reads a supply0 net, the simulator returns 0 at strength supply0 — same on every cycle, same in every time slot. No memory is allocated for tracking driver state; no resolution events are scheduled.

The waveform dump for a supply net typically shows the constant value with a strength annotation — Su0 (supply0) or Su1 (supply1) — indicating to the user that this net is electrically tied to a rail. Some waveform viewers hide supply nets by default since their values never change; the rail-tie nature makes them uninteresting for debugging.

12. Waveform Analysis

Strictly speaking, supply0 / supply1 nets have no interesting waveform — their values are constant for the entire simulation. The figure below shows a typical waveform from a module that uses both supply nets and regular signals; the supply rows confirm the constant value and the strength annotation.

The takeaway: supply nets do not need a waveform analysis section in any normal sense — they have no temporal behaviour to analyse. The figure is for completeness; in practice, debugging a design rarely involves looking at supply-net waveforms.

13. Synthesis Insight

supply0 / supply1 are uniquely synthesis-friendly among the strength-aware net family.

Every modern synthesis tool recognises the keywords and maps them to the foundry's tie-off standard cells:

• supply0 → TIE0 (or equivalent — TIELO_X1, TIE_LO, TIE_ZERO, etc.; names vary by foundry).
• supply1 → TIE1 (or TIEHI_X1, TIE_HI, TIE_ONE, etc.).

The tie cell is electrically a single transistor — NMOS for TIE0 (drain shorted to GND), PMOS for TIE1 (drain shorted to VDD). The output is the constant logic value; the cell consumes no dynamic power (no switching) and minimal leakage power (a single transistor's sub-threshold current).

At placement-and-routing time, the tool's power-grid synthesis pass routes the chip's actual VDD and VSS planes to the tie cell's source pin. The tie cell's output is routed normally as a logic net to its consumers.

// RTL
supply0 gnd_tie;
supply1 vdd_tie;
 
// After synthesis (conceptually):
TIE0 u_tie_lo (.Y(gnd_tie_net));      // single tie cell instance
TIE1 u_tie_hi (.Y(vdd_tie_net));      // single tie cell instance
// gnd_tie_net is routed to every consumer that read supply0 in RTL.
// vdd_tie_net is routed to every consumer that read supply1 in RTL.

The mapping is universal. Synopsys Design Compiler, Cadence Genus, Synopsys Fusion Compiler, Yosys (open-source), and every other modern flow recognise supply0 / supply1 and produce the tie cells. There is no rewrite, no "internal-vs-port" distinction, no gate-level divergence — supply0 / supply1 are the only strength-aware nets that synthesise cleanly everywhere in the hierarchy.

14. Industry Use Cases

The three places supply0 / supply1 show up in modern engineering work:

14.1 Top-level unused-input tie-offs

The most common use. A chip-level wrapper module instantiates a peripheral IP with 64 inputs but uses only some of them; the rest are tied via supply0 (for inputs that should be 0) or supply1 (for inputs that should be 1). The synthesis tool generates a single TIE0 / TIE1 cell with fan-out to all sinks.

14.2 Library cell power pins

Every foundry's standard-cell Verilog model declares the cell's VDD / VSS pins as supply1 / supply0. The synthesis tool sees the supply declarations on the cell's inout ports and routes them to the chip's power planes during the power-grid pass. RTL designers don't normally see these declarations — they live inside the library files — but they're fundamental to the synthesis flow.

14.3 Multi-domain power modelling

Designs with multiple power domains (always-on at 0.9 V, high-performance at 1.0 V, switchable peripheral at 0.8 V) declare each domain's VDD and VSS as separate supply nets. UPF / CPF power-intent files reference these supply nets to specify domain boundaries, isolation cells, and level shifters. Modern SoCs typically have 3–10 power domains, each represented by a pair of supply nets at the chip-level wrapper.

In all three cases, supply0 / supply1 are doing real work — generating tie cells, routing to power planes, defining domain boundaries. They are the only strength-aware nets that synthesise everywhere in a clean, well-defined way.

15. Common Mistakes

Five pitfalls that catch engineers using supply0 / supply1.

15.1 Writing assign to a supply net

The most common syntax error. An engineer declares supply0 gnd_tie; and then writes assign gnd_tie = 1'b0; "just to be safe." The simulator either warns (VCS, Questa) or errors out (Xcelium); the discipline is that the keyword is the value — no assign is needed or legal. Removing the assign fixes the code.

15.2 Using supply nets for algorithmic constants

A supply net synthesises to a tie cell — a piece of silicon. Using supply0 for "the reset value of this 32-bit register" generates a 32-cell TIE0 instance whose output drives the register's D input through the reset mux — wasteful. The right pattern: write 8'h00 as a literal in the reset branch of the always block; the synthesis tool optimises the constant into the gates of the using logic without instantiating tie cells.

15.3 Forgetting that supply nets ARE constants

A supply0 net cannot ever read 1. Code that tries to "drive supply0 to 1 during a special mode" doesn't work — there's no way to change the value. If a signal needs to switch between 0 and 1 based on a condition, it's not a supply net; it's a regular wire driven by a conditional assign.

15.4 Vector supply nets — bit-level individual control

A supply0 [7:0] gnd_byte; is eight bits, all 0 — not "eight independent supply0 bits that can each be 0 or 1." If you need a mix of 0 and 1 bits, declare separate nets or use a regular wire with an explicit assign 8'h0F;. Vector supply nets are useful only for "all bits at the same rail value" patterns.

15.5 Forgetting the inout direction on cell power ports

A standard cell's power port declaration must be inout (or output in some unusual cases) — never input. A supply0 declared as input on a port is a logical impossibility: the supply value is the constant 0, so an "input" supply0 would mean "consume a 0 from outside" which is incoherent. The right pattern: inout supply0 vss; and inout supply1 vdd; on every standard cell's power ports.

16. Debugging Lab

17. Coding Guidelines

1. Use supply0 for rail ties to GND, supply1 for rail ties to VDD. Unused-input tie-offs, library cell power pins, multi-domain power modelling. Not for algorithmic constants.
2. Never write an assign to a supply net. The keyword is the value; explicit drivers are either ignored (warning) or rejected (error). Removing the assign is the fix.
3. Declare one pair per module. supply0 gnd_tie; supply1 vdd_tie; once at module scope; reuse them in port lists. Name them clearly.
4. Use scalar supply nets with replication for vector tie-offs. {48{gnd_tie}} generates one tie cell with 48-way fanout, not 48 separate tie cells.
5. Power-port directions are inout. Never input. The supply value is constant, so "consuming" it is incoherent.
6. Use literal constants for algorithmic values. Reset values, default addresses, opcode constants → 1'b0, 8'h00, 8'hAA. Let synthesis optimise these into the using gates.
7. signed is legal but pointless. Supply nets carry a single value at every bit position; signedness doesn't change anything. Skip the modifier.
8. Document the modelled rail. A one-line comment naming the power domain ("Always-on VDD; 0.9 V") tells the next engineer the keyword's purpose.

18. Interview Q&A

19. Exercises

Three exercises that turn the supply-net model into reflex.

Exercise 1 — Predict the resolved value

For each scenario, predict the resolved value and strength.

Hints. Supply nets have a single implicit driver at supply strength. The keyword is the value. Explicit drivers are either ignored (warning) or rejected (error).

Exercise 2 — Implement a tie-off wrapper

Write a Verilog module peripheral_with_ties that instantiates a hypothetical peripheral_64 IP block with the following port mapping:

• 16 active input bits driven by wire [15:0] active_in.
• 32 input bits tied permanently to 0.
• 16 input bits tied permanently to 1.
• 32-bit output data_out.

Hints. Declare two scalar supply nets (gnd_tie, vdd_tie) at module scope. Use replication concat to expand them to the needed widths. The IP's input port is 64 bits; the concat order from MSB to LSB should match the IP's port description.

Exercise 3 — Identify the bug

The following module is supposed to tie an unused interrupt enable to GND, but synthesis produces a tri net with multiple drivers and the gate-level netlist has a multi-driver violation. Identify the bug and fix it.

module unused_irq (
    input  wire        clk,
    output wire        irq_out
);
    supply0 irq_disabled;
 
    assign irq_disabled = 1'b0;   // "make sure it's 0"
    assign irq_out = irq_disabled;
endmodule

What to produce. (a) Explain why the synthesis tool sees a multi-driver violation. (b) Fix the bug by removing the explicit driver. (c) Explain why the explicit assign 1'b0; was redundant in the first place.

20. Summary

supply0 and supply1 are Verilog's rail-tie net types — special nets that model the chip's GND and VDD rails at supply strength (rank 7, the strongest on the IEEE 1364 lattice).

The mechanism is precise:

• supply0 — value 0, strength supply0, electrically tied to the chip's GND plane.
• supply1 — value 1, strength supply1, electrically tied to the chip's VDD plane.
• No explicit drivers. The keyword is the value. Writing assign supply_net = anything; is either a warning (VCS, Questa) or an error (Xcelium).
• Unbreakable strength. Nothing in the design can override a supply net — the resolution function always returns the supply value at supply strength.

The use cases are well-defined:

• Unused-input tie-offs. Declare supply0 gnd_tie; and supply1 vdd_tie; once per module; use them in port-mapping concatenations to tie unused bits to defined values. The synthesis tool generates one tie cell per net with fanout to all sinks.
• Library-cell power pins. Every foundry standard-cell .v model declares its VDD / VSS pins as inout supply1 / inout supply0. The synthesis tool routes the chip's power planes to these pins during the power-grid pass.
• Multi-power-domain modelling. Designs with multiple power domains use separate supply nets per domain. UPF / CPF flows reference these as the building blocks for domain boundaries, isolation cells, and level shifters.

The synthesis story is uniquely good:

• Maps to library tie-off cells (TIE0, TIE1) on every synthesis tool.
• One tie cell per scalar supply net; output fans out to all sinks.
• Routed via the power-grid synthesis pass, not the signal-routing pass.
• No internal-vs-port distinction — synthesises cleanly everywhere in the hierarchy.
• Contributes zero simulation overhead (no events, no resolution).

The day-to-day discipline:

• Use supply0 / supply1 for rail ties. Unused inputs, library power pins, multi-domain modelling. Not for algorithmic constants — use literals (1'b0, 8'h00).
• Never write assign supply_net = ...;. The keyword is the value; explicit drivers are illegal.
• One pair per module, reused. Declare gnd_tie and vdd_tie once; use them everywhere a tie-off is needed.
• Scalar + replication for wide ties. {48{gnd_tie}} is one tie cell with 48-way fanout; supply0 [47:0] bus; is 48 tie cells.
• Power-port direction is inout. Never input — that's a logical impossibility for a constant-value net.

This page closes Section 5.1 — the full net family is now covered: wire / tri (5.1.1), Signal Strengths (5.1.2), wand / wor (5.1.3), trireg (5.1.4), tri0 / tri1 (5.1.5), and supply0 / supply1 (this page). The chapter now pivots from nets to variables: 5.2 Register Data Types introduces reg, integer, real, and the scalar / vector / array dimensions that define how the simulator stores algorithmic state across cycles.

Related Tutorials

• Signal Strengths — Chapter 5.1.2; the strength lattice that supply strength sits at the top of.
• tri0 and tri1 Nets — Chapter 5.1.5; the pull-net types whose pull strength loses to the supply nets' supply strength.
• wire and tri Nets — Chapter 5.1.1; the baseline net types this page is a specialisation of.
• Physical Data Types — Chapter 5.1; the parent overview of the net family.
• Variables & Data Types — Chapter 5; nets and variables together.