Checkpointing Capability

Checkpointing correspond to ability to save and reload the whole simulator state, to be able restart the simulation from this specific point.
This capability is currently implemented for single-core simulators only. We plan to extend it to multi-core simulators.

Considering the speed of simulation especially at cycle-level, only part of the full trace is usually simulated, as explained in the Sampling page.

Even if simulating a single part of the whole simulation trace, the researcher will want to skip the first instructions of the program which are not representative of the whole program behavior.
To do so you can fastforward you simulator relying only on an instruction set simulator for this first subset of instructions, and then start your cycle-level simulation.

Trying various hardware parameters in your simulator for the same benchmark will lead you to a try-error process running many such simulations. There is no point in running this fastforward multiple times, as the result is exactly the same for each run.
Checkpointing after the first fastforwarding will allow other simulations to reload such a checkpoint without performing the emulation.

For more complex sampling techniques, you will generate a checkpoint corresponfing of the starting simulation point of each sample, and you will therefore be able to jump from a sample to another without performing any instruction set simulation.

Even at trasaction-level you may benefits from checkpointing: Running a Full System simulation usually imply:

1. Booting the target operating system
2. Running the benchmark from within the operating system

The part corresponding to booting the OS will usually be the same and provide the same results for every benchmark you try.
So it will be relevant to checkpoint the simulator after it booted the OS, and then to reload this checkpoint for every benchmark you want to test, just changing the device corresponding to the mount point where your benchmark is.

Checkpointing is fine as long as the only modifications between to different runs only concern hardware parameters.

However if you perform some modification on the software (the simulated program) between each run, you will have to regenerate the checkpoints for every run, losing the benefits from checkpointing.

The point is that in the embedded domain, hardware and software are usually designed at the same time, making checkpointing techniques more restrictive for speeding up simulation.

Checkpointing techniques however may have other applications:

• Building regular checkpoint while simulating will slow down the simulation, but will allow to backtrack the simulation, effectively simulating backward when detecting a bug.
• Checkpointing may also be used in a context of distributing many simulation experiments on a cluster of simulation host. This will allow to migrate simulations transparently.

We implemented a checkpointing corresponding to the state of the instruction set simulator, for it to be reloaded by either the instruction set simulator or the cycle-level simulator.

The information needed to be saved in a checkpoint are:

• processor information: All the register values
• memory information: The whole memory content
• system information: Information about opened input/output files (for each file: opening mode, file permissions, cursor position in the file)

The figure below illustrate the required interfaces:

While loading a checkpoint, a simulator should set the values corresponding to what was saved in the checkpoint:

• The register values should be written in the CPU module
• The memory data should be written in the main memory module
• The system information should be restored (re-opening input and output files, restoring file cursor values, ...)

The figure below illustrates the required interfaces, the checkpoint apprearing in brown.