(AFDX) (Avionics Ethernet)

of 419 Rockwell Collins, Inc. Proprietary Information

User's Manual for the V6 End System

CPN 815-7272-001 Rev A

Rockwell Collins, Inc. 400 Collins Rd. NE

Cedar Rapids, IA 52498

CAGEC 4V792

NAME ROLE APPROVAL

Prepared By: Robert H. Pulju Preparer N/A

Checked By: Nikki R. Hinton Software Control Library Electronic Approval in PDM

Approved By: Leigh A. Parker Engineering Electronic Approval in PDM

Approved By: Duane R. Cooley Software Quality Electronic Approval in PDM

NOTICE: The contents of this document are proprietary to Rockwell Collins, Inc. and shall not be disclosed, disseminated, copied, or used except for purposes expressly authorized in writing by Rockwell Collins, Inc.

NOTICE: The technical data in this document (or file) is controlled for export under the Export Administration Regulations (EAR), 15 CFR Parts 730-774. Violations of these export laws may be subject to fines and penalties under the Export Administration Act.

NOTICE: This document is a paper representation of the master data which is maintained in the Product Data Management (PDM) system.

NOTICE: The following software was used to produce this document: Microsoft Word XP

NOTICE: Copyright 2007 Rockwell Collins, Inc. All rights reserved.

User's Manual for the V6 End System 815-7272-001 Rev -

Page 2 of 435 Rockwell Collins, Inc. Proprietary Information

Revision History Ver Rev Date Originator Reason for Change -001 - 01-24-2007 Robert H. Pulju Initial Release -001 A 12-3-2007 Robert H. Pulju Updates with new errata



Table of Contents Revision History..........................................................................................................................................2

Table of Contents........................................................................................................................................3

List of Figures .............................................................................................................................................7

List of Tables .............................................................................................................................................10

1. Introduction ......................................................................................................................................11 1.1 Scope .........................................................................................................................................11 1.2 Applicability ................................................................................................................................11

2. Technical Overview .........................................................................................................................12 2.1 Common Data Network Overview..............................................................................................12 2.2 Logical Host Interface ................................................................................................................12 2.2.1 COM Ports ............................................................................................................................13 2.2.1.1 Transmit COM Ports ........................................................................................................13 2.2.1.1.1 AFDX and SAP Ports .................................................................................................13 2.2.1.2 Receive COM Ports .........................................................................................................14 2.2.1.2.1 Sampling Ports ...........................................................................................................15 2.2.1.2.2 Queuing Ports.............................................................................................................16 2.2.1.2.3 AFDX and SAP Ports .................................................................................................16 2.2.2 Types of Buffers....................................................................................................................17 2.2.2.1 Buffering Modes...............................................................................................................17 2.2.2.2 Buffer Types ....................................................................................................................17 2.2.2.2.1 Tx SubVL Buffers .......................................................................................................18 2.2.2.2.2 Rx Port Buffers ...........................................................................................................19 2.2.2.2.3 Rx VL Buffer ...............................................................................................................19 2.2.2.2.4 Rx ES Buffer ...............................................................................................................19 2.2.2.3 Buffer Sizing ....................................................................................................................19 2.2.2.3.1 Transmit Buffers .........................................................................................................20 2.2.2.3.2 Receive Queuing Buffers............................................................................................20 2.2.2.3.3 Receive Sampling Buffers ..........................................................................................21 2.2.3 Transmit Message Interface .................................................................................................22 2.2.3.1 Message Structure...........................................................................................................22 2.2.3.1.1 IP Access Message ....................................................................................................23 2.2.3.1.2 MAC Access Message ...............................................................................................23 2.2.3.1.3 Message Flags ...........................................................................................................24 2.2.3.2 Process............................................................................................................................25 2.2.3.3 Errors ...............................................................................................................................27 2.2.4 Receive Message Interface ..................................................................................................28 2.2.4.1 Message Structure...........................................................................................................28 2.2.4.1.1 EDE Access Message ................................................................................................28 2.2.4.1.2 IP Access Message ....................................................................................................29 2.2.4.1.3 MAC Access Message ...............................................................................................30 2.2.4.1.4 Receive Flags Field ....................................................................................................30 2.2.4.2 Receive Message Transfer..............................................................................................32 2.2.4.2.1 Queuing Buffers..........................................................................................................32 2.2.4.2.2 Sampling Buffers ........................................................................................................34 2.2.4.3 Process............................................................................................................................35



2.2.4.4 Errors ...............................................................................................................................36 2.3 Ethernet Interface.......................................................................................................................36 2.3.1 Virtual Links...........................................................................................................................36 2.3.2 Traffic Scheduling Overview .................................................................................................37 2.3.2.1 Transmission Tables........................................................................................................38 2.3.3 SubVLs..................................................................................................................................43 2.3.4 Message Construction / Parsing...........................................................................................45 2.3.4.1 Encapsulation of Protocol Fields .....................................................................................45 2.3.4.2 MAC / VL..........................................................................................................................46 2.3.4.3 IP Header.........................................................................................................................47 2.3.4.3.1 IP Fragmentation / Reassembly .................................................................................49 2.3.4.4 UDP Header ....................................................................................................................50 2.3.4.5 EDE..................................................................................................................................50 2.3.4.5.1 EDE Time Agent.........................................................................................................51 2.3.4.6 Integrity Checking / Redundancy Management...............................................................53 2.3.4.6.1 AFDX Integrity Checking ............................................................................................53 2.3.4.6.2 AFDX Redundancy Management...............................................................................54 2.3.4.6.3 EDE Integrity Checking ..............................................................................................56 2.3.4.6.4 EDE Redundancy Management.................................................................................61 2.4 Modes of Operation....................................................................................................................62 2.4.1 INIT .......................................................................................................................................63 2.4.2 CONF....................................................................................................................................65 2.4.3 OPS.......................................................................................................................................65 2.4.4 TEST.....................................................................................................................................65 2.4.5 POST ....................................................................................................................................65 2.4.6 QUIET ...................................................................................................................................66 2.5 Configuring the Packet Engine...................................................................................................67 2.5.1 Board Configuration ..............................................................................................................67 2.5.1.1 Programming and Erasing...............................................................................................67 2.5.2 User Configuration ................................................................................................................67 2.5.2.1 Erasing a Configuration Table .........................................................................................68 2.5.2.2 Programming a Configuration Table................................................................................68 2.5.2.3 Performing a Configuration..............................................................................................68

