Arria® 10 and Cyclone® 10 GX Avalon® Streaming Interface for PCI Express* User Guide

Download PDF
ID 683647
Date 9/11/2024
Public
Document Table of Contents
Document Table of Contents x
1. Datasheet 2. Quick Start Guide 3. Arria® 10 or Cyclone® 10 GX Parameter Settings 4. Physical Layout 5. Interfaces and Signal Descriptions 6. Registers 7. Reset and Clocks 8. Interrupts 9. Error Handling 10. PCI Express Protocol Stack 11. Transaction Layer Protocol (TLP) Details 12. Throughput Optimization 13. Design Implementation 14. Additional Features 15. Hard IP Reconfiguration 16. Testbench and Design Example 17. Debugging A. Transaction Layer Packet (TLP) Header Formats B. Lane Initialization and Reversal C. Arria® 10 or Cyclone® 10 GX Avalon-ST Interface for PCIe Solutions User Guide Archive D. Document Revision History
1. Datasheet x
1.1. Arria® 10 or Cyclone® 10 GX Avalon-ST Interface for PCI Express* Datasheet 1.2. Release Information 1.3. Device Family Support 1.4. Configurations 1.5. Debug Features 1.6. IP Core Verification 1.7. Resource Utilization 1.8. Recommended Speed Grades 1.9. Creating a Design for PCI Express
1.1. Arria® 10 or Cyclone® 10 GX Avalon-ST Interface for PCI Express* Datasheet x
1.1.1. Arria® 10 or Cyclone® 10 GX Features
1.6. IP Core Verification x
1.6.1. Compatibility Testing Environment
2. Quick Start Guide x
2.1. Directory Structure 2.2. Design Components 2.3. Generating the Design 2.4. Simulating the Design 2.5. Compiling and Testing the Design in Hardware
3. Arria® 10 or Cyclone® 10 GX Parameter Settings x
3.1. Parameters 3.2. Arria® 10 or Cyclone® 10 GX Avalon-ST Settings 3.3. Base Address Register (BAR) and Expansion ROM Settings 3.4. Base and Limit Registers for Root Ports 3.5. Device Identification Registers 3.6. PCI Express and PCI Capabilities Parameters 3.7. Vendor Specific Extended Capability (VSEC) 3.8. Configuration, Debug, and Extension Options 3.9. PHY Characteristics 3.10. Example Designs
3.6. PCI Express and PCI Capabilities Parameters x
3.6.1. PCI Express and PCI Capabilities 3.6.2. Error Reporting 3.6.3. Link Capabilities 3.6.4. MSI and MSI-X Capabilities 3.6.5. Slot Capabilities 3.6.6. Power Management
4. Physical Layout x
4.1. Hard IP Block Placement In Cyclone® 10 GX Devices 4.2. Hard IP Block Placement In Arria® 10 Devices 4.3. Channel and Pin Placement for the Gen1, Gen2, and Gen3 Data Rates 4.4. Channel Placement and fPLL and ATX PLL Usage for the Gen3 Data Rate 4.5. PCI Express Gen3 Bank Usage Restrictions
5. Interfaces and Signal Descriptions x
5.1. Avalon‑ST RX Interface 5.2. Avalon-ST TX Interface 5.3. Clock Signals 5.4. Reset, Status, and Link Training Signals 5.5. ECRC Forwarding 5.6. Error Signals 5.7. Interrupts for Endpoints 5.8. Interrupts for Root Ports 5.9. Completion Side Band Signals 5.10. Parity Signals 5.11. LMI Signals 5.12. Transaction Layer Configuration Space Signals 5.13. Hard IP Reconfiguration Interface 5.14. Power Management Signals 5.15. Physical Layer Interface Signals
5.1. Avalon‑ST RX Interface x
5.1.1. Avalon-ST RX Component Specific Signals 5.1.2. Data Alignment and Timing for the 64‑Bit Avalon® -ST RX Interface 5.1.3. Data Alignment and Timing for the 128‑Bit Avalon‑ST RX Interface 5.1.4. Data Alignment and Timing for 256‑Bit Avalon‑ST RX Interface 5.1.5. Tradeoffs to Consider when Enabling Multiple Packets per Cycle
5.2. Avalon-ST TX Interface x
5.2.1. Avalon-ST Packets to PCI Express TLPs 5.2.2. Data Alignment and Timing for the 64‑Bit Avalon-ST TX Interface 5.2.3. Data Alignment and Timing for the 128‑Bit Avalon‑ST TX Interface 5.2.4. Data Alignment and Timing for the 256‑Bit Avalon‑ST TX Interface 5.2.5. Root Port Mode Configuration Requests
5.2.4. Data Alignment and Timing for the 256‑Bit Avalon‑ST TX Interface x
5.2.4.1. Single Packet Per Cycle 5.2.4.2. Multiple Packets per Cycle on the Avalon-ST TX 256-Bit Interface
5.12. Transaction Layer Configuration Space Signals x
5.12.1. Configuration Space Register Access Timing 5.12.2. Configuration Space Register Access
5.15. Physical Layer Interface Signals x
5.15.1. Serial Data Signals 5.15.2. PIPE Interface Signals 5.15.3. Test Signals 5.15.4. Arria® 10 Development Kit Conduit Interface
6. Registers x
6.1. Correspondence between Configuration Space Registers and the PCIe Specification 6.2. Type 0 Configuration Space Registers 6.3. Type 1 Configuration Space Registers 6.4. PCI Express Capability Structures 6.5. Intel-Defined VSEC Registers 6.6. Advanced Error Reporting Capability
6.5. Intel-Defined VSEC Registers x
6.5.1. CvP Registers
6.6. Advanced Error Reporting Capability x
6.6.1. Uncorrectable Internal Error Mask Register 6.6.2. Uncorrectable Internal Error Status Register 6.6.3. Correctable Internal Error Mask Register 6.6.4. Correctable Internal Error Status Register
7. Reset and Clocks x
7.1. Reset Sequence for Hard IP for PCI Express IP Core and Application Layer 7.2. Clocks
7.2. Clocks x
7.2.1. Clock Domains 7.2.2. Clock Summary
7.2.1. Clock Domains x
7.2.1.1. coreclkout_hip 7.2.1.2. pld_clk
8. Interrupts x
8.1. Interrupts for Endpoints 8.2. Interrupts for Root Ports
8.1. Interrupts for Endpoints x
8.1.1. MSI and Legacy Interrupts 8.1.2. MSI-X 8.1.3. Implementing MSI-X Interrupts 8.1.4. Legacy Interrupts
9. Error Handling x
9.1. Physical Layer Errors 9.2. Data Link Layer Errors 9.3. Transaction Layer Errors 9.4. Error Reporting and Data Poisoning 9.5. Uncorrectable and Correctable Error Status Bits
10. PCI Express Protocol Stack x
10.1. Top-Level Interfaces 10.2. Transaction Layer 10.3. Data Link Layer 10.4. Physical Layer
10.1. Top-Level Interfaces x
10.1.1. Avalon-ST Interface 10.1.2. Clocks and Reset 10.1.3. Local Management Interface (LMI Interface) 10.1.4. Hard IP Reconfiguration 10.1.5. Interrupts 10.1.6. PIPE
10.2. Transaction Layer x
10.2.1. Configuration Space
11. Transaction Layer Protocol (TLP) Details x
11.1. Supported Message Types 11.2. Transaction Layer Routing Rules 11.3. Receive Buffer Reordering
11.1. Supported Message Types x
11.1.1. INTX Messages 11.1.2. Power Management Messages 11.1.3. Error Signaling Messages 11.1.4. Locked Transaction Message 11.1.5. Slot Power Limit Message 11.1.6. Vendor-Defined Messages 11.1.7. Hot Plug Messages
11.3. Receive Buffer Reordering x
11.3.1. Using Relaxed Ordering
12. Throughput Optimization x
12.1. Throughput of Posted Writes 12.2. Throughput of Non-Posted Reads
13. Design Implementation x
13.1. Making Pin Assignments to Assign I/O Standard to Serial Data Pins 13.2. Recommended Reset Sequence to Avoid Link Training Issues 13.3. SDC Timing Constraints
14. Additional Features x
14.1. Configuration over Protocol (CvP) 14.2. Autonomous Mode 14.3. ECRC
14.2. Autonomous Mode x
14.2.1. Enabling Autonomous Mode 14.2.2. Enabling CvP Initialization
14.3. ECRC x
14.3.1. ECRC on the RX Path 14.3.2. ECRC on the TX Path
16. Testbench and Design Example x
16.1. Endpoint Testbench 16.2. Test Driver Module 16.3. Root Port BFM Overview 16.4. BFM Procedures and Functions
16.1. Endpoint Testbench x
16.1.1. Endpoint Testbench for SR-IOV
16.3. Root Port BFM Overview x
16.3.1. BFM Memory Map 16.3.2. Configuration Space Bus and Device Numbering 16.3.3. Configuration of Root Port and Endpoint 16.3.4. Issuing Read and Write Transactions to the Application Layer
16.4. BFM Procedures and Functions x
16.4.1. ebfm_barwr Procedure 16.4.2. ebfm_barwr_imm Procedure 16.4.3. ebfm_barrd_wait Procedure 16.4.4. ebfm_barrd_nowt Procedure 16.4.5. ebfm_cfgwr_imm_wait Procedure 16.4.6. ebfm_cfgwr_imm_nowt Procedure 16.4.7. ebfm_cfgrd_wait Procedure 16.4.8. ebfm_cfgrd_nowt Procedure 16.4.9. BFM Configuration Procedures 16.4.10. BFM Shared Memory Access Procedures 16.4.11. BFM Log and Message Procedures 16.4.12. Verilog HDL Formatting Functions
16.4.9. BFM Configuration Procedures x
16.4.9.1. ebfm_cfg_rp_ep Procedure 16.4.9.2. ebfm_cfg_decode_bar Procedure
16.4.10. BFM Shared Memory Access Procedures x
16.4.10.1. Shared Memory Constants 16.4.10.2. shmem_write Task 16.4.10.3. shmem_read Function 16.4.10.4. shmem_display Verilog HDL Function 16.4.10.5. shmem_fill Procedure 16.4.10.6. shmem_chk_ok Function
16.4.11. BFM Log and Message Procedures x
16.4.11.1. ebfm_display Verilog HDL Function 16.4.11.2. ebfm_log_stop_sim Verilog HDL Function 16.4.11.3. ebfm_log_set_suppressed_msg_mask Task 16.4.11.4. ebfm_log_set_stop_on_msg_mask Verilog HDL Task 16.4.11.5. ebfm_log_open Verilog HDL Function 16.4.11.6. ebfm_log_close Verilog HDL Function
16.4.12. Verilog HDL Formatting Functions x
16.4.12.1. himage1 16.4.12.2. himage2 16.4.12.3. himage4 16.4.12.4. himage8 16.4.12.5. himage16 16.4.12.6. dimage1 16.4.12.7. dimage2 16.4.12.8. dimage3 16.4.12.9. dimage4 16.4.12.10. dimage5 16.4.12.11. dimage6 16.4.12.12. dimage7
17. Debugging x
17.1. Simulation Fails To Progress Beyond Polling.Active State 17.2. Hardware Bring-Up Issues 17.3. Link Training 17.4. Creating a Signal Tap Debug File to Match Your Design Hierarchy 17.5. Use Third-Party PCIe Analyzer 17.6. BIOS Enumeration Issues
17.3. Link Training x
17.3.1. Link Hangs in L0 State
A. Transaction Layer Packet (TLP) Header Formats x
A.1. TLP Packet Formats without Data Payload A.2. TLP Packet Formats with Data Payload
D. Document Revision History x
D.1. Document Revision History of the Arria® 10 or Cyclone® 10 GX Avalon® Streaming (Avalon-ST) Interface for PCIe* Solutions User Guide
1. Datasheet
2. Quick Start Guide
3. Arria® 10 or Cyclone® 10 GX Parameter Settings
4. Physical Layout
5. Interfaces and Signal Descriptions
6. Registers
7. Reset and Clocks
8. Interrupts
9. Error Handling
10. PCI Express Protocol Stack
11. Transaction Layer Protocol (TLP) Details
12. Throughput Optimization
13. Design Implementation
14. Additional Features
15. Hard IP Reconfiguration
16. Testbench and Design Example
17. Debugging
A. Transaction Layer Packet (TLP) Header Formats
B. Lane Initialization and Reversal
C. Arria® 10 or Cyclone® 10 GX Avalon-ST Interface for PCIe Solutions User Guide Archive
D. Document Revision History

