2.2.3.  Execution Stages

A central means by which the OMI works are callbacks, registered and removed by the model manager. With the number and kind of callbacks it registers, the model manager can choose the granularity of interaction with the application. Basically a callback is kind of a function pointer in the C programming language, allowing a dynamic linkage of simulator and model manager.

The omiCallbackDescriptionT structure is used during registration to characterize exactly how the callback should be executed. This includes a callback reason – an indication of the circumstances under which a callback is to occur. The registration routine is omiRegisterCallback, it may be invoked in the bootstrap and elaboration stage. On execution of a callback an omiCallbackInfoT structure keeps recipient information for both, the caller and the callee, such as the current simulation time, caller-specific data, callee private data and additional state information.

Figure  2.15 on page 104 shows the different execution stages with the most important callbacks. Of course these are only the main callbacks, whereas the standard defines much more functions for different purposes.

An important concept of directing the simulation are the control requests, which are used by a model manager to directly affect the flow of execution. A control request is not an implicit command, but – as the name suggests – a request for an action. An application may decline or accept a request. The request for termination is the only one that cannot be declined and does not return control to the model manager routine. A normal control request can e. g. be a request to revert to a previous state or to suspend the manager, to save its state or load it. Requests are executed either immediately or at the end of the simulation cycle, whatever is reasonable for the particular request. It is significant that during the omiControlRequest routine the application does not call any model manager callbacks. Therefore, from the model manager’s perspective, the application returns immediately, signaling acceptance. In the next steps the model manager returns control to the application, which then executes the requested operation and finally resumes execution at the appropriate point.

Another essential technique is the system exceptions, which include errors like segmentation violation, bus errors and process signals like break or end. All these exceptions are to be handled by the application. Although a model manager may install its own exception handler, the application’s handler shall be restored before returning the execution control. Of course a model manager should only catch exceptions that it can handle completely.

The model manager can aid in increasing the usability of the models under its control by providing special capabilities, like state viewing and -manipulation. These capabilities are accessed through so-called model manager commands using a function of type omiCommandRoutineT. The actual command is issued through a string argument to this routine. Using the command facility it is possible to add dynamic operations that are not part of the set of OMI routines. The model manager is responsible for interpreting the arguments and performing the appropriate actions. Model manager commands are either called by the application or by the end user through an interface provided by the application.

Now in the following sections not the mentioned generic techniques will be discussed but the execution stages in detail.

2.2.3.1 Bootstrap Stage

The first execution stage takes place at startup time, where the application goes through a particular initialization protocol with each of the model manager it is using. The initialization protocol clarifies the OMI version for the interaction, the addresses of the callback routines and several session-specific options. In order to detect version clashes the bootstrap process is split up into two steps, realized with two routines called by the application.

• The first routine to be called is the model manager’s omiBootstrap function, which initiates the communication. The application gets knowledge of the range of OMI revisions the model manager supports. Referring to this range the application selects a specific OMI version for the session. Additionally the function returns a pointer to the second routine, which should only be called if no version clashes occur and the pointer is valid.
• The second routine – only to be called if the first one successes – is the omiBeginSession function. Goal of this routine is to exchange all basic characteristics of the session. This includes the OMI revision as well as the nature of the OMI session and the reference simulation style. The model boundary type supported by the application is given, so is the time value precision and the timing mode. As functional information besides the names of application and model manager all callback pointers of both sides are exchanged.

2.2.3.2 Elaboration Stage

In the elaboration stage the application tells the model manager(s) to instantiate the models, including their tailoring to specific needs and binding their ports to the environment. For this the application goes through the following protocol for each model. Interleaving calls are not allowed.

• A call of omiCreateInstance triggers the actual model instantiation. For each model this routine is called once, creating a unique instance.
• With the omiSetParameter function the model instances are tailored. Parameters not set explicitly with function calls are set to default values by the model manager.
• After passing all parameters to the instance the application elaborates it by calling omiElaborateInstance, forcing the parameters to take effect. Here the data objects like ports, viewports and parameters are created.
• As the ports are now created, each one can be connected to the application environment utilizing the omiConnectPort routine. A port shall be entirely connected, which is important for non-atomic ports.
• The final function call for a model elaboration is omiEndPortConnect, signaling the end of the protocol.

The means by which objects are defined and created were explained in the above section about the information model. For all incompletely characterized types the model manager replenishes these objects with right values for the missing values, like bounds for unconstrained arrays or storage sizes. The information for these replenishments is supplied by the application. Certain restrictions are imposed on the model boundaries. A parameter definition shall not be parameterized type, so not depend on other parameter values. A port definition may not have an unconstrained array type, as the size of a port array then would be undefined and so impossible to use. The same restriction applies to viewport definitions.

