The interface supports Block reads and writes. A Block is a list of register addresses to be read or written in a single operation. The following Block commands are supported: - SetBlockConfig: Defines a Block Configuration - GetBlockConfig: Retrieves a Block Configuration - ClearBlockConfig: Clears a Block Configuration - ReadBlock: Reads registers defined in Block Configuration - WriteBlock: Writes registers defined in Block Configuration

A Block definition consists of the following fields: - BlockId (2-bytes) - Flags (2-bytes) - same definition as for ReadRegs/WriteRegs: - Bit 0 - Onboard/Offboard Addressing: 0-Onboard 1-Offboard - Bit 4 - 32-bit/16-bit Register Size: 0-32bit 1-16bit - Register Count (2-bytes): Number of Registers defined in Block - Register Addresses (Register Count) * (4-bytes): List of Register Addresses

Block commands differ from ReadRegs/WriteRegs commands because they allow for non-patterned multiple register reads or writes. In other words, the addresses can be in any order and not be defined by any particular pattern. All registers specified within a Block are bound by the same Flags settings. You can’t mix Onboard/Off-board addressing or 32-bit/16-bit register sizes.

Timer Driven Response (TDRs) provides a mechanism to execute a list of commands based on a timer event. This command type is also known as an UnPrompted Reply (UPR) command. These commands require the user to listen (asynchronously) for responses based on external events (timers or interrupts).

The TDR configuration is very similar to that of an Interrupt Driven Response (IDR); the only difference being the specification of the timer period instead of the interrupt vector for the IDR.

The following TDR commands are supported: - SetTDRConfig: Defines a TDR - GetTDRConfig: Retrieves a TDR definition - ClearTDRConfig: Clears a TDR definition - StartTDR: Starts the timer associated with the TDR - StopTDR: Stops the timer associated with the TDR

A TDR definition consists of the following fields: - TDR Id (2-bytes): Unique Id to reference TDR definition. Valid values are 1→16. - Response Protocol (2-bytes): Protocol to be used for responses. Valid values are: 0-TCP; 1-UDP - Response IP Address Length (2-bytes): Length of Response Address in bytes. Valid values are: 4 - IPv4 Address; 16 – IPv6 Address - Response Address (4 or 16-bytes): Destination IPv4 Address or IPv6 Address for responses - Response Port (2-bytes): Destination Port for responses - Period (2-bytes): Period in milliseconds between responses. Valid values are: 40-65535 - Command Count (2-bytes): Number of Commands to execute - Command 1 → Command N: Commands to execute. Valid Commands are: ReadRegs; WriteRegs; ReadBlock; WriteBlock

Commands contained in the command list follow the same message protocol as all other commands. Each command must contain the full Header, Payload, and Trailer fields. A maximum of 16 TDRs may be defined. A maximum of 4 Commands may be defined in a TDR.

Timer Driven Responses use SequenceNo’s to identify the TDR to which a particular response belongs. For normal (Command/Response) type commands the SequenceNo is provided by the user in the Command and then that value is returned to the user in the Response. For Unprompted Replay type commands (Timer Driven Responses-TDRs and Interrupt Driven Responses-IDRs) the SequenceNo value returned in the response is provided by the following formulas:

For TDRs: SequenceNo == 0x8000 | (uhTDRIndex << 10) | (uhCommandIndex << 6)

For IDRs: SequenceNo == 0xC000 | (uhIDRIndex << 10) | (uhCommandIndex << 6)

This provides the mechanism to identify the TDR or IDR for which an Un-prompted Replay is associated with.

Bit Assignments: - Bit 15: IDR Response - Bit 14: TDR Response - Bit 13-10: TDR/IDR Index (TDRIndex == TDRId – 1) or (IDRIndex == IDRId - 1) - Bit 9-6: CommandIndex (CommandIndex == CommandId – 1) - Bit 5-0: Reserved

Interrupt Driven Responses (IDRs) provide a mechanism to execute a list of commands based on an interrupt. This command type is known as an UnPrompted Reply (UPR) command. These commands require the user to listen (asynchronously) for responses based on external events (timers or interrupts).