5.2. Avalon-ST TX Interface

The following table describes the signals that comprise the Avalon-ST TX Datapath. The TX data signal can be 64, 128, or 256 bits.

Table 29.  64-, 128-, or 256‑Bit Avalon-ST TX Datapath

Signal

Direction

Description

tx_st_data[<n>-1:0]

Input

Data for transmission. Transmit data bus. Refer to the following sections on data alignment for the 64-, 128-, and 256-bit interfaces for the mapping of TLP packets to tx_st_data and examples of the timing of this interface. When using a 64-bit Avalon-ST bus, the width of tx_st_d ata is 64. When using a 128-bit Avalon-ST bus, the width of tx_st_data is 128 bits. When using a 256‑bit Avalon‑ST bus, the width of tx_st_data is 256 bits. The Application Layer must provide a properly formatted TLP on the TX interface. The mapping of message TLPs is the same as the mapping of Transaction Layer TLPs with 4 dword headers. The number of data cycles must be correct for the length and address fields in the header. Issuing a packet with an incorrect number of data cycles results in the TX interface hanging and becoming unable to accept further requests.

<n> = 64, 128, or 256.

tx_st_sop[<n>-1:0]

Input

Indicates first cycle of a TLP when asserted together with tx_st_valid. <n> = 1 or 2.

