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.8. Interrupt Interface

The SR-IOV Bridge supports MSI and MSI-X interrupts for both Physical and Virtual Functions. It also supports legacy Interrupts for Physical Functions. The Application Layer can use this interface to generate MSI or MSI-X interrupts from both PFs and VFs. The Application Layer can generate legacy interrupts from PFs only. The Application Layer should select one of the three types of interrupts, depending on the support provided by the platform and the software drivers. Ground the input pins for the unused interrupt types.

This interface also includes signals to set and clear the individual bits in the MSI Pending Bit Register.

Table 28.  MSI Interrupts

Signal

Direction

Description

app_msi_req

Input

When asserted, the Application Layer is requesting that an MSI interrupt be sent. Assertion causes an MSI posted write TLP to be generated. The MSI TLP uses app_msi_req_fn[7:0], app_msi_tc and app_msi_num to create the TLP. Refer to Timing Diagram for MSI Interrupt Generation for a timing diagram.

app_msi_req_fn[7:0]

Input

Specifies the function generating the MSI or MSI-X interrupt. Driven in the same cycle as app_msi_req or app_msix_req.

app_msi_ack

Output

Ack for MSI interrupts. When asserted, indicates that Hard IP has sent an MSI posted write TLP in response app_msi_req . The Application Layer must wait for app_msi_ack after asserting app_msi_req. The Application Layer must de-assert app_msi_req for at least 1 cycle before signaling a new MSI interrupt.

app_msi_addr_pf[127:0]

Output

Driven by the MSI address registers of PF0 and PF1. app_msi_addr_pf[63:0] specifies the PF0 address. app_msi_addr_pf[127:64] specifies the PF1 address.
app_msi_data_pf[16<n>-1:0]

Output

Driven by the MSI Data Registers of PF0 and PF1. <n>= the number of PFs.

app_msi_enable_pf[1:0]

Output

Driven by the MSI Enable bit of the MSI Control Registers of PF0 and PF1.

app_msi_mask_pf[32<n>-1:0]

Output

The MSI Mask Bits of the MSI Capability Structure drive app_msi_mask_pf. This mask allows software to disable or defer message sending on a per-vector basis. app_msi_mask_pf[31:0] mask vectors for PF0.app_msi_mask_pf[63:32] mask vectors for PF1.

app_msi_multi_msg_enable_pf[5:0]

Output

Defines the number of interrupt vectors enabled for each PF. The following encodings are defined:

  • 3'b000: 1 vector
  • 3'b001: 2 vectors
  • 3'b010: 4 vectors
  • 3'b100: 16 vectors
  • 3'b101: 32 vectors

The MSI Multiple Message Enable field of the MSI Control Register of PF0 drives app_msi_multi_msg_enable_pf[2:0]. The MSI Multiple Message Enable field of the MSI Control Register of PF1 drives app_msi_multi_msg_enable_pf[5:3].

app_msi_num[4:0]

Input

Identifies the MSI interrupt type to be generated. Provides the low-order message data bits to be sent in the message data field of MSI messages. Only bits that are enabled by the MSI Message Control Register apply.

app_msi_pending_bit_write_data

Input

Writes the MSI Pending Bit Register of the specified function when msi_pending_bit_write_en is asserted. app_msi_num[4:0] specifies the bit to be written. For more information about the MSI Pending Bit Array (PBA), refer to Section 6.8.1.7 Mask Bits for MSI (Optional) in the PCI Local Bus Specification, Revision 3.0. Refer to Timing Diagram for MSI Pending Bit Write Operation below.

msi_pending_bit_write_en

Input

Writes a 0 or 1 into selected bit position in the MSI Pending Bit Register. app_msi_num[4:0] specifies the bit to be written. msi_pending_bit_write_data specifies the data to be written (0 or 1). app_msi_req_fn specifies the function number.

msi_pending_bit_write_en cannot be asserted when app_msi_req is high. Refer to Timing Diagram for MSI Pending Bit Write Operation below.

app_msi_pending_pf[63:0]

Output

The MSI Data Registers of PF0 and PF1 drive msi_pending_pf[63:0]

app_msi_tc[2:0]

Input

Specifies the traffic class to be used to send the MSI or MSI-X posted write TLP. Must be valid when app_msi_req or app_msix_req is asserted.

app_msi_status[1:0] Output

Indicates the status of an MSI request. Valid when app_msi_ack is asserted. The following encodings are defined:

  • 2'b00: MSI message sent
  • 2'b01: MSI message is pending and not sent upstream because the MSI mask was set. And, the Pending bit was set for the MSI number.
  • 2/b10: Requested aborted because of invalid parameters. Or, request aborted because the MSI Enabled bit was not set in the function's MSI Capability structure.
  • 2'b11: Reserved.
