| [Top] | [Contents] | [Index] | [ ? ] |
This file documents the collection of simulation tools and packages (nmisim) for the integration of neural systems based around the Network Model Interface (NMI). This edition documents version 1.01.
1. Notices 2. Introduction 3. Installation 4. NMI Components 5. Support File Packages 6. Example Applications
-- The Detailed Node Listing ---
Introduction
2.1 Problem Definition 2.2 Approach 2.3 Overview of Resources 2.4 Conclusions 2.5 Obtaining 2.6 Other Documentation
Installation
3.1 Dependencies 3.2 Platforms 3.3 Required Software 3.4 Building
Building
Support File Packages
5.1 Organising Support Files 5.2 Component Support Package Layout 5.3 Component Support Packages Available 5.4 Framework Support Package Layout 5.5 Framework Support Packages Available
Organising Support Files
5.1.1 Library Files 5.1.2 Tutorial Files 5.1.3 Post-processing Files
Example Applications
6.1 Working Memory and Attention 6.2 Motor Control of a Robotic Arm 6.3 Real-time Cerebellar Models for Motor Control
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
NMI Simulation Resources (nmisim)
Copyright (C) 2002 - 2003 The Salk Institute for Biological Studies
Copyright (C) 1997 - 2003 Mike Arnold, Altjira Software
Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.
Elements of the described software were developed with the support of NASA Grant Number: NCC 2-1253.
This software and documentation is provided "as is" without express or implied warranty. All questions should be addressed to mikea@salk.edu.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This file documents the collection of simulation tools and packages (nmisim) for the integration of neural systems. It is based around the Network Model Interface (NMI) or (libnmi) which defines how a generic component within a model interacts with a generic model or simulation framework. Apart from libnmi, the nmisim collection contains frameworks, interoperability packages, data post-processing packages, software development packages and models.
2.1 Problem Definition 2.2 Approach 2.3 Overview of Resources 2.4 Conclusions 2.5 Obtaining 2.6 Other Documentation
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
What are the practical issues involved in building large neural systems that model a substantial number of areas in the brain? The creation of such systems is beyond the scope of small research groups, yet there is the need to address the issue outside of the context of large, well-funded, highly structured and heavily managed research initiatives, that is to address the issue within the more fragmented and less well-funded context of many small independent collaborating research teams. The essence of the solution is to integrate the work from many researchers, but we wish to avoid solutions which impose harsh constraints on the individual researcher, in particular the imposition of specific modeling environments or sets of tools. Such impositions often meet with resistance, due to a perceived reduction in immediate effectiveness, a requirement for extensive training and a lack of suitability. It should also be possible to integrate existing work, not just future work that may be carried out within some particular simulation methodology.
One approach is for the integrators to re-build published work within some target modeling environment, and it is possible to argue the value of this approach on two counts. Firstly it validates the original work, and secondly it is the only way of providing the integrators with the requisite sufficient understanding of the component. This approach is costly so we turn instead to a solution based on the integration of a component model as a piece of software.
What constraints do the investigation of large neural systems place on their implementation? Such systems are interesting because they address cognitive function within a semi-complete system, which implies their necessary investigation within the context of complex behavioural tasks. The target implementation may therefore vary with the system being investigated, with requirements varying from interacting with a simulated world in virtual time, to a real world in real time, to specific robotic or prosthetic platforms. The constraints on target implementations are therefore varied and largely unknown.
One is therefore faced with the task of integrating disparate, sometimes pre-existing, software components into a range of frameworks, targeting a variety of physical implementations. This diversity will not just include different physical memory models, but also components implemented within Field Programmable Gate Arrays (FPGAs) or as analogue VLSI.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document describes an approach based around the concept of a Network Model Interface (NMI) or (libnmi) which defines the interaction between a generic component and a generic implementation framework. It is used to wrap up a component prior to its integration. Other wrappers exist to allow the deployment of NMI-wrapped components within a number of different frameworks, including Matlab and tenns. The NMI does not define a framework and it trys not to address framework issues, apart from defining three primary areas of interaction: the passing of data, the passing of control and timing information, and the passing of configuration information. The aim is to seperate the implementation of a component from its deployment. The NMI does impose a master-slave relationship where the framework is the master. The scope of a component is strictly limited to itself. It has no knowledge of the other components within the system and is directly dependent on the framework for all information external to itself.
The NMI is designed specifically for models that fit into a network paradigm of nodes and connections. A component usually represents a set of nodes and defines its connectivity with, and the communication of data with, the rest of the system in terms of sets of input or output nodes. The network paradigm is crucial in that the scope for all possible interactions between components is explicit in the network connectivity and must be implemented through the uni-directional communication of data. The passing of configuration information and the passing of control are considered separate to the passing of data, as there are no mechanisms to pass configuration information or control between components. Even if a particular component does not conceptually reflect a network of neurons, its communication within the system may always be abstracted using the network paradigm. The NMI is implemented as an object-oriented class where a specific type of component exists as a derived class. Data is communicated in packets and multiple arbitary data types are supported through the use of a templated packet type derived from a base packet type.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Resources within the nmisim collection fall in to a number of different categories:
these are components that have been wrapped up using NMI, so that they can be integrated into any NMI compatible framework. For a complete list refer to 4. NMI Components.
Currently two frameworks support the integration of NMI components. TENNS is designed for heterogenous models that fit a network paradigm of nodes and connections. matnmi is a wrapper that allows NMI components to be accessed from within Matlab.
Frameworks generally support their own abstractions. A set of packages exist to facilitate the transfer of models between frameworks as NMI components. tcc can be used to package TENNS models as NMI components.
Matlab code can be packaged up as NMI components using one of two approaches. The computationally most efficient approach is take a specific set of matlab code and to pre-compile it into C code using the Matlab compiler `mcc'. The C code can then be wrapped up within a NMI component. A more convenient but computationally less efficient approach is to use the Matlab Engine NMI Component (libmtng) which uses the matlab engine to allow a run-time specified body of matlab code to be run as an NMI component.
MCell abstractions and simulations can be imported using libmcell.
The Data Extraction Library (libdext) and its accompanying matlab wrapper and associated matlab files (matdpp) work with frameworks such as TENNS to manage the post-processing of generated data files.
Support file packages can be specific to a framework or a NMI component and include configuration libraries, tutorials and post-processing support. For availability refer to the documentation for the relevant framework or NMI component and to 5.3 Component Support Packages Available and 5.5 Framework Support Packages Available.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
What is left largely unaddressed by this approach of integrating software components are some important systems integration and engineering issues. This is not meant to refer to the software engineering issues but to those relating to the practice of integrating existing components versus their re-implementing as new components. In practice, the function of a component will never be transparent. This makes it difficult to both validate the component and to gain sufficient understanding of the component. These and managing the knowledge required to do the integration are the real issues in building large neural systems, not issues of parallel programming and software methodologies. This is reflected in those approaches based around the use of markup languages to structure the information within the domain of biological models. The approach based around the NMI differs from those and others in that it focuses on how large neural systems can be implemented in the short term and with limited resources. This acknowledges the unknown nature of the integration problems and the need to identify them within the context of actual experience. In defining this approach we have tried to identify a shortest path to allow us to study the problem at first hand.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The Network Model Interface may be obtained here. To obtain any of the other packages refer to their documentation.
3rd party meta-packages are available that contain a collection of NMI related packages, including libnmi, arranged in to a single tree to facilitate the building and installation of multiple packages in a single pass. These meta-packages may include this documentation. For installation instructions refer to 3. Installation.
The latest version of this documentation may be found at http://www.cnl.salk.edu/~mikea/doc/nmisim/nmisim.html.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Further information regarding the interoperability of NMI components and supporting frameworks, their development and use, and all associated support file packages, is available in the Network Model Interface documentation. A poster presentation of the role of NMI in the integration of neural systems, given at CNS'03, is available here.
Also refer to the documentation for each NMI component and each supporting framework. The current list of NMI based components and associated support file packages is available here.
This documentation is also installed to ${prefix}/doc/nmisim, where `${prefix}' is the installation directory specified during the build configuration.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This section is only relevant if installing nmisim meta-packages that contain a collection of NMI-related packages arranged into a single tree.
3.1 Dependencies 3.2 Platforms 3.3 Required Software 3.4 Building
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Nmisim packages are dependent on the ANSI Standard C++ Library. Check with the documentation for the individual packages for variations.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Nmisim has been successfully tested on the following systems:
Check with the documentation for the individual packages for variations.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The following software is suggested. Other versions may work but have not been tested. Check with the documentation for the individual packages for variations.
Package maintenance requires:
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Nmisim is a meta-package consisting of a number of inter-dependent packages. All of the packages are dependent on the NMI libnmi package. All of the packages are (or should be) constructed in a standard manner to take advantage of the GNU build automation tools automake and autoconf.
The standard steps in building any package that is constructed using these tools are:
More detailed information is also available in the INSTALL file in the Nmisim distribution and in the individual package distributions.
The packages in the Nmisim meta-package can be built individually, that is configured, built and installed one at a time, though in this case care must be taken to ensure that they are built in an appropriate order as some packages require other packages. It is more usual to treat the packages as a single large package and to configure, build and install them as one. For this reason Nmisim lays out each of the packages as a subdirectory and supplies a configure script and a Makefile in the top-level directory to handle the configuration and building of the selected packages in the correct order.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If distributed as a gzipped tar file, try:
cd /usr/local/src zcat nmisim-1.0.tar.gz | tar xf - |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Because of the dependencies between the packages, the configuration of one package may not be able to complete before a requisite package is completely installed.
For this reason the Nmisim installation is done in two stages.
In the first stage, when first installing Nmisim, each selected package must be configured, built and installed separately and in the correct order.
The script build-seq.sh can be used to automate this process.
This process does not use the configure script or the Makefile in the top-level Nmisim directory.
Using build-seq.sh will make all the necessary calls to configure, make and make install as required.
After calling build-seq.sh the Nmisim installation is complete, though if the source tree is to be frequently modified and rebuilt then it may be advisable to proceed to the second optional stage.
In the optional second stage, after the packages are installed, the Nmisim installation can be re-configured and re-built as a single tree, making use of the configure script and the Makefile in the top-level Nmisim directory.
The first advantage of this approach is that make and make install can be used from the top-level directory to maintain the Nmisim installation.
The second advantage of this approach is that it ensures that each of the packages are configured in a compatible way, by passing the same configuration options to all of the packages.
Failure to configure the packages in the same way can lead to problems for some of the packages when linking.
Note that if the build-seq.sh is used in the first stage, the same configuration options are automatically passed to each package.
The re-configuration in the second stage can be handled by the conf-tree.sh script.
Using this script ensures that any dependencies are resolved within the Nmisim source tree and any executables are linked against the libraries within the build tree, as opposed to resolving within the install destination.
The benefit of this is that running make install does not cause needless re-compilations.
After calling conf-tree.sh, it is then necessary to call make followed by make install, after which the second stage is complete.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The packages to be built are selected be editing the following files in the Nmisim top-level directory: `configure.ac, Makefile.am, build-seq.sh'.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Whilst Nmisim can be built within the source tree, it is usual to build it as a seperate object tree. The build is then installed to the `<installation prefix>' as described in 3.4.6 Configuring. The object tree may be located either within or outside of the source tree.
Note that all calls to configure, to make and to any other configuration scripts, must be run from within the object tree.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The two helper scripts build-seq.sh and conf-tree.sh take the same arguments:
script <installation prefix> [configure-arguments ...] |
where `<installation prefix>' is the directory where Nmisim is to be installed, and the remaining arguments are passed to the configure scripts. On some systems it is important that the the scripts be called using an absolute not a relative pathname. For example:
/usr/local/src/nmisim-1.0/build-seq.sh /usr/local --enable-graphics |
Refer to the INSTALL and README files in the distribution and in the individual package distributions for details on the available configuration options.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
After modifying any of the source, just run make or make install from the top-level directory.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Note that most NMI libraries are built as shared libraries using libtool.
This means that they can not be linked against until fully installed, that is utnil calling make install.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Because the `Makefiles' and `configure' scripts are generated using autoconf and automake, only the `Makefile.am' and `configure.ac' scripts should be modified.
The generated `Makefiles' include targets to maintain themselves by automatic calling of autoconf and automake as required, so after modifying any of the `Makefile.am' or `configure.ac' files it is necessary only to run make.
Of course this applies only to modifications made after the initial installation has completed.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
To add a new package, modify the files as directed in 3.4.4 Selecting the Packages. Configure, build and install the package as directed in its documentation.
To maintain the installation of the package as a part of the Nmisim source tree, if the conf-tree.sh script was used in the original installation, then re-run this script, otherwise simply run make.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
To upgrade to a new version of Nmisim, unpack the new version over the old version as directed in 3.4.2 Unpacking, though first maintaining a copy of the configuration files modified as directed in 3.4.4 Selecting the Packages.
Check these modified configuration files against the new ones in case new packages have been added in the new version.
Next run make from the top-level directory.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The current list of NMI based components and associated support file packages is available at http://www.cnl.salk.edu/~mikea/nmi/components.html.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
5.1 Organising Support Files 5.2 Component Support Package Layout 5.3 Component Support Packages Available 5.4 Framework Support Package Layout 5.5 Framework Support Packages Available
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
5.1.1 Library Files 5.1.2 Tutorial Files 5.1.3 Post-processing Files
This section describes the types of support files that are available within nmisim and suggests a standard directory layout for organising them.
Support file packages are considered specific to either a framework or an NMI component. Note that an NMI specific package may contain support files to support the integration of the NMI component in to a range of different frameworks and therefore can include both framework independent and framework specific files. Framework specific files usually have framework specific suffixes, for example `.m' for matlab and `.cnf' or `.cmp' for TENNS.
Each NMI component or framework may have a number of support file packages associated with it.
Each package may have different types of support files which are distributed within the installation directory as indicated in the figure below. These include library files, tutorial files and post-processing files. The root directory for the support files is by default `prefix/share/nmisim' where `prefix' is the primary nmisim installation directory. A package should also include documentation files which are installed outside of the tree shown below, usually in `prefix/doc/package'.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A package will generally contain library files. These are organised within the framework or `libnmi' sub-directory of the installation directory, according to whether the package is specific to a framework or to an NMI component. Note that an NMI specific package may contain library files to support the integration of the NMI component in to a range of different frameworks.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A package should contain tutorial related support files. These are organised within either the `tutorial/framework' or `tutorial/libnmi' sub-directory of the installation directory according to whether the package is specific to a framework or to an NMI component. Note that an NMI specific support file package may contain tutorial files to illustrate the integration of the NMI component in to a range of different frameworks.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A package should contain matdpp post-processing support files. These are organised within either the `matdpp/framework' or `matdpp/libnmi' sub-directory of the installation directory according to whether the package is specific to a framework or to an NMI component.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A support file package for an NMI component should contain files of the following types, located relative to the root directory for the support files. This is by default `prefix/share/nmisim' where `prefix' is the primary nmisim installation directory.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The current list of NMI based components and associated support file packages is available at http://www.cnl.salk.edu/~mikea/nmi/components.html. Also refer to the documentation for each component.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A support file package for a framework should contain files of the following types, located relative to the root directory for the support files. This is by default `prefix/share/nmisim' where `prefix' is the primary nmisim installation directory.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The current list of NMI based components and associated support file packages including those for specific supported frameworks is available at http://www.cnl.salk.edu/~mikea/nmi/components.html. Also refer to the documentation for each framework.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
6.1 Working Memory and Attention 6.2 Motor Control of a Robotic Arm 6.3 Real-time Cerebellar Models for Motor Control
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The NMI is being used within a system encompassing the ventral pathway, pre-frontal areas, the frontal eye fields, the basal ganglia, the cerebellum and a model of the external world, applied to the block building task. This task integrates a number of distinct elements and research efforts. The ventral pathway, frontal eye fields and pre-frontal areas are combined in a dynamical model of working memory directed visual attention, providing both the bottom-up sensory motor loop upon which the task is based together with the mechanism for its top-down modulation by cognitive processes. Simple task learning is based on the use of a cortical-basal ganglia-thalamic loop for the selection and evaluation of actions. By analogy to actor-critic methods of reinforcement learning, the basal ganglia corresponds to the actor, and the ventral tegmental area corresponds to the critic. The ventral tegmental area generates reward prediction errors which are used both to drive the learning in the basal ganglia and the ventral tegmental area, and to drive the exploration in the system by controlling the stability of patterns of activity in prefrontal areas. Planning is introduced through the use of an internal model, as possibly modeled by the cerebellum, to replace the external world during a virtual multi-step sequential exploration phase.
This is system characterised by different neural paradigms, spiking and non-spiking, and a range of learning algorithms with varying degrees of scope. Existing implementations include shared memory architectures and targeted implementations include distributed memory architectures and the use of FPGAs. In particular we have used NMI to integrate from collaborating researchers pre-existing software models for the ventral pathway, frontal eye fields, some pre-frontal areas and the block world.
Fred Hamker, Caltech, Pasadena, Marwan Jabri, Oregon Graduate Institute, Portland. Mike Arnold, CNL, The Salk Institute, San Diego. Terrence Sejnowski, CNL, The Salk Institute, San Diego
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The NMI is being used in the exploration of how feedforward and open-loop motor control strategies can be used to control both a hardware implementation and a software model of a human arm. The hardware implementation consists of a two-joint arm controlled by pairs of McKibben air muscles. The software model consists of a two-joint arm controlled by 3 pairs of muscles based on the Hill muscle model.
The feed-forward motor control algorithm relys on the movement of limbs by flexor/extensor muscle pairs. The algorithm is related to equilibrium point control but with the distinction that the dynamic response of the system is also controlled yet no desired trajectory need be specified. The model reproduces important bodies of experimental data observed during reaching movements. The open-loop controller is based on the cerebellum.
Chris Assad, Jet Propulsion Lab, Pasadena, Eric Ronco, Sony Computer Science Lab, Paris, Mike Arnold, CNL, The Salk Institute, San Diego, Marwan Jabri, Oregon Graduate Institute, Portland, Terrence Sejnowski, CNL, The Salk Institute, San Diego
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A spiking cerebellar model, implemented in part within an FPGA, is applied in real-time to motor control. The elements of the work are as follows. First, the use of a biologically detailed model of the cerebellum composed of conductance based spiking neurons to learn a number of simulated tracking tasks. Second, the integration of the cerebellar control system with a stable feed-forward end-point motor controller for arm-based tracking tasks. Third, the evaluation of efficient software based event driven methods for modeling spiking neurons. Fourth, the efficient digital implementations of spiking neurons using FPGAs.
These four elements are all brought together within a single system running in real-time on a PC with an add-on FPGA card. The system consists of seperate components combined within a framework, for the task, the motor controller, the cerebellar granular layer and the remainder of the cerebellum. The neural paradigm for the cells in the granular layer of the cerebellum is implemented in hardware on the FPGA, whilst the associated network connectivity, routing of spikes and learning is implemented in software on the PC. The neural paradigm for the remaining cells in the olivary-cerebellar system are implemented using event-driven methods in software. Each of the demonstrated elements and components is the result of a seperate research effort, representing the work of large and diverse group of researchers.
Mike Arnold, CNL, The Salk Institute, San Diego, Eduardo Ros, University of Granada, Granada, Olivier Coenen, Sony Computer Science Lab, Paris, Eric Ronco, Sony Computer Science Lab, Paris, Rodrigo Agis, University of Granada, Granada, Eva Ortigosa, University of Granada, Granada, Terrence Sejnowski, CNL, The Salk Institute, San Diego.
| [Top] | [Contents] | [Index] | [ ? ] |
| [Top] | [Contents] | [Index] | [ ? ] |
1. Notices
2. Introduction
3. Installation
4. NMI Components
5. Support File Packages
6. Example Applications
| [Top] | [Contents] | [Index] | [ ? ] |
| Button | Name | Go to | From 1.2.3 go to |
|---|---|---|---|
| [ < ] | Back | previous section in reading order | 1.2.2 |
| [ > ] | Forward | next section in reading order | 1.2.4 |
| [ << ] | FastBack | previous or up-and-previous section | 1.1 |
| [ Up ] | Up | up section | 1.2 |
| [ >> ] | FastForward | next or up-and-next section | 1.3 |
| [Top] | Top | cover (top) of document | |
| [Contents] | Contents | table of contents | |
| [Index] | Index | concept index | |
| [ ? ] | About | this page |