3. Packet Engine 3 ASIC Overview.....................................................................................................70 3.1 External Physical Characteristics...............................................................................................71 3.1.1 Power / Ground.....................................................................................................................71 3.1.2 PCI Interface .........................................................................................................................72 3.1.2.1 PCI Bus Discovery...........................................................................................................72 3.1.2.1.1 PCI Bus Enumeration .................................................................................................72 3.1.2.1.2 PCI Device Address Space Configuration..................................................................74 3.1.2.2 PCI Timing Diagrams.......................................................................................................75 3.1.3 Buffer Memory Interface .......................................................................................................76 3.1.3.1 Buffer Memory Write Timing ............................................................................................78 3.1.3.2 Buffer Memory Read Timing............................................................................................80 3.1.4 PHY Interface........................................................................................................................81 3.1.4.1 RMII .................................................................................................................................81 3.1.4.1.1 RMII Transmit Timing at 100 Mbit ..............................................................................81 3.1.4.1.2 RMII Transmit Timing at 10 Mbit ................................................................................82 3.1.4.1.3 RMII Receive Timing at 100 Mbit ...............................................................................83 3.1.4.1.4 RMII Receive Timing at 10 Mbit .................................................................................83 3.1.4.2 Management Data Input/Output (MDIO) .........................................................................84 3.1.4.2.1 MDIO timing at 12.5 MHz ...........................................................................................84 3.1.4.2.2 MDIO timing at 5 MHz ................................................................................................85



3.1.4.2.3 MDIO timing at 2.5 MHz .............................................................................................86 3.1.5 SPI Interface .........................................................................................................................87 3.1.5.1 Serial PROM Interface Timing Diagrams ........................................................................87 3.1.5.1.1 Serial Output Timing...................................................................................................87 3.1.5.1.2 Serial Input Timing......................................................................................................88 3.1.6 Clock Interface ......................................................................................................................89 3.1.7 Sync Interface .......................................................................................................................89

4. Software Overview...........................................................................................................................91 4.1 Logical Architecture of the Driver ...............................................................................................91 4.1.1 Configuration API Functions .................................................................................................92 4.1.2 Application API Functions .....................................................................................................92 4.1.3 Management API Functions..................................................................................................93 4.2 Physical Structure of the Driver..................................................................................................93

5. Performance and Timing.................................................................................................................95 5.1 Host Performance Analysis........................................................................................................95 5.1.1 Committed Performance Analysis Timings...........................................................................95 5.2 EDE Performance Variables ......................................................................................................96

Appendix A Driver API Description....................................................................................................97 A.1 Directory: api\application\src\ .....................................................................................................97 A.2 Directory: api\config\src\...........................................................................................................105 A.3 Directory: api\init\src\................................................................................................................106 A.4 Directory: api\management\src\ ...............................................................................................106 A.5 Directory: api\mib\src\ ..............................................................................................................119 A.6 Directory: api\test\src\ ..............................................................................................................120 A.7 Directory: bite\bite_util\src\.......................................................................................................124 A.8 Directory: bite\post_mode\src\ .................................................................................................124 A.9 Directory: bite\test_mode\src\ ..................................................................................................125 A.10 Directory: program_specific\src\...............................................................................................130

Appendix B Hardware / Software Interface Description ................................................................133 B.1 PCI Configuration Space..........................................................................................................134 B.2 Transmit Buffer Window...........................................................................................................159 B.3 Receive Buffer Window............................................................................................................163 B.4 BAR3 Address Space ..............................................................................................................165 B.5 BAR4 Address Space ..............................................................................................................309

Appendix C Configuration Binary Descriptions .............................................................................313 C.1 Configuration Table Checkbits .................................................................................................314 C.2 Board Configuration Table (BC)...............................................................................................316 C.3 Network Configuration Table....................................................................................................347

Appendix D End System Requirements Allocated to the Host .....................................................378

Appendix E Errata..............................................................................................................................412 E.1 CDN00003487 RBM MIB Vector is reversed........................................................................412 E.2 CDN00005343 BAR3 Address Space Wraps Around ..........................................................412 E.3 CDN00006372 Redundancy Management Sequence Number not updated with IP-Level Failure.................................................................................................................................................412 E.4 CDN00006688 IP Reassembly Fails when Attempting to use Frames from Alternate LANs after first frame is discarded ...............................................................................................................413 E.5 CDN00008518 Read/Write Contention in REPC Table........................................................413



E.6 CDN00008538 Frame discarded when SEU detected on RCPL table.................................414 E.7 CDN00008724 RERPRX/TX and REVC memory tables do not initialize last memory location 414 E.8 CDN00008796 Timing Issue in RCPL Search Block ............................................................415 E.9 CDN00008810 IP Length Field invalid when MAC CRC is disabled ....................................416 E.10 CDN00009255 Tx EDE Fragmentation does not result in proper AFDX Frames with certain MTUs 416 E.11 CDN00009266 PCI BAR3 Read State Machine Ready Error...............................................417 E.12 CDN00009287 O_V2_SIG_TOUT read from previously discarded message......................417 E.13 CDN00009398 Fragment discards are not counted per requirements.................................418 E.14 CDN00009426 PCI Wait States not handled properly..........................................................418 E.15 CDN00009967 DCA flag bit may be captured incorrectly in 0 byte EDE messages............419 E.16 CDN00010589 Rx MAC hangs up if cross side frame accept is out of sync by 6 clocks.....419 E.17 CDN00010867 RBA is cleared when queue not empty........................................................420 E.18 CDN00010869 Asynchronous Interfaces in Control/Status block need to be double-clocked 420 E.19 CDN00011200 50MHz BIST not functional ..........................................................................420 E.20 CDN00011250 Discard of non-configured UDP or TCP First Fragment mis-reported in MIB 421 E.21 CDN00011323 Reassemblies not discarded for out of order frames ...................................421 E.22 CDN00011512 Config Space Write to the SID Register is mapped to ETM Register..........422 E.23 CDN00011568 Receive Messages fail wraparound for maximum installed RAM................422 E.24 CDN00013600 RM Accept MIB does not increment ............................................................423 E.25 CDN00013726 Malformed EDE Packet is Accepted when all EDE Validations are Disabled 423 E.26 CDN00013730 Nuisance Buffer Overflows Occur on EDE Ports with RM Enabled.............424 E.27 CDN00013734 MDIO Logic Timing limits PHY Compatibility ...............................................424

Appendix F Acronym List .................................................................................................................435



List of Figures Figure 1: COM Port Overview.....................................................................................................................13

Figure 2: Transmit Port Types ....................................................................................................................14

Figure 3: Sampling Port Operation .............................................................................................................15

Figure 4: Queuing Port Operation...............................................................................................................16

Figure 5: Receive Buffer Types ..................................................................................................................18

Figure 6: SubVL Buffering...........................................................................................................................20

Figure 7: Queuing Port Buffering ................................................................................................................21

Figure 8: Sampling Port Operation .............................................................................................................22

Figure 9: Transmit IP Access Message ......................................................................................................23

Figure 10: Transmit MAC Access Message................................................................................................24

Figure 11: Transmit Message Flags Field...................................................................................................24

Figure 12: Receive EDE Access Message .................................................................................................29

Figure 13: Receive IP Access Message .....................................................................................................30

Figure 14: Receive MAC Access Message.................................................................................................30

Figure 15: Receive Message Flags ............................................................................................................31

Figure 16: Queuing Port Buffer Operation ..................................................................................................33

Figure 17: Sampling Port Buffer Operation.................................................................................................34

Figure 18 End System ASIC Logical Operation..........................................................................................38

Figure 19: Ports, SubVLs, and VLs.............................................................................................................44