The IDR configuration is very similar to that of a TDR; the only difference being the specification of the interrupt vector instead of the timer period for the TDR.

The following IDR commands are supported: - SetIDRConfig: Defines an IDR configuration - GetIDRConfig: Retrieves an IDR configuration - ClearIDRConfig: Clears an IDR configuration - EnableIDR: Enables the execution of associated commands on specified the interrupt - DisableIDR: Disables the execution of associated commands on specified the interrupt

An IDR configuration consists of the following fields: - IDR Id (2-bytes): Unique Id to reference IDR definition. Valid values are 1→16. - Response Protocol (2-bytes): Protocol to be used for responses. Valid values are: 0-TCP; 1-UDP - Response IP Address Length (2-bytes): Length of Response Address in bytes. Valid values are: 4 - IPv4 Address; 16 – IPv6 Address - Response Address (4 or 16-bytes): Destination IPv4 Address or IPv6 Address for responses - Response Port (2-bytes): Destination Port for responses - Vector (4-bytes): Valid values are 0x00000000→0xffffffff - Command Count (2-bytes): Number of Commands to execute - Command 1 → Command N: Commands to execute. Valid Commands are: ReadRegs; WriteRegs; ReadBlock; WriteBlock

Commands contained in the command list follow the same message protocol as all other commands. Each command must contain the full Header, Payload, and Trailer fields. A maximum of 16 IDRs may be defined. A maximum of 4 Commands may be defined in an IDR.

Interrupt Driven Responses use SequenceNo’s to identify the IDR to which a particular response belongs. For normal (Command/Response) type commands the SequenceNo is provided by the user in the Command and then that value is returned to the user in the Response. For Unprompted Replay type commands (Timer Driven Responses-TDRs and Interrupt Driven Responses-IDRs) the SequenceNo value returned in the response is provided by the following formulas:

For TDRs: SequenceNo == 0x8000 | (uhTDRIndex << 10) | (uhCommandIndex << 6)

For IDRs: SequenceNo == 0xC000 | (uhIDRIndex << 10) | (uhCommandIndex << 6)

This provides the mechanism to identify the TDR or IDR for which an Un-prompted Replay is associated with.

Bit Assignments: - Bit 15: IDR Response - Bit 14: TDR Response - Bit 13-10: TDR/IDR Index (TDRIndex == TDRId – 1) or (IDRIndex == IDRId - 1) - Bit 9-6: CommandIndex (CommandIndex == CommandId – 1) - Bit 5-0: Reserved

The interface supports a command Scripting functionality. This capability allows the user to assemble sequences of predefined interface commands that are stored in the operation memory of the Motherboard Ether Listener process. These command sequences (called Scripts) are available for the duration of the existing process only; they are not stored on the Motherboard. On reset, all Scripts are cleared from memory.

Up to 16 Scripts can be defined. Each Script is identified by its ScriptId (1→16).

Users can Write Scripts, Read Scripts, Execute Scripts, and Clear Scripts using the commands defined below:

Each Script can have a maximum of 100 Commands provided the summation of all command bytes combined does not exceed the maximum allowable bytes (1500) per Ethernet Message.

When a Script is executed all commands are executed serially in the exact sequence they are defined in the Script. Responses are generated for each command and are executed exactly as if the commands were sent individually.

The following Scripting commands are provided: - ClearScript: Clear the contents of the designated Script. - WriteScript: Write commands to the designated Script. - ReadScript: Read the commands from the designated Script. - ExecuteScript: Execute the designated Script. - SetSafeStateScriptId: A single ScriptId may be designated as the SafeState Script. The SafeState Script may be executed when SafeState criteria are met such as EtherOpMode Communication Timeout. Valid values are 1 → 16. Setting a value of 0 clears the SafeStateScriptId. - GetSafeStateScriptId: Retrieve the current SafeStateScriptId. A value of 0 indicates the current SafeStateScriptId is cleared.

The Scripting functionality currently supports the following commands: - NOP - ReadRegs - WriteRegs - ReadFIFO - MaskReg - MaskValueReg