When using a 256-bit Avalon-ST bus with Multiple packets per cycle, bit 0 indicates that a TLP begins in tx_st_data[127:0], bit 1 indicates that a TLP begins in tx_st_data[255:128].

tx_st_eop[<n>-1:0]

Input

Indicates last cycle of a TLP when asserted together with tx_st_valid. <n> = 1 or 2.

When using a 256-bit Avalon-ST bus with Multiple packets per cycle, bit 0 indicates that a TLP ends with tx_st_data[127:0], bit 1 indicates that a TLP ends with tx_st_data[255:128].

tx_st_ready

Output

Indicates that the Transaction Layer is ready to accept data for transmission. The core deasserts this signal to throttle the data stream. tx_st_ready may be asserted during reset. The Application Layer should wait at least 2 clock cycles after the reset is released before issuing packets on the Avalon‑ST TX interface. The reset_status signal can also be used to monitor when the IP core has come out of reset.

If tx_st_ready is asserted by the Transaction Layer on cycle <n> , then <n + readyLatency> is a ready cycle, during which the Application Layer may assert valid and transfer data.

When tx_st_ready, tx_st_valid and tx_st_data are registered (the typical case), Intel recommends a readyLatency of 2 cycles to facilitate timing closure; however, a readyLatency of 1 cycle is possible. If no other delays are added to the read‑valid latency, the resulting delay corresponds to a readyLatency of 2.