Figure 20: VL Servicing SubVLs .................................................................................................................45

Figure 21: Encapsulation of User Data .......................................................................................................46

Figure 22: MAC Header Fields ...................................................................................................................46

Figure 23: IP Header Fields ........................................................................................................................47

Figure 24: Fragmentation and Reassembly................................................................................................49

Figure 25: UDP Header Fields....................................................................................................................50



Figure 26: EDE Protocol Fields...................................................................................................................51

Figure 27: Calculating the EDE CRCs ........................................................................................................51

Figure 28: EDE Time Agent State Logic .....................................................................................................52

Figure 29: Integrity Checking and Redundancy Management....................................................................53

Figure 30: AFDX Integrity Checking Flow Diagram ....................................................................................54

Figure 31: AFDX Redundancy Management Flow Diagram.......................................................................55

Figure 32: EDE Integrity Checking Flow Diagram ......................................................................................56

Figure 33: EDE Ordinal Check Flow Diagram ............................................................................................57

Figure 34: EDE Age Check Flow Diagram..................................................................................................58

Figure 35: IC Flow Chart and Health Updates............................................................................................59

Figure 36: Health Updates Diagram ...........................................................................................................60

Figure 37: EDE Redundancy Management Flow Diagram.........................................................................61

Figure 38: Mode Change Diagram..............................................................................................................63

Figure 39: Initialization Timeline .................................................................................................................64

Figure 40: Programming a Configuration....................................................................................................68

Figure 41: Performing a Configuration........................................................................................................69

Figure 42: Packet Engine Component Block Diagram ...............................................................................70

Figure 43: Packet Engine Package Specification ......................................................................................71

Figure 44: PCI Timing .................................................................................................................................75

Figure 45: Buffer Memory Write Timing ......................................................................................................78

Figure 46: Buffer Memory Read Timing......................................................................................................80

Figure 47: RMII Transmit Timing at 100 Mbit..............................................................................................81

Figure 48: RMII Transmit Timing at 10 Mbit................................................................................................82

Figure 49: RMII Receive Timing at 100 Mbit...............................................................................................83

Figure 50: RMII Receive Timing at 10 Mbit.................................................................................................83

Figure 51: MDIO timing at 12.5 MHz ..........................................................................................................84

Figure 52: MDIO timing at 5 MHz ...............................................................................................................85



Figure 53: MDIO timing at 2.5 MHz ............................................................................................................86

Figure 54: Serial Timing..............................................................................................................................87

Figure 55: Serial Input Timing.....................................................................................................................89

Figure 56: Sync Timing ...............................................................................................................................90

Figure 57: End System Device Driver Integration.......................................................................................91

Figure 58: Logical Architecture of the Driver Software ...............................................................................91



List of Tables Table 1: Usage of Transmit IP Access Message Fields .............................................................................23

Table 2: Transmit Message Flags and Message Types .............................................................................25

Table 3: Receive Flags Bits ........................................................................................................................31

Table 4: Parsing Receive Message Headers..............................................................................................32

Table 5: IP Header Values in Tx and Rx.....................................................................................................48

Table 6: Health Updates .............................................................................................................................59

Table 7: PROM Load and Configuration Times..........................................................................................65

Table 8: PCI Address Space Configuration ................................................................................................74

Table 9: PCI Timing Parameter Table ........................................................................................................75

Table 10: Buffer Memory Write Parameter Table .......................................................................................78

Table 11: Buffer Memory Read Parameter Table.......................................................................................80

Table 12: RMII Transmit Timing Parameter Table at 100 Mbit...................................................................81

Table 13: RMII Transmit Timing Parameter Table at 10 Mbit.....................................................................82

Table 14: RMII Receive Timing Parameter Table at 100 Mbit....................................................................83

Table 15: RMII Receive Timing Parameter Table at 10 Mbit......................................................................83

Table 16: MDIO timing Parameter Table at 12.5 MHz................................................................................84

Table 17: MDIO timing Parameter Table at 5 MHz.....................................................................................85

Table 18: MDIO timing Parameter Table at 2.5 MHz..................................................................................86

Table 19: Serial Timing Parameter Table ...................................................................................................87

Table 20: Serial Input Timing Parameter Table ..........................................................................................89

Table 21: Sync Timing Parameter Table ....................................................................................................90

Table 22 PCI Transmit Messages Worst-Case Timing - T is one Clock Period at 33MHz ......................95

Table 23 PCI Receive Messages Worst-Case Timing - T is one Clock Period at 33MHz .......................95



1. Introduction 1.1 Scope This document is intended to provide technical information regarding the Packet Engine 3 ASIC to users of the Rockwell Collins End System solution. This document is not intended to provide requirements traceability.

The appendices of this document provide further resource data including software descriptions, hardware-software interface descriptions, configuration binary descriptions, and requirements of a host utilizing the Packet Engine 3 ASIC.

1.2 Applicability This issue of the End System Users Manual is applicable to the Packet Engine 3 (V6) version of the End System.



2. Technical Overview The Version 6 End System is an ARINC 664 compatible device specifically designed for the Common Data Network. The architecture of the End System includes the Packet Engine 3 ASIC, driver software used to interface with the ASIC hardware, and the ESBIN configuration tool which is used to configure the Packet Engine and the driver software for operation.

This section describes the system level concepts surrounding the V6 End System. Section 2.1 discusses an overview of the Common Data Network and the End Systems responsibilities for LRU intercommunication across the bus. Section 2.2 discusses the concepts surrounding the logical host interface to the End System (including the Packet Engine ASIC). Section 2.3 discusses the logical interface of the End System to the network. This includes packaging and processing of messages as well as the management of messages across redundant network interfaces. Section 2.4 discusses the functional modes of the End System and the proper sequencing of those modes during power-up or reset. Section 2.5 discusses the process and timing to configure the Packet Engine ASIC and the driver software.

2.1 Common Data Network Overview The Common Data Network (CDN) is a statically configured Ethernet network based on an Aircraft Data Network as described in ARINC 664, Part 7.

Each end system (or node) on the network is statically configured for the type and addressing of its network data as well as for the type of logical link it uses when attached to the network. The end system may be statically configured for 100BaseT or 10BaseT Ethernet traffic and is always configured for full-duplex operation. Since the end system is statically configured, it does not perform auto-negotiation for either of these features. Usage of COTS devices that perform auto-negotiation may not result in the behavior that is expected.

The Rockwell Collins V6 End System solution allows a host to be interoperable on the Common Data Network. The Rockwell Collins V6 End System solution consists of a Packet Engine 3 ASIC, driver software, and the ESBIN binary configuration tool.

2.2 Logical Host Interface The host application software communicates across the Common Data Network to other hosted applications using End System Communication (COM) Ports. COM ports are mapped directly from one transmitting application to one or many receiving applications. When initiating a transmission or reception operation, the host application provides the End System with a COM Port Index. This COM Port Index is then used by the End System to transfer or retrieve the message and ensure that proper configuration of the port is maintained by the host application. Section 2.2.1 discusses the functionality of COM ports and the interface of the host application to the End System

