The Nano Interface Unit (NIU2A) is a second-generation, integrated, compact, “nano-sized” subsystem with unprecedented I/O capability configurations. The NIU2A connects to existing platform Ethernet networks, making data available to any system on the network. Optionally, the NIU2A can be delivered with ARM® Cortex®-A9 access support for standalone or other processor related capability.

The NIU2A easily adds sensor data acquisition and distribution and communication interfaces to mission computers without expensive chassis and backplane redesign. It has been designed with rugged embedded industrial, military and aerospace applications in mind.

Leveraging NAI’s field-proven, unique modular architecture, the NIU2A supports a wide selection of different Intelligent I/O, motion simulation/measurement and communications functions such as:

This approach provides unprecedented flexibility for supporting existing or new applications where there are specific interfacing requirements. Significant application benefits include:

Notes:

*1 - Designed to meet / Generic Test Reports Available

*2 - Utilizing proper shielded cables and system grounding practices

Typical Mean Time Between Failure (MTBF) predication calculation estimates are as follows:

Contact factory for other environment, temperature or configuration prediction calculation requests.

The NIU2A packing materials were designed specifically for transport protection of the NIU2A. When receiving the shipment container, inspect packaging for any evidence of physical damage. If damage is evident, it is recommended that the carrier agent is present when opening the shipping container. It is further recommended that all packing material is retained in the event the NIU2A needs to be shipped elsewhere.

An identification label, indicating part number, unique serial number, and Ethernet PHY MACs / default IP address(es) is affixed to the back of the system chassis.

Inspect the chassis and connectors to ensure that they were not damaged during transit.

The NIU2A is a rugged, aluminum, conduction-cooled system. It must be mounted to a cold plate. The system thermal management design considerations should ensure that the chassis thermal interface (NIU2A bottom surface) does not exceed 71°C. Mounting holes are provided on the chassis bottom housing flanges (as depicted). See the outline drawing below.

Chassis ground point threaded insert location is on the connector side of the NIU2A as shown.

Generic pinout. See module I/O section or contact factory regarding any special module I/O configuration.

Primary SBC/host/mission computer communications interface to the NIU2A is via the Gig-E port(s). Full command/control/register data query is requested and sent as a TCP/IP or UDP type message to the NIU2A via NAI Ethernet protocol structure, i.e. the NIU2A receives a message command and replies accordingly. In addition to direct read/write function module register access, once initialized the protocol can also support multi-register block read/writes as well as generate interrupt driven output messages or timed interval data 'dump' messages.

For detailed supplement, please visit the NIU2A model page and refer to:

NAI Ethernet Interface for Generation 5 SBC and Embedded IO Boards Software Specification

The NIU2A is delivered as a tested unit. All operations have been verified. It is recommended that Power and Ethernet connections be made to verify operation of the function module(s) fitted within the NIU2A by making use of NAI’s “Embedded Soft Panel” (ESP), which can be utilized as a board/module level debugging tool (if the NIU2A function module(s) configuration supports). The example process shown below describes the use of NAI’s ESP Ethernet connectivity/exercising debug tool. Refer to the product web page software tab to download and access the latest ESP software package, including documentation, for the expected host operating system.

After applying appropriate power to the NIU2A, connect a Host computer (laptop or similar running e.g. Windows 7, Linux or other OS) and the ESP interface program application to either NIU2A Ethernet Port 1 or Port 2 (only for Dual Ethernet option). Type in the NIU’s default IP Address (e.g. 10.8.19.55 - see unit ID label for actual) and the screen below will display. The ESP is an interactive GUI application allowing full access, query and operation of the module(s) function(s) configured in the NIU2A.

Note: Ethernet port assignments and MAC address (factory default IP addresses are indicated on the system label). Please refer to the Configuration / Ordering information section of this document.

This screen shot shows that the “Board” is a NIU1A (NIU2A, etc.) and will interface over UDP. The particular IP address in this example is the default 192.168.1.6.

Additional operational windows will be dependent on the function modules installed. The ESP program, once communication has been established, can query the board (NIU2A) function module(s) configuration, and provides accessible function specific operating windows to allow full exercising of all the function programmable variables. Refer to the product web page software tab to download and access the latest ESP software package, including documentation, for the expected host operating system.

The table below lists the BAR used for access to the motherboard and module registers. The second BAR is used internally for motherboard and module firmware updates. The other cPCI/PCIe BARs not listed are not used.

The memory map for the modules are dependent on the types of modules on the board and the order in which the modules are installed on the board as well as the firmware installed on the motherboard. The function modules are enumerated allowing for dynamic memory space allocation and therefore the “start” address of the module function register area is factory pre-defined (and read from) the Module Address register.

Motherboard Registers:

Read/Write access to the motherboard registers starts with the base address for the board and then the motherboard base offset address.

For example, to address Module Slot 1 Start Address register (i.e. register address = 0x0400):

