What exactly counts as a "boundary path" for CCD, and what's the strongest way to protect them from useful-skew changes?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
Boundary paths are paths connected to boundary registers -- the transitive fanout of input ports or fanin of output ports. ccd.optimize_boundary_timing (false) excludes them from CCD entirely; ccd.optimize_boundary_timing_upstream (false) goes further and additionally prevents the tool from changing the clock-tree fanin cone of boundary registers, a heavier restriction on CCD's scope near I/O.
Technical Explanation
- Boundary paths are paths connected to boundary registers -- specifically the transitive fanout of input ports or the fanin of output ports.
- ccd.optimize_boundary_timing = false excludes boundary paths from CCD entirely -- useful skew won't be applied to registers near the chip's I/O boundary.
- ccd.optimize_boundary_timing_upstream = false goes further: it additionally prevents the tool from changing the clock-tree fanin cone feeding boundary registers, a heavier restriction than just excluding the boundary paths themselves.
- I/O clock latency is adjusted by default during clock_opt and compute_clock_latency -- to disable that specifically for the whole block, use either of the above options; for specific I/O paths, use ccd.skip_path_groups instead; for specific I/O clocks, use set_latency_adjustment_options -exclude_clocks.
Formula Or Decision Rule
Least restrictive to most: default (CCD optimizes boundary paths normally) -> optimize_boundary_timing=false (excludes boundary paths) -> optimize_boundary_timing_upstream=false (also protects the clock-tree fanin cone feeding boundary registers).
What To Check
- Warning sign: boundary registers near I/O show unexpected clock latency changes after a CCD run that was supposed to be scoped away from them.
- Inspect: check which of the boundary-protection options (optimize_boundary_timing vs. optimize_boundary_timing_upstream) was actually set, since they protect different scopes.
- Correct: use optimize_boundary_timing_upstream=false specifically if the fanin cone itself (not just the boundary path) needs protecting.
Command Checks & Actions
set_app_options -name ccd.optimize_boundary_timing -value falseExcludes boundary paths from CCD.
set_app_options -name ccd.optimize_boundary_timing_upstream -value falseAlso protects the clock-tree fanin cone feeding boundary registers.
set_latency_adjustment_options -exclude_clocks {clkX}Excludes specific I/O clocks from latency adjustment instead of a blanket boundary exclusion.
Healthy, Suspicious & Hard-stop Results
- Expected: boundary register clock latency stays stable across CCD runs when the appropriate boundary-protection option is set.
- Investigate: boundary path exclusion is set, but the fanin cone feeding those registers still changed -- check whether optimize_boundary_timing_upstream was also needed, not just optimize_boundary_timing.
- Stop: I/O timing intent depends on stable boundary-register clock latency, but no boundary-protection option was set at all before running CCD.
Common Mistake
The Trap: Setting ccd.optimize_boundary_timing=false and assuming boundary registers are now fully protected, when the clock-tree fanin cone feeding them can still change unless optimize_boundary_timing_upstream is also set.
What The Interviewer Is Testing
Whether you know boundary-path protection has two distinct levels (the path itself, versus the upstream fanin cone) rather than one on/off switch.
Practical Example
Debug Scenario: A design's I/O timing contract requires stable clock latency at boundary registers. ccd.optimize_boundary_timing was set false, but a later timing diff still shows latency changes -- tracing it back, CCD was still adjusting the clock-tree fanin cone feeding those registers, which only optimize_boundary_timing_upstream=false would have prevented.
Physical 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