Stratix V Avalon-ST Interface with SR-IOV PCIe Solutions: User Guide

Download PDF
ID 683488
Date 5/02/2016
Public
Document Table of Contents
Document Table of Contents x
1. Datasheet 2. Getting Started with the SR-IOV DMA Example Design 3. Parameter Settings 4. Interfaces and Signal Descriptions 5. Registers 6. Programming and Testing SR-IOV Bridge MSI Interrupts 7. Error Handling 8. IP Core Architecture 9. Design Implementation 10. Transceiver PHY IP Reconfiguration 11. Debugging A. Frequently Asked Questions for PCI Express B. Transaction Layer Packet (TLP) Header Formats C. Stratix V Avalon-ST with SR-IOV Interface for PCIe Solutions User Guide Archive 12. Document Revision History
1. Datasheet x
1.1. Stratix® V Avalon-ST Interface with SR-IOV for PCIe Datasheet 1.2. Release Information 1.3. Device Family Support 1.4. Design Examples for SR-IOV 1.5. Debug Features 1.6. IP Core Verification 1.7. Performance and Resource Utilization 1.8. Recommended Speed Grades for SR-IOV Interface 1.9. Creating a Design for PCI Express
1.1. Stratix® V Avalon-ST Interface with SR-IOV for PCIe Datasheet x
1.1.1. SR-IOV Features
1.6. IP Core Verification x
1.6.1. Compatibility Testing Environment
2. Getting Started with the SR-IOV DMA Example Design x
2.1. Generating the Example Design Testbench 2.2. Understanding the Generated Files and Directories 2.3. Simulating the SR-IOV Example Design 2.4. Running a Gate-Level Simulation 2.5. Understanding the DMA Functionality 2.6. Compiling the Example Design with the Quartus® Prime Software 2.7. Using the IP Catalog To Generate Your Stratix V Hard IP for PCI Express as a Separate Component
3. Parameter Settings x
3.1. System Settings 3.2. SR-IOV System Settings 3.3. Base Address Register (BAR) Settings 3.4. SR-IOV Device Identification Registers 3.5. Interrupt Capabilities 3.6. PCI Express and PCI Capabilities Parameters 3.7. PHY Characteristics 3.8. Simulation Options
3.6. PCI Express and PCI Capabilities Parameters x
3.6.1. Device Capabilities 3.6.2. Error Reporting 3.6.3. Link Capabilities 3.6.4. Slot Capabilities 3.6.5. Power Management
4. Interfaces and Signal Descriptions x
4.1. Avalon-ST TX Interface 4.2. Component-Specific Avalon-ST Interface Signals 4.3. Avalon-ST RX Interface 4.4. BAR Hit Signals 4.5. Configuration Status Interface 4.6. Clock Signals 4.7. Function-Level Reset Interface 4.8. Interrupt Interface 4.9. Configuration Extension Bus (CEB) Interface 4.10. Implementing MSI-X Interrupts 4.11. Local Management Interface (LMI) Signals 4.12. Reset, Status, and Link Training Signals 4.13. Transceiver Reconfiguration 4.14. Serial Data Signals 4.15. Test Signals 4.16. PIPE Interface Signals
4.9. Configuration Extension Bus (CEB) Interface x
4.9.1. Vital Product Data (VPD) Capability
4.9.1. Vital Product Data (VPD) Capability x
4.9.1.1. Determine the Pointer Address of an External Capability Register 4.9.1.2. VPD Capability Implementation
4.14. Serial Data Signals x
4.14.1. Physical Layout of Hard IP In Stratix V Devices 4.14.2. Channel Placement in Arria V GZ and Stratix V GX/GT/GS Devices
5. Registers x
5.1. Correspondence between Configuration Space Registers and the PCIe Specification 5.2. PCI and PCI Express Configuration Space Registers 5.3. MSI Registers 5.4. MSI-X Capability Structure 5.5. Power Management Capability Structure 5.6. PCI Express Capability Structure 5.7. Advanced Error Reporting (AER) Enhanced Capability Header Register 5.8. Uncorrectable Error Status Register 5.9. Uncorrectable Error Mask Register 5.10. Uncorrectable Error Severity Register 5.11. Correctable Error Status Register 5.12. Correctable Error Mask Register 5.13. Advanced Error Capabilities and Control Register 5.14. Header Log Registers 0-3 5.15. SR-IOV Virtualization Extended Capabilities Registers 5.16. Virtual Function Registers
5.2. PCI and PCI Express Configuration Space Registers x
5.2.1. Type 0 Configuration Space Registers 5.2.2. PCI and PCI Express Configuration Space Register Content 5.2.3. Interrupt Line and Interrupt Pin Register
5.15. SR-IOV Virtualization Extended Capabilities Registers x
5.15.1. SR-IOV Virtualization Extended Capabilities Registers Address Map 5.15.2. ARI Enhanced Capability Header 5.15.3. SR-IOV Enhanced Capability Registers 5.15.4. Initial VFs and Total VFs Registers 5.15.5. VF Device ID Register 5.15.6. Page Size Registers 5.15.7. VF Base Address Registers (BARs) 0-5 5.15.8. Secondary PCI Express Extended Capability Header 5.15.9. Lane Status Registers
6. Programming and Testing SR-IOV Bridge MSI Interrupts x
6.1. Setting Up and Verifying MSI Interrupts 6.2. Masking MSI Interrupts 6.3. Dropping a Pending MSI Interrupt
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. Data Link Layer 8.2. Physical Layer 8.3. Top-Level Interfaces 8.4. Physical and Virtual Function Address Assignments 8.5. Stratix V Hard IP for PCI Express with Single-Root I/O Virtualization (SR-IOV)
8.3. Top-Level Interfaces x
8.3.1. Avalon-ST Interface 8.3.2. Clocks and Reset 8.3.3. Transceiver Reconfiguration 8.3.4. Interrupts 8.3.5. PIPE
9. Design Implementation x
9.1. Making Analog QSF Assignments Using the Assignment Editor 9.2. Making Pin Assignments to Assign I/O Standard to Serial Data Pins 9.3. Recommended Reset Sequence to Avoid Link Training Issues 9.4. SDC Timing Constraints
10. Transceiver PHY IP Reconfiguration x
10.1. Connecting the Transceiver Reconfiguration Controller IP Core 10.2. Transceiver Reconfiguration Controller Connectivity for Designs Using CvP
11. Debugging x
11.1. Setting Up Simulation 11.2. Hardware Bring-Up Issues 11.3. Link Training 11.4. Use Third-Party PCIe Analyzer 11.5. BIOS Enumeration Issues
11.1. Setting Up Simulation x
11.1.1. Changing Between Serial and PIPE Simulation 11.1.2. Using the PIPE Interface for Gen1 and Gen2 Variants 11.1.3. Viewing the Important PIPE Interface Signals 11.1.4. Disabling the Scrambler for Gen1 and Gen2 Simulations 11.1.5. Disabling 8B/10B Encoding and Decoding for Gen1 and Gen2 Simulations 11.1.6. Changing between the Hard and Soft Reset Controller
11.3. Link Training x
11.3.1. Debugging Link that Fails To Reach L0
B. Transaction Layer Packet (TLP) Header Formats x
B.1. TLP Packet Formats without Data Payload B.2. TLP Packet Formats with Data Payload
12. Document Revision History x
12.1. Document Revision History for the Intel® Arria® 10 Avalon® Streaming with SR-IOV IP for PCIe* User Guide
1. Datasheet
2. Getting Started with the SR-IOV DMA Example Design
3. Parameter Settings
4. Interfaces and Signal Descriptions
5. Registers
6. Programming and Testing SR-IOV Bridge MSI Interrupts
7. Error Handling
8. IP Core Architecture
9. Design Implementation
10. Transceiver PHY IP Reconfiguration
11. Debugging
A. Frequently Asked Questions for PCI Express
B. Transaction Layer Packet (TLP) Header Formats
C. Stratix V Avalon-ST with SR-IOV Interface for PCIe Solutions User Guide Archive
12. Document Revision History

