How do you audit clock groups and inter-clock relationships?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
Every set_clock_groups declaration (asynchronous, exclusive, or logically_exclusive/related) directly determines which clock-domain crossings the tool will even attempt to analyze — get this wrong and you're not analyzing what you think you're analyzing. An "asynchronous" group declaration tells the tool two clocks have no fixed phase relationship, so it won't check timing across that boundary at all — appropriate for a genuine CDC crossing with proper synchronizers, completely wrong if the two clocks actually do have a real timing relationship in some mode.
Technical Explanation
- g. two clock-mux branches that are never both active) removes paths between those clocks from analysis on the assumption they can never coexist — the audit question is whether that mutual exclusivity is actually guaranteed by the design, not just assumed.
- A single broad group declaration — one wildcard pattern meant to catch one specific pair of clocks — can silently sweep in an entire family of clock crossings you didn't intend to exempt from analysis, exactly the same trap as an overly broad false path.
- Auditing means going through the clock group list and, for each group, checking membership scope (exactly which clocks are actually swept in by the pattern) and mode scope (is this group definition active in every mode, or should it be restricted to specific scenarios) — a group that's correct in one functional mode can be wrong in another if it isn't scoped properly.
What To Check
- Warning sign: Broad asynchronous grouping removes valid timed crossings.
- Inspect: Compare one named object across the related reports; the same object should tell a consistent story.
- Correct: Narrow the group to verified relationships and inspect representative cross-clock paths and exceptions.
Command Checks & Actions
- report_clocks: shows clock definitions and relationships
- report_exceptions: shows timing exceptions and their scope
Run the commands in order. Each line answers a separate part of the check.
Healthy, Suspicious & Hard-stop Results
- Expected: Every asynchronous, exclusive, or related declaration changes which crossings are analysed, so membership and mode scope must be reviewed.
- 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