Shielding Nets

Global routing, track assignment, detail routing, DRC convergence, SI and postroute optimization

When two signal wires run next to each other for any appreciable length, they couple. The switching activity on one wire injects charge into its neighbor through the parasitic capacitance between them, and the result is crosstalk — a glitch on a quiet victim, or a timing shift (push-out or pull-in) on a switching one. For most of a design this coupling is a manageable nuisance that the timer and the crosstalk engines clean up after the fact. But for a small set of truly sensitive nets — the clock spines, a handful of asynchronous control signals, analog references — you do not want to leave noise immunity to chance. You isolate those nets physically. That is what shielding does: it walls a sensitive wire off from aggressive neighbors by placing quiet, tied-off conductors on either side of it. This chapter walks through what shielding actually buys you, how to describe a shield rule to the router, the difference between shielding as you route versus bolting it on afterward, and the practical questions that decide whether a net is worth the silicon a shield consumes.

What Shielding Is and Why It Helps

A shield wire is simply a piece of metal that runs parallel to your protected signal and is tied to a constant potential — either VSS (ground shield) or VDD (power shield). Because the shield never switches, it presents a stable, non-aggressive face to the victim. The coupling capacitance that would otherwise have formed between your sensitive net and a noisy data wire now forms between your sensitive net and the quiet shield instead. Coupling to a static node behaves like grounded

capacitance, not like the Miller-multiplied coupling you get from a switching aggressor, so the effective noise injected onto the victim drops dramatically. Shielded signal track (coupling absorbed by guards) shield (GND) victim net shield (GND)

◆ Figure 13.1 Cross-section of a shielded signal track — protected net in the center, grounded shield wires on both

adjacent tracks, with coupling-cap arrows pointing to the shields instead of to data neighbors There are two distinct benefits, and which one matters depends on the net:

• Noise / glitch immunity. For a victim that is supposed to hold a steady value — a latch enable, a reset, an analog bias — a coupled glitch can momentarily lift or drop the node enough to be wrongly sampled. A shield absorbs that injected charge, keeping the functional noise margin intact.
• Delay stability (SI timing). For a clock or a timing-critical data net, the worry is not a wrong value but a wrong arrival time. Switching aggressors can speed up or slow down a transition depending on whether they switch in the same or opposite direction. Shielding removes the aggressor, so the net's delay is deterministic — which is exactly what you want on a clock, where added jitter and skew uncertainty are expensive. This is why clocks are the canonical shielding target. A clock fans out everywhere, it has the highest activity factor in the design, and any SI-induced variation on it directly eats into your timing margin across the whole block.

Defining a Shield Rule

Shielding is expressed through the routing-rule machinery. You create a routing rule of type shield that tells the router what the shield conductor looks like — its width, the layers it is allowed on, the spacing to maintain from the protected net — and then you attach that rule to the nets you want protected. In a the routing tool / the router-style flow this is define_routing_rule with shield-specific options.

# Define a shield rule: shield wires on M4-M7, drawn at min width,
# kept one track away from the protected signal
define_routing_rule shield_rule_clk \
-shield \
-shield_layers {M4 M5 M6 M7} \
-shield_widths {0.05 0.05 0.06 0.06} \
-shield_spacings {0.07 0.07 0.08 0.08} \
-shield_net VSS

A few things to internalize here. The -shield_net decides whether you are building a ground shield or a power shield; ground (VSS) is by far the most common because VSS is usually the quieter, lowerimpedance reference. The -shield_widths and -shield_spacings are per-layer, because the layer pitches differ as you go up the stack. And the layers you list should be the layers your protected nets actually route on — there is no point defining a shield on a layer your clock never uses. Once the rule exists, you bind it to the nets that need protection. You can drive this off a net's role (clock nets are easy to collect) or off an explicit list:

# Collect the clock nets and associate the shield rule with them
set clk_nets [get_nets -hierarchical -filter "net_type == clock"]
apply_routing_rule $clk_nets -rule shield_rule_clk
# A handful of critical async controls get the same treatment
apply_routing_rule [get_nets {top/rst_sync top/scan_en top/test_mode}] \
-rule shield_rule_clk

Shielding During Routing vs Postroute

There are two moments at which shields can be created, and they have different trade-offs. Shielding during routing. Here the router is aware of the shield requirement while it builds the signal route, so it reserves the adjacent tracks and lays the shield down together with the wire. This generally produces the cleanest, most complete coverage — the shield follows the victim faithfully, and the router accounts for the extra tracks when planning the rest of the routing, so you get fewer downstream congestion surprises. You enable it through an tool option on the common router so that the engine honors shield rules as it routes.