tx_st_valid

Input

Clocks tx_st_data to the core when tx_st_ready is also asserted. Between tx_st_sop and tx_st_eop, tx_st_valid must not be deasserted in the middle of a TLP except in response to tx_st_ready deassertion. When tx_st_ready deasserts, this signal must deassert within 1 or 2 clock cycles. When tx_st_ready reasserts, and tx_st_data is in mid-TLP, this signal must reassert within 2 cycles. The figure entitled64-Bit Transaction Layer Backpressures the Application Layer illustrates the timing of this signal.

For 256-bit data, when you turn on Enable multiple packets per cycle, the bit 0 applies to the entire bus tx_st_data[255:0]. Bit 1 is not used.

To facilitate timing closure, Intel recommends that you register both the tx_st_ready and tx_st_valid signals. If no other delays are added to the ready-valid latency, the resulting delay corresponds to a readyLatency of 2.

tx_st_empty[1:0]

Input

Indicates the number of qwords that are empty during cycles that contain the end of a packet. When asserted, the empty dwords are in the high‑order bits. Valid only when tx_st_eop is asserted.

Not used when tx_st_data is 64 bits. For 128‑bit data, only bit 0 applies and indicates whether the upper qword contains data. For 256‑bit data, both bits are used to indicate the number of upper words that contain data, resulting in the following encodings for the 128‑and 256-bit interfaces:

128-Bit interface:tx_st_empty = 0, tx_st_data[127:0]contains valid datatx_st_empty = 1, tx_st_data[63:0] contains valid data

256‑bit interface:tx_st_empty = 0, tx_st_data[255:0] contains valid datatx_ st_empty = 1, tx_st_data[191:0] contains valid datatx_st_empty = 2, tx_st_data[127:0] contains valid datatx_st_empty = 3, tx_st_data[63:0] contains valid data

For 256-bit data, when you turn on Enable multiple packets per cycle, the following correspondences apply:

  • bit 1 applies to the eop occurring in rx_st_data[255:128]
  • bit 0 applies to the eop occurring in rx_st_data[127:0]

When the TLP ends in the lower 128bits, the following equations apply:

  • tx_st_eop[0]=1 & tx_st_empty[0]=0, tx_st_data[127:0] contains valid data
  • tx_st_eop[0]=1 & tx_st_empty[0]=1, tx_st_data[63:0] contains valid data, tx_st_data[127:64] is empty

When TLP ends in the upper 128bits, the following equations apply:

  • tx_st_eop[1]=1 & tx_st_empty[1]=0, tx_st_data[255:128] contains valid data
  • tx_st_eop[1]=1 & tx_st_empty[1]=1, tx_st_data[191:128] contains valid data, tx_st_data[255:192] is empty
tx_st_err

Input

Indicates an error on transmitted TLP. This signal is used to nullify a packet. It should only be applied to posted and completion TLPs with payload. To nullify a packet, assert this signal for 1 cycle after the SOP and before the EOP. When a packet is nullified, the following packet should not be transmitted until the next clock cycle. tx_st_err is not available for packets that are 1 or 2 cycles long.

