2.4.4.  Octopus through OMI Eyes

The section headlines will be similar to those in the OMI discussion to retain the way of contemplation.

2.4.4.1 Basic OMI Concepts

One of the first properties mentioned was the way of delivery of the models and model managers. With Octopus, models are always delivered to the end user as a unit together with the model manager as a shared library on Solaris or as a dynamically linked library on Windows. Although it is theoretically possible to dynamically include models, Octopus does not cover this in respect of any dynamic library handling. The common process is to link Octopus with all models needed for a particular system, and give the end result away as a product.

Of course the implementation is much more interesting than the way of delivery, so next thing to review is the way of bootstrapping Octopus. There is no bootstrap file, as it was considered to be packaged together with the model manager. This fact is quite obvious, because there is no OMI compliant application reading and interpreting the bootstrap file, so why generate one. The adaptation to the application is made within the library, and the adaptation layer of course knows what to do. A further discussion on bootstrapping and elaboration will follow in section  2.4.4.3 on page 162.

Very important in the OMI are the model boundary class and the simulation style, the applications using Octopus have to support. The answer is simple but as well dissatisfying: The requirements totally depend on the adaptation layer. The Octopus simulator interface supports applications with unrestricted model boundary class and an event-driven simulation style. But the adaptation layer – actually being on the application side – can convert semantics and data to any of the other model boundary classes, too. The same applies to the simulation style. An application, only capable of cycle-based simulation, can invoke its calls to the adaptation layer and this will care for pending events and in unused cycles simply do nothing.

2.4.4.2 Information Model

Another interesting piece of information is the type concept of Octopus, the way information is stored and processed. Referring to the OMI standard, the three basic terms for model boundary classes are port, parameter and viewport. The port concept is implemented using the same term – port. Octopus port can be used not only for internal interaction of models, but also for communication between Octopus and the application. For data retrieval and manipulation usually ports are used, the implementation for this is a subject of section 0. A parameter, used for tailoring model instances, is realized availing configurable models. A user-defined structure can be passed to a model at creation time. The particular model delimits the amount of adaptability by defining the structure. This will be shown in practical experience with two models in sections  3.1.2 on page 174 and  3.1.3 on page 191. The Octopus feature named backdoor register access implements the third basic term, viewport, not literally but conceptual, allowing the application to get a module’s register contents without performing a normal access that may produce side effects.

An implementation for root object and library objects is missing, but again, this would be useful only for an OMI application. The counterpart for the model object is the structure motModelEntryT, which contains properties for name, timing information and type as well as relationships for model manager commands and addresses of the callback functions. The model instance object is included in the structure; important for this is the relationship to the parameter object named ConfigInfo, which holds the actual model parameters.

For performance reasons, Octopus does not use a class-oriented data type system, as invented with the OMI Information Model. Anyhow, there are some structure definitions, e. g. motPortT for the definition of ports, specifying name, direction, sensitivity and initial type-token combination. Another structure definition is the motSignalDefinitionT type. It specifies signal properties, especially of signals that are connected externally. Although Octopus defines several types for e. g. port directions, debug print type, reset type, it does not inherit any data object classes. Many types are enumerations to make the numbers they hide more readable.

Timing definitions are provided not in standard delay format (SDF), but on a model base using the motClockEntryT structure type. It describes the correlation of model timing and the global clock in respect of multiplier, offset, times to wake up and power off, an own clock rate; or even to define the model as clock-less. There are some macros that allow a more easy configuration of models that fall in one of the four subsequent categories.

• Models without clock.
• Models using the system clock.
• Models using a scaled system clock.
• Models using an own clock frequency.

There are no special implementations for array types or records, the common C programming language constructs are used for these.

2.4.4.3 Sessions and Execution Stages

This section will go through the five stages, introduced in section 2.2.3 on page 102: Bootstrap, elaboration, initialization, simulation and termination.

For each stage the OMI standard will be compared with the actual Octopus implementation. Some of the appropriate callbacks for the particular stages will be mentioned, without going too much into interaction details.

Bootstrap Stage.

As already discussed, there is no bootstrapping in Octopus, as the name – respectively the address – of the bootstrap function does not have to be determined. If in future Octopus is to support OMI applications, it will be a penny to add a bootstrap file and the appropriate functions.

Elaboration Stage.

The omiCreateInstance function, to be invoked for each model, has its equivalent in the Init callback function that is registered in the motModelEntryT structure. So in Octopus, elaboration starts even before, when it raises the motInitialSetup function that is located in the configuration file models.cpp. This function is responsible to pass an array with all model entries, another one with all signal definitions – the netlist – and a third one specifying all model manager commands. Beside these main tasks, the dump code for signal dumping is registered. After this function, Octopus knows which models are to be used and what parameters they have and need. Then it goes through the array and invokes the Init callbacks. Each model’s initialization is responsible to create its registers and ports, then to announce them to Octopus. The registers have to contain initial values, while output ports need their initial type-token combination, which leads directly to the next stage.

Initialization Stage.

The Init callback does not only create the model instance, it also configures the model with the information available, using the function motGetModelConfigInfo, which returns a pointer to the configuration structure mentioned above. In the models, created for the thesis, it will be seen that elaboration and initialization cannot be strictly separated, because information in the configuration structure is used to determine how many registers are to be created. So there are no exact analogies for the omiDriverInitialization, omiInitializeDriver and omiNetInitialization functions.

Simulation Stage.

Octopus is driven by the application, which calls Octopus’ motEval function. A simulation loop looks like specified in Figure  2.16 on page 110, all possibilities shown there are implemented in Octopus.

Termination Stage.

The termination stage was explained in section  2.4.1.2 on page 143. Ending a session is no big deal, it has to be clear that termination must follow strict rules to avoid memory leaks or access to already destroyed objects.