# Make the router create shields as part of signal routing
set_tool_option -name common.shielding_nets -value true
# Now run routing; nets carrying a shield rule will be shielded inline
auto_route

Postroute shielding. Here you route the signals first, normally, and then run a dedicated shielding pass that walks each protected net and tries to add shield wires in the space left over beside it. This is

the pragmatic choice when you decided late that a net needed protection, or when you want full control over timing — you can shield, re-time, and decide whether the resource cost was worth it. The downside is that the router is now fitting shields into whatever room remains; in a congested area there may be no adjacent track free, so coverage can be partial.

In practice many teams do both: turn on inline shielding for the known critical set (clocks, top reset), then run a postroute audit and patch any net whose shield coverage came out thin. Shielded signal track (coupling absorbed by guards) shield (GND) victim net shield (GND)

◆ Figure 13.2 Two-panel comparison — left panel "during routing" shows victim plus continuous shields on reserved

tracks; right panel "postroute" shows victim with shields present only where adjacent tracks happened to be free, with gaps

Reshielding Modified Nets

Shielding is not a one-and-done step, because the design keeps moving after you first shield it. ECOs, postroute optimization, hold fixing, and metal fill all rip up and reroute pieces of nets. When a protected net gets rerouted, its old shield no longer follows the new path — you can end up with a shield stranded next to empty space and a freshly routed segment with no protection at all. The fix is to let the tool reshield nets that have been touched. An tool option tells the router that whenever it modifies a shielded net during a later operation, it should also repair or rebuild the shield along the changed segment.

# Repair shields automatically when protected nets are rerouted later
set_tool_option -name common.reshield_modified_nets -value true
# A postroute optimization that reroutes some nets will now
# also bring their shields back along the new geometry
postroute_opt

Without this, a perfectly clean shielding pass can silently degrade over the course of an ECO-heavy backend, and you only discover the gaps when a late SI run flags noise on a clock you thought was protected. Turning on reshielding closes that loop. It is one of the small settings that separates a robust flow from one that looks fine in the first pass and falls apart by tapeout.

PG Shield Distance Threshold

Not every protected net needs a freshly drawn dedicated shield on both sides. Often a sensitive net already runs close to a power or ground rail — a wide PG strap on the same layer, for instance. If a VSS or VDD conductor is already sitting right next to your victim, it is effectively acting as a shield for free, and drawing a second redundant shield wire there just wastes a track. The PG shield distance threshold is the knob that captures this. It defines how close an existing PG wire has to be to the protected net for the tool to count it as already providing the shield. If a PG conductor lies within the threshold, that side of the victim is considered shielded and the router skips adding its own shield there; if the nearest PG metal is farther away than the threshold, the side is treated as unshielded and a new shield gets drawn.

# An existing PG wire within 0.20 um counts as a shield;
# beyond that, the router adds its own shield on that side
set_tool_option -name common.pg_shield_distance_threshold -value 0.20

Tuning this matters. Set it too tight and you draw redundant shields right beside PG straps, burning routing resource for no benefit. Set it too loose and you credit a distant PG wire as a shield when it is too far away to actually suppress coupling, leaving the victim under-protected. A reasonable starting point is on the order of one to two routing pitches on the relevant layer, then validate against your SI analysis.

Choosing What to Shield — and Paying for It

Shielding is not free, and that is the whole reason it is selective. Every shielded net consumes one or two extra tracks for its length, plus the vias and the tie connections to PG. On a congestion-limited block, shielding the wrong set of nets can be the difference between a clean route and a design that will not close DRC. So the discipline is to shield the nets where SI risk genuinely threatens function or timing, and accept ordinary crosstalk management everywhere else. The natural candidates, roughly in priority order:

timing

references

it High-frequency nets deserve a specific mention. The faster the edge rate, the more charge a switching aggressor injects per transition, so high-speed signals couple harder and benefit most from isolation. But that same speed often comes with long, parallel routing for buses, which is exactly where shielding gets expensive — so you typically shield the most timing-critical members of a bus rather than the whole thing. The resource cost is the constant counterweight. A useful mental model: a fully two-sided shield roughly triples the track footprint of the net it protects (the victim plus a shield on each side). On a clock that is worth it; applied indiscriminately it is how you run out of routing tracks.

Coordinated vs Single-Sided Shielding and Tie-Off

