How do source and estimated network latency differ pre-floorplan?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
Think of clock latency as having two legs of a journey: source latency is the trip before the clock even reaches your block — from the true clock origin (PLL, oscillator, or an off-chip source) to the point where your design's clock port sees it. Network latency is the trip inside your block — from that entry point through the clock tree to each flip-flop's clock pin.
Technical Explanation
- Pre-floorplan, there's no real clock tree yet, so "network latency" at this stage is really just a placeholder number — an assumption the methodology tells you to plug in [SDC:
set_clock_latency] so early STA isn't wildly optimistic. - Don't confuse that placeholder with measured/propagated latency after CTS — the estimated number is a guess based on similar past designs or a rule of thumb; the post-CTS number comes from actual buffer delays and wire RC in the routed tree.
- Practically: source latency models something largely outside your control (the clock generation/distribution network upstream), while network latency is squarely inside your PD scope and should tighten toward its real value as you move through placement and CTS.
- Getting this split wrong is a classic mistake — teams sometimes double-count clock delay by adding uncertainty for both when only one representation is active in a given stage.
What To Check
- Warning sign: Latency is double-counted or assigned to the wrong side of the clock boundary.
- Inspect: Compare one named object across the related reports; the same object should tell a consistent story.
- Correct: Correct stage-specific latency ownership and compare clock path breakdowns.
Command Checks & Actions
- report_clocks: shows clock definitions and relationships
- report_clock_settings: shows latency, transition, uncertainty, and clock-analysis settings
Run the commands in order. Each line answers a separate part of the check.
Healthy, Suspicious & Hard-stop Results
- Expected: Source latency models delay before the design clock source; estimated network latency is a methodology assumption inside the design and must not be confused with measured CTS latency.
- Stop before floorplanning when required logic or timing coverage is missing or unexplained.
Common Mistake
The Trap: Do not assume the check passed just because ICC2 continued. Fix or narrowly justify the named objects, then rerun the same command.
What The Interviewer Is Testing
Be ready to explain why this matters before floorplanning.
Follow-up Question & Model Response
Model response: “I would save the report, inspect one affected object in the correct block and scenario, and make or request this correction. ”
Physical Design & Planning Handbook
Master ASIC Physical Design Planning & Floorplanning
Dive into 14 comprehensive chapters covering netlist sanity, FinFET grids, macro placement, power grids, CTS, and timing budgeting.
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