There are three sets of Avalon® streaming interface sink signals available to the incoming packets on the transmit TX path. Avalon® streaming interface sink connects to the eCPRI IP and external sink interfaces (ext_sink_0 and ext_sink_1) connect to external user logic. The incoming eCPRI packets passes through Ethernet header insertion block to insert Ethernet header, optionally with different VLAN tags, IPv4, and UDP headers configured during configuration time.

You can send different types of packets through the external sink interfaces signal (For example, C&M and synchronization PTP packets) which arbitrates with eCPRI packets and the IP sends packets with the higher priority to Ethernet MAC for transmission. The incoming external user packets are expected to arrive with Ethernet MAC header inserted on the packets. In the External sink interface data path, we have Queue FIFO to store the packets entering via external sink interface 0 and 1. The user can configure the Queue FIFO depth using the parameter External Sink 0 Queue FIFO Depth and External Sink 1 Queue FIFO Depth from the IP GUI. These FIFOs are using Store and Forward mechanism for packet processing so the user must top configure the Queue FIFO depth to store full packet. If users set the External Sink 0 Queue FIFO Depth to 128 (8 bytes wide), packet size should not be beyond 950 bytes with consideration of the FIFO ALMOST FULL level & ready latency logic. There are two potential scenarios for utilizing the external sink interface. In the first scenario (when NUMBER_EXT_SINK_INTF is set to 2), users can make use of both external sink interface signals. Specifically, the PTP packets need to send over ext_sink_0, while C&M and other types of packets need to send over ext_sink_1. It is important to note that in this scenario, sending C&M/ and other types (miscellaneous) of traffic to ext_sink_0 and sending PTP packets to ext_sink_1 is not allowed. In the second scenario (when NUMBER_EXT_SINK_INTF is set to 1), it is for a single external sink interface and used for PTP/ C&M/Other types of traffic. Users should send all packets, including the PTP, C&M, and others, to ext_sink_0, and ext_sink_1 is not accessible for user operations. Users have the flexibility to enable either a single external sink interface or two external sink interfaces by configuring the parameter NUMBER_EXT_SINK_INTF through the IP GUI.

The tables below summarizes the valid use cases for the external sink interface, as described above.

In addition to priority logic, The IP handles timestamp requests and fingerprint IDs for PTP/Misc. packets at external sink interfaces 0 and 1, making these interfaces consistent. Users can configure the fingerprint ID width at these interfaces using the parameter PTP_TS_FP_WIDTH. For E-Tile, the maximum width is 6 bits, and for F-Tile/H-Tile, it can be configured up to 30 bits. This configuration should align with Ethernet requirements.

The eCPRI IP will add 2 bits of encoding to distinguish timestamp responses between eCPRI and external sink interface packets. Therefore, at the MAC source interface, the Fingerprint ID signal will have an additional 2 bits added by the eCPRI IP.

The first packet arbitration feature operates on the basis of fixed priority arbitration (TX_ARBITRATION_SCHEME = "FIXED"). The priority of the packets transmitted to the Ethernet MAC are determined based on the user-configured CSR settings within the priority CSR for various packet types, including the eCPRI, PTP, and M-plane/other categories. You have the choice of three distinct CSR options: eCPRI_priority, PTP_priority, and miscellaneous_priority for priority configuration, allowing the priority values to be configured between 0 to 7.

The C&M and PTP synchronization packets are sent through external sink interface signal. When using the two external sink interfaces, packet priority assignment depends on the detected packet types when packets enter their respective interfaces. For instance, when PTP packets enter via ext_sink_0, their priority are determined by the user-configured ptp_priority register. For C&M and other types of packets entering via the ext_sink_1 interface, their priority are determined by the misc_priority register. In case of a single external sink interface, packet priority assignment is also determined by detected packet types. Specifically, PTP packets are assigned priority values based on the ptp_priority register, while non-PTP packets (C&M and others) receive priority values from the misc_priority register.

The ext_sink_0 and ext_sink_1 packets are generally low bandwidth traffic. When there is collision between the ext_sink_0/ext_sink_1 packet and the eCPRI packets, the IP assesses packet priorities and performs the arbitration to facilitate the transmission of high-priority packets through the Ethernet via the MAC source interface, while low-priority packets experience back-pressure. If a user configures the same priority for all three packet types, the arbitration sequence prioritizes PTP, followed by eCPRI, and then the Miscellaneous (C&M/other types of packets). Fixed priority arbitration consistently grants precedence to high-priority packets over low-priority packets. The eCPRI IP module implements a counter for monitoring the granted packet count between eCPRI, external sink 0, and external sink 1. It raises the priority of ext_sink_0 and ext_sink_1 packets when the counter reaches a programmable threshold to allow the packet transmission to the Ethernet MAC and prevents packet starvation. User have the option to enable or disable the handling of packet starvation for ext_sink_0 and ext_sink_1 through the Packet Queue Starvation Handling register.