For 256-bit data, when you turn on Enable multiple packets per cycle, bit 0 applies to the entire bus tx_st_data[255:0]. Bit 1 is not used.

Refer to the figure entitled 128-Bit Avalon-ST tx_st_data Cycle Definition for 3-Dword Header TLP with non-Qword Aligned Address for a timing diagram that illustrates the use of the error signal. Note that it must be asserted while the valid signal is asserted.

tx_st_parity[<n>-1:0]

Input

Byte parity is generated when you turn on Enable byte parity ports on Avalon ST interface on the System Settings tab of the parameter editor.Each bit represents odd parity of the associated byte of the tx_st_data bus. For example, bit[0] corresponds to tx_st_data[7:0], bit[1] corresponds to tx_st_data[15:8], and so on.

<n> = 8, 16, or 32.

Component Specific Signals

tx_cred_data_fc[11:0]

Output

Data credit limit for the credit type specified by tx_cred_fc_sel. Each credit is 16 bytes. There is a latency of two pld_clk clocks between a change on tx_cred_fc_sel and the corresponding data appearing on tx_cred_data_fc and tx_cred_hdr_fc.

tx_cred_fc_hip_cons[5:0]

Output

Asserted for 1 cycle each time the Hard IP consumes a credit. These credits are from messages that the Hard IP for PCIe generates for the following reasons:

  • To respond to memory read requests
  • To send error messages

This signal is not asserted when an Application Layer credit is consumed. For optimum performance the Application Layer can track of its own consumed credits. (The hard IP also tracks credits and deasserts tx_st_ready if it runs out of credits of any type.) To calculate the total credits consumed, the Application Layer can add its own credits consumed to those consumed by the Hard IP for PCIe. The credit signals are valid after the link is up.

The 6 bits of this vector correspond to the following 6 types of credit types:

  • [5]: posted headers
  • [4]: posted data
  • [3]: non‑posted header
  • [2]: non‑posted data
  • [1]: completion header
  • [0]: completion data

During a single cycle, the IP core can consume either a single header credit or both a header and a data credit.

tx_cred_fc_infinite[5:0]

Output

When asserted, indicates that the corresponding credit type has infinite credits available and does not need to calculate credit limits. The 6 bits of this vector correspond to the following 6 types of credit types:

  • [5]: posted headers
  • [4]: posted data
  • [3]: non‑posted header
  • [2]: non‑posted data
  • [1]: completion header
  • [0]: completion data
tx_cred_fc_sel[1:0]

Input

Signal to select between which credit type is displayed on the tx_cred_hdr_fc and tx_cred_data_fc outputs. There is a latency of two pld_clk clocks between a change on tx_cred_fc_sel and the corresponding data appearing on tx_cred_data_fc and tx_cred_hdr_fc. The following encoding are defined:

  • 2'b00: Output Posted credits
  • 2'b01: Output Non-Posted credits
  • 2'b10: Output Completions
tx_cred_hdr_fc[7:0]

Output

Header credit limit for the credit type selected by tx_cred_fc_sel. Each credit is 20 bytes. There is a latency of two pld_clk clocks between a change on tx_cred_fc_sel and the corresponding data appearing on tx_cred_data_fc and tx_cred_hdr_fc.

tx_cons_cred_sel Input When 1, the output tx_cred_data* and tx_cred_hdr* signals specify the value of the hard IP internal credits-consumed counter. When 0, tx_cred_data* and tx_cred_hdr* signal specify the limit value.
ko_cpl_spc_header[7:0]

Output

The Application Layer can use this signal to build circuitry to prevent RX buffer overflow for completion headers. Endpoints must advertise infinite space for completion headers; however, RX buffer space is finite. ko_cpl_spc_header is a static signal that indicates the total number of completion headers that can be stored in the RX buffer.

ko_cpl_spc_data[11:0]

Output

The Application Layer can use this signal to build circuitry to prevent RX buffer overflow for completion data. Endpoints must advertise infinite space for completion data; however, RX buffer space is finite. ko_cpl_spc_data is a static signal that reflects the total number of 16 byte completion data units that can be stored in the completion RX buffer.


Section Content
Avalon-ST Packets to PCI Express TLPs
Data Alignment and Timing for the 64‑Bit Avalon-ST TX Interface
Data Alignment and Timing for the 128‑Bit Avalon‑ST TX Interface
Data Alignment and Timing for the 256‑Bit Avalon‑ST TX Interface
Root Port Mode Configuration Requests

Related Information
Level Two Title