A team proposes reducing the signoff corner set to save runtime near a deadline. How do you respond?
From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide
Short Answer
Support reduction only where it is provably safe — merging modes whose constraints are genuinely compatible, or distributing the existing scenario set to run in parallel — never by silently dropping a corner. Each mode-and-corner scenario represents a real operating condition; blindly removing one means whatever path is worst-case there is simply never checked, with no signoff warning that anything was skipped.
Technical Explanation
The number of signoff scenarios is the number of modes multiplied by the number of corners, and every combination exists because some path is genuinely worst-case under it. Dropping a scenario means whatever is worst-case there goes unverified, silently, with the report looking exactly as clean as if it had been checked.
- Distinguish redundant from load-bearing before touching anything. Some scenarios are dominated — always at least as good as one you are keeping — and removing those loses nothing. Others are the sole worst case for real paths and cannot go without a gap. Only analysis tells them apart, not a deadline-driven guess.
- Use the tool's own scenario-reduction feature instead of an ad hoc cut. PrimeTime's mode merging for scenario reduction determines which modes' constraints are compatible enough to merge into one superset mode, cutting the mode count — and the mode-times-corner scenario count — without dropping coverage.
- Prefer acceleration over reduction wherever possible. Distributed multi-scenario analysis (DMSA) runs the existing scenario set in parallel across compute resources, cutting wall-clock time with nothing dropped. Selective path-based analysis (PBA) on only the violating paths, instead of full graph-based analysis (GBA) everywhere, is another way to buy back runtime without losing coverage.
- If a scenario genuinely must go, make it a documented, escalated decision. Name exactly which scenario is dropped and what goes unverified, signed off by whoever owns the schedule-versus-risk tradeoff — never a silent line deleted from a run script.
- The response to the team, in one sentence: run mode merging and DMSA first, since they often deliver the runtime win with zero coverage loss, and treat an actual scenario drop as a risk decision with a name and a signature, not a script edit.
Common Mistake
The Trap: treating "reduce the corner set" and "reduce runtime" as the same request, and reaching straight for scenario deletion instead of mode merging or DMSA parallelization.
- Deletion is the only one of the three options that can silently lose coverage — merging preserves it by construction, and parallelizing changes nothing about which scenarios run, only how.
- Jumping straight to deletion under deadline pressure skips the cheaper, safer options entirely, often for a smaller runtime win than mode merging alone would have delivered.
Follow-up Question & Model Response
"The team says mode merging and DMSA were already tried and the deadline still can't be met without dropping something. What do you do?"
Candidate Model Response: At that point I would ask for the specific list of scenarios being considered for removal and, for each one, which paths are uniquely worst-case there — using existing signoff history or a quick per-scenario worst-slack comparison to identify genuinely dominated scenarios first. Any scenario that is not clearly dominated becomes an explicit, named risk item escalated to whoever owns the schedule decision, with the specific unverified condition written down, rather than an unstated gap in the next signoff report.
Practical Example
A signoff run spans 4 modes times 6 PVT corners, 24 scenarios, with two days left before tapeout. Running report_mode (PT) and applying PrimeTime's mode merging finds that a test_mode and a scan_mode share compatible constraints and merge into one superset mode, cutting the scenario count to 18 with no coverage loss. Distributing the remaining 18 across available compute hosts under DMSA brings wall-clock time within the deadline. The team still wants one more corner dropped for margin; the SSG 0.72 V 125 °C setup corner is checked against per-scenario worst-slack history and found to be the sole worst case for 40 paths in the memory interface, so it is kept, and the schedule risk is escalated instead of the corner being silently removed.
Complete STA Handbook
Master Signoff-Ready Static Timing Analysis
Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.
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