Ensure the bandwidth of external source/sink interface signal won't starve the overall bandwidth and cause interruption on eCPRI traffics. The current grant ratio between the ext_sink_0/ext_sink_1 packets versus the eCPRI packet is 10:1. For example, if we consider starvation handling for the ext_sink_0, this ratio implies that after every 10 high-priority eCPRI/ext_sink_1 packets, only 1 low-priority ext_sink_0 packet is transmitted. This ratio translates to approximately 2.5G (25G/10) or 1G (10G/10) of bandwidth allocated to the ext_sink_0.The maximum ext_sink_0 FIFO depth is 512 or 4096 bytes for the eCPRI IP, with the same starvation handling applying to the ext_sink_1's low-priority packets when compared to the high-priority packets of eCPRI and the ext_sink_0. If any external sink interface experiences starvation, it eventually makes the ext_sink_0/ext_sink_1 FIFO full and backpressure to the user logic of the external sink interface. Users have the capability to monitor backpressure and make changes to priority and starvation handling during runtime. It's important to note that any updated values of CSR priority do not apply to packets that have already been assigned a priority, stored in the FIFO, and ready for arbitration.

When you set the Ethernet frame size to 9000 bytes, data from Avalon® streaming interface sink directly pass through and does not required buffering. You must assert avst_sink_valid continuously between the assertions of avst_sink_sop and avst_sink_eop. The only exception is when avst_sink_ready signal deasserts, and you are required to deassert avst_sink_valid for three cycles of READY_LATENCY.

The second L2 CoS priority arbitration is based on the ORAN-WG4.CUS.0-v07.01 specification, Section 5.3 Quality of Service, where the L2 CoS Priority of the packet determines the arbitration priority of the packet. You can enable this arbitration with Advance Mapping Mode. There are eight queues available to queue the packets for arbitration. Each queue is assigned with fixed priority 0 to 7, where queue 7 has the highest arbitration priority, and queue 0 has the lowest arbitration priority. The eCPRI packets are stored into each queue according to the Priority Code Point (PCP) tag value extracted from the packet; for example, a packet with the PCP tag value of 7 is queued into queue 7.

The eCPRI queue size for each priority must be configurable independently and use M20K to reduce ALM count. Queue depth must be configurable with a depth of 0/256/412/1024/1250 based on IP parameter selection per queue. The unused queue shall be configurable with the size of 0 to ensure no resource wastage. For queue 7, the minimum size is 256, and value 0 is not allowed to avoid a case where all queues are 0 sizes. When a particular queue size is configured to 0 (other than queue 7) and there is a request decoded with the PCP tag value of the queue, the request shall be routed to queue 7.

The ORAN C/U Plane packet uses the eCRPI IP Advance Mapping Mode feature to get the PCP value for the packet. When ORAN C/U Plane packet is sent into eCPRI IP, eCPRI IP uses the PCID sent as sideband and the packet to map to the VLAN tag register. The PCP values extracted from the VLAN tag register determine the queue to store the ORAN C/U Plane packet. The PCP field is extracted from the VLAN tag of L2 header for ext_sink_0, ext_sink_1 and other traffic. Packets are stored in the queue according to the PCP field.

The PCP arbitration arbitrates the traffic (C/U/S/M/Other) based on the PCP tag value in the round-robin and sends towards the Ethernet. Since the PTP software stack might not always generate PTP packets with the VLAN ID, the following statements explain the PCP values handling for each ITU-T profile:

• The first two profiles (8264 and 8275.1 profiles) – No VLAN ID (IP assigns the priority based on the ptp_priority CSR, the default value is 7).
• The third profile (8275.2 profile) – parse PTP packet to extract PCP from L2/L3 header.
• The primary use case is based on the L2 header and not the L3 header (8275.2 profile) – parser can parse the L2 header only to determine PTP packets and no L3 header parsing.
• For packets without a VLAN tag, the IP assigns priority based on the user-configured CSR values for each interface, ptp_priority, and misc_priority.

When the arbitration queue is full, backpressure applies to both eCPRI IP and S/M packets DCFIFO. Backpressure shall only apply on the same priority request. For example, when queue 7 is full, back pressure happens on traffic with PCP = 7 only (can be S/U/C/M plane traffic). Due to one input from ORAN IP for the U plane, subsequent packets with different priorities are blocked when the head of traffic is blocked. If the queue full happens in the middle of the packet, you must submit the remaining packet to the queue before switching to other traffic.

Run time priority change on traffic: You can switch PCP field values at packet boundary only, priority should remain the same for whole packet.

There is no starvation handling in hardware. For example, low-priority traffic always gives way to high-priority traffic and waits for its turn. Therefore, you are expected to handle the traffic flow between different queues to ensure no starvation scenarios which causes low-priority traffic continuously to get stuck in the queue without getting the arbitration grant.

Each queue generates FIFO full port and sends it to the eCPRI IP interface.