Arria V Avalon-ST Interface for PCIe Solutions User Guide

Download PDF
ID 683733
Date 1/04/2023
Public
Document Table of Contents
Document Table of Contents x
1. Datasheet 2. Getting Started with the Arria V Hard IP for PCI Express 3. Parameter Settings 4. Interfaces and Signal Descriptions 5. Registers 6. Interrupts 7. Error Handling 8. IP Core Architecture 9. Transaction Layer Protocol (TLP) Details 10. Throughput Optimization 11. Design Implementation 12. Additional Features 13. Hard IP Reconfiguration 14. Transceiver PHY IP Reconfiguration 15. Testbench and Design Example 16. Debugging A. Transaction Layer Packet (TLP) Header Formats B. Lane Initialization and Reversal C. Document Revision History
1. Datasheet x
1.1. Arria V Avalon-ST Interface for PCIe Datasheet 1.2. Features 1.3. Release Information 1.4. Device Family Support 1.5. Configurations 1.6. Example Designs 1.7. Debug Features 1.8. IP Core Verification 1.9. Performance and Resource Utilization 1.10. Recommended Speed Grades 1.11. Creating a Design for PCI Express
1.8. IP Core Verification x
1.8.1. Compatibility Testing Environment
2. Getting Started with the Arria V Hard IP for PCI Express x
2.1. Qsys Design Flow 2.2. Modifying the Example Design 2.3. Using the IP Catalog To Generate Your Arria V Hard IP for PCI Express as a Separate Component
2.1. Qsys Design Flow x
2.1.1. Generating the Testbench 2.1.2. Simulating the Example Design 2.1.3. Generating Synthesis Files 2.1.4. Understanding the Files Generated 2.1.5. Understanding Physical Placement of the PCIe IP Core 2.1.6. Compiling the Design in the Quartus® Prime Software
3. Parameter Settings x
3.1. Avalon-ST System Settings 3.2. Link Capabilities 3.3. Port Function Parameters Shared Across All Port Functions 3.4. Port Function Parameters Defined Separately for All Port Functions
3.3. Port Function Parameters Shared Across All Port Functions x
3.3.1. Device Capabilities 3.3.2. Error Reporting 3.3.3. Link Capabilities 3.3.4. Slot Capabilities 3.3.5. Power Management
3.4. Port Function Parameters Defined Separately for All Port Functions x
3.4.1. Base Address Register (BAR) and Expansion ROM Settings 3.4.2. Base and Limit Registers for Root Ports 3.4.3. Device Identification Registers for Function <n> 3.4.4. Func <n> Device 3.4.5. Func <n> Link 3.4.6. Func <n> MSI and MSI-X Capabilities 3.4.7. Func <n> Legacy Interrupt
4. Interfaces and Signal Descriptions x
4.1. Arria V Hard IP for PCI Express with Avalon-ST Interface to the Application Layer 4.2. Clock Signals 4.3. Reset Signals 4.4. Hard IP Status 4.5. Error Signals 4.6. ECRC Forwarding 4.7. Interrupts for Endpoints 4.8. Interrupts for Root Ports 4.9. Completion Side Band Signals 4.10. Transaction Layer Configuration Space Signals 4.11. LMI Signals 4.12. Power Management Signals 4.13. Physical Layer Interface Signals
4.1. Arria V Hard IP for PCI Express with Avalon-ST Interface to the Application Layer x
4.1.1. Avalon‑ST RX Interface 4.1.2. Avalon-ST TX Interface
4.1.1. Avalon‑ST RX Interface x
4.1.1.1. Avalon-ST RX Component Specific Signals 4.1.1.2. Data Alignment and Timing for the 64‑Bit Avalon® -ST RX Interface 4.1.1.3. Data Alignment and Timing for the 128‑Bit Avalon‑ST RX Interface
4.1.2. Avalon-ST TX Interface x
4.1.2.1. Avalon-ST Packets to PCI Express TLPs 4.1.2.2. Data Alignment and Timing for the 64‑Bit Avalon-ST TX Interface 4.1.2.3. Data Alignment and Timing for the 128‑Bit Avalon‑ST TX Interface 4.1.2.4. Root Port Mode Configuration Requests
4.10. Transaction Layer Configuration Space Signals x
4.10.1. Configuration Space Register Access Timing 4.10.2. Configuration Space Register Access
4.13. Physical Layer Interface Signals x
4.13.1. Transceiver Reconfiguration 4.13.2. Serial Interface Signals 4.13.3. Hard IP Reconfiguration Interface 4.13.4. PIPE Interface Signals 4.13.5. Test Signals
4.13.2. Serial Interface Signals x
4.13.2.1. Physical Layout of Hard IP in Arria V Devices 4.13.2.2. Channel Placement in Arria V Devices
5. Registers x
5.1. Correspondence between Configuration Space Registers and the PCIe Specification 5.2. Type 0 Configuration Space Registers 5.3. Type 1 Configuration Space Registers 5.4. PCI Express Capability Structures 5.5. Intel-Defined VSEC Registers 5.6. CvP Registers 5.7. Uncorrectable Internal Error Mask Register 5.8. Uncorrectable Internal Error Status Register 5.9. Correctable Internal Error Mask Register 5.10. Correctable Internal Error Status Register
6. Interrupts x
6.1. Interrupts for Endpoints 6.2. Interrupts for Root Ports
6.1. Interrupts for Endpoints x
6.1.1. MSI Interrupts 6.1.2. MSI-X 6.1.3. Implementing MSI-X Interrupts
6.1.3. Implementing MSI-X Interrupts x
6.1.3.1. Legacy Interrupts
6.1.3.1. Legacy Interrupts x
6.1.3.1.1. Enabling MSI or Legacy Interrupts
7. Error Handling x
7.1. Physical Layer Errors 7.2. Data Link Layer Errors 7.3. Transaction Layer Errors 7.4. Error Reporting and Data Poisoning 7.5. Uncorrectable and Correctable Error Status Bits
8. IP Core Architecture x
8.1. Top-Level Interfaces 8.2. Transaction Layer 8.3. Data Link Layer 8.4. Physical Layer 8.5. Multi-Function Support
8.1. Top-Level Interfaces x
8.1.1. Avalon-ST Interface 8.1.2. Clocks and Reset 8.1.3. Local Management Interface (LMI Interface) 8.1.4. Hard IP Reconfiguration 8.1.5. Transceiver Reconfiguration 8.1.6. Interrupts 8.1.7. PIPE
8.2. Transaction Layer x
8.2.1. Configuration Space
9. Transaction Layer Protocol (TLP) Details x
9.1. Supported Message Types 9.2. Transaction Layer Routing Rules 9.3. Receive Buffer Reordering
9.1. Supported Message Types x
9.1.1. INTX Messages 9.1.2. Power Management Messages 9.1.3. Error Signaling Messages 9.1.4. Locked Transaction Message 9.1.5. Slot Power Limit Message 9.1.6. Vendor-Defined Messages 9.1.7. Hot Plug Messages
9.3. Receive Buffer Reordering x
9.3.1. Using Relaxed Ordering
10. Throughput Optimization x
10.1. Throughput of Posted Writes 10.2. Throughput of Non-Posted Reads
11. Design Implementation x
11.1. Making Analog QSF Assignments Using the Assignment Editor 11.2. Making Pin Assignments 11.3. Recommended Reset Sequence to Avoid Link Training Issues
12. Additional Features x
12.1. Configuration over Protocol (CvP) 12.2. Autonomous Mode 12.3. ECRC
12.2. Autonomous Mode x
12.2.1. Enabling Autonomous Mode 12.2.2. Enabling CvP Initialization
12.3. ECRC x
12.3.1. ECRC on the RX Path 12.3.2. ECRC on the TX Path
14. Transceiver PHY IP Reconfiguration x
14.1. Connecting the Transceiver Reconfiguration Controller IP Core 14.2. Transceiver Reconfiguration Controller Connectivity for Designs Using CvP
15. Testbench and Design Example x
15.1. Endpoint Testbench 15.2. Root Port Testbench 15.3. Test Driver Module 15.4. Root Port Design Example 15.5. Root Port BFM Overview 15.6. BFM Procedures and Functions 15.7. Setting Up Simulation
15.1. Endpoint Testbench x
15.1.1. Endpoint Testbench for SR-IOV
15.5. Root Port BFM Overview x
15.5.1. BFM Memory Map 15.5.2. Configuration Space Bus and Device Numbering 15.5.3. Configuration of Root Port and Endpoint 15.5.4. Issuing Read and Write Transactions to the Application Layer
15.6. BFM Procedures and Functions x
15.6.1. ebfm_barwr Procedure 15.6.2. ebfm_barwr_imm Procedure 15.6.3. ebfm_barrd_wait Procedure 15.6.4. ebfm_barrd_nowt Procedure 15.6.5. ebfm_cfgwr_imm_wait Procedure 15.6.6. ebfm_cfgwr_imm_nowt Procedure 15.6.7. ebfm_cfgrd_wait Procedure 15.6.8. ebfm_cfgrd_nowt Procedure 15.6.9. BFM Configuration Procedures 15.6.10. BFM Shared Memory Access Procedures 15.6.11. BFM Log and Message Procedures 15.6.12. Verilog HDL Formatting Functions
15.6.9. BFM Configuration Procedures x
15.6.9.1. ebfm_cfg_rp_ep Procedure 15.6.9.2. ebfm_cfg_decode_bar Procedure
15.6.10. BFM Shared Memory Access Procedures x
15.6.10.1. Shared Memory Constants 15.6.10.2. shmem_write Task 15.6.10.3. shmem_read Function 15.6.10.4. shmem_display Verilog HDL Function 15.6.10.5. shmem_fill Procedure 15.6.10.6. shmem_chk_ok Function
15.6.11. BFM Log and Message Procedures x
15.6.11.1. ebfm_display Verilog HDL Function 15.6.11.2. ebfm_log_stop_sim Verilog HDL Function 15.6.11.3. ebfm_log_set_suppressed_msg_mask Task 15.6.11.4. ebfm_log_set_stop_on_msg_mask Verilog HDL Task 15.6.11.5. ebfm_log_open Verilog HDL Function 15.6.11.6. ebfm_log_close Verilog HDL Function
15.6.12. Verilog HDL Formatting Functions x
15.6.12.1. himage1 15.6.12.2. himage2 15.6.12.3. himage4 15.6.12.4. himage8 15.6.12.5. himage16 15.6.12.6. dimage1 15.6.12.7. dimage2 15.6.12.8. dimage3 15.6.12.9. dimage4 15.6.12.10. dimage5 15.6.12.11. dimage6 15.6.12.12. dimage7
15.7. Setting Up Simulation x
15.7.1. Changing Between Serial and PIPE Simulation 15.7.2. Using the PIPE Interface for Gen1 and Gen2 Variants 15.7.3. Viewing the Important PIPE Interface Signals 15.7.4. Disabling the Scrambler for Gen1 and Gen2 Simulations 15.7.5. Disabling 8B/10B Encoding and Decoding for Gen1 and Gen2 Simulations 15.7.6. Changing between the Hard and Soft Reset Controller
16. Debugging x
16.1. Hardware Bring-Up Issues 16.2. Link Training 16.3. Use Third-Party PCIe Analyzer 16.4. BIOS Enumeration Issues
16.2. Link Training x
16.2.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
C. Document Revision History x
C.1. Document Revision History of the Arria V Avalon® Streaming (Avalon-ST) Interface for PCIe* Solutions User Guide
1. Datasheet
2. Getting Started with the Arria V Hard IP for PCI Express
3. Parameter Settings
4. Interfaces and Signal Descriptions
5. Registers
6. Interrupts
7. Error Handling
8. IP Core Architecture
9. Transaction Layer Protocol (TLP) Details
10. Throughput Optimization
11. Design Implementation
12. Additional Features
13. Hard IP Reconfiguration
14. Transceiver PHY IP Reconfiguration
15. Testbench and Design Example
16. Debugging
A. Transaction Layer Packet (TLP) Header Formats
B. Lane Initialization and Reversal
C. Document Revision History