Messages awaiting transmission to the Ethernet or retrieval from the host are stored into buffered RAM. Allocation of this buffer RAM to transmitting and receiving applications is done at configuration time, and is managed by the Packet Engine ASIC. Section 2.2.2 describes the different types of buffers available in the End System and the functionality associated with each one.

The driver software is responsible for the interaction between the host application and the Packet Engine. This message structure and process for these interactions is well defined and can be found in Section 2.2.3 (Transmit Message Interface) and Section 2.2.4 (Receive Message Interface).



2.2.1 COM Ports COM Ports are the logical interface between the host application and the processes using the End System. Hosted applications write and read messages from a COM port. A COM port has each of the following characteristics

May exist in transmit and receive May be Sampling or Queuing May be AFDX or SAP May hold messages up to 8KB large

Figure 1: COM Port Overview

2.2.1.1 Transmit COM Ports Transmit COM ports are used by the hosted application to transmit messages to other hosted applications on the Common Data Network. Transmit COM ports are all queuing ports. Messages are transmitted in the order that they are put into the queue.

2.2.1.1.1 AFDX and SAP Ports

COM Ports may be configured and accessed as AFDX COM ports or SAP ports. AFDX COM ports and SAP ports are differentiated by the addressing of the ports. Both AFDX COM ports and SAP ports have a configured association with a given Virtual Link. However, SAP ports do not have a configured association with a remote UDP/IP address, while AFDX COM ports do.

AFDX COM ports are strongly configured. In transmission, there is a well defined configured association between the port and the destination UDP/IP addressing of messages transmitted by the port. In transmission, the destination UDP/IP addressing of the messages on the port is defined at configuration time. In reception, the hosted application has no need to read the addressing of the remote transmitter. AFDX COM ports may be configured as a sampling port or a queuing port.



SAP ports are loosely configured. In transmission, there is not a configured association between the port and the remote addressing of the messages on the port. In transmit, the hosted application is required to provide the destination UDP/IP addressing for each message. In reception, the hosted application is expected to query the End System for the remote UDP/IP addressing of each received message.

SAP ports may be used to transmit non-UDP frames as well. When configured, SAP ports provide access to the top of the IP layer, bypassing UDP header generation by the End System. In this manner, the hosted application may send ICMP or TCP messages if desired.

MAC ports may also be configured on the End System for hosted application use. In the case of MAC ports, the hosted application must provide the entire frame including MAC header to the End System.

UDP Access MessageHost Provides UDP

Payload Data

IP Access MessageHost Provides IP

Payload Data

MAC Access MessageHost Provides Entire Frame

Host-NodeInterface

UDP

IP

MAC

SubVL Buffer

SAP(UDP)

AFDXCOM

SAP(IP) MAC

Figure 2: Transmit Port Types

Figure 2 shows the different types of transmit ports that exist in the End System. The stair-stepped line in the picture describes the host-node interface of the End System. The UDP, IP, and MAC access message formats and usage are described in Section 2.2.4.

2.2.1.2 Receive COM Ports Receive COM ports are used by the hosted application to receive messages from other hosted applications on the Common Data Network. Receive ports may be configured as sampling or queuing ports. There is no difference between a SAP port and AFDX COM port in reception. The hosted application may choose to access the message as a SAP or AFDX COM port by selecting the correct driver API to read the message.



2.2.1.2.1 Sampling Ports

Sampling ports exist in reception only. They provide the most recently received message to the hosted application. When messages arrive to a sampling port, and have been validated by the End System, the newly received message replaces the current message in the sampling port. Messages within a sampling port may be read without destroying the data within the port. This allows multiple applications to read the same sampling port without impacting each other.

21

Rx COM Port

CDN

1460730 146Rx COM Port

CDN

3

App730

730

Rx COM Port

730

4

Rx COM Port

CDN

730

5

Rx COM Port

CDN

960

960 523

6

App960

Rx COM Port

960

Figure 3: Sampling Port Operation

Figure 3 shows a number of messages being received by a sampling COM port and being read by an application:

1) A number of messages are received from the CDN to a sampling COM port.

2) After the messages are received and validated by the End System, the port contains the last message received, which in the diagram was labeled 730.

3) At that time, the application is able to receive message 730, which is retained in the COM port after the host reads it.

4) More messages are received from the CDN to the sampling COM port,

5) Once again, the COM port holds the last message received and validated by the End System, which in the diagram is labeled 960.

6) The application is then able to read the latest sample, which is retained in the COM port until overwritten by the network.

Sampling ports are not capable of IP reassembly, and therefore are limited to hold messages with 1471 bytes of user payload or less. If messages destined for a sampling port are larger than the configured



size of the port, then the port will signal that a port overflow occurred. In the case of a port overflow, the message that caused the overflow is discarded.

2.2.1.2.2 Queuing Ports

Queuing Ports provide messages to the hosted application in the order that they are received. When messages are received and validated by the End System, they are then stored at the end of the queue. Reading a message removes it from the queue. This means that queuing ports should not be shared by different applications sharing an End System, as either application may remove data from the port.

21

Rx COM Port

CDN

1460730 146Rx COM Port

CDN

730

146

1460

3

Rx COM Port

730

146

App1460

Figure 4: Queuing Port Operation

Figure 4 shows a number of messages being received by a queuing COM port and being read by an application:

1) A number of messages are received from the CDN to a queuing COM port.

2) After the messages are received and validated by the End System, the port contains all messages that have been received.

3) At that time, the application is able to read the messages from the queue. After the message is read by the application, the message is no longer available in the queue.

Queuing COM ports may hold messages with user payloads as large as 8192 bytes, and therefore are capable of IP reassembly. The number of messages that a queuing COM port can store is configurable. The amount of data that a queuing COM port can hold is also configurable. When a message arrives that would cause the buffer to hold too many messages or too much data, the port will signal a buffer overflow. In the case of a buffer overflow, the message that caused the buffer overflow (the most recently received message) is discarded.

2.2.1.2.3 AFDX and SAP Ports

The End System does not differentiate AFDX COM ports or SAP ports in reception. Section 2.2.4 describes the interface between the End System driver software and the Packet Engine ASIC. A hosted application may receive AFDX COM port messages using the getAfdxMsg API function. A hosted application may receive SAP port messages using the getSapUdpMsg API function.

The End System will return the following data from AFDX COM port messages to the hosted application:

o Message Data

o Rx Timestamp (in the Packet Engines clock domain)



o Message Flags

The End System will return the following data from SAP port messages to the hosted application:

o Message Data

o Rx Timestamp (in the Packet Engines clock domain)

o Message Flags

o Source IP Address

o Source UDP Port Number

o IP Protocol Value

o EDE Tx Timestamp (if the message was EDE wrapped)

o EDE Sequence Number (if the message was EDE wrapped)

o Note that EDE is described later in this document

2.2.2 Types of Buffers 2.2.2.1 Buffering Modes The End System can be configured for two different types of buffering modes: AFDX Compliant and AFDX Strict. The buffering mode of the End System is configured using ESBIN, and tells the End System what classifications of traffic it may process.