Additional commands will be added in later interface revisions.

The interface supports ZBlock reads and writes. A ZBlock is a list of register addresses to be read or written in a single operation. ZBlocks are very similar to the Block commands defined earlier with a single difference: ZBlocks may contain Onboard and Offboard addresses in a single Block. Regular Blocks restrict you to all Onboard or all Offboard addresses. All other functionality is the same.

The following ZBlock commands are supported: - SetZBlockConfig: Defines a ZBlock Configuration - GetZBlockConfig: Retrieves a ZBlock Configuration - ClearZBlockConfig: Clears a ZBlock Configuration - ReadZBlock: Reads registers defined in ZBlock Configuration - WriteZBlock: Writes registers defined in ZBlock Configuration

A ZBlock definition consists of the following fields: - ZBlockId (2-bytes) - Flags (2-bytes) - same definition as for ReadRegs/WriteRegs: - Bit 4 - 32-bit/16-bit Register Size: 0-32bit 1-16bit - Register Count (2-bytes): Number of Registers defined in ZBlock - Register Address Flags (Register Count) * (2-bytes): List of Register Address Flags. Each 2-byte Flags corresponds to a single Register Address. Bit 0 - Onboard/Offboard Addressing: 0-Onboard 1-Offboard. - Register Addresses (Register Count) * (4-bytes): List of Register Addresses

ZBlock commands differ from ReadRegs/WriteRegs commands because they allow for non-patterned multiple register reads or writes. In other words, the addresses can be in any order and not be defined by any particular pattern. All registers specified within a ZBlock must be either 32-bit or 16-bit register sizes. You cannot mix 32-bit and 16-bit register commands in a single ZBlock.

The interface supports I2C reads and writes.

The following I2C commands are supported: - ReadI2CRaw: Reads registers over I2C - WriteI2CRaw: Writes registers over I2C

A I2C Raw Data definition consists of the following fields: - Response Data Length (2-bytes): Number of data bytes that will be returned by the command - I2C Command data Length: Number of data bytes in the I2C read command. - I2C Command: The I2C Addresses (command) - I2C Command data (I2C Command data Length bytes): The data that will be sent with the I2C read command

These commands are intended for Factory Test only and may not be available on all platforms.

The following System configuration commands are supported: - Get System Configuration: Reads the system configuration data (Card PCI / VME data such as Base Address size …​).

System configuration data definition consists of the following fields: - Card number (4 bytes - int32_t): The card index number. - Base Address (4 bytes - uint32_t): Base address of the card. - Size (4 bytes - uint32_t): The size of the card. - Lane (2 bytes - uint16_t): The PCIe Lane. - Bus (2 bytes - uint16_t): The PCI Bus. - Dev (2 bytes - uint16_t): The PCI Dev. - Func (2 bytes - uint16_t): The PCI Function. - DevId (2 bytes - uint16_t): The card PCI Device ID.

Error responses will return the error number via the TypeCode with a value between 0x8000 and 0x8FFF inclusive. The packet also contains an ASCII encoded message field which is not null terminated. The size of this message field can be determined by subtracting 10 from the Length field. For information about valid error codes refer to Response Type Codes.

An example string which may occur in the Message field is “ReadRegs – wrong number of bytes in payload”. This string would occur with error code 0x8006 – Invalid Payload Size.

North Atlantic Industries (NAI) is a leading independent supplier of Embedded I/O Boards, Single Board Computers, Rugged Power Supplies, Embedded Systems, and Motion Simulation and Measurement Instruments for the Military, Aerospace, and Industrial Industries. We accelerate our clients' time-to-mission with a unique approach based on a Custom-on-Standard Architecture™ (COSA®) that delivers the best of both worlds: custom solutions from standard COTS components.

We have built a reputation by listening to our customers, understanding their needs, and designing, testing, and delivering board and system-level products for their most demanding air, land, and sea requirements. If you are experiencing any problems with our products, we urge you to contact us as soon as possible.

Please visit us at: www.naii.com or select one of the following for immediate assistance: