Thousands of registers show no_clock after SDC load. What do you do?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
When thousands of registers suddenly report no_clock, don't reach for a targeted patch — treat it as a hard stop and a readiness check on the whole handoff, because a fix at this scale that "just" attaches clocks locally is very likely to be masking a real upstream problem. Systematically test the competing root causes rather than guessing: wrong current mode active in the tool, an empty or misconfigured clock-source selector, a broken generated-clock or gated-clock path somewhere upstream, or a hierarchy mismatch between the SDC's object names and the actual netlist.
Technical Explanation
- The debugging output has to be concrete — named objects, not a vague "looks like clocking is broken" — because whoever picks this up next needs to reproduce exactly what you found from the same handoff data.
- This is a pattern worth internalizing for PD-readiness debugging generally: a problem this widespread is almost always systemic (mode/scenario/hierarchy), not thousands of independent local issues.
- Resist the urge to write a wildcard SDC patch that forces clocks onto the flagged registers — if the real cause is a hierarchy or mode mismatch, that patch just hides the defect until it resurfaces somewhere worse.
What To Check
- Warning sign:
check_timingreports a large no_clock population although read_sdc completed. - Inspect: Keep at least two possible causes open, then use one named object and the active mode or scenario to separate them.
- Correct: Correlate affected hierarchy with report_clocks and selector results, then return the defect to the SDC or netlist owner and rerun.
Command Checks & Actions
check_timing-include {no_clock}: finds missing or inconsistent timing setup- report_clocks: shows clock definitions and relationships
- get_pins -hierarchical <clock_pin_pattern>: selects instance pins
Run the commands in order. Each line answers a separate part of the check.
Healthy, Suspicious & Hard-stop Results
- Expected: Treat this as a hard stop and test competing causes: wrong current mode, empty clock source selector, broken generated/gated path, or mismatched hierarchy.
- 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