What is CCD (Concurrent Clock and Data optimization), and what does it actually change in the clock tree?

Short Answer

CCD applies useful-skew techniques during datapath optimization -- deliberately adjusting individual registers' clock arrival times to spend positive slack on paths that need it, instead of treating every register's clock latency as fixed. It's enabled by default for place_opt and clock_opt, but must be explicitly enabled for route_opt. The adjustments are stored as offsets -- set_clock_latency -offset and set_clock_balance_point -offset -- visible via write_script but NOT captured by write_sdc, which matters if you're trying to hand off timing intent downstream.

Technical Explanation

• CCD deliberately shifts some registers' clock arrival time to borrow slack from paths with margin and give it to paths without, instead of treating every register's clock latency as fixed.
• Enabled by default for place_opt and clock_opt; must be explicitly enabled for route_opt via route_opt.flow.enable_ccd.
• Adjustments are stored as offsets [SDC: set_clock_latency -offset, set_clock_balance_point -offset], viewable via write_script -format icc2 -- but NOT captured by write_sdc, so downstream SDC handoff loses this information.
• CCD in place_opt needs the same accurate-clock-model prerequisites as trial clock trees do -- without propagated clocks from a trial tree or optimize_icgs, CCD has nothing real to work from.
• ccd.timing_effort (default medium) and ccd.hold_control_effort (default low) apply to the final_opt stage of both clock_opt and route_opt; raising hold_control_effort reduces the number of setup violations fixed, so it's a real tradeoff, not a free upgrade.
• report_ccd_timing debugs this: by default, the worst D-slack and Q-slack for the 5 most critical endpoint registers; -type stage/-type chain trace how a specific offset propagates through neighboring stages.

Healthy, Suspicious & Hard-stop Results

• Expected: report_ccd_timing shows meaningful D-slack/Q-slack improvement on the paths CCD targeted, with no new setup violations on paths that were previously clean.
• Investigate: CCD offsets exist per write_script but the written SDC doesn't reflect them -- confirm this is expected (write_sdc genuinely doesn't capture CCD offsets) before assuming something is broken.
• Stop: hold_control_effort was raised without a genuine hold-critical reason, and setup violations increased as a direct result -- that's the documented tradeoff working as intended, but it needs to be a deliberate choice, not an accident.

What The Interviewer Is Testing

Whether you know CCD's adjustments live in offsets that don't survive a write_sdc round-trip, and whether you understand the real hold-vs-setup tradeoff in the effort knobs rather than treating "higher effort" as strictly better.