execute interface is implemented by objects that
drive a simulation, which is often processor models. The object
does not have to implement cycle or
step.
An object implementing the execute interface must be
coupled with one object implementing the cycle
interface. It can be the same object that implements the
cycle interface.
The run function is called when the simulator starts or restarts the execution.
By default the Simics scheduler will assume that the object being called in
with the execute interface also implements the corresponding
processor_info and step interfaces.
If this assumption is incorrect, the implementation of the run
function is responsible for maintaining the simulators view of the current
objects implementing the processor_info and
step interfaces. It does that by using the appropriate
functions in the cell_inspection interface. The current
objects must always be correctly set when either the run function
returns, when any API method is called, or when any other object is called
through an interface. Several Simics features, such as CLI commands, device
logging, and hap handling make use of the current objects.
To handle asynchronous events, and thus allow for reasonable interactive
performance, the implementor of execute needs to either make
sure that run returns after not having run for too long, or
preferably regularly call the VT_check_async_events method. In
the Simics library CPU models, VT_check_async_events is called
after servicing events from the cycle or step
interfaces.
The simulator core will call stop when it detects a condition that should interrupt the simulation. The callee should stop as soon as possible when in a stable state, typically when the current executing instruction is finished after getting a request to stop. In some cases the callee might receive multiple stop requests in a rapid sequence. Conditions leading to a stop request include SIM_break_simulation being called from a device or hap-handler, breakpoint triggered, low-memory situations, the user interrupting the simulation with Ctrl-C, and the Simics core halting the object when it is at the end of the allowed time window in temporal decoupled simulation. It is forbidden to do anything in the stop function that can lead to a new stop request, this includes posting events, printing SIM_log-messages, etc. Before returning from the run method, the VT_stop_event_processing function should be called. The requirement to call VT_stop_event_processing is likely to be lifted in future versions of Simics.
The switch_in function is called whenever the execute object is about to gain control of the simulation from some other execute object in the cell. Similarly, switch_out is invoked before control is relinquished. It should be noted that these functions are called in a deterministic manner which is not true for run.
The switch_in and switch_out functions are not called at simulation start (or checkpoint load), in general.
SIM_INTERFACE(execute) {
void (*run)(conf_object_t *obj);
void (*stop)(conf_object_t *obj);
void (*switch_in)(conf_object_t *obj);
void (*switch_out)(conf_object_t *obj);
};
#define EXECUTE_INTERFACE "execute"