The Nano Interface Unit (NIU1A) 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 NIU1A can be delivered with ARM® Cortex®-A9 access support for standalone or other processor related capability.

The NIU1A 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 NIU1A 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 (contact factory for availability).

*2 - Utilizing proper shielded cables and system practices.

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

The NIU1A packing materials were designed specifically for transport protection of the NIU1A. 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 NIU1A 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 NIU1A 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 (NIU1A 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 NIU1A as shown.

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

Front Panel LEDs indications

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

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

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.