A team proposes leaving clocks ideal (skipping propagated timing) post-CTS to save runtime near a deadline. How do you respond?

Short Answer

Refuse it. An ideal clock uses estimated or zero network latency, not the real skew of the clock tree that clock tree synthesis (CTS) just built, so it silently mis-times every path in the domain - hold checks worst of all, since hold is dominated by skew. Solve runtime with parallelism and prioritization instead, not by falsifying the clock model.

Technical Explanation

• Name the risk first. An ideal clock uses estimated or zero network latency plus an estimated-uncertainty placeholder, not the real skew of the clock tree that exists post-CTS. That real skew can be significant, and ideal analysis simply cannot see it - a path that genuinely fails because of real skew shows no violation at all.
• A missed violation is a silicon escape. At signoff, a violation the tool never saw is a violation that reaches fabrication, not a violation that gets fixed.
• Hold pays the highest price. Hold checks are dominated by the skew between the launch and capture clock edges. A small amount of real skew can create - or cure - a hold failure, and hold failures are frequently catastrophic and unfixable once the chip is fabricated.
• Ideal is not a cheaper flavor of accurate. The entire reason to propagate clocks after CTS is that the real tree's latency and skew materially change the timing outcome. Skipping propagation makes the signoff a statement about a design that was never actually built.
• Runtime is not the real trade being offered. The hours saved buy a signoff that means nothing, which is a worse outcome than spending the hours.
• The actual fix for runtime pressure. Attack the runtime directly: threaded multicore analysis via set_host_options -max_cores (PT), adequate memory and core allocation, high-capacity mode when memory-bound, distributed multi-scenario analysis (DMSA) for many scenarios in parallel, and removing redundant update_timing (PT) calls and wasteful reporting from the script.
• If the full signoff genuinely cannot finish in time. Prioritize the highest-risk corners, modes and blocks rather than degrading accuracy everywhere at once. Never falsify the clock model just to make the deadline look met.

Follow-up Question & Model Response

If a team insists runtime is the real emergency, what's a legitimate way to cut signoff time without touching the clock model at all?

Candidate Model Response: Start with set_host_options -max_cores to parallelize the analysis across available cores, since a large design's timing update is one of the most parallelizable parts of the flow. Check whether the run is memory-bound rather than compute-bound and switch to high-capacity mode if so, since a memory-starved run can be far slower than the core count suggests. Use distributed multi-scenario analysis so multiple MCMM scenarios run concurrently instead of sequentially. Finally, audit the script itself for redundant update_timing calls or reporting commands that force unnecessary re-analysis - these are frequently the actual source of wasted runtime, not the clock propagation step being proposed for removal.