2.2.1.  Basic OMI Concepts

A few basic terms are defined by the standard; they will be represented here.

The architecture, the OMI is founded on, defines the Open Model Interface to be the linkage between an application and one or more model managers. An application can be a debugger or simulator front-end, basically a software tool that uses a number of models.

A model in OMI context is a “tailorable, functional representation” ([IEE99, p. 3]) of a VC, not a stand-alone application but a component delivered in object code format to ensure intellectual property protection. The model may cover aspects of specification that can be simulated as well as timing information and physical characteristics. All data related to the VC can be integrated into the model. Usually a model is customized and then incorporated one or more times into a complete system, it is then called a model instance. So a model can have any number of instances associated with it.

The application using the models can be specialized to a simulator, adding the capability of simulating the behavior of a hardware or system design. The OMI models do not interact directly with the application; they are integrated into a model manager, which coordinates interactions. In Figure  2.13 on page 71 the structure is visualized. A model and its instances are associated to exactly one model manager. A model manager manages any number of models. An application uses one or more model managers. A model manager is used by only one application. The interface between application and model manager is the OMI, as mentioned before.


PIC

Figure 2.13: OMI model integration, [IEE99, p. 4]

It is essential that an application never directly calls a model routine, as the model manager may run private communication with internal services like error handling.

Models do not necessarily be delivered as single parts, they can be collected to form a model library, controlled by a common model manager, as shown in Figure  2.14 on page 74. For model usage it does not matter whether it is part of a library or not. The same way it is possible to deliver the OMI software elements as a monolithic block, e. g. a model that includes its own model manager.


PIC

Figure 2.14: Basic OMI elements, [IEE99, p. 5]

The lines between the elements in the two figures have arrows on both ends, indicating that information flows in both directions at each connection. Especially at the OMI boundary this means that the standard defines function calls across the interface go in both directions, resulting in an application part and a model manager part of OMI.

As models can be implemented using a variety of languages, the IEEE standard uses the general term modeling language for all languages that are used to develop OMI models. The compiler, which produces the object code representation from a high-level modeling language like a HDL, is called a model compiler. So for example a VHDL or Verilog design is fed into a model compiler to get object code, whereas with C code a normal C compiler is sufficient.

An OMI model package contains a so-called bootstrap file besides the dynamically loadable model manager object file. The only global symbol the object file may define is the omiBootstrapRoutineT function. The bootstrap file is needed by the application to bootstrap the model manager it is associated to, it gives information on the location-independent name of the model manager object file and the C name of the bootstrap routine for the model manager. The file contents looks like this:

MANAGER: vendorX_MODELMANAGER_1.0.so
BOOTSTRAP: vendorX_bootstrap_1_0

An OMI application can be specified using two key characteristics, presented in detail in [IEE99], section 4.3 on pages 8-9. The terms “port”, “viewport” and “parameter” are explained in detail in the subsequent section 2.2.2 on page 78.

Model boundary class.
This represents what and how many kinds of object data types the application environment supports regarding the model interface. The OMI defines four classes.
Two-state model boundary class.
Ports and viewports can only pass a two-state logic value (‘0’, ‘1’) or arrays of it. A parameter is a Boolean, Integer or String.
Four-state model boundary class.
Ports and viewports can only pass a two- or four-state logic value (‘0’, ‘1’, ‘Z’, ‘X’) or arrays of it. A parameter is a Boolean, Integer or String.
Simple-logic model boundary class.
Ports and viewports pass any logic type or arrays of it, Real and Integer. A parameter is a Boolean, Integer or String.
Unrestricted model boundary class.
Ports, viewports and parameters can be any OMI type.
Simulation style.
Applications may provide different environments:
Cycle-based.
The application does not use or support delayed updates or event times. This restricts simulation to a simple clock-based model.
Event-driven.
All callbacks and simulator routines can be used, allowing a general, event-based simulation paradigm. The event-driven style includes the cycle-based style.

The application characteristics are vital to the simulation environment as they may narrow the bunch of fitting model managers.

It is required that an OMI-compliant simulator – remember a simulator being a special type of application – at least supports the two-state model boundary class and the cycle-based simulation style. An OMI event-based simulator is a different kind of OMI-compliant simulator that supports at least the simple-logic model boundary class and the event-driven simulation style.

The model or model manager determines the characteristics of the application and diagnoses incompatibilities between them and its own requirements or those of the models. The information gained can be used to auto-reconfigure the model manager or model to the simulation environment provided by the application during the bootstrap process.

Execution is activity – calls to OMI routines – during an OMI session driven by an application and one or more model managers. Simulation is a primary kind of execution but not the only one. One could think of an execution that only extracts timing information. Of course the execution proceeds on an orderly fashion, separated into three sessions and five stages, presented in order of occurrence:

Model query session.
The only stage residing in this session is the Bootstrap, where the nature of the session is established and general setup activities are done.
Elaboration session.
The Elaboration stage creates the model instances required for the OMI session.
Simulation session.
This is the only session consisting of two stages. The Initialization establishes the initial values of stateful data objects, while the Simulation after it approximates the behavior of a system by exercising a set of models. Therefore it uses stimulus and response propagation.

All stages can directly lead to the fifth stage, Termination, without executing the following stages, making it the final stage in every case.