Visible to Intel only — GUID: nik1410565000689
Ixiasoft
1. Datasheet
2. Getting Started with the Stratix V Hard IP for PCI Express
3. Getting Started with the Configuration Space Bypass Mode Qsys Example Design
4. Parameter Settings
5. Interfaces and Signal Descriptions
6. Registers
7. Interrupts
8. Error Handling
9. PCI Express Protocol Stack
10. Transaction Layer Protocol (TLP) Details
11. Throughput Optimization
12. Design Implementation
13. Additional Features
14. Hard IP Reconfiguration
15. Transceiver PHY IP Reconfiguration
16. Testbench and Design Example
17. Debugging
A. Frequently Asked Questions for PCI Express
B. Lane Initialization and Reversal
C. Document Revision History
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 Simulation Log File Generation
2.1.6. Understanding Physical Placement of the PCIe IP Core
2.1.7. Compiling the Design in the Qsys Design Flow
2.1.8. Modifying the Example Design
2.1.9. Using the IP Catalog To Generate Your Stratix V Hard IP for PCI Express as a Separate Component
3.3.1. Timing for Configuration Read to Function 0 for the 256-Bit Avalon-ST Interface
3.3.2. Timing for Configuration Write to Function 0 for the 256-Bit Avalon-ST Interface
3.3.3. Timing for Memory Write and Read of Function 1 256-Bit Avalon-ST Interface
3.3.4. Partial Transcript for Configuration Space Bypass Simulation
5.1. Clock Signals
5.2. Reset, Status, and Link Training Signals
5.3. ECRC Forwarding
5.4. Error Signals
5.5. Interrupts for Endpoints
5.6. Interrupts for Root Ports
5.7. Completion Side Band Signals
5.8. Configuration Space Bypass Mode Interface Signals
5.9. Parity Signals
5.10. LMI Signals
5.11. Transaction Layer Configuration Space Signals
5.12. Hard IP Reconfiguration Interface
5.13. Power Management Signals
5.14. Physical Layer Interface Signals
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. CvP Registers
6.7. Uncorrectable Internal Error Mask Register
6.8. Uncorrectable Internal Error Status Register
6.9. Correctable Internal Error Mask Register
6.10. Correctable Internal Error Status Register
16.6.1. ebfm_barwr Procedure
16.6.2. ebfm_barwr_imm Procedure
16.6.3. ebfm_barrd_wait Procedure
16.6.4. ebfm_barrd_nowt Procedure
16.6.5. ebfm_cfgwr_imm_wait Procedure
16.6.6. ebfm_cfgwr_imm_nowt Procedure
16.6.7. ebfm_cfgrd_wait Procedure
16.6.8. ebfm_cfgrd_nowt Procedure
16.6.9. BFM Configuration Procedures
16.6.10. BFM Shared Memory Access Procedures
16.6.11. BFM Log and Message Procedures
16.6.12. Verilog HDL Formatting Functions
16.7.1. Changing Between Serial and PIPE Simulation
16.7.2. Using the PIPE Interface for Gen1 and Gen2 Variants
16.7.3. Viewing the Important PIPE Interface Signals
16.7.4. Disabling the Scrambler for Gen1 and Gen2 Simulations
16.7.5. Disabling 8B/10B Encoding and Decoding for Gen1 and Gen2 Simulations
16.7.6. Changing between the Hard and Soft Reset Controller
Visible to Intel only — GUID: nik1410565000689
Ixiasoft
16. Testbench and Design Example
This chapter introduces the Root Port or Endpoint design example including a testbench, BFM, and a test driver module. You can create this design example for using design flows described in Getting Started with the Stratix V Hard IP for PCI Express .
When configured as an Endpoint variation, the testbench instantiates a design example and a Root Port BFM which provides the following functions:
- A configuration routine that sets up all the basic configuration registers in the Endpoint. This configuration allows the Endpoint application to be the target and initiator of PCI Express transactions.
- A Verilog HDL procedure interface to initiate PCI Express* transactions to the Endpoint.
When configured as a Root Port, the testbench instantiates a Root Port design example and an Endpoint model, which provides the following functions:
- A configuration routine that sets up all the basic configuration registers in the Root Port and the Endpoint BFM. This configuration allows the Endpoint application to be the target and initiator of PCI Express transactions.
- A Verilog HDL procedure interface to initiate PCI Express transactions to the Endpoint BFM.
This testbench simulates a single Endpoint or Root Port DUT.
The testbench uses a test driver module, altpcietb_bfm_rp_<gen>_x8.sv, to exercise the target memory. At startup, the test driver module displays information from the Root Port Configuration Space registers, so that you can correlate to the parameters you specified using the parameter editor.
Note: The Intel testbench and Root Port or Endpoint BFM provide a simple method to do basic testing of the Application Layer logic that interfaces to the variation. This BFM allows you to create and run simple task stimuli with configurable parameters to exercise basic functionality of the Intel example design. The testbench and Root Port BFM are not intended to be a substitute for a full verification environment. Corner cases and certain traffic profile stimuli are not covered. Refer to the items listed below for further details. To ensure the best verification coverage possible, Intel suggests strongly that you obtain commercially available PCI Express verification IP and tools, or do your own extensive hardware testing or both.
Your Application Layer design may need to handle at least the following scenarios that are not possible to create with the Intel testbench and the Root Port BFM:
- It is unable to generate or receive Vendor Defined Messages. Some systems generate Vendor Defined Messages. Consequently, you must design the Application Layer to process them. The Hard IP block passes these messages on to the Application Layer which, in most cases should ignore them.
- It can only handle received read requests that are less than or equal to the currently set Maximum payload size option specified under PCI Express/PCI Capabilities heading under the Device tab using the parameter editor. Many systems are capable of handling larger read requests that are then returned in multiple completions.
- It always returns a single completion for every read request. Some systems split completions on every 64-byte address boundary.
- It always returns completions in the same order the read requests were issued. Some systems generate the completions out-of-order.
- It is unable to generate zero-length read requests that some systems generate as flush requests following some write transactions. The Application Layer must be capable of generating the completions to the zero length read requests.
- It uses fixed credit allocation.
- It does not support parity.
- It does not support multi-function designs.
- It does not support Single Root I/O Virtualization (SR-IOV).