How would you set up an ideal network and control its propagation?
From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide
Short Answer
Mark the source objects ideal with set_ideal_network (PT); the ideal property then spreads forward through combinational logic and stops at the first sequential cell. Add -no_propagate when only the immediate net, not its whole downstream fanout, should stay ideal.
Technical Explanation
set_ideal_network (PT) marks specific objects as ideal — it does not mark a region of the design.
- What "ideal" means: the tool treats the marked network as having no real interconnect delay to compute, useful before a clock tree exists.
- What becomes ideal: the listed ports or pins, plus anything reachable downstream through combinational cells. A pin counts as ideal if it's in the list, if its driver cell is ideal, or if it loads a net that is already ideal.
- Where propagation stops: it crosses combinational gates but halts the moment it hits a sequential cell — a flip-flop or latch. The ideal tag describes a combinational network fed from the source, not a whole clock domain.
-no_propagate: confines the ideal property to the nets and pins that are electrically connected to the source, skipping the transitive fanout entirely. Use this when only one specific net, a single high-fanout enable, say, needs to stay ideal while everything downstream of it gets real, computed timing.- Giving the network its own numbers: once a network is ideal,
set_ideal_latency(PT) andset_ideal_transition(PT) let you assign it a delay or slew instead of leaving both at zero.
Common Mistake
The Trap: assuming set_ideal_network marks a clock domain rather than a combinational network from one source.
- Someone marks a clock port ideal expecting the whole tree, including the flops it drives, to read as ideal — but propagation stops at every register it reaches.
- The result looks fine until a downstream sequential path is checked against a stale assumption of zero clock delay past that flop, and the review misses it because the label "ideal" was applied at the top.
Follow-up Question & Model Response
Why would you ever want -no_propagate instead of letting the ideal property spread through the fanout?
Candidate Model Response: Full propagation is convenient for an early-stage clock port, where you want the entire pre-CTS tree to read as ideal. But for a single control net — a scan enable or a test-mode select feeding many cells — you usually only want the source pin itself exempted from real delay, not every gate it happens to fan out to. -no_propagate limits the ideal tag to the electrically connected nets and pins at the source, so downstream logic still gets computed, realistic delay. Without it, marking one enable ideal could silently zero out delay across a much larger swath of combinational logic than intended, hiding a real timing problem.
Practical Example
A pre-CTS floorplan has a scan-enable port SE driving 40 combinational mux-select pins across the design. Running set_ideal_network [get_ports SE] (PT) would mark all 40 downstream mux pins ideal too, since propagation follows the transitive fanout through combinational cells. Instead the team runs set_ideal_network -no_propagate [get_ports SE], which keeps only the SE port itself ideal; the 40 mux pins keep their real, extracted delay from the placement so far. A quick report_timing -to [get_pins mux_12/S] (PT) confirms the mux select pin still shows a nonzero interconnect delay, not zero.
Complete STA Handbook
Master Signoff-Ready Static Timing Analysis
Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.
Offline PDF Bundle
Want all 1109 questions offline?
Get the complete 4-book PDF bundle (PnR, STA, MMMC, Low Power) with a clickable table of contents - no ads, no internet needed.
Continue practising