[OpenSPARC-T2-SAM] / sam-t2 / docs / mmi / index.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title>SPARC Architectural Model: Device Model API</title>
</head>
<body bgcolor="#ffffff" lang="en-US">
<h1>SPARC Architectural Model: Device Model API</h1>
<h2>Introduction</h2>
This document describes the MMI 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>
<p>API function and type names are prefixed with <tt>mmi_</tt> 
(which means Module Model Interfaced).
</p>
<p></p>
<h4>Attaching Modules</h4>
<li> A device-model is built as 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> The <tt><b>sysconf</b></tt> directive
  <p></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. This is followed by the properties associated with
the instance, in the form of name=value words.
To properly instantiate the device node,
SAM calls the instance creator function registered from within the
module.
  </ul>
</li>
<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 (for example, to
register certain callback functions) as well as other instances (for example, 
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>
<p>Modules may call each other by getting pointers to their interfaces
(<a href="%20mmi_get_interface.html">mmi_get_interface</a>).
When a module is unloaded, other modules should receive the
corresponding configuration (config) change notification and remove 
their interface pointers to the unloaded module.
</p>
<h2>API Overview</h2>
<h4>Module instantiation</h4>
<ul>
  <li><a href="mmi_register_instance_creator.html">mmi_register_instance_creator</a>
  </li>
  <li><a href="mmi_register_instance.html">mmi_register_instance</a> </li>
  <li><a href="mmi_get_instance.html">mmi_get_instance</a>
  </li>
</ul>
<h4>Module connectivity</h4>
<ul>
  <li><a href="mmi_map_physio.html">mmi_map_physio</a> </li>
  <li><a href="mmi_register_config_cb.html">mmi_register_config_cb</a> </li>
  <li><a href="mmi_register_interface_cb.html">mmi_register_interface_cb</a>
  </li>
  <li><a href="mmi_get_interface.html">mmi_get_interface</a> </li>
  <li><a href="mmi_register_modinfo_cb.html">mmi_register_modinfo_cb</a></li>
  <li><a href="mmi_register_asi_action.html">mmi_register_asi_action</a></li>
  <li><a href="mmi_register_asi_cb_data.html">mmi_register_asi_cb_data</a><br>
  </li>
</ul>
<h4>Memory Access</h4>
<ul>
  <li><a href="mmi_memaccess.html">mmi_memread</a> </li>
  <li><a href="mmi_memaccess.html">mmi_memwrite</a>
  </li>
</ul>
<h4>Interrupts</h4>
<ul>
  <li><a href="mmi_interrupt.html">mmi_interrupt_packet</a> </li>
  <li><a href="mmi_interrupt.html">mmi_interrupt_vector</a>
  </li>
</ul>
</body>
</html>
Commit	Line	Data
920dae64 AT	1	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
	2	<html>
	3	<head>
	4	<title>SPARC Architectural Model: Device Model API</title>
	5	</head>
	6	<body bgcolor="#ffffff" lang="en-US">
	7	<h1>SPARC Architectural Model: Device Model API</h1>
	8	<h2>Introduction</h2>
	9	This document describes the MMI device-model API for the SPARC
	10	Architectural Model (SAM).
	11	A SAM device model is built as a shared library (loadable module) which
	12	is dynamically loaded into SAM during initialization.
	13	<p>The <tt>sysconf</tt> directives in the input configuration file
	14	specify the device module, instance name and its associated properties.
	15	</p>
	16	<p>API function and type names are prefixed with <tt>mmi_</tt>
	17	(which means Module Model Interfaced).
	18	</p>
	19	<p></p>
	20	<h4>Attaching Modules</h4>
	21	<li> A device-model is built as a shared object (.so file). A shared
	22	object typically has only one visible module that plugs into SAM.
	23	Internally within the device model, there can be a hierarchy of
	24	components (for example, Niagara ethernet module).</li>
	25	<br>
	26	<li>An <i>instance</i> is what actually represents a device in SAM.
	27	There are generally multiple instances of a given device module.</li>
	28	<br>
	29	<li> The <tt><b>sysconf</b></tt> directive
	30	<p></p>
	31	<ul>
	32	<tt>sysconf</tt> directives are specified in the simulation
	33	configuration file. Each sysconf line specifies
	34	the module to be loaded if necessary, and the name of the device node
	35	to be instantiated. This is followed by the properties associated with
	36	the instance, in the form of name=value words.
	37	To properly instantiate the device node,
	38	SAM calls the instance creator function registered from within the
	39	module.
	40	</ul>
	41	</li>
	42	<h4> The <tt>mmi_instance_t</tt> handle</h4>
	43	Each instance can be referred to using an opaque <tt>mmi_instance_t</tt>
	44	handle. This includes code referring to its own instance (for example, to
	45	register certain callback functions) as well as other instances (for example,
	46	to get an exported interface).
	47	<h4>Threading Model </h4>
	48	SAM can be run in multi-threaDed mode. It is recommended that module
	49	developers for SAM
	50	assume that simulated SPARCv9 CPUs may be bound to separate host
	51	threads, running on different
	52	processors on the host machine running the simulation.
	53	<p>
	54	A strand, however, is never simulated by more than one simulation
	55	thread, and
	56	when a strand performs a callback to the module it may be assumed that
	57	strand execution
	58	is stopped at the point of callback.
	59	<h4>Module to Module Interaction </h4>
	60	Modules may be loaded in any order (as specified in the sysconf file).
	61	In some cases, modules may be unloaded at any time.
	62	The SAM sysconf mechanism does not allow for device modules to be
	63	unloaded but the older <tt>ldm</tt> UI command does allow this.
	64	<p>Each module is notified when another module changes status
65	(<a href="mmi_register_config_cb.html">mmi_register_config_cb</a>).
66	</p>
67	<p>Modules may call each other by getting pointers to their interfaces
68	(<a href="%20mmi_get_interface.html">mmi_get_interface</a>).
69	When a module is unloaded, other modules should receive the
70	corresponding configuration (config) change notification and remove
71	their interface pointers to the unloaded module.
72	</p>
73	<h2>API Overview</h2>
74	<h4>Module instantiation</h4>
75	<ul>
76	<li><a href="mmi_register_instance_creator.html">mmi_register_instance_creator</a>
77	</li>
78	<li><a href="mmi_register_instance.html">mmi_register_instance</a> </li>
79	<li><a href="mmi_get_instance.html">mmi_get_instance</a>
80	</li>
81	</ul>
82	<h4>Module connectivity</h4>
83	<ul>
84	<li><a href="mmi_map_physio.html">mmi_map_physio</a> </li>
85	<li><a href="mmi_register_config_cb.html">mmi_register_config_cb</a> </li>
86	<li><a href="mmi_register_interface_cb.html">mmi_register_interface_cb</a>
87	</li>
88	<li><a href="mmi_get_interface.html">mmi_get_interface</a> </li>
89	<li><a href="mmi_register_modinfo_cb.html">mmi_register_modinfo_cb</a></li>
90	<li><a href="mmi_register_asi_action.html">mmi_register_asi_action</a></li>
91	<li><a href="mmi_register_asi_cb_data.html">mmi_register_asi_cb_data</a><br>
92	</li>
93	</ul>
94	<h4>Memory Access</h4>
95	<ul>
96	<li><a href="mmi_memaccess.html">mmi_memread</a> </li>
97	<li><a href="mmi_memaccess.html">mmi_memwrite</a>
98	</li>
99	</ul>
100	<h4>Interrupts</h4>
101	<ul>
102	<li><a href="mmi_interrupt.html">mmi_interrupt_packet</a> </li>
103	<li><a href="mmi_interrupt.html">mmi_interrupt_vector</a>
104	</li>
105	</ul>
106	</body>
107	</html>