Interlaken (2nd Generation) Intel® FPGA IP User Guide

Download PDF
ID 683396
Date 10/04/2021
Public

A newer version of this document is available. Customers should click here to go to the newest version.

Document Table of Contents
Document Table of Contents x
1. Introduction 2. Getting Started 3. Parameter Settings 4. Functional Description 5. Interface Signals 6. Register Map 7. Test Features 8. Interlaken (2nd Generation) Intel® FPGA IP User Guide Archives 9. Document Revision History for Interlaken (2nd Generation) Intel® FPGA IP User Guide
1. Introduction x
1.1. Features 1.2. Device Family Support 1.3. Performance and Resource Utilization 1.4. Flexible Lanes Support 1.5. Round-trip Latency 1.6. Release Information
2. Getting Started x
2.1. Installing and Licensing Intel® FPGA IP Cores 2.2. Generated File Structure 2.3. Specifying the IP Core Parameters and Options 2.4. Simulating the IP Core 2.5. Compiling the Full Design and Programming the FPGA 2.6. Integrating Your IP Core in Your Design
2.1. Installing and Licensing Intel® FPGA IP Cores x
2.1.1. Intel® FPGA IP Evaluation Mode
2.6. Integrating Your IP Core in Your Design x
2.6.1. Pin Assignment 2.6.2. Adding the External PLL 2.6.3. PMA Adaptation Flow
3. Parameter Settings x
3.1. Main Parameters 3.2. PMA Adaptation Parameters
4. Functional Description x
4.1. Interfaces 4.2. IP Clocks 4.3. High Level Data Path Flow for Interlaken Mode 4.4. High Level Data Path Flow for Interlaken Look-aside Mode 4.5. Modes of Operation 4.6. Performance 4.7. IP Core Reset 4.8. M20K ECC Support 4.9. Out-of-Band Flow Control
4.3. High Level Data Path Flow for Interlaken Mode x
4.3.1. Interlaken TX Path 4.3.2. Interlaken RX Path 4.3.3. Unused Transceiver Channels
4.3.1. Interlaken TX Path x
4.3.1.1. Transmit Path Blocks 4.3.1.2. In-Band Calendar Bits on Transmit Side
4.3.2. Interlaken RX Path x
4.3.2.1. Receive Path Blocks 4.3.2.2. In-Band Calendar Bits on Receive Side 4.3.2.3. RX Errored Packet Handling
4.3.2.3. RX Errored Packet Handling x
4.3.2.3.1. Example With Errors and In-Band Calendar Bits
4.4. High Level Data Path Flow for Interlaken Look-aside Mode x
4.4.1. Interlaken Look-aside TX Path 4.4.2. Interlaken Look-aside RX Path
4.4.1. Interlaken Look-aside TX Path x
4.4.1.1. Transmit Path Blocks
4.4.2. Interlaken Look-aside RX Path x
4.4.2.1. Receive Path Blocks 4.4.2.2. RX Error Handling
4.5. Modes of Operation x
4.5.1. Interleaved and Packet Modes 4.5.2. Interlaken Mode 4.5.3. Interlaken Look-aside Mode 4.5.4. Multi-Segment Mode
4.5.2. Interlaken Mode x
4.5.2.1. Transmit User Data Interface Examples 4.5.2.2. Receive User Data Interface Example
4.5.3. Interlaken Look-aside Mode x
4.5.3.1. Transmit User Data Interface Example 4.5.3.2. Receive User Data Interface Examples
4.5.4. Multi-Segment Mode x
4.5.4.1. Multi-Segment Interface Example
5. Interface Signals x
5.1. Clock and Reset Interface Signals 5.2. Transmit User Interface Signals 5.3. Receive User Interface Signals 5.4. Management Interface Signals 5.5. Reconfiguration Interface Signals 5.6. Interlaken Link and Miscellaneous Signals 5.7. External PLL Interface Signals
7. Test Features x
7.1. Internal Serial Loopback Mode 7.2. External Loopback Mode
1. Introduction
2. Getting Started
3. Parameter Settings
4. Functional Description
5. Interface Signals
6. Register Map
7. Test Features
8. Interlaken (2nd Generation) Intel® FPGA IP User Guide Archives
9. Document Revision History for Interlaken (2nd Generation) Intel® FPGA IP User Guide

4.3.2.3.1. Example With Errors and In-Band Calendar Bits

This example illustrates the expected behavior of the 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.
Figure 13. Interlaken IP Core Receiver Side With irx_err ErrorsThis figure illustrates the attempted transfer of a 179-byte packet on the RX user data transfer interface to channel 2, after the 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 Interlaken IP core asserts irx_sop[1] when data is ready on irx_dout_words. When the Interlaken IP core asserts irx_sop[1], 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 Interlaken IP core holds the value of irx_num_valid[7:4] at 4'b1000. In the following clock cycle, labeled with data value d3, the Interlaken IP core holds the following values on critical output signals:
  • irx_num_valid[7:4] at the value of 4'b0111 to indicate the current data symbol contains seven 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 179 bytes from the Interlaken IP core. However, the Interlaken IP core marks the burst 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 139-byte packet.

Level Two Title