Introduction
This document describes the MMI (Module Model Interface) device-model API
for the SPARC Architectural Model (SAM). A SAM device model is built as a
shared library (loadable module) which is dynamically loaded into SAM during
initialization.
The sysconf directives in the input configuration file specify the device module, instance name and its associated properties.
API function and type names are prefixed with mmi_.
Attaching Modules
A device-model is typically contained within a shared object (.so file). A shared object typically has only one visible module that plugs into SAM.
Internally within the device model, there can be a hierarchy of components (for example, Niagara ethernet module).
An instance is what actually represents a device in SAM. There are generally multiple instances of a given device module.
The sysconf directive
sysconf directives are specified in the simulation configuration file. Each sysconf line specifies
the module to be loaded if necessary, and the name of the device node to be instantiated. To properly instantiate the device node,
SAM calls the instance creator function registered from within the module.
The mmi_instance_t handle
Each instance can be referred to using an opaque mmi_instance_t handle. This includes code referring to its own instance (eg to register certain callback functions) as well as other instances (eg to get an exported interface)
Threading Model
SAM can be run in multi-threaded mode. It is recommended that module developers for SAM
assume that simulated SPARCv9 CPUs may be bound to separate host threads, running on different
processors on the host machine running the simulation.
A strand, however, is never simulated by more than one simulation thread, and
when a strand performs a callback to the module it may be assumed that strand
execution is stopped at the point of callback.
Module to Module Interaction
Modules may be loaded in any order (as specified in the sysconf file). In some cases, modules may be unloaded at any time.
The SAM sysconf mechanism does not allow for device modules to be unloaded but the older ldm UI command does allow this.
Each module is notified when another module changes status
(mmi_register_config_cb).
Modules may call each other by getting pointers to their interfaces
(mmi_get_interface).
When a module is unloaded, other modules should receive the corresponding config change notification
and remove their interface pointers to the unloaded module.