Why is scan-shift hold time fixing intentionally deferred during placement optimization?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
Scan flip-flops sit in long shift chains connected through dedicated scan-in/scan-out pins, and during scan-shift mode the clock runs much slower than functional speed — hold time between adjacent scan flops in that mode depends purely on local clock skew. The catch: during placement, clocks are still modeled as ideal (zero latency, zero skew, per the earlier "why clocks must remain ideal" question) — so under that ideal model, literally every back-to-back scan flop pair looks like a hold violation, even though none of them actually are.
Technical Explanation
- Scan flip-flops sit in long shift chains connected through dedicated scan-in/scan-out pins, and during scan-shift mode the clock runs much slower than functional speed — hold time between adjacent scan flops in that mode depends purely on local clock skew.
- The catch: during placement, clocks are still modeled as ideal (zero latency, zero skew, per the earlier "why clocks must remain ideal" question) — so under that ideal model, literally every back-to-back scan flop pair looks like a hold violation, even though none of them actually are.
- If the placer tried to fix scan hold under this ideal-clock assumption, it would insert a hold-delay buffer between essentially every pair of scan flops across the whole chip — thousands of buffers solving zero real problems.
- The correct methodology is sequencing: disable hold fixing on scan-shift scenarios during
place_opt, let scan chains get re-stitched via ScanDEF as placement settles, build the real clock tree in CTS, and only then fix any remaining genuine scan-hold violations post-CTS with short routing detours or dedicated delay cells. - This is a direct, concrete instance of the same principle the ideal-clock question establishes in the abstract — deferring optimization until the thing being optimized against (a real clock tree) actually exists.
Common Mistake
The Trap: Enabling hold optimization across all scenarios including scan shift during place_opt. The design area expands by 15% purely from fake scan-shift hold buffers.
Follow-up Question & Model Response
"When should scan hold timing be analyzed and fixed?"
Candidate Model Response: Scan hold should be analyzed post-CTS once real clock skew is known. Most scan hold violations disappear naturally due to clock tree insertion delay balancing.
Practical Example
Disabling Pre-CTS Scan Hold Fixing:
# Synopsys ICC2: Disable hold optimization on test mode scenarios during place_opt
set_scenario_options -scenarios [get_scenarios *scan*] -hold false
# Enable setup optimization only
set_scenario_options -scenarios [get_scenarios *scan*] -setup truePhysical 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.
Continue practising