AFDX Strict mode is the buffering mode of the End System that is used when the End System is required to process AFDX frames with IP protocols. In AFDX Strict Mode, only Port Buffers and VL Buffers are allowed to be configured. Furthermore, VL Buffers are only allowed to buffer IP payloads.

AFDX Compliant mode is used when the End System is required to process non-AFDX frames in addition to AFDX frames. In AFDX Compliant mode, the End System will process all AFDX frames with UDP protocol into port buffers. AFDX frames with other protocols may be placed into VL buffers as configured by ESBIN. An End System Buffer (ES Buffer) may be configured to store any non-AFDX frames that are received by the End System.

Another configurable parameter of End System reception buffering is the parameter which controls buffering of Transmission Control Protocol (TCP) frames. Frames encapsulated by the TCP header may be buffered into Port Buffers or VL Buffers. It is suggested that End System configurations are written to only allow TCP buffering into VL buffers.

2.2.2.2 Buffer Types All messages presented to the End System for transmission are queued into SubVL buffers (as shown in Figure 2). SubVL buffers may be associated with any number of Tx COM ports. The association between Tx COM ports and SubVL buffers is provided to the End System upon configuration time. Up to 4 SubVL buffers may be configured for each transmit virtual link on the End System.



The End System implements three different types of buffers in reception: Port Buffers, VL Buffers, and an End System buffer. The user is allowed to configure up to 4096 different buffers comprised of these different types.

Figure 5: Receive Buffer Types

Figure 5 shows the different types of receive buffers that may be configured on the End System. The stair-stepped line in the picture describes the host-node interface (HNI) for the End System. The HNI line in the picture dictates the amount of header information that the host needs to control. For port buffers processing UDP frames, the End System will process the MAC, IP, and UDP headers. The End System will only process the IP header for other AFDX messages. Non-AFDX messages will only be queued by the End System, and will not be processed.

2.2.2.2.1 Tx SubVL Buffers

SubVL buffers are queuing buffers only. Data is provided into the SubVL by hosted applications. Data is stored into SubVL buffers by applications on a first-come, first-serve basis, which means that buffer availability to an application may be affected by the usage of that SubVL buffer by other applications. For this reason, sharing of SubVL buffers by applications needs to be carefully considered.

SubVL buffers are dequeued by the End System when a message on the SubVL buffer is transmitted. Since SubVLs are serviced by VLs, transmission of messages on a SubVL is regulated by the traffic shaping algorithms of the VL. SubVL buffers are serviced by VLs in a round robin order as data is available on each SubVL. For this reason, the SubVL is guaranteed at least one-fourth (1/4th) of the bandwidth available to the associated VL.

SubVL buffers need to be sized to hold the user payload of all messages that could be queued into the buffer at any given time. The SubVL buffers need to be sized to also include 16 bytes of overhead for each message that could be queued into the SubVL.



2.2.2.2.2 Rx Port Buffers

Port buffers are the most commonly used buffer in reception on the End System. A port buffer is configured to support a well defined set of destination addressing. Frames queued into port buffers must match the Virtual Link, IP destination address, UDP destination port number, and physical interface configured for the buffer. If a frame destined for a port buffer does not match all four criteria of any port buffer, then the frame is discarded.

Port buffers may be configured at an End System level to hold UDP messages only or to allow TCP messages as well. If TCP messages are stored in port buffers, the TCP header will be made available to the hosted application. The End System only processes the TCP header to read the destination port number of the incoming message. Messages derived from UDP datagrams will hold only the UDP payload of the message. Section 2.2.4 describes the receive message interface from the Packet Engine.

Port buffers may be configured for sampling or queuing functionality. They may also be configured to allow reception of IP-fragmented UDP datagrams.

In the case of EDE messages, the EDE Timestamp and EDE Sequence Number are available from the Packet Engine ASIC, and may be read by the hosted application.

2.2.2.2.3 Rx VL Buffer

Virtual Link (VL) buffers are used when AFDX messages arrive that can not be buffered into port buffers. This means that any non-UDP messages may be buffered into VL buffers. One VL buffer may be configured for each VL in the End System. That VL buffer holds all types of non-UDP frames received by the End System on that particular VL. On VLs that support EDE messages, a VL buffer may not be configured. Any attempted configuration of a VL buffer will result in an error message from ESBIN.

VL buffers only allow for queuing functionality. However, IP reassembly is not available to VL buffers. VL buffers may also be configured to filter out selective classes of frames. A VL buffer may be configured to accept / discard ICMP messages, TCP messages, other IP messages, or non-IP messages.

2.2.2.2.4 Rx ES Buffer

The End System (ES) Buffer is a single buffer that services the hosted application. The ES buffer may only be enabled in AFDX Compliant buffering mode, as the buffer only holds non-AFDX frames.

The ES buffer is also a queuing buffer only, and also does not allow for IP reassembly. Frames processed by the ES buffer contain the entire MAC message, and no IP or UDP processing is done on these frames.

The ES buffer is configurable to filter out certain messages based on MAC destination addressing. Frames with individual (unicast) MAC destination addresses, group (multicast) MAC destination addresses, and broadcast destination addresses may be selected for buffer filtering in the End System.

2.2.2.3 Buffer Sizing Allocation of the buffer memories of the End System is done by the ESBIN configuration program as specified by the input file. ESBIN allocates space for each Tx and Rx Buffer based on parameters fed through the input file. Buffers are logically partitioned for each port, and no ports buffer allocation may be impacted by other buffer allocations within the End System

Buffers are allocated in 64-bit words. Specifying a portion of the word will allocate the entire word



2.2.2.3.1 Transmit Buffers

Transmit buffers are sized directly by the configuration input file using the SubVL productions parameter. Setting to 8192 allocates 8192 bytes of buffer memory to the corresponding SubVL.

Message Data

Message Header

SubVL Buffer

Message Data

Message Header

Message Data

Message Header

Message Data

Message Header

Figure 6: SubVL Buffering

Figure 6 shows a message being stored into a SubVL buffer. As shown, SubVL buffers hold application data from a hosted application as well as the message header appended by the End System driver software. The message header in transmit is 16 bytes long and is described in Section 2.2.3.

If an application were to attempt to queue a message into a SubVL buffer that causes a buffer overflow, then that message will be discarded by the Packet Engine ASIC and the overflow will be indicated in the Transmit Message Status register.

2.2.2.3.2 Receive Queuing Buffers

In reception, queuing port buffers are sized indirectly by the configuration input file using the and parameters from either the End System Buffer production, the Virtual Link production, or the Rx COM Port production.

The parameter is used to allocate buffer spacing for message headers in reception. The parameter is used to allocate spacing for the message data. In the case of EDE messages, the EDE parameters from the messages are considered part of message data, and an additional overhead of 12 bytes per message needs to be considered. The End System requires 2 words (16 bytes) of allocated space for each message header. Due to message-level redundancy management, the End System requires allocation for each physical interface for the size of the parameter. Therefore, is set to 4 messages, and is set to 8192 bytes, then ESBIN will allocate 16448 bytes ((8192 bytes x 2) + (4 messages x 16 bytes)) of buffer memory to that queuing buffer.