4.1.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 or 128.

Table 26.  64- or 128‑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- and 128-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. 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 or 128.

tx_st_sop

Input

Indicates first cycle of a TLP when asserted together with tx_st_valid.

tx_st_eop

Input

Indicates last cycle of a TLP when asserted together with tx_st_valid.

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.

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 the 128-Bit interface:
  • If tx_st_empty = 0, tx_st_data[127:0] contains valid data.
  • If tx_st_empty = 1, tx_st_data[63:0] contains valid data.
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.

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_fifo_empty Output

When asserted, indicates that no TLPs are pending in the internal TX FIFO.

Component Specific Signals

tx_cred_datafccp[11:0]

Output

Data credit limit for the received FC completions. Each credit is 16 bytes.

tx_cred_datafcnp[11:0]

Output

Data credit limit for the non-posted requests. Each credit is 16 bytes.

tx_cred_datafcp[11:0]

Output

Data credit limit for the FC posted writes. Each credit is 16 bytes.

tx_cred_fchipcons[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. The Application Layer must keep track of its own consumed credits. To calculate the total credits consumed, the Application Layer must add its own credits consumed to those consumed by the Hard IP for PCIe. The credit signals are valid after dlup (data link up) is asserted.

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_fcinfinite[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_hdrfccp[7:0]

Output

Header credit limit for the FC completions. Each credit is 20 bytes.

tx_cred_hdrfcnp[7:0]

O

Header limit for the non-posted requests. Each credit is 20 bytes.

tx_cred_hdrfcp[7:0]

O

Header credit limit for the FC posted writes. Each credit is 20 bytes.

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
Root Port Mode Configuration Requests

Level Two Title