How do you validate clock period and waveform?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
Two clocks can have the exact same period and still be completely different signals โ the waveform (where the rising and falling edges actually sit inside that period) is what determines when your active clock edge really happens. Start with the period: compare what's reported [SDC: from ] against the interface spec for every mode the chip supports โ functional, test, low-power, etc. A clock that's correct in functional mode but wrong in scan mode will pass some checks and silently break others.create_clock -period
Technical Explanation
- Then check the waveform edges:
create_clock -waveform {rise fall}defines exactly when the clock goes high and low within that period. If someone fat-fingers the waveform list, you can get a clock with the right period but the wrong duty cycle or edge polarity โ and STA will happily analyze against the wrong edge. - Pay special attention to non-50% duty cycle clocks โ some interfaces (DDR-style, certain memory or PHY clocks) deliberately use asymmetric high/low times, and if your waveform assumes 50/50 when the spec says otherwise, every setup/hold check downstream is computed against the wrong edge.
- "
- Remember this validation happens before CTS โ you're checking the constraint's correctness, not the physical clock tree, so errors caught here save you from chasing phantom timing failures later.
What To Check
- Warning sign: The period is correct but active edges or duty cycle are wrong.
- Inspect: Compare one named object across the related reports; the same object should tell a consistent story.
- Correct: Correct the owning clock definition and inspect paths using both intended edges.
Command Checks & Actions
- report_clocks: shows clock definitions and relationships
Run the commands in order. Each line answers a separate part of the check.
Healthy, Suspicious & Hard-stop Results
- Expected: Compare reported period and edge waveform with the interface specification for each mode, including non-50-percent duty cycles when relevant.
- 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