How do you debug a generated clock's source and master?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
A generated clock's SDC declaration is only as trustworthy as the real logic it claims to describe — everything you report about it (its master, its source pin, its target pin, its divide/multiply factor, its phase, its edge mapping) has to actually match what the netlist implements. Start by confirming the declared master clock is the genuine upstream clock this signal is derived from — not a plausible-sounding but incorrect clock that happens to share a similar name.
Technical Explanation
- Verify the source object — the pin where the generated clock's definition actually attaches — sits on a real signal path traceable back to that master, through actual combinational or sequential logic (a divider, a MUX), not through a coincidental naming pattern.
- Check the target pin, and confirm the divide-by or multiply-by factor declared in SDC actually matches what the real divider circuit implements — a declared "divide by 2" on a circuit that actually divides by 4 will silently corrupt every downstream timing calculation for that clock domain.
- Check phase and edge mapping too — these have to correspond to the real waveform relationship the logic produces, not just a default assumption.
- The debugging method is always the same: trace the real physical/logical connectivity between the stated master and the stated target, and compare every parameter in the SDC declaration against what that real logic actually does — any mismatch is the bug, whether it's in the SDC declaration or in your understanding of the RTL.
What To Check
- Warning sign: The clock name exists but derives from the wrong pin or an unrelated master.
- Inspect: Compare one named object across the related reports; the same object should tell a consistent story.
- Correct: Correct the generated-clock definition and prove the source path and sink coverage.
Command Checks & Actions
- report_clocks: shows clock definitions and relationships
check_timing-include {generated_clock no_clock}: finds missing or inconsistent timing setup
Run the commands in order. Each line answers a separate part of the check.
Healthy, Suspicious & Hard-stop Results
- Expected: The reported master, source object, target pin, divide/multiply factor, phase, and edge mapping must match real logic connectivity.
- 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