Configuration via Protocol (CvP) Implementation in V-series FPGA Devices User Guide

Download PDF
ID 683889
Date 9/04/2020
Public
Document Table of Contents
Document Table of Contents x
1. Overview 2. FPGA Configuration using CvP 3. CvP Topologies 4. Design Considerations 5. CvP Example Designs 6. CvP Driver and Registers 7. Document Revision History for the Configuration via Protocol (CvP) Implementation in V-series FPGA Devices User Guide
1. Overview x
1.1. Benefits of Using CvP 1.2. CvP System 1.3. CvP Modes 1.4. CvP Revision Design Flow 1.5. CvP Topologies 1.6. Additional Information about PCI Express
2. FPGA Configuration using CvP x
2.1. CvP Configuration Images 2.2. CvP Modes 2.3. Alternative to CvP Initialization: Autonomous HIP Mode 2.4. CvP Compression and Encryption Features 2.5. Core Image Update 2.6. CvP Pins
2.2. CvP Modes x
2.2.1. CvP Initialization Mode 2.2.2. CvP Update Mode
2.4. CvP Compression and Encryption Features x
2.4.1. Data Compression 2.4.2. Data Encryption
3. CvP Topologies x
3.1. Single Endpoint 3.2. Multiple Endpoints 3.3. Mixed Chain
3.3. Mixed Chain x
3.3.1. Configuring Slave FPGAs with Different Configuration Files 3.3.2. Configuring Slave FPGAs with a Single Configuration File
4. Design Considerations x
4.1. Preparing the Design for CvP Revision Design Flow 4.2. Designing CvP for an Open System 4.3. Designing CvP for a Closed System 4.4. Clock Connections for CvP Designs Including the Transceiver Reconfiguration Controller
4.2. Designing CvP for an Open System x
4.2.1. FPGA Power Supplies Ramp Time Requirement 4.2.2. PCIe Wake-Up Time Requirement
4.2.2. PCIe Wake-Up Time Requirement x
4.2.2.1. PCIe Wake-Up Time Requirement for CvP Initialization Mode 4.2.2.2. PCIe Wake-Up Time Requirement for CvP Update Mode
4.2.2.2. PCIe Wake-Up Time Requirement for CvP Update Mode x
4.2.2.2.1. Recommended Configuration Schemes 4.2.2.2.2. Estimating PCIe Wake-Up Time Requirement
5. CvP Example Designs x
5.1. Understanding the Design Steps for CvP Initialization Mode 5.2. Understanding the Design Steps for CvP Initialization Mode with the Revision Design Flow 5.3. Understanding the Design Steps for CvP Update Mode 5.4. Bringing Up the Hardware 5.5. CvP Debugging Check List 5.6. Known Issues and Solutions
5.1. Understanding the Design Steps for CvP Initialization Mode x
5.1.1. Downloading and Generating the High Performance Reference Design 5.1.2. Setting up CvP Parameters for CvP Initialization Mode 5.1.3. Compiling the Design for the CvP Initialization Mode 5.1.4. Splitting the SOF File for the CvP Initialization Design Mode
5.2. Understanding the Design Steps for CvP Initialization Mode with the Revision Design Flow x
5.2.1. Downloading and Generating the High Performance Reference Design 5.2.2. Workaround for a Known Issue with Transceiver Reconfiguration Controller IP Core 5.2.3. Creating an Alternate user_led.v File for the Reconfigurable Core Region 5.2.4. Setting up CvP Parameters for CvP Initialization Mode 5.2.5. Creating CvP Revisions of the Core Logic Region Using the CvP Revision Design Flow 5.2.6. Compiling both the Base and cvp_app Revisions in the CvP Revision Design Flow 5.2.7. Splitting the SOF File for the CvP Initialization Mode with the CvP Revision Design Flow
5.3. Understanding the Design Steps for CvP Update Mode x
5.3.1. Downloading and Generating the High Performance Reference Design 5.3.2. Workaround for a Known Issue with Transceiver Reconfiguration Controller IP Core 5.3.3. Creating an Alternate user_led.v File for the Reconfigurable Core Region 5.3.4. Setting up CvP Parameters for CvP Update Mode 5.3.5. Creating CvP Revisions of the Core Logic Region Using the CvP Revision Design Flow 5.3.6. Compiling the Design for the CvP Update Mode 5.3.7. Splitting the SOF File for the CvP Update Design Mode 5.3.8. Splitting the SOF File for the CvP Update Mode with the CvP Revision Design Flow
5.4. Bringing Up the Hardware x
5.4.1. Installing Jungo WinDriver in Windows Systems 5.4.2. Installing Jungo WinDriver in Linux Systems 5.4.3. Installing Open Source CvP Driver in Linux System 5.4.4. Modifying MSEL for Active Serial x4 Flash on Stratix V Dev-Kit 5.4.5. Programming CvP Images and Validating the Link
5.6. Known Issues and Solutions x
5.6.1. Using MSI-X in CvP Initialization Mode
6. CvP Driver and Registers x
6.1. CvP Driver Support 6.2. CvP Driver Flow 6.3. VSEC Registers for CvP
6.3. VSEC Registers for CvP x
6.3.1. Altera-defined Vendor Specific Capability Header Register 6.3.2. Altera-defined Vendor Specific Header Register 6.3.3. Altera Marker Register 6.3.4. CvP Status Register 6.3.5. CvP Mode Control Register 6.3.6. CvP Data Registers 6.3.7. CvP Programming Control Register 6.3.8. Uncorrectable Internal Error Status Register 6.3.9. Uncorrectable Internal Error Mask Register 6.3.10. Correctable Internal Error Status Register 6.3.11. Correctable Internal Error Mask Register
1. Overview
2. FPGA Configuration using CvP
3. CvP Topologies
4. Design Considerations
5. CvP Example Designs
6. CvP Driver and Registers
7. Document Revision History for the Configuration via Protocol (CvP) Implementation in V-series FPGA Devices User Guide

