A team proposes reducing the signoff corner set to save runtime near a deadline. How do you respond?
From PDVerse PrimeTime STA Interview Guide · pdVerse Mentor Guide
Ten-second Interview Answer
Support reduction only where corner-analysis proves the dropped corners are dominated, push acceleration instead, and refuse blind dropping - an unanalyzed corner is a silent coverage gap where a real failure escapes to silicon with no warning.
Complete Technical Explanation
Start by naming the risk. Each corner represents a real operating condition, and paths are worst-case at different ones -setup at a slow corner, hold at a fast corner, SI at a particular RC corner. Drop a corner that is worst-case for some paths and those paths are simply never verified at their worst condition, so a real violation there escapes with no signoff warning at all. That means the whole question turns on distinguishing redundant corners from load-bearing ones. Some corners are genuinely dominated, always better than a corner you are keeping, and can go safely; others are the worst case for some paths and must stay. Corner-analysis, which identifies dominance and worst-case coverage, is what tells them apart - not a deadline-driven guess. So the answer is to reduce intelligently: use corner-analysis to find the dominant set that covers all worst cases, keep those, and drop only the provably dominated ones, which cuts runtime without losing coverage. Better still, prefer acceleration over reduction - distribute the runs so scenarios execute in parallel, apply PBA selectively to violators, and use ML acceleration to cut wall-clock time with nothing dropped. And if a real coverage reduction is genuinely forced, it becomes an explicit, documented, escalated risk decision naming which corners were dropped and what is unverified, never a silent omission in a script.
In Pd / Signoff
This lands as a concrete pre-tapeout decision: run corner-analysis to rank dominance, keep the covering set, and put the rest of the runtime problem on the compute farm through distributed multi-scenario analysis with PBA restricted to GBA violators. The output is a scenario list you can defend line by line at the signoff gate.
Common Trap
Dropping the corners that historically never showed violations. Historical cleanliness is not dominance - it can just mean those paths were not critical in the previous netlist - and because the reduced run reports nothing about what it did not analyze, the gap leaves no evidence anywhere.
Expect Next
When is corner reduction provably safe versus dangerous?
Topic And Primetime Commands
STA Fundamentals / STA in the Flow. No specific PrimeTime command is required for this conceptual answer.
Keep 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