2.2.3.3 Initialization Stage

After the pure elaboration stage the stateful OMI objects, like ports, viewports, nets or drivers, have no initial values yet and can yield erroneous values when accessing them. Therefore the initialization stage assigns values first to the drivers associated with OMI output or bi-directional ports, then to output or bi-directional nets and finally to ports and viewports. The order of these three sub-stages does matter, since the port initialization may require nets to have valid values. The stage is triggered by the application calling the omiDriverInitialization routine. The model manager then invokes omiInitializeDriver for each driver. A model manager may register an omiNetInitialization callback in order to obtain the initial value of a net as soon as it becomes available.

2.2.3.4 Simulation Stage

Here the actual simulation takes place by executing a series of simulation cycles. The simulator and the models manager interact through the execution of callbacks registered by the model manager. The callbacks lead to multiple port changes by retrieving values from the simulator.

The OMI standard describes the simulation stage in detail in [IEE99], chapter 6.

A system of processes builds the OMI simulation. An OMI process is a black box that represents an independent thread of execution during simulation. The content of a process is not specified in detail in the standard for interoperability reasons.

Network propagation means, that the process recomputes the OMI network in order to reflect changes in nets or their drivers. Pending updates are executed and removed from the queues. In a given simulation cycle, network propagation takes place only once. The propagation can be regarded as a transaction, thus implying to be an atomic step: no update is visible prior to the network propagation step, and any change to OMI ports can take effect after the propagation. This technique ensures that the set of OMI processes is always consistent.

The set of OMI processes can be divided into three basic types, differing by the times they are executed:

New-time-step processes.

These processes execute at the beginning of a time step, prior to network propagation in the first simulation cycle.

Post-propagation processes.

As the name implies, these processes execute each cycle after the network propagation has taken place.

End-time-step processes.

At the end of a time step, just before simulation time is advanced, this kind of process is executed. Here, no data in the current cycle should be affected.

The differences between event-driven simulation style and cycle-base simulation style can be seen best by showing the two flow charts Figure  2.16 on page 110 and Figure  2.17 on page 113.

The time period that covers all of the activity that occurs between consecutive updates to the current simulation time is called simulation time step. It may contain more than one simulation cycle, due to the possibility of scheduling zero-delay updates.

Cycle-based simulation does not know the concept of time steps, there is only one process left of the three kinds: the post-propagation process. In this kind of simulation style, it is not feasible to have transparent data paths, which means that a change in the input port’s value directly – within the same cycle – affects the output port’s value. This is forbidden because cycle-based simulation, by concept, computes the next state, including output values, from the current one plus input values. This concept does not work if the output can change within a particular state, this would lead to another state before having calculated the next transition.

OMI defines some callbacks, used to implement simulation cycles:

omiSimulationStep.

This callback is executed when simulation time reaches a specified activation point.

omiCycleSensitivity, omiNetSensitivity.

These two functions react on changes on the values of nets. They are called zero or once in a given simulation cycle, even if more than one change has occurred. omiCycleSensitivity is responsible for scheduling activity with unit delay and omiNetSensitivity cares on changes on one or more nets.

omiNetUpdate.

This function callback determines which nets are changing and simultaneously obtains their new values. It does not present a stable view of the OMI network, because it may be invoked during network propagation when transaction is in progress.

The OMI standard additionally includes a concept that allows reverting to a previous state. This does not only mean that it is possible to reset the session to its beginning state, but also to return the session to a previously saved simulation state. This of course requires that the model manager and all attached models support state saving and loading, a serialization concept has to be implemented in all parts. The according callbacks for the reversion functionality are omiReset, omiBeginSimulation, omiSave and omiRestore; all do what their name indicates. Additionally there are two functions for saving and restoring opaque references, usually implemented as pointers: omiSaveReference and omiRestoreReference.

2.2.3.5 Termination Stage

The final stage’s task is to gently shut down an OMI session. Termination is initiated due to one of three reasons. There may be an explicit request, which can mean, the session is ended by user action. The second possibility is the occurrence of a fatal error within execution and the last one is the equivalence to natural death – the normal completion of the simulation due to absence of any further scheduled activity.

Termination callbacks of the model manager shall be called by the application to release resources like files or sockets. After the execution of the termination callbacks no further communication between the application and the model manager can take place, as handles and data structures are invalid.

The application may also receive a control request for termination for a particular model manager. There are two possibilities of reacting to such a request: either it terminates the entire session or only terminates the session for the particular model manager and continues simulation with the remaining ones. With both choices the simulator terminates the particular model manager and ceases communication with it.