A path shows negative setup slack, but you believe it's a genuine multicycle path that was never constrained. Give the end-to-end procedure to confirm and fix it safely.
From PDVerse PrimeTime STA Interview Guide · pdVerse Mentor Guide
Ten-second Interview Answer
Confirm the path exists and see what constrains it today, get the real cycle count from the designer, apply set_multicycle_path -setup N with the matching -hold, then re-verify with report_timing -exceptions all that it is dominant on exactly that path.
Complete Technical Explanation
Treat it as an investigation rather than a fix. Start by confirming the logical relationship: all_fanout -from <launch> -to <capture> verifies that the path exists the way you believe it does. Then inspect what constrains it today with report_timing -from <launch> -to <capture> -exceptions all - is some exception already dominant, or is the path genuinely unconstrained beyond the default single-cycle check? Next comes the step people skip: confirm the hardware intent with the designer. How many cycles does the enable actually allow? Never invent a multicycle number to make timing pass. With that number in hand, apply set_multicycle_path -setup N together with the matching -hold of N-1, or whatever hold value the real enable behaviour dictates. Re-run report_timing -exceptions all and confirm two things: the multicycle exception is now dominant on exactly this path, and nothing unintended was swept in by your object specification. Check the hold side explicitly - avoiding a bogus hold requirement is the entire purpose of the -hold option. Finally, diff the constraint against the golden SDC and document the rationale. The discipline behind every step is that a multicycle path is a design fact, verified with the designer, not a slack-closing trick, and an interviewer is watching to see which of those two you believe.
In Pd / Signoff
This is the standard route for any exception added during timing closure. The artefacts you leave behind matter as much as the constraint itself: the designer's confirmation of the cycle count, the before-and-after report_timing -exceptions all output, and the SDC diff. Reviewers approve the exception on that evidence, not on the improved slack number.
Common Trap
Applying -setup N because the slack happens to fit in N cycles, skipping both the designer confirmation and the hold check. You get a green setup report, an invented hold requirement that gets buffered away, and a functional failure in silicon if the enable never actually allowed N cycles.
Expect Next
What exactly would you ask the designer to establish the cycle count, and which clock's cycles are you counting?
Topic And Primetime Commands
Timing Exceptions / Multicycle Paths. report_timing, all_fanout, set_multicycle_pathKeep building interview depth
Continue practising STA
Continue learning free
Get a practical low-power chapter
Receive the existing “Low Power and Multivoltage Fundamentals” PDF chapter and its download link by email.
Continue practising