A generated clock exists by name but has no valid path from its master. How do you diagnose it?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
The existence of an object named as a generated clock in your database proves only one thing — that the object was created. It says absolutely nothing about whether it's electrically or logically valid, and treating "it exists" as "it's correct" is exactly how this bug slips through review. A properly formed generated clock has to be derived from another clock through real logic — a divider, a MUX, some genuine circuit path — its source and master relationship must trace back through actual netlist connectivity, not just a name someone typed into an SDC command.
Technical Explanation
- Start diagnosis by checking the declared master and source objects — do they actually exist in the current netlist, and does a real signal path connect them to the generated clock's target pin?
- Check the target pin itself — is the pin where the generated clock is supposedly created actually reachable from the stated source through combinational logic that could plausibly implement the divide/multiply/phase relationship claimed?
- g. a permanently-selected MUX input) can structurally break the path the generated clock declaration assumes exists.
- Check for disabled timing arcs along the same path — if an arc between the master and the generated clock's target has been disabled (by library model, user constraint, or loop-breaking), the "master path" the tool needs to propagate through is functionally gone even though the SDC declaration still references it.
- Ultimately you have to trace real netlist connectivity end to end — from the declared master, through actual gates/MUXes, to the actual target pin — and confirm every link in that chain is both present and timing-enabled. If any link is missing, disabled, or broken by case analysis, that's your root cause, and the SDC declaration needs to be corrected to match reality (or the logic needs fixing if the declaration was actually right).
What To Check
- Warning sign: Registers downstream remain unclocked or the generated-clock check warns despite a reported clock.
- Inspect: Keep at least two possible causes open, then use one named object and the active mode or scenario to separate them.
- Correct: Correct the owning generated-clock definition or netlist connection and prove source-to-target reachability.
Command Checks & Actions
- report_clocks: shows clock definitions and relationships
check_timing-include {generated_clock no_clock}: finds missing or inconsistent timing setupreport_disable_timing: shows timing arcs that cannot propagate
Run the commands in order. Each line answers a separate part of the check.
Healthy, Suspicious & Hard-stop Results
- Expected: The name proves object creation only; inspect master, source, target, transformation, case analysis, disabled arcs, and real netlist 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