How do source and estimated network latency differ pre-floorplan?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
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.
Technical Explanation
Source latency belongs before the block clock source. Estimated network latency represents an early assumption inside the block; it is not measured clock-tree delay.
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. • Investigate: Latency is double-counted or assigned to the wrong side of the clock boundary. • Stop before floorplanning when required logic or timing coverage is missing or unexplained. Correct stage-specific latency ownership and compare clock path breakdowns.
Common Mistake
Do not assume the check passed just because ICC2 continued: Latency is double-counted or assigned to the wrong side of the clock boundary. 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: Latency is double-counted or assigned to the wrong side of the clock boundary.
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: Correct stage-specific latency ownership and compare clock path breakdowns. Then I would reopen the clean checkpoint and rerun the same evidence.”
Practical Example
Symptom: Latency is double-counted or assigned to the wrong side of the clock boundary. Corrective path: Correct stage-specific latency ownership and compare clock path breakdowns.
Continue practising