Collaborating using Simics Recording Checkpoints

By Jakob Engblom

One of the main themes of the Simics 4.8 release is the use of Simics to collaborate between team members, teams, and organizations. To facilitate this, Simics checkpoints have been extended with significant new metadata capabilities as well as the ability to record a simulation session and communicate the recording as part of a checkpoint. Checkpointing can really transform how developers and testers and users communicate issues in their systems, and the new checkpointing features and metadata makes the mechanism even more powerful. We have a video up on YouTube demonstrating this Simics feature.

The checkpoint comments and metadata introduced in Simics 4.6 are still there, but they have now been extended with additional information in form of execution history and user-provided timed comments. As shown below, traditional Simics checkpoints (and all other snapshot technologies) capture the state of the system at a single point in time. With the introduction of reverse execution, users have asked for a way to save the reverse execution history in a checkpoint so that a colleague could reverse and see just what they saw. With the new recording checkpoints, that has finally been realized. This greatly helps realizing efficient bug transportation workflows.

Another thing that was added are user-provided comments on the execution of a system (the little speech bubbles in the picture above). These are text strings tied to a certain point in time, and shown in the timeline view. They can be added by a user manually from the GUI, from the command-line, or automatically from scripts and custom modules. They are saved in checkpoints and can give the recipient of a checkpoint a good idea on how the system they are investigating arrived at the state that it is in. A simple example from the network debug demo I have blogged about before looks like the picture below. When used along with reverse execution, you can click on the comments to jump to that point in time (provided they are within the bounds of the reverse execution session, of course):

To actually implement checkpoints containing an interval of time, we rely on Simics determinism. We do not save the state at every point cycle in the time interval (which would obviously be far too expensive). Instead, we save a traditional Simics checkpoint at the start of the time interval, and then record all inputs to the simulation and save those too. If you peek inside, the checkpoint actually contains a traditional Simics checkpoint and the recording in a single package, like this:

Saving a time interval rather than just a point of time in a checkpoint does enable a user to apply reverse execution to the execution experienced and recorded by another user, but it requires that the recipient of the checkpoint runs through the recording once. The picture below explains how this works.

When the recipient of the checkpoint opens the checkpoint, time is at the start of the recorded time interval. Reverse execution is then turned on, and the recording in the checkpoint is replayed. As it is replayed, the reverse execution state is constructed. Once the replay has finished, the checkpoint recipient is able to reverse back and forth within the time interval saved in the checkpoint.

This method is many times more efficient than trying to save the quite complex internal representation of a Simics reverse execution history, and is useful in a wider variety of cases. For example, it means that we can pass recordings along just to show things, without necessarily going into reverse execution or debugging at the end of the recording.

Wind River Blog Network

The Wind River Blog Network is made up of a variety of voices: executives, technologists and industry enthusiasts. We hope to foster conversations and encourage the sharing of insights regarding the evolving landscape of intelligent, connected systems with our ecosystem of customers, partners and colleagues.