A buffer will overflow if a message arrives that would overrun the message header allocation or the message data allocation of either interface. This means that even though twice the parameter is allocated to the port, effectively, the End System is not guaranteed to store message data equaling more than the parameter. That is, if the parameter is set to 8192 bytes, then the End System could store more than 8192 bytes of message data if accepted data is intermixed between each physical interface, but the hosted application is not guaranteed more than 8192 bytes in case the accepted data arrives from only one interface.

Message Data

Message Header

Queuing Port BufferMessage Header

Message Header

Message Data

Message Data

Message Header

Message Data

Figure 7: Queuing Port Buffering

Figure 7 shows a message being processed by the receiving End System and stored into a queuing port buffer. As shown, the compiled message header is stored in allocated message header spacing (in this case, is set to 4), while the message data is stored in buffer memory allocated for message data.

2.2.2.3.3 Receive Sampling Buffers

In reception, sampling port buffers are sized indirectly by the configuration input file using the parameter of the Receive COM Port production. ESBIN allocates 6 words of buffer memory for message headers and allocates six times the parameter for message data. This allocation is required due to the asynchronous nature of host read requests of the buffer and the Ethernet reception of data to the buffer. If a configuration input file has a parameter of 1000 bytes on a sampling port buffer, then ESBIN will allocate 6048 bytes ((1000 bytes x 6) + (3 headers x 16 bytes)) of buffer memory.



Message Header

Sampling Port BufferStale Message Header

Message Header

Message Header

Message Data Stale Message Data

Stale Message DataStale Message Data

Stale Message Data

Message Data

Message Data

Message Header

Message Data

Data being provided to host

Data being received to End

System

Figure 8: Sampling Port Operation

Figure 8 shows a message being received into a sampling port buffer while the buffer is being read by a hosted application. The message header and message data are stored in the port buffer, but can not overwrite the message being read by the hosted application. Furthermore, the newly received data can not be overwritten by incoming messages that have not been validated. Therefore, three message headers are required. Once the host has completed reading the message, the sampling port buffer will be updated to indicate the most current sample.

2.2.3 Transmit Message Interface The transmit message interface is the interface between the End System driver software and the Packet Engine ASIC used for transmitting application data on the CDN. It is important to understand this interface at a system level in order to understand the capabilities and limitations of the interface. The transmit message interface is defined by the message structure and the process used to transfer the message to the Packet Engine ASIC. The driver software also implements several optional features of the transmit message interface. These optional features are noted in the transmit message process section.

2.2.3.1 Message Structure There are two different types of messages used by the transmit message interface based on the type of message that is attempted to be sent. The IP Access Message and UDP Access Message both are characterized with 16 bytes message headers and are differentiated by the Packet Engine ASIC using the 8 bit flags field.

Both message structures require a SubVL index and a port index to be specified. The port index is specified by the hosted application to the End System driver software. The SubVL index is specified by the configuration of the End System device driver based on the port index passed by the hosted application.

Both message structures also require a message length to be specified. The message length is specified in bytes and is calculated by the driver software by adding 16 bytes to the length of the message data specified by the hosted application.



2.2.3.1.1 IP Access Message

The IP Access Message is used for transmitting EDE, UDP, and IP messages. The IP Access Message header is composed by the End System driver software and transmitted across the Packet Engine interface.

LengthSub VL #

FlagsPort Index

Dest IP Address

Dest Port #Protoco

lRsvd

User Payload

31 715 0

Figure 9: Transmit IP Access Message

Figure 9 shows the transmit IP Access Message composed by the End System driver software. The usage of these fields depends on the type of access requested by the hosted application. Table 1 specifies the usage of these fields by the driver software.

Table 1: Usage of Transmit IP Access Message Fields

Type of Message (from Hosted Application)

Destination IP Address

Destination UDP Port Number

Protocol

AFDX COM Port Set to 0 Set to 0 Set to 0

SAP (UDP) Port Specified by Host

Specified by Host

Set to 0x11

SAP (IP) Port Specified by Host

N/A Specified by Host

If the hosted application attempts to use a port in a way contrary to the configuration of the port, then the message attempted will be discarded by the Packet Engine. That is, if a port is configured for AFDX COM port usage and the host attempts to send a SAP message, then the Packet Engine will notice the mistake and discard the message. (The driver software enforces configuration as well, and will return an error in the case that the port is improperly used)

2.2.3.1.2 MAC Access Message

The MAC access message is used to transmit miscellaneous MAC messages on the Ethernet interface. In the case of MAC access, the host specifies the destination MAC address, the MAC Length/Type field,



and the user payload. The Packet Engine uses its source MAC address in the message and calculates the AFDX sequence number and MAC frame check sequence (FCS).

MAC messages are still associated with virtual links for transmit regulation, though the addressing of the frame is specified by the host.

LengthSub VL #

FlagsPort Index

Dest MAC Address

MAC L/T

User Payload

31 15 0

Figure 10: Transmit MAC Access Message

Figure 10 shows the format of the transmit MAC message header that is created by the driver software and transferred to the Packet Engine.

2.2.3.1.3 Message Flags

The Packet Engine differentiates the transmit IP access message and the transmit MAC access message using the flags field embedded into each message. The driver software composes the message flags based on the application programming interface (API) function that is called by the hosted application.

Figure 11 shows the format of the transmit message flags field in MSB to LSB order. The fields specified by dashes (-) indicate that they are not read by the Packet Engine and can be set to any value. The driver software sets these bits to zero.

Figure 11: Transmit Message Flags Field

The PV bit specifies if the Protocol field in the message is the value that the Packet Engine should use. This bit is only used for SAP (IP) ports, as AFDX COM ports and SAP (UDP) ports use a configured value for the IP protocol field.

The DPV bit specifies if the destination port number in the transmit message is valid. This bit is set to 1 to specify that the destination port number in the transmit message is the valid number. A value of 0 specifies that the configured destination port number should be used for this message.

The IPV bit specifies if the destination IP address in the transmit message is valid. A value of 1 indicates to the Packet Engine that that host believes the destination IP address in the transmit message is the



valid number. A value of 0 indicates that the configured destination IP address should be used for this message.

The FM bit specifies the format of the transmit access message. A value of 1 indicates to the Packet Engine that the transmit message is an IP access message. A value of 0 indicates to the Packet Engine that the transmit message is a MAC access message.

Table 2 shows the possible values for all of the bits in the transmit message flags field. As shown, many of the possible combinations of flags bits are invalid, and messages composed with those combinations of flags fields will be discarded by the Packet Engine.

Table 2: Transmit Message Flags and Message Types

PV IPV DPV FM Message Type

0 0 0 0 MAC Access Message

0 0 1 0 Invalid

0 1 0 0 Invalid

0 1 1 0 Invalid

1 0 0 0 Invalid

1 0 1 0 Invalid

1 1 0 0 Invalid

1 1 1 0 Invalid

0 0 0 1 AFDX COM Port

0 0 1 1 Invalid

0 1 0 1 Invalid