4.2. Component-Specific Avalon-ST Interface Signals

Table 22.  Component Specific Avalon- ST TX Signals

Signal

Direction

Description

tx_cons_cred_select 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.

This signal is present when you turn On Enable credit consumed selection port in the parameter editor .

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

Output

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

tx_cred_hdrfcnp[7:0]

Output

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

tx_cred_hdrfcp[7:0]

Output

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

The following table describes the signals that comprise the completion side band signals for the Avalon-ST interface. The Stratix V Hard IP for PCI Express provides a completion error interface that the Application Layer can use to report errors, such as programming model errors. When the Application Layer detects an error, it can assert the appropriate cpl_err bit to indicate what kind of error to log. If separate requests result in two errors, both are logged. The Hard IP sets the appropriate status bits for the errors in the Configuration Space. It also automatically sends error messages in accordance with the PCI Express Base Specification. Note that the Application Layer is responsible for sending the completion with the appropriate completion status value for non-posted requests. Refer to Error Handling for information on errors that are automatically detected and handled by the Hard IP.

For a description of the completion rules, the completion header format, and completion status field values, refer to Section 2.2.9 of the PCI Express Base Specification.

Table 23.  Completion Signals for the Avalon-ST Interface

Signal

Direction

Description

cpl_err[6:0]

