Get email delivery of the Cadence blog featured here
The concept of Save and Restore is simple: instead of re-initializing your simulation every time you want to run a test, only initialize it once. Then you can save the simulation as a “snapshot” and re-run it from that point to avoid hours of initialization times. It used to be inconvenient. Using this feature in simulators could have massive productivity gains, but not all users made the most of it due to a couple of hassles regarding the way snapshots saved states. The result is billions of wasted compute cycles on simulation farms worldwide.
Under Incisive, there was no procedural way from within your HDL code to execute a save—you had to do the save from tcl at a “clean” point in the simulation. This created awkward situations where you couldn’t use Save and Restore exactly when you wanted, but only at certain times in between delta cycles, and you had to write some roundabout code that was generally hard to read and often created more issues down the road than it solved. Beyond that, if you were using C/C++ code that you wrote yourself, you had to manage all state data used by that code on your own as well. PLI, VPI, and VHPI have mechanisms to deal saving data, but it is a significant effort that many C/C++ applications ignore.
Xcelium Simulator brings an improved approach to the Save and Restore feature by not taking a “snapshot” of the system, but instead saving the entire memory image. The main goal of Xcelium’s new Save and Restore feature is to get the Save and Restore methodology to a point where “it just works.” There won’t be any manual fiddling required accurately save and restore the model. You will be able to save, and restart, with a few commands and no hassle.
As it stands, Xcelium’s Save and Restore functions greatly improve the overall usability of saving and restoring over Incisive. Under old mechanism, if a test opened a file while it ran, the file handle / pointer would not be saved. Xcelium’s improvements save all file pointers in the image so that this is no longer an issue – open files are restored to their save state so a restart resumes at the same point. The new Save and Restore also fixes saved-memory issues with custom-built C code, so you will no longer have to manually handle state information stored in memory when saving—it will be saved for you, automatically.
Over time, the new Save and Restore feature will be updated to do even more out-of-the-box. The saved file islarger than the snapshot, but saving a memory image streamlines and eases the Save and Restore feature usage significantly. The file size is mitigated somewhat with the -zlib option, a compression tool integrated into Xcelium Simulator that automatically compresses the image—in the future, this compression will be improved, creating a yet smaller saved image. Save and Restore functionality for sockets and for thread-handling in multi-threaded applications are on the table for a future update as well.
Right now, not everyone is using Save and Restore. Those not using it are wasting energy and time in their simulation farms. With Incisive, they were saddled with manually saving all of the external data used in their tests, coupled with the inconvenient and awkward saving restrictions—meaning that those engineers were stuck with the wasted compute cycles. The new Save and Restore upgrades in the Xcelium Simulator fix those major issues, which means that there are no more excuses to avoid this time saving technology. Whether you are setting up a regression environment, doing test development, or creating relatively smaller block-level tests, or simply care about saving the Earth from global warming, Save and Restore cuts your test initialization time drastically and reduces the compute resources you need, with no hassle.
If you want to take a look at the app note, check it out here.