0 1 1 1 SAP (UDP) Port

1 0 0 1 Invalid

1 0 1 1 Invalid

1 1 0 1 SAP (IP) Port

1 1 1 1 Invalid

2.2.3.2 Process The process for transmitting a message to the End System is described below. There are several parts of the process that may be removed depending on the environment of the End System driver software. That is, if MCDC coverage is a large concern, and the integrator can ensure that a hosted application is not



going to call the wrong API function, then checks for SAP usage or COM port usage or ports may be removed from the driver software.

Errors introduced by the hosted application or by misuse of the Packet Engine are reported back to the hosted application through return parameters.

1. Check for correct usage of configured port The driver software checks to ensure that the configuration of the port matches the hosted application usage of the port. That is, if the host calls PutAfdxMsg for a specific buffer, the driver software will ensure that the buffer specified is configured for AFDX COM port access. If the buffer specified does not match the API function specified by the hosted application, then the driver software will report an error to the hosted application. This is an optional software check that may be removed by the software integrator if the environment does not require this check.

2. Check for EDE_INHIBITED The EDE protocol requires that any messages destined for ports configured for EDE are inhibited for transmission until the hosted LRU/LRM has received certain EDE protocol packets from the network time manager (or until a certain timeout has occurred). If a hosted application attempts to transmit a message before EDE_INHIBITED is cleared, then the driver software shall report to the user that the message was discarded due to this reason. This is NOT an optional software check, and must be retained in the API functions by the software integrator.

3. Check to ensure data length is in valid range The driver software ensures that the length of the user data is within the valid range. The minimum user payload size that can be transmitted is 1 byte. The maximum user payload size that can be transmitted varies upon the type of message being transmitted. For non-EDE messages, the user payload may be as long as 8192 bytes. For EDE messages, the user payload can not exceed 8180 bytes. In the case that the user attempts to send a message that is too large, the driver software will report an error to the hosted application. This is an optional software check done to ensure that the hosted application does not violate interoperability requirements. If the hosted environment does not require this check, it may be removed by the software integrator. However, removal of this check is not recommended.

4. Check transmit buffer availability The driver software checks the transmit buffer availability before transferring the message to the Packet Engine. If the transmit buffer availability for the associated SubVL is not set, then the driver software will discard the message and report an error to the hosted application. This is an optional software check done to mitigate buffer overrun. In some systems, the Maximum Message Size is much larger than the nominal message size, and therefore, this check may throw away messages that would otherwise pass. If this check is disabled, then a check should be placed after Transmit Lf to ensure the message was correctly transmitted.

5. Compose Message Header



The driver software composes the message header based on the API function called as described in section 2.2.3.1.

6. Disable Interrupts The driver software disables interrupts around the transferring of the message to the Packet Engine. This is done to ensure partition safe operation of the End System. The code for this function is located in the project specific section of the driver software. For further information about project specific functions refer to section 0 This is an optional part of software that may be removed by the software integrator. This is only recommended for single thread systems.

7. Transfer Message Header and User Payload to the Transmit Buffer Window There is a difference here between the V5 and V6 transmit message process. In the V5, the driver software needed to respect initial latency (Li) between copying the header and the user payload. There is no need for any wait in V6. A software integrator may use a bursted transaction to copy the entire message to the Transmit Buffer Window of the Packet Engine.

8. Respect Final Latency (Lf) The driver software must respect the final latency before it may continue onward. This final latency allows the Packet Engine to manipulate its pointers and clear the BAR1 into buffer memory. The coding for this step is also found in the project specific area of the driver software to allow for specific implementation by the software integrator. The maximum Lf time is described in section 5.1of this document.

9. Check for buffer overflow The driver software checks for buffer overrun of the SubVL buffer. This may seem redundant with step 4. However, there are no checks by the Packet Engine or driver software to ensure that the specified user data from the hosted application is not larger than the maximum message size. Therefore, a user may be able to overflow the SubVL buffer, even in the case where transmit buffer availability is confirmed by the driver software. This step may be removed if the hosted application has no need to be cognizant of overflow or respond to overflow.

10. Restore Interrupts Once Lf has been met, the driver software restores interrupts before returning to the hosted application. This is an optional part of software that may be removed by the software integrator as long as the disable interrupts step is also removed.

2.2.3.3 Errors There are several errors that may be reported by the Packet Engine. These errors are useful for integration debugging of the HNI (host-node interface). These errors may be polled using the Packet Engine Management Information Base (MIB) counters.



Buffer Overflow. Buffer overrun occurs when the host processor attempts to queue a message into a SubVL buffer that is larger than the remaining size of the SubVL buffer. In the case of buffer overflow, the attempted message is discarded by the Packet Engine.

Message Overwrite Warning. The message overwrite warning is reported by the Packet Engine when the host processor transfers more data to the Packet Engine than was specified in the length field of the message header. In the case of an overwrite warning, the message is still accepted up to the size of the length field. The remaining data words transferred are discarded by the Packet Engine.

Message Underwrite Error. The message underwrite error is reported by the Packet Engine when the host processor attempts to start a new message transfer before the previous message transfer has completed. In the case of an underwrite error, the partially transferred message is aborted, and the newly transferred message is accepted.

2.2.4 Receive Message Interface The receive message interface is the interface between the End System driver software and the Packet Engine ASIC used when receiving data from the Ethernet to the hosted application. The receive message interface is defined by the message structure and the process used to poll data from the Packet Engine and transfer it into host memory. The driver software implements several optional features of this interface. These features are noted in the receive message process section.

In the receive message interface, buffers are locked and unlocked for reading by the host. Upon a message lock, the message is retrieved from buffer RAM and delivered to the Receive Buffer Window. Upon message unlock, the message is released from the receive buffer, and the next message is made ready for the host.

2.2.4.1 Message Structure The structure of the message transferred from the Packet Engine varies greatly by the type of message that is stored in the buffer. There are 3 types of message structures that need to be parsed by the driver software. The size of the message headers are also variable based on the type of message. The driver software may differentiate these different types of messages using the flags field.

There are some fields that are common to each access message type. The Rx Timestamp is a 48 bit counter field which indicates the receipt time of the message by the Packet Engine. The Length field denotes the length of the message (message header and user payload).

2.2.4.1.1 EDE Access Message

The EDE access message is compiled by the Packet Engine for all messages encoded in EDE. When processing the EDE message, the source message addressing as well as the EDE message fields are attached to the access message for transferal to the host.



EDE Timestamp

Length Protocol Flags

Source IP Address

Src UDP Port

User Payload

EDE Seq Number

31 715 0

EDE CRC-X EDE CRC-Y

Rx Timestamp (48 bits)

Figure 12: Receive EDE Access Message

When the driver software detects that the message from the Packet Engine is an EDE access message, it parses the message appropriately. Depending on the API function called, a number of fields may be returned to the host by reference, including the EDE timestamp and EDE sequence number. The EDE CRCs are available from the host domain. However, there are no API functions that deliver this data to the hosted application.

Since all EDE messages are UDP/IP messages, the EDE access message includes the source IP address and source UDP port number from the received message.

