Why are clocks normally ideal before floorplanning?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
There is no implemented clock tree, so built-tree skew and route latency do not exist; only justified early assumptions belong in the model.
Technical Explanation
Before a clock tree exists, its routed delay and skew cannot be measured. Early clock values are modelling assumptions and should be labelled and reviewed as such.
What To Check
• Warning sign: A copied post-CTS propagated-clock setting creates fictional network behaviour. • Inspect: Compare one named object across the related reports; the same object should tell a consistent story. • Correct: Remove unsupported propagation and use the approved pre-CTS source latency, uncertainty, and transition model.
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: There is no implemented clock tree, so built-tree skew and route latency do not exist; only justified early assumptions belong in the model. • Investigate: A copied post-CTS propagated-clock setting creates fictional network behaviour. • Stop before floorplanning when required logic or timing coverage is missing or unexplained. Remove unsupported propagation and use the approved pre-CTS source latency, uncertainty, and transition model.
Common Mistake
Do not assume the check passed just because ICC2 continued: A copied post-CTS propagated-clock setting creates fictional network behaviour. 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: A copied post-CTS propagated-clock setting creates fictional network behaviour.
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: Remove unsupported propagation and use the approved pre-CTS source latency, uncertainty, and transition model. Then I would reopen the clean checkpoint and rerun the same evidence.”
Practical Example
Symptom: A copied post-CTS propagated-clock setting creates fictional network behaviour. Corrective path: Remove unsupported propagation and use the approved pre-CTS source latency, uncertainty, and transition model.
Continue practising