IntermediateQuestion 104 of 112Source: Synopsys PrimeTime User Guide: Saving and Restoring the Session

Why do engineers save a PrimeTime session with save_session instead of re-running the whole flow?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

Reading in a large netlist, linking libraries, applying SDC, and running the first update_timing (PT) can take a long time on a real design, and repeating all of it just to check one more report wastes that time every session. save_session (PT) writes the fully loaded and timed design state to disk, and restore_session (PT) brings it back almost immediately, so a designer can pick up exactly where the last session left off.

Timeline showing a two-hour save_session setup once, followed by three engineers each running restore_session the next morning in minutes instead of repeating the full netlist read and timing update. — Technical Reference DiagramWhy do engineers save a PrimeTime session with save_session instead of re-running the whole flow?

Technical Explanation

save_session my_session (PT) captures the design, libraries, constraints, and the timing graph after everything has been read in and updated, storing it in a named directory.
restore_session my_session (PT) loads that saved state back into a fresh PrimeTime invocation, skipping the netlist read, library link, and initial timing update entirely.
This is especially valuable for overnight or batch signoff runs, where the setup work is done once and then restored repeatedly for different reporting or debug passes afterward.
A saved session does not preserve every attribute a script applied by hand, the PrimeTime user guide notes some attributes must be reapplied after a restore rather than assuming they survived the save.
Sessions are version-specific by default, meaning a session saved by one PrimeTime release may not restore cleanly in a different release unless saved with -version compatible (PT).
Saving and restoring a session is also how a design team can hand off an identical, already-timed state to another engineer without them repeating the full setup themselves.

Common Mistake

The Trap: Assuming every custom attribute set earlier in the session, such as one applied with set_user_attribute (PT), automatically survives a save and restore.

The PrimeTime user guide is explicit that save_session does not save attributes, so any attribute-driven behavior can silently disappear after a restore unless it is reapplied in the restoring script.

Follow-up Question & Model Response

Why would a saved session fail to restore correctly on a different PrimeTime release even though nothing about the design changed?

Candidate Model Response: save_session (PT) writes an internal representation of the timing graph and design state that is tied to the exact PrimeTime version that created it, since internal data structures can change between releases. Restoring that file on a newer or older release risks a mismatch the tool cannot safely resolve, so by default a session only restores cleanly on the same version. save_session -version compatible (PT) trades some of that internal detail for a format meant to survive across releases, at the cost of a slightly larger and slower session file. Teams that archive sessions for long-term reuse, rather than same-day handoff, typically choose the compatible format for exactly this reason.

Practical Example

A signoff team runs save_session full_chip_mmmc (PT) once after a two-hour setup covering twelve scenarios, then has three different engineers each run restore_session full_chip_mmmc (PT) the next morning to debug different violating paths in parallel, none of them repeating the original two-hour setup.

Complete STA Handbook