Figure 9. Timing Diagram for MSI Interrupt Generation
Figure 10. Timing Diagram for MSI Pending Bit Write Operation The MSI Pending Bit Write Operation aborts the pending MSI interrupt.
Table 29.   MSI-X Interrupts

Signal

Direction

Description

app_msix_req

Input

When asserted, the Application Layer is requesting that an MSI-X interrupt be sent. Assertion causes an MSI-X posted write TLP to be generated. The MSI-X TLP uses data from app_msi_req_fn, app_msix_addr, app_msix_data, and app_msi_tc inputs. Refer to Timing Diagram for MSI-X Interrupt Generation below.

app_msix_ack

Output

Ack for MSI-X interrupts. When asserted, indicates that Hard IP has sent an MSI-X posted write TLP in response app_msix_req . The Application Layer must wait for after asserting app_msix_req. The Application Layer must de-assert app_msix_req for at least 1 cycle before signaling a new MSI interrupt.

app_msix_addr[63:0]

Input

The Application Layer drives the address for the MSI-X posted write TLP on this input. Driven in the same cycle as app_msix_req.

app_msix_data[31:0]

Input

The Application Layer drives app_msix_data[31:0] for the MSI-X posted write TLP. Driven in the same cycle as app_msix_req.

app_msix_enable_pf[1:0]

Output

The MSI-X Enable bit of PF0 and PF1 MSI-X Control Register drive this output.

app_msix_enable_vf[<n>-1:0]

Output

The MSI-X Enable bit of the MSI-X Control Register for VF0 drives bit[0]. The MSI-X Enable bit of the MSI-X Control Register for VF1 drives bit[1], and so on.

app_msix_err

Output

Indicates an error during the execution of an MSI-X request. Valid when app_msix_ack is asserted. The following encodings are defined:

  • 1b'0: MSI-X message sent
  • 1b'1: Error detected during execution of the MSI-X request. No message sent. The following errors may occur:
    • The function number is invalid
    • The MSI-X Enable bit for the function was not set
    • The MSI-X Function Mask was not set

app_msix_fn_mask_pf[1:0]

Output

The MSI-X Function Mask bit of PF0 and PF1 MSI-X Control Register drive this output.

app_msix_fn_mask_vf[<n>-1:0]

Output

The MSI-X Function Mask bit of the MSI-X Control Register for VF0 drives bit[0]. The MSI-X Function Mask bit of the MSI-X Control Register for VF1 drives bit[1], and so on. <n> equals the total number of VFs for both PF0 and PF1.

Figure 11. Timing Diagram for MSI-X Interrupt Generation
Table 30.  Legacy Interrupts

Signal

Direction

Description

app_int_sts_a

Input

The Application Layer uses this signal to generate a legacy INT<x> interrupt. <x> corresponds to a-d for functions programmed to use interrupt pins a-d. The Hard IP sends an INTx_Assert message upstream to the Root Complex in response to a low-to- high transition. The Hard IP sends a INTX_Deassert in response to a high-to-low transition. The INTX_Deassert message is only sent if a previous INTx_Assert message was sent. Legacy Interrupt Assertion and Legacy Interrupt Deassertion for timing diagrams.

This input has no effect if the INT<x>Disable bit in the PCI Command Register of the interrupting function is set to 1.

app_int_sts_b

Input

app_int_sts_c

Input

app_int_sts_d

Input

app_int_ack

Output

A pulse on this output indicates that an INTx_Assert or INTX_Deassert message has been sent. Assertion is in response to a transition on aapp_int_sts_<x> input. This signal is asserted for at least 1 cycle when an INTx_Assert message TLP has been transmitted. It is asserted when either of the following occurs:
  • A low-to-high transition on one of the app_int_sts_<x> inputs
  • A INTX_Deassert message TLP has been transmitted in response to a high-to-low transition
The Application Layer must wait for app_int_ack the after making a transition on one of theapp_int_sts_<x> inputs, before signaling a new transition.
app_int_pend_status[1:0] Input The Application Layer must drive each of these inputs with the interrupt pending status of the corresponding PF. The Interrupt Pending Status bit of the PCI Status Register records the pending status .

app_int_sts_fn

Input

Identifies the function generating the legacy interrupt. When app_int_sts_fn = 0, specifies status for PF0. When app_int_sts_fn = 1, specifies status for PF1.

app_intx_disable[1:0]

Output

This output is driven by the INT<x>Disable bit of the PCI Command Register of FP0 and PF1. app_intx_disable[0] disables PF0. app_intx_disable[1] disables PF1.

Figure 12. Legacy Interrupt Assertion
Figure 13. Legacy Interrupt Deassertion
Related Information
Level Two Title