5.5. CvP Debugging Check List

  1. Check the PCIe configuration to ensure that it supports CvP. For instance, Stratix V does not support Gen3 CvP.
  2. Confirm that the current Quartus Prime software version supports CvP.
  3. Check that your physical pin assignments support CvP. For Example, for Stratix V, only the bottom left Stratix V Hard IP for PCI Express supports CvP. Other Hard IP cores in the same device do not support CvP.
  4. Check the PCB connections for PERST# and refclk.
  5. Make sure the reset and clock connections to the Transceiver Reconfiguration Controller IP Core are correct. For CvP mode, you must use refclk to drive reconfig_clk. PERST#must drive reconfig_reset to the Hard IP for PCI Express IP Core.
  6. Confirm that the design meets timing constraints for setup, hold time, and recovery for multi-corners.
  7. Check that the test_in bus is hardwired to 0xA8. The following test_in signals are most important when debugging:
    1. Setting test_in[7]=1 disables support for the low power states.
    2. Setting test_in[5]=1 prevents the core from entering the Compliance Mode.
    3. Setting test_in[3]=1 indicates that the Hard IP for PCI Express is implemented in an FPGA.
    4. Setting test_in[0] = 0 uses timeout and counter values which meet the PCIe specifications. Otherwise the shorter, non-compliant simulation values are used.
  8. Disable power management support in the host BIOS settings.
  9. Confirm that the Vendor ID and Device ID arguments specified as arguments to the quartus_cvp.exe command match the values specified in the Hard IP for PCI Express IP Core GUI.
  10. If you are designing an open system, test with different PCs and compare the results.
  11. If the first CvP update fails, check that the correct quartus_cvp.exe command is used. For 32-bit systems, you must use .\quartus\bin\quartus_cvp.exe. For 64-bit systems, the correct quartus_cvp version is .\quartus\bin64.
  12. Before executing the quartus_cvp command, make sure that the Memory Space Enable bit is set in the Command register of PCI Express Configuration Space. If the BIOS does not enable this bit, you must use a system tool such as RW Utilities to write a value of 0x0006 to the Command register at offset 0x4. Writing this value will set both Memory Space Enable and Master Bus Enable bits.
  13. If encryption or compression is enabled, disable them and retry. Record the symptoms.
  14. Check if the design works after configuring the FPGA with the SOF via JTAG and then doing a warm reboot. The .sof file contains both periphery image and the core image; consequently, this test will not determine which type of image causes the failure.
  15. Use a PCI Express analyzer to capture the PCIe trace of the failing scenarios. Observe the transitions of LTSSM if it fails to get insight into the link failures.
  16. Use the Power On Trigger of the SignalTap II Embedded Logic Analyzer and record the LTSSM transitions. Determine whether the LTSSM goes to L0 (0xF) or toggles between Detect states and Polling states.
  17. Disable the Transceiver Reconfiguration Controller and hardwire other inputs to zero, except the reconfig_to_xcvr() bus which requires bit[44] of each channel to be driven high. The remaining bit of reconfig_to_xcvr() are tied to low. The sample file is top_wo_reconfig.v under ./altera_pcie_cvp/hw_devkit_ed directory.
  18. If CvP fails, try a similar Altera CvP example design to determine if the symptoms remain the same. If the failure still persists, try a non-CvP design and take note of the differences.
  19. Determine if the example CvP design with similar configuration works on the same platform.
  20. If you have tried all these suggestions and your design is still not working, file a Service Request (SR). In your SR, include the following information:
    1. Describe what you have tried and the results of your tests.
    2. List the Quartus Prime software version, the target device, information about the system under test, and what CvP modes are being used.
    3. Specify where the failure occurs. Does it occur after loading the periphery, on the first CvP update, or on subsequent CvP updates?
    4. If possible, attach your design so that we can review the reset and clock connections and try to replicate your failure.
    5. Describe the steps necessary to run your design.
  21. For subsequent CvP update, you must compile both revisions for any changes to any of the following logic:
    1. The periphery logic
    2. The I/O ports or core wrapper
    3. The Quartus Prime software version
Related Information
Level Two Title