How does set_host_options -max_cores speed up timing updates on a large design?
From PDVerse STA Mentor Guide · pdVerse Mentor Guide
Short Answer
A single-core PrimeTime run processes the design's timing update one operation at a time, which becomes the bottleneck on a design with millions of instances and many scenarios. set_host_options -max_cores N (PT) lets PrimeTime split timing updates and parasitic reads across N cores on the same machine, so the same update finishes in a fraction of the time.
Technical Explanation
set_host_options -max_cores 32(PT) tells PrimeTime the maximum number of cores it may use for operations that support multicore processing, such asupdate_timing(PT) and parasitic data reading.- Multicore analysis inside a single PrimeTime process is different from distributed multi-scenario analysis, which splits separate scenarios across separate machines rather than splitting one scenario's work across cores.
- Setting
-max_cores 1(PT) explicitly disables multicore behavior and forces single-core analysis, sometimes used for debugging or to match an older, single-threaded run bit-for-bit. - Parallel parasitic data reading, part of what multicore analysis speeds up, can also be disabled separately through
set_host_options(PT) if a specific SPEF format is causing an issue under parallel reads. - The speed-up from more cores is not unlimited, beyond some point the design's own structure, how much of the timing graph can actually be split into independent chunks, limits how much extra cores help.
- Because this setting affects parallel operations, it is typically set once early in a script, alongside other host-options settings, rather than adjusted mid-session.
Common Mistake
The Trap: Assuming that requesting a larger -max_cores value always produces a proportionally faster run.
- On a design where much of the timing graph cannot be split independently, or on a machine with fewer physical cores than requested, the extra cores add little or no speed and just reserve resources that could have gone to another job.
Follow-up Question & Model Response
How is multicore analysis with set_host_options -max_cores different from running multiple MCMM scenarios in parallel?
Candidate Model Response: Multicore analysis under -max_cores (PT) speeds up the work inside one single scenario, splitting operations like update_timing (PT) across cores on one machine so that one scenario's timing finishes faster. Distributed multi-scenario analysis instead runs entirely separate scenarios, each a different mode-corner combination, on separate machines at the same time, so the whole signoff matrix finishes sooner even though each individual scenario's own speed is unchanged. A real signoff flow typically uses both together, multiple scenarios distributed across machines, with each scenario itself using several cores for its own internal work. Confusing the two means assuming one setting solves a problem the other was actually built for.
Practical Example
On a 40-million-instance SoC, a single-core update_timing -full (PT) run takes roughly ninety minutes. Adding set_host_options -max_cores 16 (PT) before that same update brings it down to about eighteen minutes on a sixteen-core signoff server, freeing the rest of the overnight run for the sixty remaining MCMM scenarios.
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.
Continue practising