2.2.4.1.2 IP Access Message

The IP access message is used for UDP or IP frames that are not EDE wrapped. Since only UDP messages are completely processed by the End System, any other types of frames (ICMP, TCP, etc) will have their headers included as user payload to the end user.

For UDP messages, the source UDP port number and source IP address are provided in the IP access message. For TCP messages, the source TCP port number and source IP address are provided in the IP access message. For all other IP frames, only the source IP address is provided to the host domain.



Length Protocol Flags

Source IP Address

Src UDP Port

User Payload

31 715 0


Figure 13: Receive IP Access Message

2.2.4.1.3 MAC Access Message

The MAC access message is used for all non-IP messages. This includes non-IP AFDX messages stored in VL buffers and non-AFDX messages stored in the End System Buffer. As shown in Figure 14, the entire message is made available to the host domain. The driver software parses the MAC access message and provides all fields to the host using the GetGenericMsg API function.

MAC L/T

Length Rsvd Flags


Reserved

Reserved

MAC Destination Address (48 bits)

MAC Source Address (48 bits)

User Payload

31 715 0

Figure 14: Receive MAC Access Message

2.2.4.1.4 Receive Flags Field

Each access message type has a common flags field definition. The flags field contains 8 bits of data that provide the hosted application with more information about the received message. The hosted application may wish to use the bits in the flags field for added functionality. For example, if the



Additional Message bit is set, then the hosted application may wish to read the next message from the Packet Engine before moving on.

Figure 15: Receive Message Flags

The following table discusses the meaning of the bits in the flags field:

Table 3: Receive Flags Bits

Bit Name Value Meaning

0 Dual Channel Availability is not present on this buffer DCA (Dual-Channel

Availability) 1 Dual Channel Availability is present on this buffer

0 One of the following is true: - The message passed EDE Age Validation - Age Validation was disabled on this port - EDE is not enabled for messages on this port

AVU (Age Validation

Unknown) 1 Age Validation was enabled and the message age could not be

validated AND the access was an EDE access message

0 The specified buffer is not enabled BE (Buffer Enabled)

1 The specified buffer is enabled

0 The source UDP/TCP port value in the message header is invalid SPV (Source Port Valid)

1 The source UDP/TCP port value in the message header is valid

0 The message was received on Interface A PI (Physical Interface)

1 The message was received on Interface B

0 At time of message lock, buffer overflow has not occurred since last message read OF

(Port Overflow) 1 At time of message lock, a buffer overflow has occurred since last

message read

0 At time of message lock, there were no additional messages in the buffer AM

(Additional Message Available) 1 At time of message lock, there was at least one additional message in

the buffer



0 The message header format is either MAC access or IP Access EDE (EDE Encoded

Message) 1 The message header format is EDE access

Parsing a received message is done by reading several fields in the message header. The EDE bit in the flags field along with the protocol field is used to understand the message header type of an incoming message transfer. The following table denotes how messages are parsed by the protocol and flags fields.

Table 4: Parsing Receive Message Headers

Protocol Field

SPV value

EDE value

Src UDPPort

Src IP Address

Msg HdrFormat

Notes

0x11 1 1 Valid Valid EDE EDE message

0x11 1 0 Valid Valid IP UDP/IP message

0x6 1 0 Valid Valid IP TCP message

0x1 0 0 Invalid Valid IP ICMP message

0x0 Invalid Invalid Invalid Invalid MAC MAC message type

2.2.4.2 Receive Message Transfer All messages are received from the Packet Engine by reading the Receive Buffer Window. The Packet Engine implements a buffer locking/unlocking protocol to coordinate message transferal with the host software.

The Packet Engine 3 has also implemented the capability to read messages starting at an offset into the message. The driver software API has provided functionality for the hosted applications to read messages at a specified offset. The driver software provides the data offset into the message upon message lock.

The host may lock a buffer that is already locked. When the host decides to do this, the existing lock is replaced by the new lock, and the message is provided again to the receive buffer window.

Messages exist in buffers as 8 byte words. If the host reads beyond the end of the message, the host may read a remnant of garbage data (1 to 7 bytes) and then all zero data. This is the case when the message length is not evenly divided by zero.

2.2.4.2.1 Queuing Buffers

Queuing buffers use the locking and unlocking function to dequeue messages from their buffer queues. The following figure shows the locking and unlocking process for queuing ports.



1COM Port

Buffer

Msg #2 (cont)

Msg #1

Msg #2

Read Ptr

Rx Buffer Window

Msg #1Write Ptr

2COM Port

Buffer

Msg #2 (cont)

Msg #1

Msg #2

Read Ptr

Rx Buffer Window

Msg #1Write Ptr

Msg #3

3Rx Buffer Window

COM Port Buffer

Msg #2 (cont)

Msg #2

Read Ptr

Write Ptr

Msg #3

4Rx Buffer Window

COM Port Buffer

Msg #2 (cont)

Msg #2

Read Ptr

Write Ptr

Msg #3

Msg #2

Figure 16: Queuing Port Buffer Operation

1. The queuing port is locked for read by the hosted application. At that point, the oldest message in the queue (in this example, Msg #1) is provided to the Rx Buffer Window. The oldest message is denoted by the read pointer maintained by the Packet Engine.

2. While the message is locked, a new message (Msg #3) arrives from the Common Data Network. The message is stored at the end of the queue, which is denoted by the write pointer. After the message is queued, the Packet Engine moves the write pointer in order to prepare for another incoming message.

3. The queuing port is unlocked by the hosted application. Upon unlock, the message that was provided to the receive buffer window (Msg #1) is removed from the queuing buffer. The Packet Engine moves the read pointer to the beginning of the next message (Msg #2) in the buffer.

4. Upon the next queuing port lock, the next message in the queue (Msg #2) is provided to the receive buffer window.



2.2.4.2.2 Sampling Buffers

Sampling buffers use the locking and unlocking function to provide the latest message sample to the hosted application. The following figure shows the locking and unlocking process for sampling ports.

1COM Port

BufferRx Buffer Window

Msg #1

2COM Port

BufferRx Buffer Window

Msg #1

3Rx Buffer Window

COM Port Buffer

4Rx Buffer Window

COM Port Buffer

Msg #2

Stale Message

Current Message

Stale Message

Stale Message

Stale Message

Current Message

Stale Message

Current Message

New Message

Stale Message

Stale Message

Current Message

New Msg from CDN

Figure 17: Sampling Port Buffer Operation

1. The sampling buffer is locked for read by the hosted application. The most recent sample received by the buffer is provided to the receive buffer window.

2. While the port is locked, a new message arrives to the sampling port from the Common Data Network. The sampling buffer is updated to denote the most recent message is no longer the message provided to the receive buffer window. Note that the newly received message does not replace the message in the receive buffer window.

3. The sampling buffer is unlocked by the hosted application. Upon unlock, the message that was provided to the receive buffer window is labeled stale and the newly received message is noted as the latest message sample.

4. Upon the next sampling port lock, the most recent sample in the buffer is provided t

Documents

(AFDX) (Avionics Ethernet)