Prove that MIS, done wrong (full factor with no window check), can be either safe-but-costly or actually wrong - and state which.
From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide
Short Answer
Applying the full multi-input switching (MIS) speed-up factor unconditionally, with the arrival-window overlap check disabled, is the optimistic extreme for hold — MIS shortens min delay, so removing the check that limits when the speed-up applies can make data arrive earlier than the model shows and hide a real hold violation. It trades accuracy for runtime, and the accuracy it gives up is on the unsafe side.
Technical Explanation
The key is remembering which delay MIS moves and which direction is dangerous for that check, then tracing what the window filter actually controls.
- What MIS is scoped to. MIS analysis applies a library-characterized speed-up factor to a gate's delay when several inputs can switch together, scoped to minimum-delay, meaning hold, checking only.
- What the arrival-window filter does by default. With
si_enable_multi_input_switching_timing_window_filter(PT) at its default true, the tool checks whether the other inputs' arrival windows overlap the input being analyzed before applying the full speed-up factor — no overlap means a smaller factor, or none, giving a larger and safer min delay. - What disabling the filter does. Setting
si_enable_multi_input_switching_timing_window_filter false(PT) applies the full speed-up factor unconditionally whenever multiple inputs can switch in the same cycle, regardless of whether their windows actually overlap — the same as assuming worst-case simultaneous switching always happens. - Why that is the optimistic extreme, not the pessimistic one. For hold, a larger min delay is the safe direction. Full-factor-with-no-window-check produces the smallest possible min delay of any MIS configuration, the least safe outcome, even though disabling a check sounds conservative.
- Why the guide's own framing can be misread. Describing this as reducing accuracy to save runtime is true, but says nothing about which direction the inaccuracy points — you have to separately reason that MIS only acts on min delay to see the risk is a masked hold violation.
- The correct posture. Disabling the window filter is a legitimate runtime trade on a design where the co-switching assumption is separately confirmed realistic, but it must be paired with hold verification that checks for exactly this optimism.
- The interview habit worth stating out loud. Always tie "pessimistic"/"optimistic" to a specific check and delay quantity — MIS only touches min delay, so any MIS accuracy question is really a hold question.
Common Mistake
The Trap: disabling si_enable_multi_input_switching_timing_window_filter (PT) purely to cut runtime on a large design, without re-running hold verification specifically on the paths where MIS-eligible cells sit.
- The runtime savings are real and immediate; the accuracy cost only shows up later, as a hold violation that silicon exhibits but the report never flagged.
- Treating this setting purely as a performance knob, rather than a modeling choice with a specific hold-side risk, is exactly how the mistake gets made — it looks like a harmless option, not a safety-relevant one.
Follow-up Question & Model Response
"If you must disable the arrival-window filter for runtime reasons, what would you add to keep the analysis safe?"
Candidate Model Response: I would add a targeted, higher-effort hold verification pass — for example path-based analysis or an independent SPICE check — specifically on the paths through MIS-eligible cells, since those are exactly the paths where the disabled filter can be optimistic. I would also document which cells qualify for MIS using report_multi_input_switching_lib_cells (PT), so the scope of the extra verification is bounded and defensible rather than a blanket re-check of the whole design.
Practical Example
A memory decoder's 4-input NAND gate qualifies for advanced-mode MIS analysis. With the arrival-window filter enabled, report_multi_input_switching_coefficient (PT) shows a partial speed-up factor of 0.91 applied, because two of the four inputs' arrival windows only partially overlap, and the hold check on that path reports +4 ps slack. Disabling si_enable_multi_input_switching_timing_window_filter (PT) to save runtime on a full-chip run applies the full 0.68 factor unconditionally, dropping the same arc's delay further and flipping the reported slack to −9 ps — revealing that the +4 ps pass under the filtered analysis was itself already close to the edge, and the full-factor result is the one worth investigating rather than dismissing as pessimistic.
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