Visible to Intel only — GUID: nik1411004526260
Ixiasoft
1. About This IP Core
2. Getting Started With the 50G Interlaken IP Core
3. 50G Interlaken IP Core Parameter Settings
4. Functional Description
5. 50G Interlaken IP core Signals
6. 50G Interlaken IP Core Register Map
7. 50G Interlaken IP Core Test Features
8. Advanced Parameter Settings
9. Out-of-Band Flow Control in the 50G Interlaken IP core
10. 50G Interlaken IP core User Guide Archives
11. Document Revision History for 50G Interlaken User Guide
A. Performance and Fmax Requirements for 40G Ethernet Traffic
2.1. Installing and Licensing Intel® FPGA IP Cores
2.2. Specifying the 50G Interlaken IP Core Parameters and Options
2.3. Files Generated for Arria V GZ and Stratix V Variations
2.4. Files Generated for Intel® Arria® 10 Variations
2.5. Simulating the 50G Interlaken IP Core
2.6. Integrating Your IP Core in Your Design
2.7. Compiling the Full Design and Programming the FPGA
2.8. Creating a Signal Tap Debug File to Match Your Design Hierarchy
5.1. 50G Interlaken IP Core Clock Interface Signals
5.2. 50G Interlaken IP Core Reset Interface Signals
5.3. 50G Interlaken IP Core User Data Transfer Interface Signals
5.4. 50G Interlaken IP Core Interlaken Link and Miscellaneous Interface Signals
5.5. 50G Interlaken IP Core Management Interface
5.6. Device Dependent Signals
Visible to Intel only — GUID: nik1411004526260
Ixiasoft
4.6.2.1. 50G Interlaken IP Core Receiver Side Example With Errors and In-Band Calendar Bits
Figure 16. 50G Interlaken IP Core Receiver Side Example With irx_err Errors
This example illustrates the expected behavior of the 50G Interlaken IP core application interface receive signals during a packet transfer with CRC or other errors. In the example, the errored packet transfer is followed by two idle cycles and a non-errored packet transfer.
This figure illustrates the attempted transfer of a 83-byte packet on the RX user data transfer interface to channel 2, after the 50G Interlaken IP Core receives the packet on the Interlaken link and detects corruption. Following the errored packet, the IP core transfers an uncorrupted packet to channel 3.
In cycle 1, the 50G Interlaken IP Core asserts irx_sop when data is ready on irx_dout_words. When the 50G Interlaken IP Core asserts irx_sop , it also asserts the correct value on irx_chan to tell the application the data channel destination of the data. In this example, the value 2 on irx_chan tells the application that the data should be sent to channel number 2.
During the SOP cycle (labeled with data value d1) and the cycle that follows the SOP cycle (labeled with data value d2), the 50G Interlaken IP Core holds the value of irx_num_valid[2:0] at 3'b100. In the following clock cycle, labeled with data value d3, the 50G Interlaken IP Core holds the following values on critical output signals:
- irx_num_valid[2:0] at the value of 3'b011 to indicate the current data symbol contains three 64-bit words of valid data.
- irx_eopbits[3] high to indicate the current cycle is an EOP cycle.
- irx_eopbits[2:0] at the value of 3'b011 to indicate that only three bytes of the final valid data word are valid data bytes.
This signal behavior, in the absence of the irx_err flag, would correctly transfer a data packet with the total packet length of 83 bytes from the 50G Interlaken IP Core.
However, the 50G Interlaken IP Core marks the packet as errored by asserting the irx_err signal, even though the irx_eopbits signal would appear to indicate the packet is valid.
The application is responsible for discarding the errored packet when it detects that the IP core has asserted the irx_err signal.
Following the corrupted packet, the IP core waits two idle cycles and then transfers a valid 75-byte packet.