Two more choices shape how much protection you actually get. Single-sided vs coordinated (two-sided) shielding. A single-sided shield places a quiet wire on only one side of the victim, leaving the other side exposed to whatever data net happens to route there. It is cheaper — one track instead of two — and is a reasonable compromise when congestion is tight or when one side already abuts PG. Coordinated, or two-sided, shielding walls the victim in on both sides and is the gold standard for clocks and analog: with both neighbors quiet, the victim's coupling environment is fully controlled. The "coordinated" framing matters because the two shields should be planned together with the victim so they stay aligned along its full length rather than appearing in disconnected fragments.

Shielded signal track (coupling absorbed by guards) shield (GND) victim net shield (GND)

◆ Figure 13.3 Side-by-side of single-sided shield (victim with one shield, one exposed data neighbor) versus

coordinated two-sided shield (victim flanked by shields on both tracks) Tie-off to PG. A shield only works if it is genuinely held at a constant potential — a floating shield is just another piece of coupling metal and can actually make things worse. So every shield segment must be tied to the power or ground network. The router connects shield wires down to the PG mesh through vias at intervals along their length; the more frequent and lower-impedance those connections, the better the shield holds its potential against injected charge. When you read out shielding results, this is worth checking: confirm that the shields are not just drawn but actually stitched to PG, because a shield that is geometrically present but electrically floating gives a false sense of security.

# After shielding, verify connectivity and coverage
check_routes
# Report how completely the protected nets were shielded
report_shielding [get_nets -hierarchical -filter "net_type == clock"]

Put together, the recipe for a robust shielding flow is: define a shield rule that matches your victim layers, bind it to a deliberately chosen set of critical nets, shield inline during routing where you can, credit existing PG metal through the distance threshold so you do not waste tracks, turn on reshielding so ECOs do not silently strip protection away, and verify at the end that every shield is tied to PG.

Interview Q&A

you care about comes from coupling capacitance to a switching neighbor — when an aggressor toggles, it injects charge proportional to that cap and the Miller effect can effectively double it. A grounded shield wire never switches, so the coupling cap from the victim now terminates on a fixed potential. Coupling to a static node behaves like ordinary grounded load capacitance, not like an active aggressor, so the injected noise and the delay variation both drop. The shield also physically displaces the data net that would otherwise have been the neighbor.

during routing when you already know the critical set before you route — the router reserves adjacent tracks and lays shields with the wire, giving complete coverage and folding the extra track demand into

its congestion planning. Shield postroute when the decision came late or you want surgical control: route normally, then run a shielding pass that fits shields into leftover space. The trade-off is coverage versus flexibility — inline gives the best, most continuous shields but raises global track demand; postroute risks partial coverage in congested regions because there may be no free adjacent track.

existing power or ground wire must be to a protected net to count as already shielding it. If PG metal sits within the threshold, that side is treated as shielded and no new shield is drawn there; beyond the threshold, the router adds its own. You tune it to avoid two failure modes: set it too tight and you draw redundant shields right next to PG straps, wasting tracks; set it too loose and you credit a PG wire that is too far away to actually suppress coupling, leaving the net under-protected. Roughly one to two routing pitches is a sane starting point, validated against SI.

happened? Almost certainly the net was rerouted by an ECO or postroute optimization and its shield was not rebuilt along the new path, leaving exposed segments. The fix is to enable reshielding of modified nets so the router repairs shields whenever it touches a protected net. The other thing to check is tie-off — confirm the shields are actually stitched to PG and not floating, since a floating shield provides no protection and can even worsen coupling. Re-run a shielding report to confirm coverage is continuous after the repair.

Key Takeaways

• A shield is a quiet, PG-tied wire run beside a sensitive net so coupling terminates on a static potential instead of a switching aggressor — cutting both glitch noise and SI delay variation.
• Shields are described with a shield routing rule ( define_routing_rule -shield ) that sets the shield's layers, widths, spacings, and tie-off net, then bound to chosen victims.
• Inline shielding ( common.shielding_nets ) gives the most complete coverage; postroute shielding trades coverage for late-stage flexibility.
• Turn on reshield_modified_nets so ECOs and optimization don't silently strip protection off rerouted nets.
• Use pg_shield_distance_threshold to credit nearby PG metal as a shield and avoid wasting tracks on redundant shields.
• Shield selectively — clocks, async controls, analog refs, critical high-frequency nets — because two-sided shielding roughly triples a net's track footprint.
• Coordinated (two-sided) shielding is the gold standard for clocks; single-sided is a congestion compromise. Always verify shields are tied to PG, never floating.