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

Download PDF
ID 683396
Date 12/04/2023
Public
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 IPs 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 IPs 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 Packet Mode Transfer Example 4.5.3.2. Receive User Data Interface Example
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.5.3.1. Transmit User Data Interface Example

The following example illustrate how to use Interlaken Look-aside TX user data interface during a normal packet transfer:

Packet Mode Transfer Example

This example illustrates the expected behavior of the Interlaken Look-aside application interface transmit signals during a packet transfer in packet mode.
Figure 24. Packet Transfer on Transmit Interface in Packet ModeThe following figure illustrates two packet transfer of 120 bytes and 49 bytes on the transmit interface with number of lanes is equal to eight and TX_CREDIT_LATENCY is equal to four.
You must assert itx_valid after TX_CREDIT_LATENCY cycle from the assertion of itx_credit even when itx_ready deasserted.

In cycle 5, the IP core detects assertion of itx_idle and all of itx_idle bits are asserted indicating that eight idle control words can be inserted in this slot.

In cycle 6, itx_valid signal is deasserted indicating that all of other signals are not valid. itx_valid signal is deasserted because TX_CREDIT_LATENCY cycles before, itx_credit was deasserted.

In cycle 7, itx_valid is asserted and itx_idle is 0x0, which indicates itx_sop, itx_eopbits, and itx_din_words signals. Assert the itx_sop[7] to indicate the start of packet. Burst control word can be inserted at this location and seven data words in itx_din_words[447:0] should follow it. Corresponding itx_chan[7] indicates the channel associated with this data packet following the control word. The IP ignores the rest of itx_chan [6:0] bits.

In cycle 8, the transfer of data packet should be terminated since itx_eopbits[3:0] is not zero. The seven data words in itx_data[511:0] should be transferred as a part of data packet. itx_chan is invalid in this cycle because itx_sop bits are not set. itx_eopbits[3:0] can be set to 4'b1000 to indicate the end of packet and last word contains 8 bytes. This eopbits field can be set to EOP_Format field of following burst control words.

In cycle 9, the itx_valid should be de-asserted because before the TX_CREDIT_LATECNY cycles, itx_credit was deasserted.

In cycle 10, the transfer of new data packet starts and this can be terminated since itx_eopbits[3:0] is not zero. In this cycle, user sends 49 bytes to the IP core. The itx_eopbits[3:0]= 4'b0001 indicates that the last word (tx_data[63:0]) only contains one byte. This itx_eopbits[3:0] value can be set to EOP_Format field of following IDLE control word.

In cycle 11, itx_valid should be asserted because before TX_CREDIT_LATENCY cycles, itx_credit was deasserted.

In cycle 12, user logic asserts itx_idle[7:0] indicating that it wants to terminate the data burst and send eight idle control words.

This signal behavior correctly transfer first data packet as follows:
  • In cycle 7, the IP core receives burst control word and 56 bytes of valid data (data 1)
  • In cycle 8, the IP core receives 64 bytes of valid data (data 2)

The total packet length for the first packet is 56 + 64 = 120 bytes.

This signal behavior correctly transfer second data packet as follows:
  • In cycle 10, the IP core receives another burst control word and 49 bytes of valid data (data 3)

The total packet length for the second packet is 49 bytes.

Level Two Title