Module Registers:

Read/Write access to the Function module’s registers start with the base address of the board. Add the “content” for the Module Start Address and then, add the specific module function register offset.

For example, to address an appropriate/specific function module with a register offset:

The Module Slot Address, Module Slot Size and Module Slot ID provide information about the modules detected on the board.

The registers identified in this section provide information about the board’s hardware.

The registers in this section provide information on the revision of the firmware installed on the motherboard.

The registers in this provide motherboard temperature measurement information.

The registers in this section provide a summary of motherboard temperature sensors and their corresponding bits. Additionally, this section provides an overview of the registers allocated to those sensors, which are used to monitor current/minimum/maximum temperature readings, upper & lower critical/warning temperature thresholds, and whether or not a programmed temperature threshold has been exceeded.

These registers are only available on Xilinx Generation 5 platforms, and are periodically populated by the motherboard core application, which only runs in Petalinux and BareMetal. For other operating systems, refer to the naibrd Software Support Kit (SSK) naibsp_system_Monitor_Temperature_Get() routine to manually retrieve the temperature (NOTE: this feature is typically utilized for development/factory use only; contact the factory for additional details on potential use, if required).

The registers in this section provide information about the Ethernet Configuration for the two ports on the board.

Important: Regardless if the board is configured for one or two Ethernet ports, the second IP address cannot be on the same Subnet as the First IP Address. The table below provides examples of valid and invalid IP Addresses and Subnet Mask Addresses.

When interrupts are enabled, the interrupt vector associated with the specific interrupt can be programmed (typically with a unique number/identifier) such that it can be utilized in the Interrupt Service Routine (ISR) to identify the type of interrupt. When an interrupt occurs, the contents of the Interrupt Vector registers is reported as part of the interrupt mechanism. In addition to specifying the interrupt vector, the interrupt can be directed (“steered”) to the native bus or to the application running on the onboard ARM processor.

Function: Provides the ability to command individual Modules to Reset, Power-down, or Power-up.

Type: unsigned binary word (32-bit)

Data Range: 0x0000 0000 to 0xFFFF FFFF

Read/Write: R/W

Operational Settings: The Module Control Commands registers provide the ability to request individual Modules to perform one of the following functions – Reset, Power-down, Power-up. Only one command can be requested at a time per Module. For example, one can’t request a Reset and a Power-down at the same time for the same Module. Once the command is recognized and handled, the bit will be cleared.

There is one Control Command Request register per Module. Each register is Bit-mapped as shown in the table below:

Function: Registers reserved as scratch pad for customer use.

Type: unsigned binary word (32-bit)

Data Range: 0x0000 0000 to 0xFFFF FFFF

Read/Write: R/W

Operational Settings: This area in memory is reserved for customer use.

Temperature Readings

Higher Precision Temperature Readings

Module Communication Status

Module BIT Status

The interface uses a specific message framework for all commands and responses. All messages begin with a Preamble code and end with a Postamble code. The message framework is shown below.

Notes

The interface provides two main addressing areas: Onboard and Off-board.

Onboard addressing refers to accessing resources located on the board that is implementing the operation interface (including its modules).

Off-board addressing refers to accessing resources located on another board reachable via VME, PCI, or other bus. Off-board addressing requires a Master/Slave configuration.

The user must always specify if a particular address is Onboard or Off-board. See the command descriptions for the onboard and off-board flags.

Within a particular board (Onboard or Off-board), the address space is broken up into two areas: Motherboard Common Address Space and Module Address Space. All addresses are 32-bit.

Motherboard Common Address Space starts at 0x00000000 and ends at 0x00004000. This is a 4Kx32-bit address space (16 kbytes).

Module Address Space starts at 0x00004000. Module addressing is dynamically configured at startup. NAI boards support between 1 and 6 modules. The minimum module address space size is 4Kx32 (16 kbytes) and module sizes are always a multiple of 4Kx32.

Module addressing is dynamic and cumulative. The first detected module (starting with Slot 1) is given an address of 0x00004000. The 2nd detected Module is given an address of:

First_Detected_Module_Address + First_Detected_Module_Size

If no module is detected in a module slot, that slot is not given an address. Therefore, if the first detected Module is in Slot 2, then that module address will be 0x00004000. If the next detected module is in Slot 4, then the address of that Module will be:

Second_Detected_Module_Address = First_Detected_Module_Address + First_Detected_Module_Size

If a 3rd Module is detected in Slot 6, then the address of that Module will be:

Third_Detected_Module_Address = Second_Detected_Module_Address + Second_Detected_Module_Size

Users can always retrieve the Module Addresses, Module Sizes and Module IDs from the fixed Motherboard Common address area. This data is set upon each board startup. While the Module Addressing is dynamic, the address where these addresses are stored is fixed. For example, to find the startup address of the module location in Slot 3, refer to the MB Common Address 0x00000408 from the Motherboard Common Addresses table that follows.