Input

Completion error from a PF or VF This signal reports completion errors to the Configuration Space. The SR-IOV Bridge responds to the assertion of these bits by logging the status in the error reporting registers of the Function and sending error messages when required. When an error occurs, the appropriate signal is asserted for one cycle. The individual bits indicate following error or status conditions:

  • cpl_err[0]: Completion timeout error with recovery. This signal should be asserted when a master-like interface has performed a non-posted request that never receives a corresponding completion transaction after the 50 ms timeout period when the error is correctable. The Hard IP automatically generates an advisory error message that is sent to the Root Complex.
  • cpl_err[1]: Completion timeout error without recovery. This signal should be asserted when a master-like interface has performed a non-posted request that never receives a corresponding completion transaction after the 50 ms time-out period when the error is not correctable. The Hard IP automatically generates a non-advisory error message that is sent to the Root Complex.
  • cpl_err[2]: Completer abort error. The Application Layer asserts this signal to respond to a non-posted request with a Completer Abort (CA) completion. The Application Layer generates and sends a completion packet with Completer Abort (CA) status to the requestor and then asserts this error signal to the Hard IP. The Hard IP automatically sets the error status bits in the Configuration Space register and sends error messages in accordance with the PCI Express Base Specification. The Application Layer generates and sends a completion packet with Completer Abort (CA) status to the requestor and then asserts this error signal to the Hard IP. The Hard IP automatically sets the error status bits in the Configuration Space register and sends error messages in accordance with the PCI Express Base Specification.
  • cpl_err[3]: Unexpected completion error. This signal must be asserted when an Application Layer master block detects an unexpected Completion. Many cases of unexpected completions are detected and reported internally by the Transaction Layer. For a list of these cases, refer to Transaction Layer Errors/
  • cpl_err[4]: Unsupported Request (UR) error for posted TLP. The Application Layer asserts this signal to treat a posted request as an Unsupported Request.The Hard IP automatically sets the error status bits in the Configuration Space register and sends error messages in accordance with the PCI Express Base Specification. Many cases of Unsupported Requests are detected and reported internally by the Transaction Layer. For a list of these cases, refer to Transaction Layer Errors.
  • cpl_err[5]: Unsupported Request error for non-posted TLP. The Application Layer asserts this signal to respond to a non-posted request with an Request (UR) completion. In this case, the Application Layer sends a completion packet with the Unsupported Request status back to the requestor, and asserts this error signal. The Hard IP automatically sets the error status bits in the Configuration Space Register and sends error messages in accordance with the PCI Express Base Specification. Many cases of Unsupported Requests are detected and reported internally by the Transaction Layer. For a list of these cases, refer to Transaction Layer Errors.
  • cpl_err[6]: Log header. If header logging is required, this bit must be set in the every cycle in which any of cpl_err[2], cpl_err[3], cpl_err[4], or cpl_err[5]is set. The header must be supplied on the inputs log_hdr[127:0].
cpl_err_fn[7:0] Input Specifies the function reporting the error on cpl_err[6:0].
cpl_pending_pf[<n>-1:0] Input

Completion pending from the PF. The Application Layer must assert this signal when a PF has issued one of more Non-Posted transactions waiting for completions. For example, when a Non-Posted Request is pending from PF0. cpl_pending_pf[0] records pending completions for PF0. cpl_pending_pf[1] records pending completions for PF1.

cpl_pending_vf[<n>-1:0] Input Completion pending from VF. The Application Layer must keep bit <n> asserted when the master block associated with Virtual Function <n> is waiting for Completion. For example, when a Non-Posted transaction is pending from VF <n>. <n> is the number of VFs.
log_hdr[127:0] Input When any of the bits 2, 3, 4, 5 of cpl_err is asserted, the Application Layer may provide the header of the TLP that caused the error condition. The order of bytes is the same as the order of the header bytes for the Avalon-ST streaming interfaces.
ko_clp_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_clp_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.
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.
Related Information
Level Two Title