sam-t2/docs/mmi/intro.html

<html>

<head>
   <title>SPARC Architectural Model: Device and Utility API</title>
</head>

<body bgcolor="#FFFFFF" LANG="en-US">

<h2>Introduction</h2>
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.
<p>
The <tt>sysconf</tt> directives in the input configuration file specify the device module, instance name and its associated properties.
<p>
API function and type names are prefixed with <tt>mmi_</tt>.
<p>
<h4>Attaching Modules</h4>

<li> 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).</li><br>

  <li>An <i>instance</i> is what actually represents a device in SAM. There are generally multiple instances of a given device module.</li><br>

  <li> <a href="sysconf.html">The <tt><b>sysconf</b></tt> directive</a>
  <p><ul>
  <tt>sysconf</tt> 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.
</ul> </li>
</ul>

<h4> The <tt>mmi_instance_t</tt> handle</h4>

Each instance can be referred to using an opaque <tt>mmi_instance_t</tt> 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)

<h4>Threading Model </h4>

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.
<p>
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.

<h4>Module to Module Interaction </h4>

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 <tt>ldm</tt> UI command does allow this.
<p>
Each module is notified when another module changes status
(<a href="mmi_register_config_cb.html">mmi_register_config_cb</a>).
<p>
Modules may call each other by getting pointers to their interfaces
(<a href=" mmi_get_interface.html">mmi_get_interface</a>).
When a module is unloaded, other modules should receive the corresponding config change notification
and remove their interface pointers to the unloaded module.

<p>
<hr>
</body>

</html>