Simulator Abstraction

The way in which executable models are used and model limitations cause artifacts related to simulation creep their way into the behavioral description of a design. To retain a clear specification, the hardware model specification shouldn't be muddled with simulation related details. The modeling system should provide an abstraction mechanism to abstract away these artifacts so that they can be understood in terms of the hardware modeled, while simulator implementation details are handled automatically or in a separate part of the specification.

For example, code to compute the branch misprediction rate should not be intertwined with the code that models the hardware. On the other hand, hooks that allow other code to run when a branch is resolved and a prediction made is OK since these events (prediction and resolution) can be understood exclusively in terms of the hardware.

As an added benefit, simulator abstractions can make building the models easier and thus reduce model construction time. This occurs because providing a simple mechanism to separate simulator concerns from the component specification makes it more likely that the component will be reusable across models where simulator usage patterns differ from the usage pattern in which the component was originally developed.

Data Collection Abstractions

In a concurrent structural system, there may not be a single component that has enough information to produce a statistic (e.g. computing the branch mispredict rate involves the commit logic and prediction logic). Furthermore, the same model may be used to collect different data at different times. (e.g. one data set is required during debugging of a design and another during performance evaluation.)

To abstract data collection from the modeling process, the system should allow a separate data collection mechanism to observe the dynamic events in the simulator and compute statistics based on these events. Furthermore since data collection often effects many parts of the system some type of aspect-oriented mechanism to specify the collection behavior for each event is highly desirable.

A summary of this abstraction in LSE and other systems can be found here.

Abstractions for other artifacts

Abstractions for other simulation artifacts or common simulator mechanisms are also desirable. Some particularly important mechanisms are checkpointing and, for microprocessor modeling, fast-forwarding of execution.

Checkpointing is a mechanism by which the state of an executing model can be dumped to permanent storage so that simulation can be restarted where it last left off, at the checkpoint. This is useful because simulations are slow and have very long run times. Checkpointing allows recovery of the simulation after system crash or a warm start of the model for experiment and debugging runs.

Fast forwarding is a mechanism used in processor simulators to use an ISA emulator that does not model the microarchitecture to determine program state at some point in a programs execution. At this point, the ISA emulator's ISA state is loaded into the hardware model and microarchitecture simulation is started for a certain length of time or until another point in program execution is reached. Fast-forwarding is used to quickly move past uninteresting portions of simulation and spend time only modeling program behavior that is interesting for the study at hand. This is necessary since most interesting programs cannot be simulated in their entirety in a reasonable amount of time (i.e. hours or days, instead of months, years, or millennia).

Work on the exact mechanisms for these abstractions in a structural simulation system is in progress.

Synergies and Interactions

The type of abstractions needed in a structural simulation environment is strongly motivated by the fact that the system is concurrent, and thus data availability is not known at any given position in the code of any component

The inclusion of Component Polymorphism and Component Communication Customization (CCC) also make it difficult to pin down exactly when enough data for a statistic is available, thus motivating a data collection interface that is built in terms of events related to the system being modeled and thus abstracted from the actual component code.

These same features (concurrency, polymorphism, CCC) also make it difficult (though not impossible) to bypass control of the machine model and update state for the model in some irregular fashion (for checkpoint recovery and fast-forwarding for example). Thus research into model abstractions that will support simulator features such as fast-forwarding in the presence of highly reusable components is necessary.

Without the simulator abstractions, the amount of true reuse afforded by concurrency is not as great as with. In the absence of concurrency, these abstractions are less important or could be constructed using well understood programming interfaces. Thus, the combination of concurrency and simulator abstractions gives rise to functionality beyond the mere sum of the functionality offered by each item alone.