Intel Arria 10 and Intel Cyclone 10 GX Avalon Memory Mapped (Avalon-MM) Interface for PCI Express User Guide
Version Information
Updated for: |
---|
Intel® Quartus® Prime Design Suite 18.0 |
1. Datasheet
1.1. Intel Arria 10 or Intel Cyclone 10 GX Avalon-MM Interface for PCIe Datasheet
Intel® Arria® 10 and Intel® Cyclone® 10 GX FPGAs include a configurable, hardened protocol stack for PCI Express* that is compliant with PCI Express Base Specification 3.0 and PCI Express Base Specification 2.0 respectively.
The Hard IP for PCI Express IP core using the Avalon® Memory-Mapped (Avalon-MM) interface removes some of the complexities associated with the PCIe* protocol. For example, it handles all of the Transaction Layer Packet (TLP) encoding and decoding. Consequently, you can complete your design more quickly. The Avalon-MM interface is implemented as a bridge in soft logic. It is available in Platform Designer.
Link Bandwidth in Gigabits Per Second (Gbps) | ||||
---|---|---|---|---|
x1 | x2 | x4 | x8 | |
PCI Express Gen1 (2.5 Gbps) |
2 |
4 |
8 |
16 |
PCI Express Gen2 (5.0 Gbps) |
4 |
8 |
16 |
32 |
PCI Express Gen3 (8.0 Gbps) |
7.87 |
15.75 |
31.5 |
63 |
Refer to AN 456: PCI Express High Performance Reference Design for more information about calculating bandwidth for the hard IP implementation of PCI Express in many Intel FPGAs.
1.2. Features
New features in the Quartus® Prime 18.0 software release:
- Added support for Intel® Cyclone® 10 GX devices for up to Gen2 x4 configurations.
- Added optional parameter to invert the RX polarity.
The Intel® Arria® 10 or Intel® Cyclone® 10 GX Hard IP for PCI Express with the Avalon-MM interface supports the following features:
- Complete protocol stack including the Transaction, Data Link, and Physical Layers implemented as hard IP.
- Support for ×1, ×2, ×4, and ×8 configurations with Gen1, Gen2, or Gen3 lane rates for Intel® Arria® 10 Root Ports and Endpoints.
- Support for ×1, ×2, and ×4 configurations with Gen1 or Gen2 lane rates for Intel® Cyclone® 10 GX Root Ports and Endpoints.
- Dedicated 16 KB receive buffer.
- Optional support for Configuration via Protocol (CvP) using the PCIe link allowing the I/O and core bitstreams to be stored separately.
- Support for 32- or 64-bit addressing for the Avalon-MM interface to the Application Layer.
- Platform Designer design example demonstrating parameterization, design modules, and connectivity.
- Extended credit allocation settings to better optimize the RX buffer space based on application type.
- Optional end-to-end cyclic redundancy code (ECRC) generation and checking and advanced error reporting (AER) for high reliability applications.
- Easy to use:
- Flexible configuration.
- No license requirement.
- Design examples to get started.
Feature |
Avalon-ST Interface |
Avalon-MM Interface |
Avalon-MM DMA |
---|---|---|---|
IP Core License |
Free |
Free |
Free |
Native Endpoint |
Supported |
Supported |
Supported |
Root port |
Supported |
Supported |
Not supported |
Gen1 |
×1, ×2, ×4, ×8 |
×1, ×2, ×4, ×8 |
x8 |
Gen2 |
×1, ×2, ×4, ×8 |
×1, ×2, ×4, ×8 |
×4, ×8 |
Gen3 |
×1, ×2, ×4, ×8 |
×1, ×2, ×4, x8 1 |
×2, ×4, ×8 |
64-bit Application Layer interface |
Supported |
Supported |
Not supported |
128-bit Application Layer interface |
Supported |
Supported |
Supported |
256‑bit Application Layer interface |
Supported |
Supported |
Supported |
Maximum payload size |
128, 256, 512, 1024, 2048 bytes |
128, 256 bytes |
128, 256 bytes |
Number of tags supported for non-posted requests |
32, 64, 128, or 256 |
8 for the 64-bit interface 16 for the 128-bit interface and 256-bit interface |
16 or 256 |
Automatically handle out-of-order completions (transparent to the Application Layer) |
Not supported |
Not Supported |
Not Supported |
Automatically handle requests that cross 4 KB address boundary (transparent to the Application Layer) |
Not supported |
Supported |
Supported |
Polarity Inversion of PIPE interface signals |
Supported |
Supported |
Supported |
Number of MSI requests |
1, 2, 4, 8, 16, or 32 |
1, 2, 4, 8, 16, or 32 2 |
1, 2, 4, 8, 16, or 32 3 |
MSI-X |
Supported |
Supported |
Supported |
Legacy interrupts |
Supported |
Supported |
Supported |
Expansion ROM |
Supported |
Not supported |
Not supported |
PCIe bifurcation | Not supported | Not supported | Not supported |
TLP (Transmit Support) |
Avalon-ST Interface |
Avalon-MM Interface |
Avalon-MM DMA |
---|---|---|---|
Memory Read Request (Mrd) | EP/RP | EP/RP | EP (Read DMA Avalon-MM Master) |
Memory Read Lock Request (MRdLk) | EP/RP | Not supported | Not supported |
Memory Write Request (MWr) | EP/RP | EP/RP | EP (Write DMA Avalon-MM Master) TX Slave (optional) |
I/O Read Request (IORd) | EP/RP | EP/RP | Not supported |
I/O Write Request (IOWr) | EP/RP | EP/RP | Not supported |
Config Type 0 Read Request (CfgRd0) | RP | RP | Not supported |
Config Type 0 Write Request (CfgWr0) | RP | RP | Not supported |
Config Type 1 Read Request (CfgRd1) | RP | RP | Not supported |
Config Type 1 Write Request (CfgWr1) | RP | RP | Not supported |
Message Request (Msg) | EP/RP | Not supported | Not supported |
Message Request with Data (MsgD) | EP/RP | Not supported | Not supported |
Completion with Data (CplD) | EP/RP | EP/RP | EP (Read & Write DMA Avalon-MM Masters) |
Completion-Locked (CplLk) | EP/RP | Not supported | Not supported |
Completion Lock with Data (CplDLk) | EP/RP | Not supported | Not supported |
Fetch and Add AtomicOp Request (FetchAdd) | EP | Not supported | Not supported |
The Intel® Arria® 10 or Intel® Cyclone® 10 GX Avalon-MM Interface for PCIe Solutions User Guide explains how to use this IP core and not the PCI Express protocol. Although there is inevitable overlap between these two purposes, use this document only in conjunction with an understanding of the PCI Express Base Specification.
1.3. Release Information
Item |
Description |
---|---|
Version |
18.0 |
Release Date | May 2018 |
Ordering Codes |
No ordering code is required |
Product IDs |
There are no encrypted files for the Intel® Arria® 10 or Intel® Cyclone® 10 GX Hard IP for PCI Express. The Product ID and Vendor ID are not required because this IP core does not require a license. |
Vendor ID |
Intel verifies that the current version of the Intel® Quartus® Prime software compiles the previous version of each IP core, if this IP core was included in the previous release. Intel reports any exceptions to this verification in the Intel IP Release Notes or clarifies them in the Intel® Quartus® Prime IP Update tool. Intel does not verify compilation with IP core versions older than the previous release.
1.4. Device Family Support
The following terms define device support levels for Intel® FPGA IP cores:
- Advance support—the IP core is available for simulation and compilation for this device family. Timing models include initial engineering estimates of delays based on early post-layout information. The timing models are subject to change as silicon testing improves the correlation between the actual silicon and the timing models. You can use this IP core for system architecture and resource utilization studies, simulation, pinout, system latency assessments, basic timing assessments (pipeline budgeting), and I/O transfer strategy (data-path width, burst depth, I/O standards tradeoffs).
- Preliminary support—the IP core is verified with preliminary timing models for this device family. The IP core meets all functional requirements, but might still be undergoing timing analysis for the device family. It can be used in production designs with caution.
- Final support—the IP core is verified with final timing models for this device family. The IP core meets all functional and timing requirements for the device family and can be used in production designs.
Device Family |
Support Level |
---|---|
Intel® Arria® 10 or Intel® Cyclone® 10 GX |
Final. |
Other device families |
Refer to the Intel's PCI Express IP Solutions web page for support information on other device families. |
1.5. Configurations
The Avalon-MM Intel® Arria® 10 Hard IP for PCI Express includes a full hard IP implementation of the PCI Express stack comprising the following layers:
- Physical (PHY), including:
- Physical Media Attachment (PMA)
- Physical Coding Sublayer (PCS)
- Media Access Control (MAC)
- Data Link Layer (DL)
- Transaction Layer (TL)
When configured as an Endpoint, the Intel® Arria® 10 or Intel® Cyclone® 10 GX Hard IP for PCI Express using the Avalon-MM supports memory read and write requests and completions with or without data.
- Two Endpoints that connect to a PCIe switch.
- A host CPU that implements CvP using the PCI Express link connects through the switch.
1.6. Design Examples
Platform Designer example designs are available for the Avalon-MM Intel® Arria® 10 or Intel® Cyclone® 10 GX Hard IP for PCI Express IP Core. You can download them from the <install_dir>/ip/altera/altera_pcie/altera_pcie_a10_ed/example_design/a10 and <install_dir>/ip/altera/altera_pcie/altera_pcie_a10_ed/example_design/c10 directories.
When you click the Generate Example Design button in the Parameter Editor, you are prompted to specify the example design location. After example design generation completes, this directory contains the customized example design that matches your parameter settings exactly; starting in the Quartus II software v15.0, this feature is available for most but not all IP core variations. If this feature is not available for your particular parameter settings, the Parameter Editor displays a warning.
Starting from the 18.0 release of the Intel® Quartus® Prime software, you can generate both Endpoint example designs and Root Port example designs.
1.7. IP Core Verification
To ensure compliance with the PCI Express specification, Intel performs extensive verification. The simulation environment uses multiple testbenches that consist of industry‑standard bus functional models (BFMs) driving the PCI Express link interface. Intel performs the following tests in the simulation environment:
- Directed and pseudorandom stimuli test the Application Layer interface, Configuration Space, and all types and sizes of TLPs
- Error injection tests inject errors in the link, TLPs, and Data Link Layer Packets (DLLPs), and check for the proper responses
- PCI-SIG® Compliance Checklist tests that specifically test the items in the checklist
- Random tests that test a wide range of traffic patterns
Intel provides example designs that you can leverage to test your PCBs and complete compliance base board testing (CBB testing) at PCI-SIG, upon request.
1.7.1. Compatibility Testing Environment
Intel has performed significant hardware testing to ensure a reliable solution. In addition, Intel internally tests every release with motherboards and PCI Express switches from a variety of manufacturers. All PCI-SIG compliance tests are run with each IP core release.
1.8. Resource Utilization
Because the PCIe protocol stack is implemented in hardened logic, it uses no core device resources (no ALMs and no embedded memory).
The Avalon-MM soft logic bridge operates as a front end to the hardened protocol stack. The following table shows the typical device resource utilization for selected configurations using the current version of the Quartus® Prime software. With the exception of M20K memory blocks, the numbers of ALMs and logic registers are rounded up to the nearest 50.
Interface Width |
ALMs |
M20K Memory Blocks |
Logic Registers |
---|---|---|---|
Avalon‑MM Bridge | |||
64 |
1100 |
17 |
1500 |
128 |
1900 |
25 |
2900 |
Avalon-MM Interface–Completer Only | |||
64 |
650 |
8 |
1000 |
128 |
1400 |
12 |
2400 |
Avalon-MM–Completer Only Single Dword | |||
64 |
250 |
0 |
350 |
1.9. Recommended Speed Grades
Lane Rate |
Link Width |
Interface Width |
Application Clock Frequency (MHz) |
Recommended Speed Grades |
---|---|---|---|---|
Gen1 |
×1 |
64 bits |
62.5, 125 |
–5, –6 |
x2 |
64 bits |
125 |
–5, –6 |
|
x4 |
64 bits |
125 |
–5, –6 |
|
Gen2 |
×1 |
64 bits |
125 |
–5, –6 |
x2 |
64 bits |
125 |
–5, –6 |
|
x4 |
64 bits |
250 |
-5 |
|
×4 |
128 bits |
125 |
–5, –6 |
Lane Rate |
Link Width |
Interface Width |
Application Clock Frequency (MHz) |
Recommended Speed Grades |
---|---|---|---|---|
Gen1 |
×8 |
64 Bits |
250 |
–1, –2 |
×8 |
128 Bits |
125 |
–1, –2, –3 |
|
×1, x2, x4 |
64 Bits |
125 |
–1, –2, –3 |
|
×1 |
64 Bits |
62.5 |
–1, –2, –3 |
|
Gen2 |
×8 |
128 bits |
250 |
–1, –2 |
×8 |
256 bits |
125 |
–1, –2, -3 |
|
×4 |
64 bits |
250 |
–1, –2 |
|
×4 |
128 bits |
125 |
–1, –2, –3 |
|
×1, x2 |
64 bits |
125 |
–1, –2, –3 |
|
Gen3 |
×8 |
256 bits |
250 |
–1, –2 |
×4 |
128 bits |
250 |
–1, –2 |
|
×4 |
256 bits |
125 |
–1, –2, –3 |
|
×2 |
64 bits |
250 |
–1, –2 |
|
×2 |
128 bits |
125 |
–1, –2, –3 |
|
×1 |
64 bits |
125 |
–1, –2, –3 |
1.10. Creating a Design for PCI Express
Select the PCIe variant that best meets your design requirements.
- Is your design an Endpoint or Root Port?
- What Generation do you intend to implement?
- What link width do you intend to implement?
- What bandwidth does your application require?
- Does your design require Configuration via Protocol (CvP)?
- Select parameters for that variant.
- For Intel® Arria® 10 devices, you can use the new Example Design tab of the component GUI to generate a design that you specify. Then, you can simulate this example and also download it to an Intel® Arria® 10 FPGA Development Kit. Refer to the Intel® Arria® 10/ Intel® Cyclone® 10 GX PCI Express* IP Core Quick Start Guide for details.
-
For all devices, you can simulate using an Intel-provided example design. All static PCI Express example designs
are available under
<install_dir>/ip/altera/altera_pcie/altera_pcie_<dev>_ed/example_design/<dev>
. Alternatively, create a simulation model and use
your own custom or third-party BFM. The Platform Designer
Generate menu generates simulation models. Intel supports
ModelSim* - Intel FPGA Edition for all IP. The PCIe cores support the
Aldec RivieraPro*, Cadence NCSim*, Mentor Graphics ModelSim*, and Synopsys VCS* and VCS-MX* simulators.
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. However, the testbench and Root Port BFM are not intended to be a substitute for a full verification environment. To thoroughly test your application, Intel suggests that you obtain commercially available PCI Express verification IP and tools, or do your own extensive hardware testing, or both.
- Compile your design using the Quartus® Prime software. If the versions of your design and the Quartus® Prime software you are running do not match, regenerate your PCIe design.
- Download your design to an Intel development board or your own PCB. Click on the All Development Kits link below for a list of Intel's development boards.
- Test the hardware. You can use Intel's Signal Tap Logic Analyzer or a third-party protocol analyzer to observe behavior.
- Substitute your Application Layer logic for the Application Layer logic in Intel's testbench. Then repeat Steps 3–6. In Intel's testbenches, the PCIe core is typically called the DUT (device under test). The Application Layer logic is typically called APPS.
2. Quick Start Guide
The Intel® Arria® 10 or Intel® Cyclone® 10 GX Hard IP for PCI Express* IP core includes a programmed I/O (PIO) design example to help you understand usage. The PIO example transfers data from a host processor to a target device. It is appropriate for low-bandwidth applications. The design example includes an Avalon-ST to Avalon-MM Bridge. This component translates the TLPs received on the PCIe* link to Avalon-MM memory reads and writes to the on-chip memory.
This design example automatically creates the files necessary to simulate and compile in the Quartus® Prime software. You can download the compiled design to the Intel® Arria® 10 GX FPGA Development Kit. The design examples cover a wide range of parameters. However, the automatically generated design examples do not cover all possible parameterizations of the PCIe IP Core. If you select an unsupported parameter set, generations fails and provides an error message.
In addition, many static design examples for simulation are only available in the <install_dir>/ip/altera/altera_pcie/altera_pcie_a10_ed/example_design/a10 and <install_dir>/ip/altera/altera_pcie/altera_pcie_a10_ed/example_design/c10 directories.
2.1. Directory Structure
2.2. Design Components for the Avalon -MM Endpoint
2.3. Generating the Design
-
Launch Platform Designer.
- If you have an existing .qsys file in your directory, the Open System dialog box appears. Click New to specify a Quartus Prime project name and custom IP variation name for your design. Then, click Create.
- If not, a new project is automatically created. Save it before moving to the next step.
- In the IP Catalog, locate and select Intel® Arria® 10/Cyclone 10 Hard IP for PCI Express. The parameter editor appears.
- On the IP Settings tabs, specify the parameters for your IP variation.
-
In the Connections panel, make the following dummy connection:
rxm_bar0 to txs slave interface.
Platform Designer determines the size of the Avalon® -MM BAR master from its connection to an Avalon® -MM slave device. When you generate the example design, this connection is removed.
- Remove the clock_in and reset_in components that were instantiated by default.
- On the Example Design tab, the PIO design is available for your IP variation.
- For Example Design Files, select the Simulation and Synthesis options.
- For Generated HDL Format, only Verilog is available.
- For Target Development Kit, select the Intel® Arria® 10 GX FPGA Development Kit option. Currently, there is no option to select an Intel® Cyclone® 10 GX Development Kit when generating an example design.
- Click Generate Example Design. The software generates all files necessary to run simulations and hardware tests on the Intel® Arria® 10 FPGA Development Kit.
2.4. Simulating the Design
- Change to the testbench simulation directory.
- Run the simulation script for the simulator of your choice. Refer to the table below.
- Analyze the results.
Simulator | Working Directory | Instructions |
---|---|---|
ModelSim* | <example_design>/pcie_example_design_tb/pcie_example_design_tb/sim/mentor/ |
|
VCS* | <example_design>/pcie_example_design_tb/pcie_example_design_tb/sim/synopsys/vcs |
|
NCSim* | <example_design>/pcie_example_design_tb/pcie_example_design_tb/sim/cadence |
|
Xcelium* Parallel Simulator | <example_design>/pcie_example_design_tb/pcie_example_design_tb/sim/xcelium |
|

2.5. Compiling and Testing the Design in Hardware

The software application to test the PCI Express Design Example on the Intel® Arria® 10 GX FPGA Development Kit is available on both 32- and 64-bit Windows platforms. This program performs the following tasks:
- Prints the Configuration Space, lane rate, and lane width.
- Writes 0x00000000 to the specified BAR at offset 0x00000000 to initialize the memory and read it back.
- Writes 0xABCD1234 at offset 0x00000000 of the specified BAR. Reads it back and compares.
If successful, the test program displays the message 'PASSED'
Follow these steps to compile the design example in the Quartus Prime software:
- Launch the Quartus Prime software and open the pcie_example_design.qpf file for the example design created above.
- On the Processing > menu,
select Start Compilation.
The timing constraints for the design example and the design components are automatically loaded during compilation.
Follow these steps to test the design example in hardware:
- In the
<example_design>/software/windows/interop
directory, unzip Altera_PCIe_Interop_Test.zip.Note: You can also refer to readme_Altera_PCIe_interop_Test.txt file in this same directory for instructions on running the hardware test.
- Install the
Intel®
FPGA
Windows Demo Driver for PCIe on the Windows host machine, using altera_pcie_win_driver.inf.Note: If you modified the default Vendor ID (0x1172) or Device ID (0x0000) specified in the component parameter editor GUI, you must also modify them in altera_pcie_win_driver.inf.
- In the <example_design> directory, launch the Quartus Prime software and compile the design (Processing > Start Compilation).
- Connect the development board to the host computer.
- Configure the FPGA on the development board using the generated .sof file (Tools > Programmer).
- Open the Windows Device Manager and scan for hardware changes.
- Select the Intel® FPGA listed as an unknown PCI device and point to the appropriate 32- or 64-bit driver (altera_pice_win_driver.inf) in the Windows_driver directory.
- After the driver loads successfully, a new device named Altera PCI API Device appears in the Windows Device Manager.
- Determine the bus, device, and function number for the
Altera PCI API Device listed in
the Windows Device Manager.
- Expand the tab, Altera PCI API Driver under the devices.
- Right click on Altera PCI API Device and select Properties.
- Note the bus, device, and function number for the device. The following figure shows one example.
Figure 11. Determining the Bus, Device, and Function Number for New PCIe Device
- In the <example_design>/software/windows/interop/Altera_PCIe_Interop_Test/Interop_software directory, click Alt_Test.exe.
- When prompted, type the bus, device, and function numbers and
select the BAR number (0-5) you specified when parameterizing the IP core.Note: The bus, device, and function numbers for your hardware setup may be different.
- The test displays the message, PASSED, if the test is successful.
3. Parameter Settings
3.1. Parameters
Parameter |
Value |
Description |
---|---|---|
Design Environment |
Standalone
System |
Identifies the environment that the IP is in.
|
Parameter |
Value |
Description |
---|---|---|
Application Interface Type |
Avalon-ST
Avalon-MM Avalon-MM with DMA Avalon-ST with SR-IOV |
Selects the interface to the Application Layer. Note: When the Design
Environment parameter is set to System, all four Application Interface Types are
available. However, when Design
Environment is set to Standalone, only Avalon-ST and Avalon-ST with SR-IOV are available.
|
Hard IP mode |
Gen3x8, Interface: 256-bit, 250 MHz Gen3x4, Interface: 256-bit, 125 MHz Gen3x4, Interface: 128-bit, 250 MHz Gen3x2, Interface: 128-bit, 125 MHz Gen3x2, Interface: 64-bit, 250 MHz Gen3x1, Interface: 64-bit, 125 MHz Gen2x8, Interface: 256-bit, 125 MHz Gen2x8, Interface: 128-bit, 250 MHz Gen2x4, Interface: 128-bit, 125 MHz Gen2x2, Interface: 64-bit, 125 MHz Gen2x4, Interface: 64-bit, 250 MHz Gen2x1, Interface: 64-bit, 125 MHz Gen1x8, Interface: 128-bit, 125 MHz Gen1x8, Interface: 64-bit, 250 MHz Gen1x4, Interface: 64-bit, 125 MHz Gen1x2, Interface: 64-bit, 125 MHz Gen1x1, Interface: 64-bit, 125 MHz Gen1x1, Interface: 64-bit, 62.5 MHz |
Selects the following elements:
Intel® Cyclone® 10 GX devices support up to Gen2 x4 configurations. |
Port type |
Native Endpoint Root Port |
Specifies the port type. The Endpoint stores parameters in the Type 0 Configuration Space. The Root Port stores parameters in the Type 1 Configuration Space. You can enable the Root Port in the current release. Root Port mode only supports the Avalon® -MM interface type, and it only supports basic simulation and compilation. However, the Root Port mode is not fully verified. |
RX Buffer credit allocation -performance for received requests |
Minimum Low Balanced |
Determines the allocation of posted header credits, posted data credits, non-posted header credits, completion header credits, and completion data credits in the 16 KB RX buffer. The settings allow you to adjust the credit allocation to optimize your system. The credit allocation for the selected setting displays in the Message pane. The Message pane dynamically updates the number of credits for Posted, Non-Posted Headers and Data, and Completion Headers and Data as you change this selection. Refer to the Throughput Optimization chapter for more information about optimizing your design. Refer to the RX Buffer Allocation Selections Available by Interface Type below for the availability of these settings by interface type. Minimum—configures the minimum PCIe specification allowed for non-posted and posted request credits, leaving most of the RX Buffer space for received completion header and data. Select this option for variations where application logic generates many read requests and only infrequently receives single requests from the PCIe link. Low—configures a slightly larger amount of RX Buffer space for non-posted and posted request credits, but still dedicates most of the space for received completion header and data. Select this option for variations where application logic generates many read requests and infrequently receives small bursts of requests from the PCIe link. This option is recommended for typical endpoint applications where most of the PCIe traffic is generated by a DMA engine that is located in the endpoint application layer logic. Balanced—configures approximately half the RX Buffer space to received requests and the other half of the RX Buffer space to received completions. Select this option for variations where the received requests and received completions are roughly equal. |
RX Buffer completion credits |
Header credits Data credits |
Displays the number of completion credits in the 16 KB RX buffer resulting from the credit allocation parameter. Each header credit is 16 bytes. Each data credit is 20 bytes. |
3.2. Avalon-MM Settings
Parameter | Value | Description |
---|---|---|
Avalon-MM address width |
32-bit 64-bit |
Specifies the address width for Avalon-MM RX master ports that access Avalon-MM slaves in the Avalon address domain. When you select Enable Avalon-MM DMA or Enable non-bursting Avalon-MM slave interface with individual byte access (TXS), this value must be set to 64. |
Enable completer-only Endpoint | On/Off | In completer-only mode, the Hard IP can receive requests, but cannot initiate upstream requests. However, it can transmit completion packets on the PCI Express TX link. This mode removes the Avalon-MM TX slave port and thereby reduces logic utilization. |
Enable completer-only Endpoint with 4-byte payload | On/Off |
This is a non-pipelined version of Completer Only mode. At any time, only a single request can be outstanding. Single DWORD completer uses fewer resources than Completer Only. This variant is targeted for systems that require simple read and write register accesses from a host CPU. If you select this option, the width of the data for RXM BAR masters is always 32 bits, regardless of the Avalon-MM width. For the Avalon-MM interface with DMA, this value must be Off. |
Enable control register access (CRA) Avalon-MM slave port | On/Off |
Allows read and write access to bridge registers from the interconnect fabric using a specialized slave port. This option is required for Requester/Completer variants and optional for Completer Only variants. Enabling this option allows read and write access to bridge registers, except in the Completer‑Only single DWORD variations. |
Export MSI/MSI-X conduit interfaces | On/Off |
When you turn this option On, the core exports top‑level MSI and MSI‑X interfaces that you can use to implement a Custom Interrupt Handler for MSI and MSI‑X interrupts. For more information about the Custom Interrupt Handler, refer to Interrupts for End Points Using the Avalon-MM Interface with Multiple MSI/MSI‑X Support. If you turn this option Off, the core handles interrupts internally. |
Enable PCIe interrupt at power-on | On/Off |
When you turn this option On, the Avalon‑MM Intel® Arria® 10 or Intel® Cyclone® 10 GX Hard IP for PCI Express the interrupt register is enabled at power-up. Turning off this option disables the interrupt register at power‑up. The setting does not affect run‑time configuration of the interrupt enable register. For the Avalon-MM interface with DMA, this value must be Off. |
Enable hard IP status bus when using the Avalon-MM interface | On/Off | When you turn this option On, your top-level variant includes
signals that are useful for debugging, including link training and
status, and error signals. The following signals are included in the
top-level variant:
|
Address width of accessible PCIe memory space | 20-64 | Specifies the number of bits necessary to access the PCIe address space. |
3.3. Base Address Register (BAR) Settings
You can configure up to six 32-bit BARs or three 64-bit BARs.
Parameter |
Value |
Description |
---|---|---|
Type |
Disabled 64-bit prefetchable memory 32-bit non-prefetchable memory 32-bit prefetchable memory I/O address space |
Defining memory as prefetchable allows data in the region to
be fetched ahead anticipating that the requestor may require more data from the
same region than was originally requested. If you specify that a memory is
prefetchable, it must have the following 2 attributes:
The 32-bit prefetchable memory and I/O address space BARs are only available for the Legacy Endpoint. |
Size |
Not configurable |
Specifies the memory size calculated from other parameters you enter. |
3.4. Device Identification Registers
Register Name |
Range |
Default Value |
Description |
---|---|---|---|
Vendor ID |
16 bits |
0x00001172 |
Sets the read-only value of the Vendor ID register. This parameter cannot be set to 0xFFFF, per the PCI Express Specification. Address offset: 0x000. |
Device ID |
16 bits |
0x00000000 |
Sets the read-only value of the Device ID register. This register is only valid in the Type 0 (Endpoint) Configuration Space. Address offset: 0x000. |
Revision ID |
8 bits |
0x00000000 |
Sets the read-only value of the Revision ID register. Address offset: 0x008. |
Class code |
24 bits |
0x00000000 |
Sets the read-only value of the Class Code register. The 24-bit Class Code register is further divided into three 8-bit fields: Base Class Code, Sub-Class Code and Programming Interface. For more details on these fields, refer to the PCI Express Base Specification. Address offset: 0x008. |
Subsystem Vendor ID |
16 bits |
0x00000000 |
Sets the read-only value of the Subsystem Vendor ID register in the PCI Type 0 Configuration Space. This parameter cannot be set to 0xFFFF per the PCI Express Base Specification. This value is assigned by PCI-SIG to the device manufacturer. This register is only valid in the Type 0 (Endpoint) Configuration Space. Address offset: 0x02C. |
Subsystem Device ID |
16 bits |
0x00000000 |
Sets the read-only value of the Subsystem Device ID register in the PCI Type 0 Configuration Space. Address offset: 0x02C |
3.5. PCI Express and PCI Capabilities Parameters
This group of parameters defines various capability properties of the IP core. Some of these parameters are stored in the PCI Configuration Space - PCI Compatible Configuration Space. The byte offset indicates the parameter address.
3.5.1. Device Capabilities
Parameter |
Possible Values |
Default Value |
Description |
---|---|---|---|
Maximum payload size |
128 bytes 256 bytes 512 bytes 1024 bytes 2048 bytes |
128 bytes |
Specifies the maximum payload size supported. This parameter sets the read-only value of the max payload size supported field of the Device Capabilities register (0x084[2:0]). Address: 0x084. |
Completion timeout range |
ABCD BCD ABC AB B A None |
ABCD |
Indicates device function support for the optional completion timeout programmability mechanism. This mechanism allows the system software to modify the completion timeout value. This field is applicable only to Root Ports and Endpoints that issue requests on their own behalf. Completion timeouts are specified and enabled in the Device Control 2 register (0x0A8) of the PCI Express Capability Structure Version. For all other functions this field is reserved and must be hardwired to 0x0000b. Four time value ranges are defined:
Bits are set to show timeout value ranges supported. The function must implement a timeout value in the range 50 s to 50 ms. The following values specify the range:
All other values are reserved. Intel recommends that the completion timeout mechanism expire in no less than 10 ms. |
Disable completion timeout |
On/Off |
On |
Disables the completion timeout mechanism. When On, the core supports the completion timeout disable mechanism via the PCI Express Device Control Register 2. The Application Layer logic must implement the actual completion timeout mechanism for the required ranges. |
3.5.2. Error Reporting
Parameter |
Value |
Default Value |
Description |
---|---|---|---|
Enable Advanced Error Reporting (AER) |
On/Off |
Off |
When On, enables the Advanced Error Reporting (AER) capability. |
Enable ECRC checking |
On/Off |
Off |
When On, enables ECRC checking. Sets the read-only value of the ECRC check capable bit in the Advanced Error Capabilities and Control Register. This parameter requires you to enable the AER capability. |
Enable ECRC generation |
On/Off |
Off |
When On, enables ECRC generation capability. Sets the read-only value of the ECRC generation capable bit in the Advanced Error Capabilities and Control Register. This parameter requires you to enable the AER capability. |
Enable ECRC forwarding on the Avalon-ST interface |
On/Off |
Off |
When On, enables ECRC forwarding to the Application Layer. On the Avalon‑ST RX path, the incoming TLP contains the ECRC dword (1) and the TD bit is set if an ECRC exists. On the transmit the TLP from the Application Layer must contain the ECRC dword and have the TD bit set. Not applicable for Avalon-MM or Avalon-MM DMA interfaces. |
Track RX completion buffer overflow on the Avalon-ST interface |
On/Off |
Off |
When On, the core includes the rxfc_cplbuf_ovf output status signal to track the RX posted completion buffer overflow status. Not applicable for Avalon-MM or Avalon-MM DMA interfaces. |
Note:
|
3.5.3. Link Capabilities
Parameter |
Value |
Description |
---|---|---|
Link port number (Root Port only) |
0x01 |
Sets the read-only value of the port number field in the Link Capabilities register. This parameter is for Root Ports only. It should not be changed. |
Data link layer active reporting (Root Port only) |
On/Off |
Turn On this parameter for a Root
Port, if the attached Endpoint supports the optional capability of
reporting the DL_Active state of the Data Link Control and Management
State Machine. For a hot-plug capable Endpoint (as indicated by the
Hot Plug Capable field of the
Slot Capabilities register), this
parameter must be turned On. For
Root Port components that do not support this optional capability, turn
Off this option. Not applicable for Avalon-MM or Avalon-MM DMA interfaces. |
Surprise down reporting (Root Port only) |
On/Off |
When your turn this option On,
an Endpoint supports the optional capability of detecting and reporting
the surprise down error condition. The error condition is read from the
Root Port. Not applicable for Avalon-MM or Avalon-MM DMA interfaces. |
Slot clock configuration |
On/Off |
When you turn this option On, indicates that the Endpoint or Root Port uses the same physical reference clock that the system provides on the connector. When Off, the IP core uses an independent clock regardless of the presence of a reference clock on the connector. This parameter sets the Slot Clock Configuration bit (bit 12) in the PCI Express Link Status register. |
3.5.4. MSI and MSI-X Capabilities
Parameter |
Value |
Description |
---|---|---|
MSI messages requested |
1, 2, 4, 8, 16, 32 |
Specifies the number of messages the Application Layer can request. Sets the value of the Multiple Message Capable field of the Message Control register, Address: 0x050[31:16]. |
MSI-X Capabilities | ||
Implement MSI-X |
On/Off |
When On, adds the MSI-X functionality. |
Bit Range | ||
Table size |
[10:0] |
System software reads this field to determine the MSI-X Table size <n>, which is encoded as <n–1>. For example, a returned value of 2047 indicates a table size of 2048. This field is read-only in the MSI-X Capability Structure. Legal range is 0–2047 (211). Address offset: 0x068[26:16] |
Table offset |
[31:0] |
Points to the base of the MSI-X Table. The lower 3 bits of the table BAR indicator (BIR) are set to zero by software to form a 64-bit qword-aligned offset. This field is read-only. |
Table BAR indicator |
[2:0] |
Specifies which one of a function’s BARs, located beginning at 0x10 in Configuration Space, is used to map the MSI-X table into memory space. This field is read-only. Legal range is 0–5. |
Pending bit array (PBA) offset |
[31:0] |
Used as an offset from the address contained in one of the function’s Base Address registers to point to the base of the MSI-X PBA. The lower 3 bits of the PBA BIR are set to zero by software to form a 32-bit qword-aligned offset. This field is read-only in the MSI-X Capability Structure. 4 |
Pending BAR indicator |
[2:0] |
Specifies the function Base Address registers, located beginning at 0x10 in Configuration Space, that maps the MSI-X PBA into memory space. This field is read-only in the MSI-X Capability Structure. Legal range is 0–5. |
3.5.5. Slot Capabilities
Parameter |
Value |
Description |
---|---|---|
Use Slot register |
On/Off |
This parameter is only supported in Root Port mode. The slot capability is required for Root Ports if a slot is implemented on the port. Slot status is recorded in the PCI Express Capabilities register. Defines the characteristics of the slot. You turn on this option by selecting Enable slot capability. Refer to the figure below for bit definitions. |
Slot power scale |
0–3 |
Specifies the scale used for the Slot power limit. The following coefficients are defined:
The default value prior to hardware and firmware initialization is b’00. Writes to this register also cause the port to send the Set_Slot_Power_Limit Message. Refer to Section 6.9 of the PCI Express Base Specification Revision for more information. |
Slot power limit |
0–255 |
In combination with the Slot power scale value, specifies the upper limit in watts on power supplied by the slot. Refer to Section 7.8.9 of the PCI Express Base Specification for more information. |
Slot number |
0-8191 |
Specifies the slot number. |
3.5.6. Power Management
Parameter |
Value |
Description |
---|---|---|
Endpoint L0s acceptable latency |
Maximum of 64 ns Maximum of 128 ns Maximum of 256 ns Maximum of 512 ns Maximum of 1 us Maximum of 2 us Maximum of 4 us No limit |
This design parameter specifies the maximum acceptable latency that the device can tolerate to exit the L0s state for any links between the device and the root complex. It sets the read-only value of the Endpoint L0s acceptable latency field of the Device Capabilities Register (0x084). This Endpoint does not support the L0s or L1 states. However, in a switched system there may be links connected to switches that have L0s and L1 enabled. This parameter is set to allow system configuration software to read the acceptable latencies for all devices in the system and the exit latencies for each link to determine which links can enable Active State Power Management (ASPM). This setting is disabled for Root Ports. The default value of this parameter is 64 ns. This is a safe setting for most designs. |
Endpoint L1 acceptable latency |
Maximum of 1 us Maximum of 2 us Maximum of 4 us Maximum of 8 us Maximum of 16 us Maximum of 32 us Maximum of 64 nsNo limit |
This value indicates the acceptable latency that an Endpoint can withstand in the transition from the L1 to L0 state. It is an indirect measure of the Endpoint’s internal buffering. It sets the read-only value of the Endpoint L1 acceptable latency field of the Device Capabilities Register. This Endpoint does not support the L0s or L1 states. However, a switched system may include links connected to switches that have L0s and L1 enabled. This parameter is set to allow system configuration software to read the acceptable latencies for all devices in the system and the exit latencies for each link to determine which links can enable Active State Power Management (ASPM). This setting is disabled for Root Ports. The default value of this parameter is 1 µs. This is a safe setting for most designs. |
These IP cores also do not support the in-band beacon or sideband WAKE# signal, which are mechanisms to signal a wake-up event to the upstream device.
3.6. Configuration, Debug, and Extension Options
Parameter |
Value |
Description |
---|---|---|
Enable configuration via Protocol (CvP) |
On/Off |
When On, the Quartus® Prime software places the Endpoint in the location required for configuration via protocol (CvP). For more information about CvP, click the Configuration via Protocol (CvP) link below. CvP is supported for Intel® Cyclone® 10 GX devices from the Intel® Quartus® Prime release 17.1.1 onwards. |
Enable dynamic reconfiguration of PCIe read-only registers |
On/Off |
When On, you can use the Hard IP reconfiguration bus to dynamically reconfigure Hard IP read‑only registers. For more information refer to Hard IP Reconfiguration Interface. |
Enable transceiver dynamic reconfiguration | On/Off | When on, creates an Avalon-MM slave interface that software can drive to update transceiver registers. |
Enable Altera Debug Master Endpoint (ADME) |
On/Off |
When On, an embedded Altera Debug Master Endpoint connects internally to the Avalon-MM slave interface for dynamic reconfiguration. The ADME can access the reconfiguration space of the transceiver. It uses JTAG via the System Console to run tests and debug functions. |
Enable Intel® Arria® 10 FPGA Development Kit connection | On/Off | When On, add control and status conduit interface to the top level variant, to be connected a PCIe Development Kit component. |
3.7. Vendor Specific Extended Capability (VSEC)
Parameter |
Value |
Description |
---|---|---|
Vendor Specific Extended Capability (VSEC) ID: | 0x00001172 | Sets the read-only value of the 16-bit User ID register from the Vendor Specific Extended Capability. |
Vendor Specific Extended Capability (VSEC) Revision: | 0x00000000 | Sets the read-only value of the 4-bit VSEC Revision register from the Vendor Specific Extended Capability. |
User Device or Board Type ID register from the Vendor Specific Extended Capability: | 0x00000000 | Sets the read-only value of the 16-bit Device or Board Type ID register from the Vendor Specific Extended Capability. |
3.8. PHY Characteristics
Parameter |
Value |
Description |
---|---|---|
Gen2 TX de-emphasis |
3.5dB 6dB |
Specifies the transmit de-emphasis for Gen2. Intel recommends the following settings:
|
Requested equalization far-end TX preset | Preset0-Preset9 | Specifies the requested TX preset for Phase 2 and 3 far-end transmitter. The default value Preset8 provides the best signal quality for most designs. |
Enable soft DFE controller IP |
On Off |
When On, the PCIe Hard IP core includes a decision feedback equalization (DFE) soft controller in the FPGA fabric to improve the bit error rate (BER) margin. The default for this option is Off because the DFE controller is typically not required. However, short reflective links may benefit from this soft DFE controller IP. This parameter is available only for Gen3 mode. It is not supported when CvP or autonomous modes are enabled. |
Enable RX-polarity inversion in soft logic |
On Off |
This parameter mitigates the following RX-polarity inversion problem. When the Intel® Arria® 10 or Intel® Cyclone® 10 GX Hard IP core receives TS2 training sequences during the Polling.Config state, when you have not enabled this parameter, automatic lane polarity inversion is not guaranteed. The link may train to a smaller than expected link width or may not train successfully. This problem can affect configurations with any PCIe* speed and width. When you include this parameter, polarity inversion is available for all configurations except Gen1 x1. This fix does not support CvP or autonomous mode. |
3.9. Example Designs
Parameter |
Value |
Description |
---|---|---|
Available Example Designs |
DMA PIO |
When you select the DMA option, the generated example design includes a direct memory access application. This application includes upstream and downstream transactions. When you select the PIO option, the generated design includes a target application including only downstream transactions. |
Simulation | On/Off | When On, the generated output includes a simulation model. |
Synthesis | On/Off | When On, the generated output includes a synthesis model. |
Generated HDL format |
Verilog/VHDL |
Verilog HDL and VHDL are supported |
Select Board |
Intel® Arria® 10 FPGA GX Development Kit Intel® Arria® 10 FPGA GX Development Kit ES2 None |
Specifies the Intel® Arria® 10 development kit. Select None to download to a custom board. Note: Currently, you cannot target an
Intel®
Cyclone® 10 GX
Development Kit when generating an example design.
|
4. Physical Layout
4.1. Hard IP Block Placement In Intel Cyclone 10 GX Devices
Refer to the Intel® Cyclone® 10 GX Device Transceiver Layout in the Intel® Cyclone® 10 GX Transceiver PHY User Guide for comprehensive figures for Intel® Cyclone® 10 GX devices.
4.2. Hard IP Block Placement In Intel Arria 10 Devices
Refer to the Intel® Arria® 10 Transceiver Layout in the Intel® Arria® 10 for comprehensive figures for Intel® Arria® 10 GT, GX, and SX devices.
4.3. Channel and Pin Placement for the Gen1, Gen2, and Gen3 Data Rates
In these figures, channels that are not used for the PCI Express protocol are available for other protocols. Unused channels are shown in gray.
For the possible values of <txvr_block_N> and <txvr_block_N+1>, refer to the figures that show the physical location of the Hard IP PCIe blocks in the different types of Intel® Arria® 10 or Intel® Cyclone® 10 GX devices, at the start of this chapter. For each hard IP block, the transceiver block that is adjacent and extends below the hard IP block, is <txvr_block_N>, and the transceiver block that is directly above is <txvr_block_N+1> . For example, in an Intel® Arria® 10 device with 96 transceiver channels and four PCIe hard IP blocks, if your design uses the hard IP block that supports CvP, <txvr_block_N> is GXB1C and <txvr_block_N+1> is GXB1D.
4.4. Channel Placement and fPLL and ATX PLL Usage for the Gen3 Data Rate
Gen3 variants must initially train at the Gen1 data rate. Consequently, Gen3 variants require an fPLL to generate the 2.5 and 5.0 Gbps clocks, and an ATX PLL to generate the 8.0 Gbps clock. In these figures, channels that are not used for the PCI Express protocol are available for other protocols. Unused channels are shown in gray.
4.5. PCI Express Gen3 Bank Usage Restrictions
Any transceiver channels that share a bank with active PCI Express interfaces that are Gen3 capable have the following restrictions. This includes both Hard IP and Soft IP implementations:
- When VCCR_GXB and VCCT_GXB are set to 1.03 V or 1.12 V, the maximum data rate supported for the non-PCIe channels in those banks is 12.5 Gbps for chip-to-chip applications. These channels cannot be used to drive backplanes or for GT rates.
PCI Express interfaces that are only Gen1 or Gen2 capable are not affected.
Status
Affects all Intel® Arria® 10 ES and production devices. No fix is planned.
5. 64- or 128-Bit Avalon-MM Interface to the Endpoint Application Layer
The Intel® Arria® 10 or Intel® Cyclone® 10 GX Hard IP for PCI Express with an Avalon-MM interface to the Application Layer includes an Avalon-MM bridge. This bridge translates PCI Express TLPs to standard Avalon-MM read and write commands, and vice versa. Consequently, you do not need a detailed understanding of the PCI Express TLPs to use this Avalon-MM variant.
The Avalon® -MM Intel® Arria® 10 Hard IP for PCI Express* communicates with the Application Layer in the FPGA core fabric via the following interfaces:
- RX Master (RXM): This is a bursting RX Avalon® -MM master interface that translates Memory Read and Write TLPs from the PCIe* domain to Avalon® -MM reads and writes and sends them to the slave in the Avalon® -MM memory space.
- TX Slave (TXS): This is a bursting TX Avalon® -MM slave interface that translates memory-mapped reads and writes from the Avalon® -MM domain to PCIe* Memory Read and Write TLPs and sends them to the PCIe* memory space.
- Control Register Access (CRA): This optional Avalon® -MM slave interface allows the Application Layer logic to access the internal control and status registers of the IP core.
- Hard IP Reconfiguration: This optional interface allows the Application Layer logic to dynamically modify the contents of the IP core's configuration registers that are read-only at run time.
- Hard IP Status: This optional interface contains status signals for the Hard IP to facilitate the debugging process.
- MSI/MSI-X: These interfaces provide the necessary information for the Application Layer logic to construct and send Message Signaled Interrupts to the host.
Variations using the Avalon-MM interface implement the Avalon-MM protocol described in the Avalon Interface Specifications. Refer to this specification for information about the Avalon-MM protocol, including timing diagrams.
5.1. 32-Bit Non-Bursting Avalon-MM Control Register Access (CRA) Slave Signals
The optional CRA port for the full-featured IP core allows upstream PCI Express devices and external Avalon-MM masters to access internal control and status registers. Both Endpoint and Root Port applications can use the CRA interface.
Signal Name |
Direction |
Description |
---|---|---|
cra_irq_O |
Output |
Interrupt request. A port request for an Avalon-MM interrupt. |
cra_readdata_o[31:0] |
Output |
Read data lines. |
cra_waitrequest_o |
Output |
Wait request to hold off more requests. |
cra_address_i[13:0] |
Input |
An address space of 16,384 bytes is allocated for the control registers. Avalon-MM slave addresses provide address resolution down to the width of the slave data bus. Because all addresses are byte addresses, this address logically goes down to bit 2. Bits 1 and 0 are 0. To read or write individual bytes of a dword, use byte enables. For example, to write bytes 0 and 1, set cra_byteenable_i[3:0]= 4'b0011 . Refer to Valid Byte Enable Configurations for valid byte enable patterns. |
cra_byteenable_i[3:0] |
Input |
Byte enable. |
cra_chipselect_i |
Input |
Chip select signal to this slave. |
cra_read_i |
Input |
Read enable. |
cra_write_i |
Input |
Write request. |
cra_writedata_i[31:0] |
Input |
Write data. |
The CRA write request uses the high to low transition of CraWaitRequest_o to signal transaction completion
The CRA read transaction has similar timings to the CRA write transaction. The CraReadData_o[31:0] signals are valid at the clock cycle when CraWaitRequest_o is low. You can use the first rising clock edge after CraWaitRequest_o goes low to latch the data.
5.2. Bursting and Non-Bursting Avalon -MM Module Signals
Signal Name |
Direction |
Description |
---|---|---|
rxm_bar<n>_write_o |
Output |
Asserted by the core to request a write to an Avalon-MM slave. |
rxm_bar<n>_address_o[<W>-1:0] |
Output |
The address of the Avalon-MM slave being accessed. |
rxm_bar<n>_writedata_o[<w>-1:0] |
Output |
RX data being written to slave. <w> = 64 or 128 for the full-featured IP core. <w> = 32 for the completer-only IP core. |
rxm_bar<n>_byteenable_o[<w>-1:0] |
Output |
Dword enables for write data. |
rxm_bar<n>_burstcount_o[6 or 5:0]
(available in burst mode only) |
Output |
>The burst count, measured in qwords, of the RX write or read request. The width indicates the maximum data that can be requested. The maximum data in a burst is 512 bytes. This optional signal is available for BAR2 only when you turn on Enable burst capabilities for RXM BAR2 ports.
|
rxm_bar<n>_waitrequest_i |
Input |
Asserted by the external Avalon-MM slave to hold data transfer. |
rxm_bar<n>_read_o |
Output |
Asserted by the core to request a read. |
rxm_bar<n>_readdata_i[<w>-1:0] |
Input |
Read data returned from Avalon-MM slave in response to a read request. This data is sent to the IP core through the TX interface. <w> = 64 or 128 for the full-featured IP core. <w> = 32 for the completer-only IP core. |
rxm_bar<n>_readdatavalid_i |
Input |
Asserted by the system interconnect fabric to indicate that the read data is valid. |
rxm_irq_i[<m>:0], <m> < 16 |
Input |
Connect interrupts to the Avalon® -MM interface. These signals are only available for the Avalon® -MM when the CRA port is enabled. A rising edge triggers an MSI interrupt. The hard IP core converts this event to an MSI interrupt and sends it to the Root Port. The host reads the Interrupt Status register to retrieve the interrupt vector. Host software services the interrupt and notifies the target upon completion. As many as 16 individual interrupt signals
(<m>≤15) are
available. If rxm_irq_<n>[<m>:0] is asserted on
consecutive cycles without the deassertion of all interrupt
inputs, no MSI message is sent for subsequent interrupts. To
avoid losing interrupts, software must ensure that all interrupt
sources are cleared for each MSI message received.
Note: These
signals are not available when the IP core is operating in
DMA mode (i.e. when the Enable Avalon-MM
DMA option in the Avalon-MM
Settings tab of the GUI is set to
On).
|
The following timing diagram illustrates the RX master port propagating requests to the Application Layer and also shows simultaneous read and write activities.
5.3. 64- or 128-Bit Bursting TX Avalon-MM Slave Signals
This optional Avalon-MM bursting slave port propagates requests from the interconnect fabric to the full-featured Avalon‑MM Intel® Arria® 10 or Intel® Cyclone® 10 GX Hard IP for PCI Express. Requests from the interconnect fabric are translated into PCI Express request packets. Incoming requests can be up to 512 bytes. For better performance, Intel recommends using a read request size of 128 bytes. A 512-byte read request results in 2, 256-byte TLPs with delays until all 256 bytes are available. Performance analyses show that a 128-byte read request size results in the lowest latency for typical systems.
Signal Name |
Direction |
Description |
---|---|---|
txs_chipselect_i |
Input |
The system interconnect fabric asserts this signal to select the TX slave port. |
txs_read_i |
Input |
Read request asserted by the system interconnect fabric to request a read. |
txs_write_i |
Input |
Write request asserted by the system interconnect fabric to request a write. |
txs_writedata_i[127 or 63:0] |
Input |
Write data sent by the external Avalon-MM master to the TX slave port. |
txs_burstcount_i[6 or 5:0] |
Input |
Asserted by the system interconnect fabric indicating the amount of data requested. The count unit is the amount of data that is transferred in a single cycle, that is, the width of the bus. The burst count is limited to 512 bytes. |
txs_address_i[<w>-1:0] |
Input |
Address of the read or write request from the external Avalon‑MM master. This address translates to 64-bit or 32-bit PCI Express addresses based on the translation table. The <w> value is determined when the system is created. |
txs_byteenable_i[<w>-1:0] |
Input |
Byte enables for read and write data. A burst must be continuous. Therefore all intermediate data phases of a burst must have a byte enable value of 0xFF. The first and final data phases of a burst can have other valid values. For the 128-bit interface, the following restrictions apply:
|
txs_readdatavalid_o |
Output |
Asserted by the bridge to indicate that read data is valid. |
txs_readdata_o[127 or 63:0] |
Output |
The bridge returns the read data on this bus when the RX read completions for the read have been received and stored in the internal buffer. |
txs_waitrequest_o |
Output |
Asserted by the bridge to hold off read or write data when running out of buffer space. If this signal is asserted during an operation, the master should maintain the read or write signal and write data stable until after the wait request is deasserted. > txs_read_i must be deasserted when is > txs_waitrequest_o asserted. |
5.4. Clock Signals
Signal |
Direction |
Description |
---|---|---|
refclk |
Input |
Reference clock for the IP core. It must have the frequency specified under the System Settings heading in the parameter editor. This is a dedicated free running input clock to the dedicated REFCLK pin. |
coreclkout_hip |
Output |
This is a fixed frequency clock used by the Data Link and Transaction Layers. |
5.5. Reset, Status, and Link Training Signals
Refer to Reset and Clocks for more information about the reset sequence and a block diagram of the reset logic.
Signal |
Direction |
Description |
---|---|---|
npor |
Input |
Active low reset signal. In the Intel hardware example designs, npor is the OR of pin_perst and local_rstn coming from the software Application Layer. If you do not drive a soft reset signal from the Application Layer, this signal must be derived from pin_perst. You cannot disable this signal. Resets the entire IP Core and transceiver. Asynchronous. This signal is edge, not level sensitive; consequently, you cannot use a low value on this signal to hold custom logic in reset. For more information about the reset controller, refer to Reset. |
app_nreset_status |
Output |
Active low reset signal. It is derived from npor or pin_perstn. You can use this signal to reset the Application Layer. |
pin_perst |
Input |
Active low reset from the PCIe reset pin of the device. pin_perst resets the datapath and control registers. Configuration via Protocol (CvP) requires this signal. For more information about CvP refer to Arria 10 CvP Initialization and Partial Reconfiguration via Protocol User Guide. Intel® Arria® 10 devices can have up to 4 instances of the Hard IP for PCI Express IP core. Each instance has its own pin_perst signal. Intel® Cyclone® 10 GX have a single instance of the Hard IP for PCI Express IP core. You must connect the pin_perst of each Hard IP instance to the corresponding nPERST pin of the device. These pins have the following locations:
For example, if you are using the Hard IP instance in the bottom left corner of the device, you must connect pin_perst to NPERSL0. For maximum use of the Intel® Arria® 10 or Intel® Cyclone® 10 GX device, Intel recommends that you use the bottom left Hard IP first. This is the only location that supports CvP over a PCIe link. If your design does not require CvP, you may select other Hard IP blocks. Refer to the Arria 10 GX, GT, and SX Device Family Pin Connection Guidelines or Intel® Cyclone® 10 GX Device Family Pin Connection Guidelines for more detailed information about these pins. |
The following figure illustrates the timing relationship between npor and the LTSSM L0 state.
5.6. Interrupts for Endpoints when Multiple MSI/MSI-X Support Is Enabled
Application Layer logic must construct the MSI (MemWr) TLP and send it using the TX slave (TXS) interface. For designs supporting multiple MSI/MSI-X, use the signals described below. For designs using a MSI TLP, use the control register access (CRA) interface to read the MSI Capability registers. The MSI information is at address offsets 14'h3C24, 14'h3C28, 14'h3C54, and 14'h3C5C. The Bus Master Enable bit is at address 14h'3C00.
Signal |
Direction |
Description |
---|---|---|
msi_intfc_o[81:0] |
Output |
This bus provides the following MSI address, data, and enabled signals:
|
msi_control_o[15:0] |
Output |
Provides for system software control of MSI as defined in Section 6.8.1.3 Message Control for MSI in the PCI Local Bus Specification, Rev. 3.0. The following fields are defined:
|
msix_intfc_o[15:0] |
Output |
Provides for system software control of MSI-X as defined in Section 6.8.2.3 Message Control for MSI-X in the PCI Local Bus Specification, Rev. 3.0. The following fields are defined:
|
intx_req_i |
Input |
When asserted, the Endpoint is requesting attention from the interrupt service routine unless MSI or MSI-X interrupts are enabled. Remains asserted until the device driver clears the pending request. |
intx_ack_o |
Output |
This signal is the acknowledge for IntxReq_i. It is asserted for at least one cycle either when either of the following events occur:
Refer to the timing diagrams below. |
The following figure illustrates interrupt timing for the legacy interface. In this figure the assertion of IntxReq_i instructs the Hard IP for PCI Express to send an Assert_INTA message TLP.
The following figure illustrates the timing for deassertion of legacy interrupts. The assertion of IntxReq_i instructs the Hard IP for PCI Express to send a Deassert_INTA message.
The following figure illustrates the timing for deassertion of legacy interrupts. The assertion of IntxReq_i instructs the Hard IP for PCI Express to send a Deassert_INTA message.
5.7. Hard IP Status Signals
Signal |
Direction |
Description |
---|---|---|
cfg_par_err |
Output |
Indicates that a parity error in a TLP routed to the internal Configuration Space. This error is also logged in the Vendor Specific Extended Capability internal error register. You must reset the Hard IP if this error occurs. |
derr_cor_ext_rcv |
Output |
Indicates a corrected error in the RX buffer. This signal is for debug only. It is not valid until the RX buffer is filled with data. This is a pulse, not a level, signal. Internally, the pulse is generated with the 500 MHz clock. A pulse extender extends the signal so that the FPGA fabric running at 250 MHz can capture it. Because the error was corrected by the IP core, no Application Layer intervention is required. 5 |
derr_cor_ext_rpl |
Output |
Indicates a corrected ECC error in the retry buffer. This signal is for debug only. Because the error was corrected by the IP core, no Application Layer intervention is required. 5 (4) |
derr_rpl |
Output |
Indicates an uncorrectable error in the retry buffer. This signal is for debug only. (4) |
dlup |
Output |
When asserted, indicates that the Hard IP block is in the Data Link Control and Management State Machine (DLCMSM) DL_Up state. |
dlup_exit |
Output |
This signal is asserted low for one pld_clk cycle when the IP core exits the DLCMSM DL_Up state, indicating that the Data Link Layer has lost communication with the other end of the PCIe link and left the Up state. When this pulse is asserted, the Application Layer should generate an internal reset signal that is asserted for at least 32 cycles. |
ev128ns |
Output |
Asserted every 128 ns to create a time base aligned activity. |
ev1us |
Output |
Asserted every 1 µs to create a time base aligned activity. |
hotrst_exit |
Output |
Hot reset exit. This signal is asserted for 1 clock cycle when the LTSSM exits the hot reset state. This signal should cause the Application Layer to be reset. This signal is active low. When this pulse is asserted, the Application Layer should generate an internal reset signal that is asserted for at least 32 cycles. |
int_status[3:0] |
Output |
These signals drive legacy interrupts to the Application Layer as follows:
|
ko_cpl_spc_data |
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. |
ko_cpl_spc_header |
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. |
l2_exit |
Output |
L2 exit. This signal is active low and otherwise remains high. It is asserted for one cycle (changing value from 1 to 0 and back to 1) after the LTSSM transitions from l2.idle to detect. When this pulse is asserted, the Application Layer should generate an internal reset signal that is asserted for at least 32 cycles. |
lane_act[3:0] |
Output |
Lane Active Mode: This signal indicates the number of lanes that configured during link training. The following encodings are defined:
|
ltssmstate[4:0] |
Output |
LTSSM state: The LTSSM state machine encoding defines the following states:
|
rx_par_err |
Output |
When asserted for a single cycle, indicates that a parity error was detected in a TLP at the input of the RX buffer. This error is logged as an uncorrectable internal error in the VSEC registers. For more information, refer to Uncorrectable Internal Error Status Register. If this error occurs, you must reset the Hard IP if this error occurs because parity errors can leave the Hard IP in an unknown state. |
tx_par_err[1:0] |
Output |
When asserted for a single cycle, indicates a parity error during TX TLP transmission. These errors are logged in the VSEC register. The following encodings are defined:
Note that not all simulation models assert the Transaction Layer error bit in conjunction with the Data Link Layer error bit. |
5.7.1. Hard IP Reconfiguration Interface
The Hard IP reconfiguration interface is an Avalon-MM slave interface with a 10‑bit address and 16‑bit data bus. You can use this bus to dynamically modify the value of configuration registers that are read-only at run time. To ensure proper system operation, reset or repeat device enumeration of the PCI Express link after changing the value of read‑only configuration registers of the Hard IP.
Signal |
Direction |
Description |
---|---|---|
hip_reconfig_clk |
Input |
Reconfiguration clock. The frequency range for this clock is 100–125 MHz. |
hip_reconfig_rst_n |
Input |
Active-low Avalon-MM reset. Resets all of the dynamic reconfiguration registers to their default values as described in Hard IP Reconfiguration Registers. |
hip_reconfig_address[9:0] |
Input |
The 10‑bit reconfiguration address. |
hip_reconfig_read |
Input |
Read signal. This interface is not pipelined. You must wait for the return of the hip_reconfig_readdata[15:0] from the current read before starting another read operation. |
hip_reconfig_readdata[15:0] |
Output |
16‑bit read data. hip_reconfig_readdata[15:0] is valid on the third cycle after the assertion of hip_reconfig_read. |
hip_reconfig_write |
Input |
Write signal. |
hip_reconfig_writedata[15:0] |
Input |
16‑bit write model. |
hip_reconfig_byte_en[1:0] |
Input |
Byte enables, currently unused. |
ser_shift_load |
Input |
You must toggle this signal once after changing to user mode before the first access to read‑only registers. This signal should remain asserted for a minimum of 324 ns after switching to user mode. |
interface_sel |
Input |
A selector which must be asserted when performing dynamic reconfiguration. Drive this signal low 4 clock cycles after the release of ser_shif t_load. |
For a detailed description of the Avalon-MM protocol, refer to the Avalon Memory Mapped Interfaces chapter in the Avalon Interface Specifications.
5.8. Physical Layer Interface Signals
Intel provides an integrated solution with the Transaction, Data Link and Physical Layers. The IP Parameter Editor generates a SERDES variation file, <variation>_serdes.v or .vhd , in addition to the Hard IP variation file, <variation>.v or .vhd. The SERDES entity is included in the library files for PCI Express.
5.8.1. Serial Data Signals
The Intel® Cyclone® 10 GX PCIe IP Core supports 1, 2, or 4 lanes. Each lane includes a TX and RX differential pair. Data is striped across all available lanes.
The Intel® Arria® 10 PCIe IP Core supports 1, 2, 4 or 8 lanes. Each lane includes a TX and RX differential pair. Data is striped across all available lanes.
Signal |
Direction |
Description |
---|---|---|
tx_out[<n>-1:0] |
Output |
Transmit output. These signals are the serial outputs of lanes <n>-1–0. |
rx_in[<n>-1:0] |
Input |
Receive input. These signals are the serial inputs of lanes <n>-1–0. |
Refer to Pin-out Files for Intel Devices for pin-out tables for all Intel devices in .pdf, .txt, and .xls formats.
Transceiver channels are arranged in groups of six. For GX devices, the lowest six channels on the left side of the device are labeled GXB_L0, the next group is GXB_L1, and so on. Channels on the right side of the device are labeled GXB_R0, GXB_R1, and so on. Be sure to connect the Hard IP for PCI Express on the left side of the device to appropriate channels on the left side of the device, as specified in the Pin-out Files for Intel Devices.
5.8.2. PIPE Interface Signals
These PIPE signals are available for Gen1, Gen2, and Gen3 variants so that you can simulate using either the serial or the PIPE interface. Simulation is much faster using the PIPE interface because the PIPE simulation bypasses the SERDES model . By default, the PIPE interface data width is 8 bits for Gen1 and Gen2 and 32 bits for Gen3. You can use the PIPE interface for simulation even though your actual design includes a serial interface to the internal transceivers. However, it is not possible to use the Hard IP PIPE interface in hardware, including probing these signals using Signal Tap.
Intel® Cyclone® 10 GX devices do not support the Gen3 data rate.
In the following table, signals that include lane number 0 also exist for lanes 1-4. For Gen1 and Gen2 operation outputs can be left floating.
Signal |
Direction |
Description |
---|---|---|
txdata0[31:0] |
Output |
Transmit data <n>. This bus transmits data on lane <n>. |
txdatak0[3:0] |
Output |
Transmit data control <n>. This signal serves as the control bit for txdata <n>. Bit 0 corresponds to the lowest-order byte of txdata, and so on. A value of 0 indicates a data byte. A value of 1 indicates a control byte. For Gen1 and Gen2 only. |
txblkst0 |
Output |
For Gen3 operation, indicates the start of a block in the transmit direction. |
txcompl0 |
Output |
Transmit compliance <n>. This signal forces the running disparity to negative in Compliance Mode (negative COM character). |
txdataskip0 |
Output |
For Gen3 operation. Allows the MAC to instruct the TX interface to ignore the TX data interface for one clock cycle. The following encodings are defined:
|
txdeemph0 |
Output |
Transmit de-emphasis selection. The Intel® Arria® 10 Hard IP for PCI Express sets the value for this signal based on the indication received from the other end of the link during the Training Sequences (TS). You do not need to change this value. |
txdetectrx0 |
Output |
Transmit detect receive <n>. This signal tells the PHY layer to start a receive detection operation or to begin loopback. |
txelecidle0 |
Output |
Transmit electrical idle <n>. This signal forces the TX output to electrical idle. |
txswing |
Output |
When asserted, indicates full swing for the transmitter voltage. When deasserted indicates half swing. |
txmargin[2:0] |
Output |
Transmit VOD margin selection. The value for this signal is based on the value from the Link Control 2 Register. Available for simulation only. |
txsynchd0[1:0] |
Output |
For Gen3 operation, specifies the transmit block type. The following encodings are defined:
|
rxdata0[31:0] |
Input |
Receive data <n>. This bus receives data on lane <n>. |
rxdatak[3:0] |
Input |
Receive data >n>. This bus receives data on lane <n>. Bit 0 corresponds to the lowest-order byte of rxdata, and so on. A value of 0 indicates a data byte. A value of 1 indicates a control byte. For Gen1 and Gen2 only. |
rxblkst0 |
Input |
For Gen3 operation, indicates the start of a block in the receive direction. |
rxdataskip0 |
Output |
For Gen3 operation. Allows the PCS to instruct the RX interface to ignore the RX data interface for one clock cycle. The following encodings are defined:
|
rxelecidle0 |
Input |
Receive electrical idle <n>. When asserted, indicates detection of an electrical idle. |
rxpolarity0 |
Output |
Receive polarity <n>. This signal instructs the PHY layer to invert the polarity of the 8B/10B receiver decoding block. |
rxstatus0[2:0] |
Input |
Receive status <n>. This signal encodes receive status, including error codes for the receive data stream and receiver detection. |
rxsynchd0[1:0] |
Input |
For Gen3 operation, specifies the receive block type. The following encodings are defined:
|
rxvalid0 |
Input |
Receive valid <n>. This signal indicates symbol lock and valid data on rxdata <n> and rxdatak <n>. |
phystatus0 |
Input |
PHY status <n>. This signal communicates completion of several PHY requests. |
powerdown0[1:0] |
Output |
Power down <n>. This signal requests the PHY to change its power state to the specified state (P0, P0s, P1, or P2). |
currentcoeff0[17:0] |
Output |
For Gen3, specifies the coefficients to be used by the transmitter. The 18 bits specify the following coefficients:
|
currentrxpreset0[2:0] |
Output |
For Gen3 designs, specifies the current preset. |
simu_mode_pipe |
Input |
When set to 1, the PIPE interface is in simulation mode. |
sim_pipe_rate[1:0] |
Output |
The 2‑bit encodings have the following meanings:
|
rate[1:0] |
Output |
The 2‑bit encodings have the following meanings:
|
sim_pipe_pclk_in |
Input |
This clock is used for PIPE simulation only, and is derived from the refclk. It is the PIPE interface clock used for PIPE mode simulation. |
sim_pipe_ltssmstate0[4:0] |
Input and Output |
LTSSM state: The LTSSM state machine encoding defines the following states:
|
rxfreqlocked0 |
Input |
When asserted indicates that the pclk_in used for PIPE simulation is valid. |
eidleinfersel0[2:0] |
Output |
Electrical idle entry inference mechanism selection. The following encodings are defined:
|
5.8.3. Intel Arria 10 Development Kit Conduit Interface
Signal Name | Direction | Description |
---|---|---|
devkit_status[255:0] | Output | The devkit_status[255:0] bus comprises
the following status signals :
|
devkit_ctrl[255:0] | Input | The devkit_ctrl[255:0] bus comprises the following
status signals. You can optionally connect these pins to an
on-board switch for PCI-SIG compliance testing, such as bypass
compliance testing.
|
5.8.4. Test Signals
Signal |
Direction |
Description |
---|---|---|
test_in[31:0] |
Input |
The bits of the test_in bus have the following definitions. Set this bus to 0x00000188.
|
6. Registers
6.1. Correspondence between Configuration Space Registers and the PCIe Specification
Byte Address |
Hard IP Configuration Space Register |
Corresponding Section in PCIe Specification |
---|---|---|
0x000:0x03C |
PCI Header Type 0 Configuration Registers |
Type 0 Configuration Space Header |
0x000:0x03C |
PCI Header Type 1 Configuration Registers |
Type 1 Configuration Space Header |
0x040:0x04C |
Reserved |
N/A |
0x050:0x05C |
MSI Capability Structure |
MSI Capability Structure |
0x068:0x070 |
MSI-X Capability Structure |
MSI-X Capability Structure |
0x070:0x074 |
Reserved |
N/A |
0x078:0x07C |
Power Management Capability Structure |
PCI Power Management Capability Structure |
0x080:0x0BC |
PCI Express Capability Structure |
PCI Express Capability Structure |
0x0C0:0x0FC |
Reserved |
N/A |
0x100:0x16C |
Virtual Channel Capability Structure |
Virtual Channel Capability |
0x170:0x17C |
Reserved |
N/A |
0x180:0x1FC |
Virtual channel arbitration table |
VC Arbitration Table |
0x200:0x23C |
Port VC0 arbitration table |
Port Arbitration Table |
0x240:0x27C |
Port VC1 arbitration table |
Port Arbitration Table |
0x280:0x2BC |
Port VC2 arbitration table |
Port Arbitration Table |
0x2C0:0x2FC |
Port VC3 arbitration table |
Port Arbitration Table |
0x300:0x33C |
Port VC4 arbitration table |
Port Arbitration Table |
0x340:0x37C |
Port VC5 arbitration table |
Port Arbitration Table |
0x380:0x3BC |
Port VC6 arbitration table |
Port Arbitration Table |
0x3C0:0x3FC |
Port VC7 arbitration table |
Port Arbitration Table |
0x400:0x7FC |
Reserved |
PCIe spec corresponding section name |
0x800:0x834 |
Advanced Error Reporting AER (optional) |
Advanced Error Reporting Capability |
0x838:0xFFF |
Reserved |
N/A |
Overview of Configuration Space Register Fields | ||
0x000 |
Device ID, Vendor ID |
Type 0 Configuration Space Header Type 1 Configuration Space Header |
0x004 |
Status, Command |
Type 0 Configuration Space Header Type 1 Configuration Space Header |
0x008 |
Class Code, Revision ID |
Type 0 Configuration Space Header Type 1 Configuration Space Header |
0x00C |
BIST, Header Type, Primary Latency Timer, Cache Line Size |
Type 0 Configuration Space Header Type 1 Configuration Space Header |
0x010 |
Base Address 0 |
Base Address Registers |
0x014 |
Base Address 1 |
Base Address Registers |
0x018 |
Base Address 2 Secondary Latency Timer, Subordinate Bus Number, Secondary Bus Number, Primary Bus Number |
Base Address Registers Secondary Latency Timer, Type 1 Configuration Space Header, Primary Bus Number |
0x01C |
Base Address 3 Secondary Status, I/O Limit, I/O Base |
Base Address Registers Secondary Status Register ,Type 1 Configuration Space Header |
0x020 |
Base Address 4 Memory Limit, Memory Base |
Base Address Registers Type 1 Configuration Space Header |
0x024 |
Base Address 5 Prefetchable Memory Limit, Prefetchable Memory Base |
Base Address Registers Prefetchable Memory Limit, Prefetchable Memory Base |
0x028 |
Reserved Prefetchable Base Upper 32 Bits |
N/A Type 1 Configuration Space Header |
0x02C |
Subsystem ID, Subsystem Vendor ID Prefetchable Limit Upper 32 Bits |
Type 0 Configuration Space Header Type 1 Configuration Space Header |
0x030 |
I/O Limit Upper 16 Bits, I/O Base Upper 16 Bits |
Type 0 Configuration Space Header Type 1 Configuration Space Header |
0x034 |
Reserved, Capabilities PTR |
Type 0 Configuration Space Header Type 1 Configuration Space Header |
0x038 |
Reserved |
N/A |
0x03C |
Interrupt Pin, Interrupt Line Bridge Control, Interrupt Pin, Interrupt Line |
Type 0 Configuration Space Header Type 1 Configuration Space Header |
0x050 |
MSI-Message Control Next Cap Ptr Capability ID |
MSI and MSI-X Capability Structures |
0x054 |
Message Address |
MSI and MSI-X Capability Structures |
0x058 |
Message Upper Address |
MSI and MSI-X Capability Structures |
0x05C |
Reserved Message Data |
MSI and MSI-X Capability Structures |
0x068 |
MSI-X Message Control Next Cap Ptr Capability ID |
MSI and MSI-X Capability Structures |
0x06C |
MSI-X Table Offset BIR |
MSI and MSI-X Capability Structures |
0x070 |
Pending Bit Array (PBA) Offset BIR |
MSI and MSI-X Capability Structures |
0x078 |
Capabilities Register Next Cap PTR Cap ID |
PCI Power Management Capability Structure |
0x07C |
Data PM Control/Status Bridge Extensions Power Management Status & Control |
PCI Power Management Capability Structure |
0x080 |
PCI Express Capabilities Register Next Cap Ptr PCI Express Cap ID |
PCI Express Capability Structure |
0x084 |
Device Capabilities Register |
PCI Express Capability Structure |
0x088 |
Device Status Register Device Control Register |
PCI Express Capability Structure |
0x08C |
Link Capabilities Register |
PCI Express Capability Structure |
0x090 |
Link Status Register Link Control Register |
PCI Express Capability Structure |
0x094 |
Slot Capabilities Register |
PCI Express Capability Structure |
0x098 |
Slot Status Register Slot Control Register |
PCI Express Capability Structure |
0x09C |
Root Capabilities Register Root Control Register |
PCI Express Capability Structure |
0x0A0 |
Root Status Register |
PCI Express Capability Structure |
0x0A4 |
Device Capabilities 2 Register |
PCI Express Capability Structure |
0x0A8 |
Device Status 2 Register Device Control 2 Register |
PCI Express Capability Structure |
0x0AC |
Link Capabilities 2 Register |
PCI Express Capability Structure |
0x0B0 |
Link Status 2 Register Link Control 2 Register |
PCI Express Capability Structure |
0x0B4:0x0BC |
Reserved |
PCI Express Capability Structure |
0x800 |
Advanced Error Reporting Enhanced Capability Header |
Advanced Error Reporting Enhanced Capability Header |
0x804 |
Uncorrectable Error Status Register |
Uncorrectable Error Status Register |
0x808 |
Uncorrectable Error Mask Register |
Uncorrectable Error Mask Register |
0x80C |
Uncorrectable Error Severity Register |
Uncorrectable Error Severity Register |
0x810 |
Correctable Error Status Register |
Correctable Error Status Register |
0x814 |
Correctable Error Mask Register |
Correctable Error Mask Register |
0x818 |
Advanced Error Capabilities and Control Register |
Advanced Error Capabilities and Control Register |
0x81C |
Header Log Register |
Header Log Register |
0x82C |
Root Error Command |
Root Error Command Register |
0x830 |
Root Error Status |
Root Error Status Register |
0x834 |
Error Source Identification Register Correctable Error Source ID Register |
Error Source Identification Register |
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
Bits |
Register Description |
Value |
Access |
---|---|---|---|
[15:0] |
PCI Express Extended Capability ID. Intel-defined value for VSEC Capability ID. |
0x000B |
RO |
[19:16] |
Version. Intel-defined value for VSEC version. |
0x1 |
RO |
[31:20] |
Next Capability Offset. Starting address of the next Capability Structure implemented, if any. |
Variable |
RO |
Bits |
Register Description |
Value |
Access |
---|---|---|---|
[15:0] |
VSEC ID. A user configurable VSEC ID. |
User entered |
RO |
[19:16] |
VSEC Revision. A user configurable VSEC revision. |
Variable |
RO |
[31:20] |
VSEC Length. Total length of this structure in bytes. |
0x044 |
RO |
Bits |
Register Description |
Value |
Access |
---|---|---|---|
[31:0] |
Intel Marker. This read only register is an additional marker. If you use the standard Intel Programmer software to configure the device with CvP, this marker provides a value that the programming software reads to ensure that it is operating with the correct VSEC. |
A Device Value |
RO |
Bits |
Register Description |
Value |
Access |
---|---|---|---|
[127:96] |
JTAG Silicon ID DW3 |
Application Specific |
RO |
[95:64] |
JTAG Silicon ID DW2 |
Application Specific |
RO |
[63:32] |
JTAG Silicon ID DW1 |
Application Specific |
RO |
[31:0] |
JTAG Silicon ID DW0. This is the JTAG Silicon ID that CvP programming software reads to determine that the correct SRAM object file (.sof) is being used. |
Application Specific |
RO |
Bits |
Register Description |
Value |
Access |
---|---|---|---|
[15:0] |
Configurable device or board type ID to specify to CvP the correct .sof. |
Variable |
RO |
6.6. CvP Registers
Bits | Register Description | Reset Value | Access |
---|---|---|---|
[31:26] | Reserved | 0x00 | RO |
[25] | PLD_CORE_READY. From FPGA fabric. This status bit is provided for debug. | Variable | RO |
[24] | PLD_CLK_IN_USE. From clock switch module to fabric. This status bit is provided for debug. | Variable | RO |
[23] | CVP_CONFIG_DONE. Indicates that the FPGA control block has completed the device configuration via CvP and there were no errors. | Variable | RO |
[22] | Reserved | Variable | RO |
[21] | USERMODE. Indicates if the configurable FPGA fabric is in user mode. | Variable | RO |
[20] | CVP_EN. Indicates if the FPGA control block has enabled CvP mode. | Variable | RO |
[19] | CVP_CONFIG_ERROR. Reflects the value of this signal from the FPGA control block, checked by software to determine if there was an error during configuration. | Variable | RO |
[18] | CVP_CONFIG_READY. Reflects the value of this signal from the FPGA control block, checked by software during programming algorithm. | Variable | RO |
[17:0] | Reserved | Variable | RO |
Bits |
Register Description |
Reset Value |
Access |
---|---|---|---|
[31:16] |
Reserved. |
0x0000 |
RO |
[15:8] |
CVP_NUMCLKS. This is the number of clocks to send for every CvP data write. Set this field to one of the values below depending on your configuration image:
|
0x00 |
RW |
[7:3] |
Reserved. |
0x0 |
RO |
[2] |
CVP_FULLCONFIG. Request that the FPGA control block reconfigure the entire FPGA including the Intel® Arria® 10 or Intel® Cyclone® 10 GX Hard IP for PCI Express, bring the PCIe link down. |
1’b0 |
RW |
[1] |
HIP_CLK_SEL. Selects between PMA and fabric clock when USER_MODE = 1 and PLD_CORE_READY = 1. The following encodings are defined:
To ensure that there is no clock switching during CvP, you should only change this value when the Hard IP for PCI Express has been idle for 10 µs and wait 10 µs after changing this value before resuming activity. |
1’b0 |
RW |
[0] |
CVP_MODE. Controls whether the IP core is in CVP_MODE or normal mode. The following encodings are defined:
|
1’b0 |
RW |
Bits |
Register Description |
Reset Value |
Access |
---|---|---|---|
[31:0] |
Upper 32 bits of configuration data to be transferred to the FPGA control block to configure the device. You can choose 32- or 64-bit data. |
0x00000000 |
RW |
[31:0] |
Lower 32 bits of configuration data to be transferred to the FPGA control block to configure the device. |
0x00000000 |
RW |
Bits |
Register Description |
Reset Value |
Access |
---|---|---|---|
[31:2] |
Reserved. |
0x0000 |
RO |
[1] |
START_XFER. Sets the CvP output to the FPGA control block indicating the start of a transfer. |
1’b0 |
RW |
[0] |
CVP_CONFIG. When asserted, instructs that the FPGA control block begin a transfer via CvP. |
1’b0 |
RW |
6.7. 64- or 128-Bit Avalon-MM Bridge Register Descriptions
The CRA Avalon-MM slave module provides access control and status registers in the PCI Express Avalon-MM bridge. In addition, it provides access to selected Configuration Space registers and link status registers in read-only mode. This module is optional. However, you must include it to access the registers.
The control and status register address space is 16 KB. Each 4 KB sub-region contains a set of functions, which may be specific to accesses from the PCI Express Root Complex only, from Avalon‑MM processors only, or from both types of processors. Because all accesses come across the interconnect fabric—requests from the Avalon‑MM Intel® Arria® 10 or Intel® Cyclone® 10 GX Hard IP for PCI Express are routed through the interconnect fabric—hardware does not enforce restrictions to limit individual processor access to specific regions. However, the regions are designed to enable straight-forward enforcement by processor software. The following figure illustrates accesses to the Avalon‑MM control and status registers from the Host CPU and PCI Express link.
The following table describes the four subregions.
Address Range |
Address Space Usage |
---|---|
0x0000-0x0FFF |
Registers typically intended for access by PCI Express link partner only. This includes PCI Express interrupt enable controls, write access to the PCI Express Avalon-MM bridge mailbox registers, and read access to Avalon-MM-to-PCI Express mailbox registers. |
0x1000-0x1FFF |
Avalon-MM-to-PCI Express address translation tables. Depending on the system design these may be accessed by the PCI Express link partner, Avalon-MM processors, or both. |
0x2000-0x2FFF |
Root Port request registers. An embedded processor, such as the Nios II processor, programs these registers to send the data for Configuration TLPs, I/O TLPs, single dword Memory Read and Write requests, and receive interrupts from an Endpoint. |
0x3000-0x3FFF |
Registers typically intended for access by Avalon-MM processors only. Provides host access to selected Configuration Space and status registers. |
The following table lists the complete address map for the PCI Express Avalon-MM bridge registers.
Address Range |
Register |
---|---|
0x0040 |
Avalon-MM to PCI Express Interrupt Status Register |
0x0050 |
Avalon-MM to PCI Express Interrupt Status Enable Register |
0x0800–0x081F |
PCI Express-to-Avalon-MM Mailbox Registers |
0x0900–x091F |
Avalon-MM to PCI Express Mailbox Registers |
0x1000–0x1FFF |
Avalon-MM to PCI Express Address Translation Table |
0x2000–0x2FFF |
Root Port TLP Data Registers |
0x3060 |
Avalon-MM to PCI Express Interrupt Status Registers for Root Ports |
0x3060 |
PCI Express to Avalon-MM Interrupt Status Register for Endpoints |
0x3070 |
INT-X Interrupt Enable Register for Root Ports |
0x3070 |
INT-X Interrupt Enable Register for Endpoints |
0x3A00-0x3A1F |
Avalon-MM to PCI Express Mailbox Registers |
0x3B00-0x3B1F |
PCI Express to Avalon-MM Mailbox Registers |
0x3C00-0x3C6C |
Host (Avalon-MM master) access to selected Configuration Space and status registers. |
6.7.1. Avalon-MM to PCI Express Interrupt Registers
6.7.1.1. Avalon-MM to PCI Express Interrupt Status Registers
Only Root Complexes should access these registers; however, hardware does not prevent other Avalon-MM masters from accessing them.
Bit |
Name |
Access |
Description |
---|---|---|---|
[31:24] |
Reserved |
N/A |
N/A |
[23] |
A2P_MAILBOX_INT7 |
RW1C |
Set to 1 when the A2P_MAILBOX7 register is written to |
[22] |
A2P_MAILBOX_INT6 |
RW1C |
1 when the A2P_MAILBOX6 register is written to |
[21] |
A2P_MAILBOX_INT5 |
RW1C |
Set 10 1 when the A2P_MAILBOX5 register is written to |
[20] |
A2P_MAILBOX_INT4 |
RW1C |
Set 10 1 when the A2P_MAILBOX4 register is written to |
[19] |
A2P_MAILBOX_INT3 |
RW1C |
Set 10 1 when the A2P_MAILBOX3 register is written to |
[18] |
A2P_MAILBOX_INT2 |
RW1C |
Set 10 1 when the A2P_MAILBOX2 register is written to |
[17] |
A2P_MAILBOX_INT1 |
RW1C |
Set 10 1 when the A2P_MAILBOX1 register is written to |
[16] |
A2P_MAILBOX_INT0 |
RW1C |
Set 10 1 when the A2P_MAILBOX0 register is written to |
[15:0] |
AVL_IRQ_ASSERTED[15:0] |
RO |
Current value of the Avalon-MM interrupt (IRQ) input ports to the Avalon-MM RX master port:
A PCIe* variant may have as many as 16 distinct IRQ input ports. Each AVL_IRQ_ASSERTED[] bit reflects the value on the corresponding IRQ input port. |
6.7.1.2. Avalon-MM to PCI Express Interrupt Enable Registers
A PCI Express interrupt can be asserted for any of the conditions registered in the Avalon-MM to PCI Express Interrupt Status register by setting the corresponding bits in the Avalon-MM to PCI Express Interrupt Enable register.
Bits |
Name |
Access |
Description |
---|---|---|---|
[31:24] |
Reserved |
N/A |
N/A |
[23:16] |
A2P_MB_IRQ |
RW |
Enables generation of PCI Express interrupts when a specified mailbox is written to by an external Avalon‑MM master. |
[15:0] |
AVL_IRQ[15:0] |
RW |
Enables generation of PCI Express interrupts when a specified Avalon-MM interrupt signal is asserted. Your system may have as many as 16 individual input interrupt signals. |
Bits |
Name |
Access |
Description |
---|---|---|---|
[31:16] |
Reserved |
N/A |
N/A |
[15:0] |
AVL_IRQ_Vector |
RO |
Stores the interrupt vector of the system interconnect fabric. When the host receives an interrupt, it should read this register to determine the servicing priority. |
6.7.1.3. PCI Express Mailbox Registers
The PCI Express Root Complex typically requires write access to a set of PCI Express to Avalon-MM Mailbox registers and read-only access to a set of Avalon-MM to PCI Express mailbox registers. Eight mailbox registers are available.
The PCI Express to Avalon MM Mailbox registers are writable at the addresses shown in the following table. Writing to one of these registers causes the corresponding bit in the Avalon-MM Interrupt Status register to be set to a one.
Address |
Name |
Access |
Description |
---|---|---|---|
0x0800 |
P2A_MAILBOX0 |
RW |
PCI Express-to-Avalon-MM Mailbox 0 |
0x0804 |
P2A_MAILBOX1 |
RW |
PCI Express-to-Avalon-MM Mailbox 1 |
0x0808 |
P2A_MAILBOX2 |
RW |
PCI Express-to-Avalon-MM Mailbox 2 |
0x080C |
P2A_MAILBOX3 |
RW |
PCI Express-to-Avalon-MM Mailbox 3 |
0x0810 |
P2A_MAILBOX4 |
RW |
PCI Express-to-Avalon-MM Mailbox 4 |
0x0814 |
P2A_MAILBOX5 |
RW |
PCI Express-to-Avalon-MM Mailbox 5 |
0x0818 |
P2A_MAILBOX6 |
RW |
PCI Express-to-Avalon-MM Mailbox 6 |
0x081C |
P2A_MAILBOX7 |
RW |
PCI Express-to-Avalon-MM Mailbox 7 |
The Avalon-MM to PCI Express Mailbox registers are read at the addresses shown in the following table. The PCI Express Root Complex should use these addresses to read the mailbox information after being signaled by the corresponding bits in the Avalon-MM to PCI Express Interrupt Status register.
Address |
Name |
Access |
Description |
---|---|---|---|
0x0900 |
A2P_MAILBOX0 |
RO |
Avalon-MM-to-PCI Express Mailbox 0 |
0x0904 |
A2P_MAILBOX1 |
RO |
Avalon-MM-to-PCI Express Mailbox 1 |
0x0908 |
A2P_MAILBOX2 |
RO |
Avalon-MM-to-PCI Express Mailbox 2 |
0x090C |
A2P_MAILBOX3 |
RO |
Avalon-MM-to-PCI Express Mailbox 3 |
0x0910 |
A2P_MAILBOX4 |
RO |
Avalon-MM-to-PCI Express Mailbox 4 |
0x0914 |
A2P_MAILBOX5 |
RO |
Avalon-MM-to-PCI Express Mailbox 5 |
0x0918 |
A2P_MAILBOX6 |
RO |
Avalon-MM-to-PCI Express Mailbox 6 |
0x091C |
A2P_MAILBOX7 |
RO |
Avalon-MM-to-PCI Express Mailbox 7 |
6.7.1.4. Avalon-MM-to-PCI Express Address Translation Table
The Avalon-MM-to-PCI Express address translation table is writable using the CRA slave port. Each entry in the PCI Express address translation table is 8 bytes wide, regardless of the value in the current PCI Express address width parameter. Therefore, register addresses are always the same width, regardless of PCI Express address width.
These table entries are repeated for each address specified in the Number of address pages parameter. If Number of address pages is set to the maximum of 512, 0x1FF8 contains A2P_ADDR_SPACE511 and A2P_ADDR_MAP_LO511 and 0x1FFC contains A2P_ADDR_MAP_HI511.
Address |
Bits |
Name |
Access |
Description |
---|---|---|---|---|
0x1000 |
[1:0] |
A2P_ADDR_SPACE0 |
RW |
Address space indication for entry 0. The following encodings are defined:
|
[31:2] |
A2P_ADDR_MAP_LO0 |
RW |
Lower bits of Avalon-MM-to-PCI Express address map entry 0. |
|
0x1004 |
[31:0] |
A2P_ADDR_MAP_HI0 |
RW |
Upper bits of Avalon-MM-to-PCI Express address map entry 0. |
0x1008 |
[1:0] |
A2P_ADDR_SPACE1 |
RW |
Address space indication for entry 1. This entry is available only if the number of translation table entries (Number of address pages) is greater than 1. The same encodings are defined for A2P_ADDR_SPACE1 as for A2P_ADDR_SPACE0.: |
[31:2] |
A2P_ADDR_MAP_LO1 |
RW |
Lower bits of Avalon-MM-to-PCI Express address map entry 1. This entry is only implemented if the number of address translation table entries is greater than 1. |
|
0x100C |
[31:0] |
A2P_ADDR_MAP_HI1 |
RW |
Upper bits of Avalon-MM-to-PCI Express address map entry 1. This entry is only implemented if the number of address translation table entries is greater than 1. |
6.7.1.5. PCI Express to Avalon-MM Interrupt Status and Enable Registers for Endpoints
The following table describes the Interrupt Status register for Endpoints. It records the status of all conditions that can cause an Avalon-MM interrupt to be asserted.
Bits |
Name |
Access |
Description |
---|---|---|---|
0 |
ERR_PCI_WRITE_FAILURE |
RW1C |
When set to 1, indicates a PCI Express write failure. This bit can also be cleared by writing a 1 to the same bit in the Avalon MM to PCI Express Interrupt Status register. |
1 |
ERR_PCI_READ_FAILURE |
RW1C |
When set to 1, indicates the failure of a PCI Express read. This bit can also be cleared by writing a 1 to the same bit in the Avalon MM to PCI Express Interrupt Status register. |
2 | TX_FIFO_EMPTY | RW1C | When set to 1, indicates that the TX buffer is
empty. Application Layer logic can read this bit to determine if all of
the TX buffer is empty before safely changing the translation address
entries. This bit is available only for Legacy Endpoints. |
[15:2] |
Reserved |
— |
— |
[16] |
P2A_MAILBOX_INT0 |
RW1C |
1 when the P2A_MAILBOX0 is written |
[17] |
P2A_MAILBOX_INT1 |
RW1C |
1 when the P2A_MAILBOX1 is written |
[18] |
P2A_MAILBOX_INT2 |
RW1C |
1 when the P2A_MAILBOX2 is written |
[19] |
P2A_MAILBOX_INT3 |
RW1C |
1 when the P2A_MAILBOX3 is written |
[20] |
P2A_MAILBOX_INT4 |
RW1C |
1 when the P2A_MAILBOX4 is written |
[21] |
P2A_MAILBOX_INT5 |
RW1C |
1 when the P2A_MAILBOX5 is written |
[22] |
P2A_MAILBOX_INT6 |
RW1C |
1 when the P2A_MAILBOX6 is written |
[23] |
P2A_MAILBOX_INT7 |
RW1C |
1 when the P2A_MAILBOX7 is written |
[31:24] |
Reserved |
— |
— |
An Avalon-MM interrupt can be asserted for any of the conditions noted in the Avalon-MM Interrupt Status register by setting the corresponding bits in the PCI Express to Avalon-MM Interrupt Enable register.
PCI Express interrupts can also be enabled for all of the error conditions described. However, it is likely that only one of the Avalon-MM or PCI Express interrupts can be enabled for any given bit. Typically, a single process in either the PCI Express or Avalon-MM domain handles the condition reported by the interrupt.
Bits |
Name |
Access |
Description |
---|---|---|---|
[31:24] | Reserved | N/A | Reserved |
[23] | P2A_MAILBOX_INT7 | RW1C | Set to a 1 when the P2A_MAILBOX7 is written to. |
[22] | P2A_MAILBOX_INT6 | Set to a 1 when the P2A_MAILBOX6 | |
[21] | P2A_MAILBOX_INT5 | Set to a 1 when the P2A_MAILBOX5 | |
[20] | P2A_MAILBOX_INT4 | Set to a 1 when the P2A_MAILBOX4 | |
[19] | P2A_MAILBOX_INT3 | Set to a 1 when the P2A_MAILBOX3 | |
[18] | P2A_MAILBOX_INT2 | Set to a 1 when the P2A_MAILBOX2 | |
[17] | P2A_MAILBOX_INT1 | Set to a 1 when the P2A_MAILBOX1 | |
[16] | P2A_MAILBOX_INT0 | Set to a 1 when the P2A_MAILBOX0 | |
[15:0] | Reserved | N/A | Reserved |
6.7.1.6. Avalon-MM Mailbox Registers
The Avalon-MM to PCI Express Mailbox registers are writable at the addresses shown in the following table. When the Avalon-MM processor writes to one of these registers the corresponding bit in the Avalon-MM to PCI Express Interrupt Status register is set to 1.
Address |
Name |
Access |
Description |
---|---|---|---|
0x3A00 |
A2P_MAILBOX0 |
RW |
Avalon-MM-to-PCI Express mailbox 0 |
0x3A04 |
A2P_MAILBOX1 |
RW |
Avalon-MM-to-PCI Express mailbox 1 |
0x3A08 |
A2P _MAILBOX2 |
RW |
Avalon-MM-to-PCI Express mailbox 2 |
0x3A0C |
A2P _MAILBOX3 |
RW |
Avalon-MM-to-PCI Express mailbox 3 |
0x3A10 |
A2P _MAILBOX4 |
RW |
Avalon-MM-to-PCI Express mailbox 4 |
0x3A14 |
A2P _MAILBOX5 |
RW |
Avalon-MM-to-PCI Express mailbox 5 |
0x3A18 |
A2P _MAILBOX6 |
RW |
Avalon-MM-to-PCI Express mailbox 6 |
0x3A1C |
A2P_MAILBOX7 |
RW |
Avalon-MM-to-PCI Express mailbox 7 |
The PCI Express to Avalon-MM Mailbox registers are read-only at the addresses shown in the following table. The Avalon-MM processor reads these registers when the corresponding bit in the PCI Express to Avalon-MM Interrupt Status register is set to 1.
Address |
Name |
Access Mode |
Description |
---|---|---|---|
0x3B00 |
P2A_MAILBOX0 |
RO |
PCI Express-to-Avalon-MM mailbox 0 |
0x3B04 |
P2A_MAILBOX1 |
RO |
PCI Express-to-Avalon-MM mailbox 1 |
0x3B08 |
P2A_MAILBOX2 |
RO |
PCI Express-to-Avalon-MM mailbox 2 |
0x3B0C |
P2A_MAILBOX3 |
RO |
PCI Express-to-Avalon-MM mailbox 3 |
0x3B10 |
P2A_MAILBOX4 |
RO |
PCI Express-to-Avalon-MM mailbox 4 |
0x3B14 |
P2A_MAILBOX5 |
RO |
PCI Express-to-Avalon-MM mailbox 5 |
0x3B18 |
P2A_MAILBOX6 |
RO |
PCI Express-to-Avalon-MM mailbox 6 |
0x3B1C |
P2A_MAILBOX7 |
RO |
PCI Express-to-Avalon-MM mailbox 7 |
6.7.1.7. Control Register Access (CRA) Avalon-MM Slave Port
Byte Offset |
Register |
Dir |
Description |
---|---|---|---|
14'h3C00 | cfg_dev_ctrl[15:0] |
O |
cfg_devctrl[15:0] is device control for the PCI Express capability structure. |
14'h3C04 | cfg_dev_ctrl2[15:0] |
O |
cfg_dev2ctrl[15:0] is device control 2 for the PCI Express capability structure. |
14'h3C08 | cfg_link_ctrl[15:0] |
O |
cfg_link_ctrl[15:0]is the primary Link Control of the PCI Express capability structure. For Gen2 or Gen3 operation, you must write a 1’b1 to Retrain Link bit (Bit[5] of the cfg_link_ctrl) of the Root Port to initiate retraining to a higher data rate after the initial link training to Gen1 L0 state. Retraining directs the LTSSM to the Recovery state. Retraining to a higher data rate is not automatic for the Intel® Arria® 10 or Intel® Cyclone® 10 GX Hard IP for PCI Express IP Core even if both devices on the link are capable of a higher data rate. |
14'h3C0C | cfg_link_ctrl2[15:0] |
O |
cfg_link_ctrl2[31:16] is the secondary Link Control register of the PCI Express capability structure for Gen2 operation. For Gen1 variants, the link bandwidth notification bit is always set to 0. For Gen2 variants, this bit is set to 1. |
14'h3C10 | cfg_prm_cmd[15:0] |
O |
Base/Primary Command register for the PCI Configuration Space. |
14'h3C14 | cfg_root_ctrl[7:0] |
O |
Root control and status register of the PCI-Express capability. This register is only available in Root Port mode. |
14'h3C18 | cfg_sec_ctrl[15:0] |
O |
Secondary bus Control and Status register of the PCI-Express capability. This register is only available in Root Port mode. |
14'h3C1C | cfg_secbus[7:0] |
O |
Secondary bus number. Available in Root Port mode. |
14'h3C20 | cfg_subbus[7:0] |
O |
Subordinate bus number. Available in Root Port mode. |
14'h3C24 | cfg_msi_addr_low[31:0] |
O |
cfg_msi_add[31:0] is the MSI message address. |
14'h3C28 | cfg_msi_addr_hi[63:32] |
O |
cfg_msi_add[63:32] is the MSI upper message address. |
14'h3C2C | cfg_io_bas[19:0] |
O |
The IO base register of the Type1 Configuration Space. This register is only available in Root Port mode. |
14'h3C30 | cfg_io_lim[19:0] |
O |
The IO limit register of the Type1 Configuration Space. This register is only available in Root Port mode. |
14'h3C34 | cfg_np_bas[11:0] |
O |
The non-prefetchable memory base register of the Type1 Configuration Space. This register is only available in Root Port mode. |
14'h3C38 | cfg_np_lim[11:0] |
O |
The non-prefetchable memory limit register of the Type1 Configuration Space. This register is only available in Root Port mode. |
14'h3C3C | cfg_pr_bas_low[31:0] |
O |
The lower 32 bits of the prefetchable base register of the Type1 Configuration Space. This register is only available in Root Port mode. |
14'h3C40 | cfg_pr_bas_hi[43:32] |
O |
The upper 12 bits of the prefetchable base registers of the Type1 Configuration Space. This register is only available in Root Port mode. |
14'h3C44 | cfg_pr_lim_low[31:0] |
O |
The lower 32 bits of the prefetchable limit registers of the Type1 Configuration Space. Available in Root Port mode. |
14'h3C48 | cfg_pr_lim_hi[43:32] |
O |
The upper 12 bits of the prefetchable limit registers of the Type1 Configuration Space. Available in Root Port mode. |
14'h3C4C | cfg_pmcsr[31:0] |
O |
cfg_pmcsr[31:16] is Power Management Control and cfg_pmcsr[15:0]is the Power Management Status register. |
14'h3C50 | cfg_msixcsr[15:0] |
O |
MSI-X message control register. |
14'h3C54 | cfg_msicsr[15:0] |
O |
MSI message control. |
14'h3C58 | cfg_tcvcmap[23:0] |
O |
Configuration traffic class (TC)/virtual channel (VC) mapping. The Application Layer uses this signal to generate a TLP mapped to the appropriate channel based on the traffic class of the packet. The following encodings are defined:
|
14'h3C5C | cfg_msi_data[15:0] |
O |
cfg_msi_data[15:0] is message data for MSI. |
14'h3C60 | cfg_busdev[12:0] |
O |
Bus/Device Number captured by or programmed in the Hard IP. |
14'h3C64 | ltssm_reg[4:0] |
O |
Specifies the current LTSSM state.
The LTSSM state machine encoding defines the following states:
|
14'h3C68 | current_speed_reg[1:0] |
O |
Indicates the current speed of the PCIe link. The following encodings are defined:
|
14'h3C6C | lane_act_reg[3:0] |
O |
Lane Active Mode: This signal indicates the number of lanes that configured during link training. The following encodings are defined:
|
6.8. Programming Model for Avalon-MM Root Port
The Application Layer writes the Root Port TLP TX Data registers with TLP formatted data for Configuration Read and Write Requests, Message TLPs, Message TLPs with data payload, I/O Read and Write Requests, or single dword Memory Read and Write Requests. Software should check the Root Port Link Status register (offset 0x92) to ensure the Data Link Layer Link Active bit is set to 1'b1 before issuing a Configuration request to downstream ports.
The TX TLP programming model scales with the data width. The Application Layer performs the same writes for both the 64- and 128-bit interfaces. The Application Layer can only have one outstanding non-posted request at a time. The Application Layer must use tags 16–31 to identify non-posted requests.
6.8.1. Sending a Write TLP
The Application Layer performs the following sequence of Avalon-MM accesses to the CRA slave port to send a Memory Write Request:
- Write the first 32 bits of the TX TLP to RP_TX_REG0 at address 0x2000.
- Write the next 32 bits of the TX TLP to RP_TX_REG1 at address 0x2004.
- Write the RP_TX_CNTRL.SOP to 1’b1 (RP_TX_CNTRL is at address 0x2008) to push the first two dwords of the TLP into the Root Port TX FIFO.
- Repeat Steps 1 and 2. The second write to RP_TX_REG1 is required, even for three dword TLPs with aligned data.
- If the packet is complete, write RP_TX_CNTRL to 2’b10 to indicate the end of the packet. If the packet is not complete, write 2’b00 to RP_TX_CNTRL.
- Repeat this sequence to program a complete TLP.
When the programming of the TX TLP is complete, the Avalon® -MM bridge schedules the TLP with higher priority than TX TLPs coming from the TX slave port.
6.8.2. Sending a Read TLP or Receiving a Non-Posted Completion TLP
The TLPs associated with the Non-Posted TX requests are stored in the RP_RX_CPL FIFO buffer and subsequently loaded into RP_RXCPL registers. The Application Layer performs the following sequence to retrieve the TLP.
- Polls the RP_RXCPL_STA TUS.SOP to determine when it is set to 1’b1.
- Then RP_RXCPL_STATUS.SOP = 1’b’1, reads RP_RXCPL_REG0 and RP_RXCPL_REG1 to retrieve dword 0 and dword 1 of the TLP.
- Read the
RP_RXCPL_STATUS.EOP.
- If RP_RXCPL_STATUS.EOP = 1’b0, read RP_RXCPL_REG0 and RP_RXCPL_REG1 to retrieve dword 2 and dword 3 of the TLP, then repeat step 3.
- If RP_RXCPL_STATUS.EOP = 1’b1, read RP_RXCPL_REG0 and RP_RXCPL_REG1 to retrieve final dwords of TLP.
6.8.3. Examples of Reading and Writing BAR0 Using the CRA Interface
You can use the CRA interface to send TLP requests. The Fmt and Type fields of the TLP Header provide the information required to determine the size of the remaining part of the TLP Header, and if the packet contains a data payload following the Header.

The CRA interface uses register addresses 0x2000, 0x2004, and 0x2008 to send TLPs, and register addresses 0x2010, 0x2014, and 0x2018 to check Completions. For details about these registers, refer to the table Root Port TLP Data Registers, 0x2000 - 0x2FFF. Below are examples of how to use Type 0 configuration TLPs to read from BAR0 and write to it.
- Use the CRA interface to read an uninitialized BAR0 using a Type 0
configuration TLP with the format as shown
below:
| fmt | typ |t| tc |t|a|l|t|t|e|att| at| length | | 000b| 00100b |0|_ 0 _|0|0|0|0|0|0| 0 | 0 |_______ 001 _______| |________ req_id: 0000 _________|___ tag: 17 ___|lbe: 0 |fbe: f | | bdf.bus |bdf.dev|bdf.func|rsvd20|reg_no.ext|reg_no.low|rsv| |______ 01 ___|__ 00 _|___ 0 __|_ 0 __|___ 0 ____|___ 04 ___| 0 | 04000001 0000170f 01000010
To send the TLP using the CRA interface, do the following steps:
- Write 0x0400_0001 to CRA interface address 0x2000.
- Write 0x0000_170F to CRA interface address 0x2004.
- Write 0x0000_0001 to CRA interface address 0x2008 (Start of Packet).
- Write 0x0100_0010 to CRA interface address 0x2000.
- Write 0x0000_0000 to CRA interface address 0x2004.
- Write 0x0000_0002 to CRA interface address 0x2008 (End of Packet).
Check the corresponding Completion using the CRA interface. The Completion TLP has four dwords, with the first three dwords as shown below, followed by one dword of uninitialized BAR0 value (which is 0xFFEF0010 in the following picture).
| fmt | typ |t| tc |t|a|l|t|t|e|att| at| length | | 010b| 01010b |0|_ 0 _|0|0|0|0|0|0| 0 | 0 |_______ 001 _______| |_____ cpl_id: 0100 ___|cpl_status: 0|bcm: 0|__ byte_cnt: 004 __| |_____ req_id: 0000 ___|___ tag: 17 ___|rsvd20: 0| low_addr: 00 | 4a000001 01000004 00001700 ffef0010
To read the Completion using the CRA interface, do the following steps:
- Keep reading CRA interface address 0x2010 until bit [0] = 0x1 (indicating the Completion packet has arrived, and you can receive the SOP in the next step.
- Read CRA interface address 0x2014. The read data value is 0x4A00_0001.
- Read CRA interface address 0x2018. The read data value is 0x0100_0004.
- Read CRA interface address 0x2010. In this example, bits [1:0] = 0x2 (indicating that you will receive the EOP in the next step). If bits [1:0] = 0x0, the values read in the next two steps are still in the middle of the packet. In this case, you need to keep reading 0x2010, 0x2014, and 0x2018 after performing the next two steps.
- Read CRA interface address 0x2014. The read data value is 0x0000_1700.
- Read CRA interface address 0x2018. The read data value is BAR0's uninitialized value.
- Use the CRA interface to initialize BAR0 with 0xFFFF_FFFF using a Type 0
configuration TLP with the format as shown
below:
| fmt | typ |t| tc |t|a|l|t|t|e|att| at| length | | 010b| 00100b |0|_ 0 _|0|0|0|0|0|0| 0 | 0 |_______ 001 _______| |________ req_id: 0000 _________|___ tag: 11 ___|lbe: 0 |fbe: f | | bdf.bus |bdf.dev|bdf.func|rsvd20|reg_no.ext|reg_no.low|rsv| |______ 01 ___|__ 00 _|___ 0 __|_ 0 __|___ 0 ____|___ 04 ___| 0 | 44000001 0000110f 01000010 ffffffff
To send the TLP using the CRA interface, do the following steps:
- Write 0x4400_0001 to CRA interface address 0x2000.
- Write 0x0000_110F to CRA interface address 0x2004.
- Write 0x0000_0001 to CRA interface address 0x2008 (Start of Packet).
- Write 0x0100_0010 to CRA interface address 0x2000.
- Write 0xFFFF_FFFF to CRA interface address 0x2004.
- Write 0x0000_0002 to CRA interface address 0x2008 (End of Packet).
Check the corresponding Completion using the CRA interface. The Completion TLP has three dwords as shown below:
| fmt | typ |t| tc |t|a|l|t|t|e|att| at| length | | 000b| 01010b |0|_ 0 _|0|0|0|0|0|0| 0 | 0 |_______ 000 _______| |_____ cpl_id: 0100 ___|cpl_status: 0|bcm: 0|__ byte_cnt: 004 __| |_____ req_id: 0000 ___|___ tag: 11 ___|rsvd20: 0| low_addr: 00 | 0a000000 01000004 00001100
To read the Completion using the CRA interface, do the following steps:
- Keep reading CRA interface address 0x2010 until bit [0] = 0x1 (indicating the Completion packet has arrived, and you can receive the SOP in the next step).
- Read CRA interface address 0x2014. The read data value is 0x0A00_0000.
- Read CRA interface address 0x2018. The read data value is 0x0100_0004.
- Read CRA interface address 0x2010. In this example, bits [1:0] = 0x2.
- Read CRA interface address 0x2014. The read data value is 0x0000_1100.
You can repeat Step 1 to read BAR0 after writing 0xFFFF_FFFF to it, and repeat Step 2 to configure the BAR0 address space.
Use the same method to configure BAR1, BAR2, BAR3, BAR4 and BAR5.
6.8.4. PCI Express to Avalon-MM Interrupt Status and Enable Registers for Root Ports
The Root Port supports MSI, MSI‑X and legacy (INTx) interrupts. MSI and MSI‑X interrupts are memory writes from the Endpoint to the Root Port. MSI and MSI‑X requests are forwarded to the interconnect without asserting CraIrq_o.
Bits |
Name |
Access Mode |
Description |
---|---|---|---|
[31:5] |
Reserved |
— |
— |
[4] |
RPRX_CPL_RECEIVED |
RW1C |
Set to 1’b1 when the Root Port has received a Completion TLP for an outstanding Non-Posted request from the TLP Direct channel. |
[3] |
INTD_RECEIVED |
RW1C |
The Root Port has received INTD from the Endpoint. |
[2] |
INTC_RECEIVED |
RW1C |
The Root Port has received INTC from the Endpoint. |
[1] |
INTB_RECEIVED |
RW1C |
The Root Port has received INTB from the Endpoint. |
[0] |
INTA_RECEIVED |
RW1C |
The Root Port has received INTA from the Endpoint. |
Bit |
Name |
Access Mode |
Description |
---|---|---|---|
[31:5] |
Reserved |
— |
— |
[4] |
RPRX_CPL_RECEIVED |
RW |
When set to 1’b1, enables the assertion of CraIrq_o when the Root Port Interrupt Status register RPRX_CPL_RECEIVED bit indicates it has received a Completion for a Non‑Posted request from the TLP Direct channel. |
[3] |
INTD_RECEIVED_ENA |
RW |
When set to 1’b1, enables the assertion of CraIrq_o when the Root Port Interrupt Status register INTD_RECEIVED bit indicates it has received INTD. |
[2] |
INTC_RECEIVED_ENA |
RW |
When set to 1’b1, enables the assertion of CraIrq_o when the Root Port Interrupt Status register INTC_RECEIVED bit indicates it has received INTC. |
[1] |
INTB_RECEIVED_ENA |
RW |
When set to 1’b1, enables the assertion of CraIrq_o when the Root Port Interrupt Status register INTB_RECEIVED bit indicates it has received INTB. |
[0] |
INTA_RECEIVED_ENA |
RW |
When set to 1’b1, enables the assertion of CraIrq_o when the Root Port Interrupt Status register INTA_RECEIVED bit indicates it has received INTA. |
6.8.5. Root Port TLP Data Registers
The TLP data registers provide a mechanism for the Application Layer to specify data that the Root Port uses to construct Configuration TLPs, I/O TLPs, and single dword Memory Reads and Write requests. The Root Port then drives the TLPs on the TLP Direct Channel to access the Configuration Space, I/O space, or Endpoint memory.
Root-Port Request Registers |
Address Range: 0x2800-0x2018 |
|||
---|---|---|---|---|
Address |
Bits |
Name |
Access |
Description |
0x2000 |
[31:0] |
RP_TX_REG0 |
W |
Lower 32 bits of the TX TLP. |
0x2004 |
[31:0] |
RP_TX_REG1 |
W |
Upper 32 bits of the TX TLP. |
0x2008 |
[31:2] |
Reserved |
— |
— |
[1] |
RP_TX_CNTRL.EOP |
W |
Write 1’b1 to specify the of end a packet. Writing this bit frees the corresponding entry in the FIFO. |
|
[0] |
RP_TX_CNTRL.SOP |
W |
Write 1’b1 to specify the start of a packet. Note: Both bits [1] and [0] are equal to 0 for all cycles in the packet
except for the SOP and EOP cycles.
|
|
0x2010 |
[31:2] |
Reserved |
— |
— |
[1] |
RP_RXCPL_STATUS.EOP |
R |
When 1’b1, indicates that the final data for a Completion TLP is ready to be read by the Application Layer. The Application Layer must poll this bit to determine when the final data for a Completion TLP is available. |
|
[0] |
RP_RXCPL_STATUS.SOP |
R |
When 1’b1, indicates that the data for a Completion TLP is ready to be read by the Application Layer. The Application Layer must poll this bit to determine when a Completion TLP is available. |
|
0x2014 |
[31:0] |
RP_RXCPL_REG0 |
RC |
Lower 32 bits of a Completion TLP. Reading frees this entry in the FIFO. |
0x2018 |
[31:0] |
RP_RXCPL_REG1 |
RC |
Upper 32 bits of a Completion TLP. Reading frees this entry in the FIFO. |
6.9. Uncorrectable Internal Error Mask Register
Bits |
Register Description |
Reset Value |
Access |
---|---|---|---|
[31:12] |
Reserved. |
1b’0 |
RO |
[11] |
Mask for RX buffer posted and completion overflow error. |
1b’0 |
RWS |
[10] |
Reserved |
1b’1 |
RO |
[9] |
Mask for parity error detected on Configuration Space to TX bus interface. |
1b’1 |
RWS |
[8] |
Mask for parity error detected on the TX to Configuration Space bus interface. |
1b’1 |
RWS |
[7] |
Mask for parity error detected at TX Transaction Layer error. |
1b’1 |
RWS |
[6] |
Reserved |
1b’1 |
RO |
[5] |
Mask for configuration errors detected in CvP mode. |
1b’0 |
RWS |
[4] |
Mask for data parity errors detected during TX Data Link LCRC generation. |
1b’1 |
RWS |
[3] |
Mask for data parity errors detected on the RX to Configuration Space Bus interface. |
1b’1 |
RWS |
[2] |
Mask for data parity error detected at the input to the RX Buffer. |
1b’1 |
RWS |
[1] |
Mask for the retry buffer uncorrectable ECC error. |
1b’1 |
RWS |
[0] |
Mask for the RX buffer uncorrectable ECC error. |
1b’1 |
RWS |
6.10. Uncorrectable Internal Error Status Register
Bits |
Register Description |
Reset Value |
Access |
---|---|---|---|
[31:12] |
Reserved. |
0 |
RO |
[11] |
When set, indicates an RX buffer overflow condition in a posted request or Completion |
0 |
RW1CS |
[10] |
Reserved. |
0 |
RO |
[9] |
When set, indicates a parity error was detected on the Configuration Space to TX bus interface |
0 |
RW1CS |
[8] |
When set, indicates a parity error was detected on the TX to Configuration Space bus interface |
0 |
RW1CS |
[7] |
When set, indicates a parity error was detected in a TX TLP and the TLP is not sent. |
0 |
RW1CS |
[6] |
When set, indicates that the Application Layer has detected an uncorrectable internal error. |
0 |
RW1CS |
[5] |
When set, indicates a configuration error has been detected in CvP mode which is reported as uncorrectable. This bit is set whenever a CVP_CONFIG_ERROR rises while in CVP_MODE. |
0 |
RW1CS |
[4] |
When set, indicates a parity error was detected by the TX Data Link Layer. |
0 |
RW1CS |
[3] |
When set, indicates a parity error has been detected on the RX to Configuration Space bus interface. |
0 |
RW1CS |
[2] |
When set, indicates a parity error was detected at input to the RX Buffer. |
0 |
RW1CS |
[1] |
When set, indicates a retry buffer uncorrectable ECC error. |
0 |
RW1CS |
[0] |
When set, indicates a RX buffer uncorrectable ECC error. |
0 |
RW1CS |
6.11. Correctable Internal Error Mask Register
Bits |
Register Description |
Reset Value |
Access |
---|---|---|---|
[31:8] |
Reserved. |
0 |
RO |
[7] | Reserved. | 1 | RO |
[6] |
Mask for Corrected Internal Error reported by the Application Layer. |
1 |
RWS |
[5] |
Mask for configuration error detected in CvP mode. |
1 |
RWS |
[4:2] |
Reserved. |
0 |
RO |
[1] |
Mask for retry buffer correctable ECC error. |
1 |
RWS |
[0] |
Mask for RX Buffer correctable ECC error. |
1 |
RWS |
6.12. Correctable Internal Error Status Register
Bits |
Register Description |
Reset Value |
Access |
---|---|---|---|
[31:7] |
Reserved. |
0 |
RO |
[6] | Corrected Internal Error reported by the Application Layer. | 0 | RW1CS |
[5] |
When set, indicates a configuration error has been detected in CvP mode which is reported as correctable. This bit is set whenever a CVP_CONFIG_ERROR occurs while in CVP_MODE. |
0 |
RW1CS |
[4:2] |
Reserved. |
0 |
RO |
[1] |
When set, the retry buffer correctable ECC error status indicates an error. |
0 |
RW1CS |
[0] |
When set, the RX buffer correctable ECC error status indicates an error. |
0 |
RW1CS |
7. Reset and Clocks
The following figure shows the hard reset controller that is embedded inside the Hard IP for PCI Express* . This controller takes in the npor and pin_perst inputs and generates the internal reset signals for other modules in the Hard IP.
7.1. Reset Sequence for Hard IP for PCI Express IP Core and Application Layer
This reset sequence includes the following steps:
- After pin_perst or npor is released, the Hard IP reset controller waits for pld_clk_inuse to be asserted.
- csrt and srst are released 32 cycles after pld_clk_inuse is asserted.
- The Hard IP for PCI Express deasserts the reset_status output to the Application Layer.
- The altpcied_<device>v_hwtcl.sv deasserts app_rstn 32 pld_clkcycles after
reset_status is released.
Note: reset_status may be toggling until the host and its receivers are detected during the link training sequence (ltssmstate[4:0] = 0x02).
The RX transceiver reset sequence includes the following steps:
- After rx_pll_locked is asserted, the LTSSM state machine transitions from the Detect.Quiet to the Detect.Active state.
- When the pipe_phystatus pulse is asserted and pipe_rxstatus[2:0] = 3, the receiver detect operation has completed.
- The LTSSM state machine transitions from the Detect.Active state to the Polling.Active state.
- The Hard IP for PCI Express asserts rx_digitalreset. The rx_digitalreset signal is deasserted after rx_signaldetect is stable for a minimum of 3 ms.
The TX transceiver reset sequence includes the following steps:
- After npor is deasserted, the IP core deasserts the npor_serdes input to the TX transceiver.
- The SERDES reset controller waits for pll_locked to be stable for a minimum of 127 pld_clk cycles before deasserting tx_digitalreset.
For descriptions of the available reset signals, refer to Reset Signals, Status, and Link Training Signals.
7.2. Clocks
The Hard IP contains a clock domain crossing (CDC) synchronizer at the interface between the PHY/MAC and the DLL layers. The synchronizer allows the Data Link and Transaction Layers to run at frequencies independent of the PHY/MAC. The CDC synchronizer provides more flexibility for the user clock interface. Depending on parameters you specify, the core selects the appropriate coreclkout_hip. You can use these parameters to enhance performance by running at a higher frequency for latency optimization or at a lower frequency to save power.
In accordance with the PCI Express Base Specification, you must provide a 100 MHz reference clock that is connected directly to the transceiver.
7.2.1. Clock Domains
As this figure indicates, the IP core includes the following clock domains: pclk, coreclkout_hip and pld_clk.
7.2.1.1. coreclkout_hip
Link Width |
Maximum Link Rate |
Avalon Interface Width |
coreclkout_hip |
---|---|---|---|
×1 |
Gen1 |
64 | 62.5 MHz6 |
×1 |
Gen1 |
64 |
125 MHz |
×2 |
Gen1 |
64 |
125 MHz |
×4 |
Gen1 |
64 |
125 MHz |
×2 |
Gen2 | 64 |
125 MHz |
×4 |
Gen2 |
128 |
125 MHz |
×1 |
Gen1 |
64 | 62.5 MHz7 |
×1 |
Gen1 |
64 |
125 MHz |
×2 |
Gen1 |
64 |
125 MHz |
×4 |
Gen1 |
64 |
125 MHz |
×8 |
Gen1 |
64 |
250 MHz |
×8 |
Gen1 |
128 |
125 MHz |
×1 |
Gen2 | 64 |
125 MHz |
×2 |
Gen2 | 64 |
125 MHz |
×4 |
Gen2 |
64 |
250 MHz |
×4 |
Gen2 |
128 |
125 MHz |
×8 |
Gen2 |
128 |
250 MHz |
×8 |
Gen2 |
256 |
125 MHz |
×1 |
Gen3 | 64 |
125 MHz |
×2 |
Gen3 | 64 |
125 MHz |
×2 |
Gen3 | 128 | 125 MHz |
×2 |
Gen3 | 64 |
250 MHz |
×4 |
Gen3 |
128 |
250 MHz |
×4 |
Gen3 |
256 |
125 MHz |
×8 |
Gen3 |
256 |
250 MHz |
7.2.1.2. pld_clk
coreclkout_hip can drive the Application Layer clock along with the pld_clk input to the IP core. The pld_clk can optionally be sourced by a different clock than coreclkout_hip. The pld_clk minimum frequency cannot be lower than the coreclkout_hip frequency. Based on specific Application Layer constraints, a PLL can be used to derive the desired frequency.
7.2.2. Clock Summary
Name |
Frequency |
Clock Domain |
---|---|---|
coreclkout_hip |
62.5, 125 or 250 MHz |
Avalon‑ST interface between the Transaction and Application Layers. |
pld_clk |
pld_clk has a maximum frequency of 250 MHz and a minimum frequency that can be equal or more than the coreclkout_hip frequency, depending on the link width, link rate, and Avalon® interface width as indicated in the table for the Application Layer clock frequency above. |
Application and Transaction Layers. |
refclk |
100 MHz |
SERDES (transceiver). Dedicated free running input clock to the SERDES block. |
8. Interrupts for Endpoints
The PCI Express Avalon-MM bridge supports MSI or legacy interrupts. The completer only single dword variant includes an interrupt handler that implements both INTX and MSI interrupts. Support requires instantiation of the CRA slave module where the interrupt registers and control logic are implemented.
The PCI Express Avalon‑MM bridge supports the Avalon‑MM individual requests interrupt scheme: multiple input signals indicate incoming interrupt requests, and software must determine priorities for servicing simultaneous interrupts.
The RX master module port has up to 16 Avalon‑MM interrupt input signals (RXmirq_irq[ <n> :0], where <n> ≤15). Each interrupt signal indicates a distinct interrupt source. Assertion of any of these signals, or a PCI Express mailbox register write access, sets a bit in the Avalon-MM to PCI Express Interrupt Status register. Multiple bits can be set at the same time; Application Layer software on the host side determines priorities for servicing simultaneous incoming interrupt requests. Each set bit in the Avalon-MM to PCI Express Interrupt Status register generates a PCI Express interrupt, if enabled, when software determines its turn. Software can enable the individual interrupts by writing to the Avalon-MM to PCI Express Interrupt Enable Register through the CRA slave.
When any interrupt input signal is asserted, the corresponding bit is written in the Avalon-MM to PCI Express Interrupt Status Register. Software reads this register and decides priority on servicing requested interrupts.
After servicing the interrupt, software must clear the appropriate serviced interrupt status bit and ensure that no other interrupts are pending. For interrupts caused by Avalon-MM to PCI Express Interrupt Status Register mailbox writes, the status bits should be cleared in the Avalon-MM to PCI Express Interrupt Status Register. For interrupts due to the incoming interrupt signals on the Avalon‑MM interface, the interrupt status should be cleared in the Avalon‑MM component that sourced the interrupt. This sequence prevents interrupt requests from being lost during interrupt servicing.
8.1. Enabling MSI or Legacy Interrupts
The PCI Express Avalon-MM bridge selects either MSI or legacy interrupts automatically based on the standard interrupt controls in the PCI Express Configuration Space registers. Software can write the Interrupt Disable bit, which is bit 10 of the Command register (at Configuration Space offset 0x4) to disable legacy interrupts. Software can write the MSI Enable bit, which is bit 0 of the MSI Control Status register in the MSI capability register (bit 16 at configuration space offset 0x50), to enable MSI interrupts.
Software can only enable one type of interrupt at a time. However, to change the selection of MSI or legacy interrupts during operation, software must ensure that no interrupt request is dropped. Therefore, software must first enable the new selection and then disable the old selection. To set up legacy interrupts, software must first clear the Interrupt Disable bit and then clear the MSI enable bit. To set up MSI interrupts, software must first set the MSI enable bit and then set the Interrupt Disable bit.
8.2. Generation of Avalon-MM Interrupts
The generation of Avalon-MM interrupts requires the instantiation of the CRA slave module where the interrupt registers and control logic are implemented. The CRA slave port has an Avalon-MM Interrupt output signal, cra_Irq_irq. A write access to an Avalon-MM mailbox register sets one of the P2A_MAILBOX_INT<n> bits in the Avalon-MM to PCI Express Interrupt Status Register and asserts the cra_Irq_o or cra_Irq_irq output, if enabled. Software can enable the interrupt by writing to the INT_X Interrupt Enable Register for Endpoints through the CRA slave. After servicing the interrupt, software must clear the appropriate serviced interrupt status bit in the PCI‑Express‑to-Avalon-MM Interrupt Status register and ensure that no other interrupt is pending.
8.3. Interrupts for Endpoints Using the Avalon-MM Interface with Multiple MSI/MSI-X Support
If you select Enable multiple MSI/MSI X support under the Avalon-MM System Settings banner in the parameter editor, the Hard IP for PCI Express exports the MSI, MSI‑X, and INTx interfaces to the Application Layer. The Application Layer must include a Custom Interrupt Handler to send interrupts to the Root Port. You must design this Custom Interrupt Handler. The following figure provides an overview of the logic for the Custom Interrupt Handler. The Custom Interrupt Handler should include hardware to perform the following tasks:
- An MSI/MXI-X IRQ Avalon‑MM Master port to drive MSI or MSI-X interrupts as memory writes to the PCIe Avalon‑MM bridge.
- A legacy interrupt signal, IntxReq_i, to drive legacy interrupts from the MSI/MSI‑X IRQ module to the Hard IP for PCI Express.
- An MSI/MSI‑X Avalon‑MM Slave port to receive interrupt control and status from the PCIe Root Port.
- An MSI-X table to store the MSI-X table entries. The PCIe Root Port sets up this table.
Refer to Interrupts for Endpoints for the definitions of MSI, MSI‑X, and INTx buses.
For more information about implementing MSI or MSI‑X interrupts, refer to the PCI Local Bus Specification, Revision 2.3, MSI-X ECN.
For more information about implementing interrupts, including an MSI design example, refer to Handling PCIe Interrupts on the Intel® FPGA wiki.
9. Error Handling
Each PCI Express compliant device must implement a basic level of error management and can optionally implement advanced error management. The IP core implements both basic and advanced error reporting. Error handling for a Root Port is more complex than that of an Endpoint.
Type |
Responsible Agent |
Description |
---|---|---|
Correctable |
Hardware |
While correctable errors may affect system performance, data integrity is maintained. |
Uncorrectable, non-fatal |
Device software |
Uncorrectable, non-fatal errors are defined as errors in which data is lost, but system integrity is maintained. For example, the fabric may lose a particular TLP, but it still works without problems. |
Uncorrectable, fatal |
System software |
Errors generated by a loss of data and system failure are considered uncorrectable and fatal. Software must determine how to handle such errors: whether to reset the link or implement other means to minimize the problem. |
9.1. Physical Layer Errors
Error |
Type |
Description |
---|---|---|
Receive port error |
Correctable |
This error has the following 3 potential causes:
|
9.2. Data Link Layer Errors
Error |
Type |
Description |
---|---|---|
Bad TLP |
Correctable |
This error occurs when a LCRC verification fails or when a sequence number error occurs. |
Bad DLLP |
Correctable |
This error occurs when a CRC verification fails. |
Replay timer |
Correctable |
This error occurs when the replay timer times out. |
Replay num rollover |
Correctable |
This error occurs when the replay number rolls over. |
Data Link Layer protocol |
Uncorrectable(fatal) |
This error occurs when a sequence number specified by the Ack/Nak block in the Data Link Layer (AckNak_Seq_Num) does not correspond to an unacknowledged TLP. |
9.3. Transaction Layer Errors
Error |
Type |
Description |
---|---|---|
Poisoned TLP received |
Uncorrectable (non-fatal) |
This error occurs if a received Transaction Layer Packet has the EP poison bit set. The received TLP is passed to the Application Layer and the Application Layer logic must take appropriate action in response to the poisoned TLP. Refer to “2.7.2.2 Rules for Use of Data Poisoning” in the PCI Express Base Specification for more information about poisoned TLPs. |
ECRC check failed (1) |
Uncorrectable (non-fatal) |
This error is caused by an ECRC check failing despite the fact that the TLP is not malformed and the LCRC check is valid. The Hard IP block handles this TLP automatically. If the TLP is a non‑posted request, the Hard IP block generates a completion with completer abort status. In all cases the TLP is deleted in the Hard IP block and not presented to the Application Layer. |
Unsupported Request for Endpoints |
Uncorrectable (non-fatal) |
This error occurs whenever a component receives any of the following Unsupported Requests:
In all cases the TLP is deleted in the Hard IP block and not presented to the Application Layer. If the TLP is a non-posted request, the Hard IP block generates a completion with Unsupported Request status. |
Unsupported Requests for Root Port |
Uncorrectable (fatal) |
This error occurs whenever a component receives an Unsupported Request including:
|
Completion timeout |
Uncorrectable (non-fatal) |
This error occurs when a request originating from the Application Layer does not generate a corresponding completion TLP within the established time. It is the responsibility of the Application Layer logic to provide the completion timeout mechanism. The completion timeout should be reported from the Transaction Layer using the cpl_err[0] signal. |
Completer abort (1) |
Uncorrectable (non-fatal) |
The Application Layer reports this error using the cpl_err[2]signal when it aborts receipt of a TLP. |
Unexpected completion |
Uncorrectable (non-fatal) |
This error is caused by an unexpected completion transaction. The Hard IP block handles the following conditions:
In all of the above cases, the TLP is not presented to the Application Layer; the Hard IP block deletes it. The Application Layer can detect and report other unexpected completion conditions using the cpl_err[2] signal. For example, the Application Layer can report cases where the total length of the received successful completions do not match the original read request length. |
Receiver overflow (1) |
Uncorrectable (fatal) |
This error occurs when a component receives a TLP that violates the FC credits allocated for this type of TLP. In all cases the hard IP block deletes the TLP and it is not presented to the Application Layer. |
Flow control protocol error (FCPE) (1) |
Uncorrectable (fatal) |
This error occurs when a component does not receive update flow control credits with the 200 µs limit. |
Malformed TLP |
Uncorrectable (fatal) |
This error is caused by any of the following conditions:
The Hard IP block deletes the malformed TLP; it is not presented to the Application Layer. |
Note:
|
9.4. Error Reporting and Data Poisoning
How the Endpoint handles a particular error depends on the configuration registers of the device.
Refer to the PCI Express Base Specification 3.0 for a description of the device signaling and logging for an Endpoint.
The Hard IP block implements data poisoning, a mechanism for indicating that the data associated with a transaction is corrupted. Poisoned TLPs have the error/poisoned bit of the header set to 1 and observe the following rules:
- Received poisoned TLPs are sent to the Application Layer and status bits are automatically updated in the Configuration Space.
- Received poisoned Configuration Write TLPs are not written in the Configuration Space.
- The Configuration Space never generates a poisoned TLP; the error/poisoned bit of the header is always set to 0.
Poisoned TLPs can also set the parity error bits in the PCI Configuration Space Status register.
Status Bit |
Conditions |
---|---|
Detected parity error (status register bit 15) |
Set when any received TLP is poisoned. |
Master data parity error (status register bit 8) |
This bit is set when the command register parity enable bit is set and one of the following conditions is true:
|
Poisoned packets received by the Hard IP block are passed to the Application Layer. Poisoned transmit TLPs are similarly sent to the link.
9.5. Uncorrectable and Correctable Error Status Bits
The following section is reprinted with the permission of PCI-SIG. Copyright 2010 PCI‑SIG.
10. Design Implementation
10.1. Making Pin Assignments to Assign I/O Standard to Serial Data Pins
-
On the
Quartus® Prime
Assignments menu, select Pin Planner.
The Pin Planner appears.
- In the Node Name column, locate the PCIe serial data pins.
- In the I/O Standard column, double‑click the right‑hand corner of the box to bring up a list of available I/O standards.
- Select the appropriate standard from the following table.
10.2. Recommended Reset Sequence to Avoid Link Training Issues
Successful link training can only occur after the FPGA is configured. Designs using CvP for configuration initially load the I/O ring and periphery image. Intel® Arria® 10 or Intel® Cyclone® 10 GX devices include a Nios II Hard Calibration IP core that automatically calibrates the transceivers to optimize signal quality after CvP completes and before entering user mode. Link training occurs after calibration. Refer to Reset Sequence for Hard IP for PCI Express IP Core and Application Layer for a description of the key signals that reset, control dynamic reconfiguration, and link training.
10.3. SDC Timing Constraints
Your top-level Synopsys Design Constraints file (.sdc) must include the following timing constraint macro for the Intel® Arria® 10 or Intel® Cyclone® 10 GX Hard IP for PCIe IP core.
SDC Timing Constraints Required for the Intel® Arria® 10 or Intel® Cyclone® 10 GX Hard IP for PCIe and Design Example
# Constraints required for the Hard IP for PCI Express # derive_pll_clock is used to calculate all clock derived # from PCIe refclk. It must be applied once across all # of the SDC files used in a project derive_pll_clocks -create_base_clocks
You should only include this constraint in one location across all of the SDC files in your project. Differences between Fitter timing analysis and Timing Analyzer timing analysis arise if these constraints are applied multiple times.
11. Throughput Optimization
Each transmitter, the write requester in this case, maintains a credit limit register and a credits consumed register. The credit limit register is the sum of all credits received by the receiver, the write completer in this case. The credit limit register is initialized during the flow control initialization phase of link initialization and then updated during operation by Flow Control (FC) Update DLLPs. The credits consumed register is the sum of all credits consumed by packets transmitted. Separate credit limit and credits consumed registers exist for each of the six types of Flow Control:
- Posted Headers
- Posted Data
- Non-Posted Headers
- Non-Posted Data
- Completion Headers
- Completion Data
Each receiver also maintains a credit allocated counter which is initialized to the total available space in the RX buffer (for the specific Flow Control class) and then incremented as packets are pulled out of the RX buffer by the Application Layer. The value of this register is sent as the FC Update DLLP value.
The PCIe Hard IP maintains its own flow control logic, including a credit consumed register, and ensures that no TLP is sent that would use more credits than are available for that type of TLP. If you want optimum performance and granularity, you can maintain your own credit consumed register and flow control gating logic for each credit category (Header/Data, Posted/Non-posted/Completion). This allows you to halt the transmission of TLPs for a category that is out of credits, while still allowing TLP transmission for categories that have sufficient credits.
The following steps describe the Flow Control Update loop. The corresponding numbers in the figure show the general area to which they correspond.
- When the Application Layer has a packet to transmit, the number of credits required is calculated. If the required credits are less than or equal to the current value of available credits (credit limit - credits consumed so far), then the packet can be transmitted immediately. However, if the credit limit minus credits consumed is less than the required credits, then the packet must be held until the credit limit is increased to a sufficient value by an FC Update DLLP. This check is performed separately for the header and data credits; a single packet consumes only a single header credit.
- After the packet is selected for transmission the credits consumed register is incremented by the number of credits consumed by this packet. This increment happens for both the header and data credit consumed registers.
- The packet is received at the other end of the link and placed in the RX buffer.
- At some point the packet is read out of the RX buffer by the Application Layer. After the entire packet is read out of the RX buffer, the credit allocated register can be incremented by the number of credits the packet has used. There are separate credit allocated registers for the header and data credits.
- The value in the credit allocated register is used to create an FC Update DLLP.
- After an FC Update DLLP is
created, it arbitrates for access to the PCI Express link. The FC Update DLLPs are
typically scheduled with a low priority; consequently, a continuous stream of
Application Layer TLPs or other DLLPs (such as ACKs) can delay the FC Update DLLP
for a long time. To prevent starving the attached transmitter, FC Update DLLPs are
raised to a high priority under the following three circumstances:
- When the last sent credit allocated counter minus the amount of received data is less than MAX_PAYLOAD and the current credit allocated counter is greater than the last sent credit counter. Essentially, this means the data sink knows the data source has less than a full MAX_PAYLOAD worth of credits, and therefore is starving.
- When an internal timer expires from the time the last FC Update DLLP was sent, which is configured to 30 µs to meet the PCI Express Base Specification for resending FC Update DLLPs.
- When the credit
allocated counter minus the last sent
credit
allocated counter is greater than or equal
to 25% of the total credits available in the RX buffer, then the FC Update
DLLP request is raised to high priority.
After arbitrating, the FC Update DLLP that won the arbitration to be the next item is transmitted. In the worst case, the FC Update DLLP may need to wait for a maximum sized TLP that is currently being transmitted to complete before it can be sent.
- The original write requester receives the FC Update DLLP. The credit limit value is updated. If packets are stalled waiting for credits, they can now be transmitted.
11.1. Throughput of Posted Writes
The throughput of posted writes is limited primarily by the Flow Control Update loop as shown in Figure 55. If the write requester sources the data as quickly as possible, and the completer consumes the data as quickly as possible, then the Flow Control Update loop may be the biggest determining factor in write throughput, after the actual bandwidth of the link.
The figure below shows the main components of the Flow Control Update loop with two communicating PCI Express ports:
- Write Requester
- Write Completer
To allow the write requester to transmit packets continuously, the credit allocated and the credit limit counters must be initialized with sufficient credits to allow multiple TLPs to be transmitted while waiting for the FC Update DLLP that corresponds to the freeing of credits from the very first TLP transmitted.
You can use the RX Buffer space allocation - Desired performance for received requests to configure the RX buffer with enough space to meet the credit requirements of your system.
11.2. Throughput of Non-Posted Reads
To support a high throughput for read data, you must analyze the overall delay from the time the Application Layer issues the read request until all of the completion data is returned. The Application Layer must be able to issue enough read requests, and the read completer must be capable of processing these read requests quickly enough (or at least offering enough non-posted header credits) to cover this delay.
However, much of the delay encountered in this loop is well outside the IP core and is very difficult to estimate. PCI Express switches can be inserted in this loop, which makes determining a bound on the delay more difficult.
Nevertheless, maintaining maximum throughput of completion data packets is important. Endpoints must offer an infinite number of completion credits. Endpoints must buffer this data in the RX buffer until the Application Layer can process it. Because the Endpoint is no longer managing the RX buffer for Completions through the flow control mechanism, the Application Layer must manage the RX buffer by the rate at which it issues read requests.
To determine the appropriate settings for the amount of space to reserve for completions in the RX buffer, you must make an assumption about the length of time until read completions are returned. This assumption can be estimated in terms of an additional delay, beyond the FC Update Loop Delay, as discussed in the section Throughput of Posted Writes. The paths for the read requests and the completions are not exactly the same as those for the posted writes and FC Updates in the PCI Express logic. However, the delay differences are probably small compared with the inaccuracy in the estimate of the external read to completion delays.
With multiple completions, the number of available credits for completion headers must be larger than the completion data space divided by the maximum packet size. Instead, the credit space for headers must be the completion data space (in bytes) divided by 64, because this is the smallest possible read completion boundary. Setting the RX Buffer space allocation—Desired performance for received completions to High under the System Settings heading when specifying parameter settings configures the RX buffer with enough space to meet this requirement. You can adjust this setting up or down from the High setting to tailor the RX buffer size to your delays and required performance.
12. Additional Features
12.1. Configuration over Protocol (CvP)
The Hard IP for PCI Express architecture has an option to configure the FPGA and initialize the PCI Express link. In prior devices, a single Program Object File (.pof) programmed the I/O ring and FPGA fabric before the PCIe link training and enumeration began. The .pof file is divided into two parts:
- The I/O bitstream contains the data to program the I/O ring, the Hard IP for PCI Express, and other elements that are considered part of the periphery image.
- The core bitstream contains the data to program the FPGA fabric.
When you select the CvP design flow, the I/O ring and PCI Express link are programmed first, allowing the PCI Express link to reach the L0 state and begin operation independently, before the rest of the core is programmed. After the PCI Express link is established, it can be used to program the rest of the device. The following figure shows the blocks that implement CvP.
CvP has the following advantages:
- Provides a simpler software model for configuration. A smart host can use the PCIe protocol and the application topology to initialize and update the FPGA fabric.
- Improves security for the proprietary core bitstream.
- Reduces system costs by reducing the size of the flash device to store the .pof.
- May reduce system size because a single CvP link can be used to configure multiple FPGAs.
12.2. Autonomous Mode
Intel’s FPGA devices always receive the configuration bits for the periphery image first, then for the core fabric image. After the core image configures, the device enters user mode. In autonomous mode, the hard IP for PCI Express begins operation when the periphery configuration completes, before it enters user mode.
In autonomous mode, after completing link training, the Hard IP for PCI Express responds to Configuration Requests from the host with a Configuration Request Retry Status (CRRS). Autonomous mode is when you must meet the 100 ms PCIe wake-up time.
The hard IP for PCIe responds with CRRS under the following conditions:
- Before the core fabric is programmed when you enable autonomous mode.
- Before the core fabric is programmed when you enable initialization of the core fabric using the PCIe link.
All PCIe IP cores on a device can operate in autonomous mode. However, only the bottom Hard IP for PCI Express on either side can satisfy the 100 ms PCIe wake up time requirement. Transceiver calibration begins with the bottom PCIe IP core on each side of the device. Consequently, this IP core has a faster wake up time.
Arria V, Cyclone V, Stratix V, Intel® Arria® 10 and Intel® Cyclone® 10 GX devices are the first to offer autonomous mode. In earlier devices, the PCI Express Hard IP Core exits reset only after full FPGA configuration.
12.2.1. Enabling Autonomous Mode
- On the Quartus Prime Assignments menu, select Device > Device and Pin Options.
-
Under Category > General turn on Enable autonomous PCIe HIP
mode.
The Enable autonomous PCIe HIP mode option has an effect if your design has the following two characteristics:
- You are using the Flash device or Ethernet controller, instead of the PCIe link to load the core image.
- You have not turned on Enable Configuration via the PCIe link in the Hard IP for PCI Express GUI.
12.2.2. Enabling CvP Initialization
- On the Assignments menu select Device > Device and Pin Options.
- Under Category, select CvP Settings.
- For Configuration via Protocol, select Core initialization from the drop-down menu.
12.3. ECRC
ECRC ensures end-to-end data integrity for systems that require high reliability. You can specify this option under the Error Reporting heading. The ECRC function includes the ability to check and generate ECRC. In addition, the ECRC function can forward the TLP with ECRC to the RX port of the Application Layer. When using ECRC forwarding mode, the ECRC check and generation are performed in the Application Layer.
You must turn on Advanced error reporting (AER), ECRC checking, and ECRC generation under the PCI Express/PCI Capabilities heading using the parameter editor to enable this functionality.
For more information about error handling, refer to Error Signaling and Logging in Section 6.2 of the PCI Express Base Specification.
12.3.1. ECRC on the RX Path
When the ECRC generation option is turned on, errors are detected when receiving TLPs with a bad ECRC. If the ECRC generation option is turned off, no error detection occurs. If the ECRC forwarding option is turned on, the ECRC value is forwarded to the Application Layer with the TLP. If the ECRC forwarding option is turned off, the ECRC value is not forwarded.
ECRC Forwarding |
ECRC Check Enable 10 |
ECRC Status |
Error |
TLP Forward to Application Layer |
---|---|---|---|---|
No |
No |
none |
No |
Forwarded |
good |
No |
Forwarded without its ECRC |
||
bad |
No |
Forwarded without its ECRC |
||
Yes |
none |
No |
Forwarded |
|
good |
No |
Forwarded without its ECRC |
||
bad |
Yes |
Not forwarded |
||
Yes |
No |
none |
No |
Forwarded |
good |
No |
Forwarded with its ECRC |
||
bad |
No |
Forwarded with its ECRC |
||
Yes |
none |
No |
Forwarded |
|
good |
No |
Forwarded with its ECRC |
||
bad |
Yes |
Not forwarded |
12.3.2. ECRC on the TX Path
When the ECRC generation option is on, the TX path generates ECRC. If you turn on ECRC forwarding, the ECRC value is forwarded with the TLP. The following table summarizes the TX ECRC generation and forwarding. All unspecified cases are unsupported and the behavior of the Hard IP is unknown.In this table, if TD is 1, the TLP includes an ECRC. TD is the TL digest bit of the TL packet.
ECRC Forwarding |
ECRC Generation Enable 11 |
TLP on Application |
TLP on Link |
Comments |
---|---|---|---|---|
No |
No |
TD=0, without ECRC |
TD=0, without ECRC |
|
TD=1, without ECRC |
TD=0, without ECRC |
|||
Yes |
TD=0, without ECRC |
TD=1, with ECRC |
ECRC is generated |
|
TD=1, without ECRC |
TD=1, with ECRC |
|||
Yes |
No |
TD=0, without ECRC |
TD=0, without ECRC |
Core forwards the ECRC |
TD=1, with ECRC |
TD=1, with ECRC |
|||
Yes |
TD=0, without ECRC |
TD=0, without ECRC |
||
TD=1, with ECRC |
TD=1, with ECRC |
13. Avalon-MM Testbench and Design Example
This chapter introduces the Endpoint design example including a testbench, BFM, and a test driver module. You can create this design example using design flows described in Quick Start Guide. This testbench uses the parameters that you specify in the Quick Start Guide.
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.
The testbench uses a test driver module, altera_avalon_dma to exercise the DMA of the design example. The test driver module displays information from the Endpoint Configuration Space registers, so that you can correlate to the parameters you specify using the parameter editor.
- 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 DUT.
The testbench uses a test driver module, altpcietb_bfm_rp_gen3_x8.sv, to exercise the target memory and DMA channel in the Endpoint BFM. The test driver module displays information from the Root Port Configuration Space registers, so that you can correlate to the parameters you specify using the parameter editor. The Endpoint model consists of an Endpoint variation combined with the DMA application.
Starting from the Intel® Quartus® Prime 18.0 release, you can generate an Intel® Arria® 10 PCIe example design that configures the IP as a Root Port. In this scenario, the testbench instantiates an Endpoint BFM and a JTAG master bridge.
The simulation uses the JTAG master BFM to initiate CRA read and write transactions to perform bus enumeration and configure the endpoint. The simulation also uses the JTAG master BFM to drive the TXS Avalon® -MM interface to execute memory read and write transactions.
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 and the Application Layer must be designed 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 equal to Device > PCI Express > PCI Capabilities > Maximum payload size 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 a fixed credit allocation.
- It does not support parity.
- It does not support multi-function designs which are available when using Configuration Space Bypass mode or Single Root I/O Virtualization (SR-IOV).
13.1. Avalon-MM Endpoint Testbench
You can generate the testbench from the example design by following the instructions in Quick Start Guide.
The Root Port BFM includes the following top-level modules in the <testbench_dir/pcie_<dev>_hip_avmm_bridge_0_example_design/pcie_example_design_tb/ip/pcie_example_design_tb/DUT_pcie_tb_ip/altera_pcie_s10_tbed_<ver>/sim directory:
- altpcietb_bfm_top_rp.sv: This is the Root Port PCI Express BFM. For more information about this module, refer to Root Port BFM.
-
altpcietb_bfm_rp_gen3_x8.sv: This module
drives transactions to the Root Port BFM. The main process operates in two
stages:
- First, it configures the Endpoint using the task ebfm_cfg_rp_eg.
-
Second, it runs a memory access test with the task target_mem_test or target_mem_test_lite.
Finally, it runs a DMA test with the task dma_mem_test
.
-
altpcietb_bfm_shmem.v: This
memory implements the following functionality:
- Provides data for TX write operations
- Provides data for RX read operations
- Receives data for RX write operations
- Receives data for received completions
In addition, the testbench has routines that perform the following tasks:
- Generates the reference clock for the Endpoint at the required frequency.
- Provides a PCI Express reset at start up.
Before running the testbench, you should set the serial_sim_hwtcl parameter in <testbench_dir>/ pcie_<dev>_hip_avmm_bridge_example_design_tb/ip/pcie_example_design_tb/DUT_pcie_tb_ip/altera_pcie_<dev>_tbed_<ver>/sim/altpcie_<dev>_tbed_hwtcl.v. Set to 1 for serial simulation and 0 for PIPE simulation.
13.2. Endpoint Design Example
This design example comprises a native Endpoint, a DMA application and a Root Port BFM. The write DMA module implements write operations from the Endpoint memory to the Root Complex (RC) memory. The read DMA implements read operations from the RC memory to the Endpoint memory.
When operating on a hardware platform, a software application running on the Root Complex processor typically controls the DMA. In simulation, the generated testbench, along with this design example, provide a BFM driver module in Verilog HDL that controls the DMA operations. Because the example relies on no other hardware interface than the PCI Express link, you can use the design example for the initial hardware validation of your system.
System generation creates the Endpoint variant in Verilog HDL. The testbench files are only available in Verilog HDL in the current release.
The DMA design example requires setting BAR 2 or BAR 3 to a minimum of 256 bytes.
To run the DMA tests using MSI, you must set the Number of MSI messages requested parameter under the PCI Express/PCI Capabilities page to at least 2.
The DMA design example uses an architecture capable of transferring a large amount of fragmented memory without accessing the DMA registers for every memory block. For each memory block, the DMA design example uses a descriptor table containing the following information:
- Size of the transfer
- Address of the source
- Address of the destination
- Control bits to set the handshaking behavior between the software application or BFM driver and the DMA module
The BFM driver writes the descriptor tables into BFM shared memory, from which the DMA design engine continuously collects the descriptor tables for DMA read, DMA write, or both. At the beginning of the transfer, the BFM programs the Endpoint DMA control register. The DMA control register indicates the total number of descriptor tables and the BFM shared memory address of the first descriptor table. After programming the DMA control register, the DMA engine continuously fetches descriptors from the BFM shared memory for both DMA reads and DMA writes, and then performs the data transfer for each descriptor.
The following figure shows a block diagram of the design example connected to an external RC CPU.
The block diagram contains the following elements:
- The DMA
application
connects to the
Avalon®
-MM
interface of the
Intel®
Arria® 10 or Intel®
Cyclone® 10 GX Hard IP for PCI
Express. The connections consist of the following interfaces:
- The Avalon® -MM RX master receives TLP header and data information from the Hard IP block.
- The Avalon® -MM TX slave transmits TLP header and data information to the Hard IP block.
- The Avalon® -MM control register access (CRA) IRQ port requests MSI interrupts from the Hard IP block.
- The sideband signal bus carries static information such as configuration information.
- The BFM shared memory stores the descriptor tables for the DMA read and the DMA write operations.
- A Root Complex CPU and associated PCI Express* PHY connect to the Endpoint design example, using a Root Port.
The example Endpoint design and application accomplish the following objectives:
- Show you how to interface to the Intel® Arria® 10 or Intel® Cyclone® 10 GX Hard IP for PCI Express* using the Avalon-MM protocol.
- Provide a DMA channel that initiates memory read and write transactions on the PCI Express* link.
The DMA design example hierarchy consists of these components:
- A DMA read and a DMA write module
- An on-chip Endpoint memory (Avalon-MM slave) which uses two Avalon-MM interfaces for each engine
The RC slave module typically drives downstream transactions which target the Endpoint on‑chip buffer memory. These target memory transactions bypass the DMA engines. In addition, the RC slave module monitors performance and acknowledges incoming message TLPs.
13.2.1. BAR/Address Map
The design example maps received memory transactions to either the target memory block or the control register block based on which BAR the transaction matches. There are multiple BARs that map to each of these blocks to maximize interoperability with different variation files. The following table shows the mapping.
Memory BAR |
Mapping |
---|---|
32-bit BAR0 32-bit BAR1 64-bit BAR1:0 |
Maps to 32 KB target memory block. Use the rc_slave module to bypass the chaining DMA. |
32-bit BAR2 32-bit BAR3 64-bit BAR3:2 |
Maps to DMA Read and DMA write control and status registers, a minimum of 256 bytes. |
32-bit BAR4 32-bit BAR5 64-bit BAR5:4 |
Maps to 32 KB target memory block. Use the rc_slave module to bypass the chaining DMA. |
Expansion ROM BAR |
Not implemented by design example; behavior is unpredictable. |
I/O Space BAR (any) |
Not implemented by design example; behavior is unpredictable. |
13.2.2. BAR Setup
The find_mem_bar task in Root Port BFM altpcietb_bfm_rp_gen3_x8.sv sets up BARs to match your design.
13.3. Avalon-MM Test Driver Module
The BFM driver module, altpcietb_bfm_driver_avmm.v is configured to test the DMA example Endpoint design. The BFM driver module configures the Endpoint Configuration Space registers and then tests the example Endpoint DMA channel. This file is in the <variation_name>_tb/altera_pcie_<dev>_tbed_<quartus_ver>/sim/ directory.
The BFM test driver module performs the following steps in sequence:
- Configures the Root Port and Endpoint Configuration Spaces, which the BFM test driver module does by calling the procedure ebfm_cfg_rp_ep, which is part of altpcietb_bfm_configure.
- Finds a suitable BAR to access the example Endpoint design Control Register space. Either BARs 2 or 3 must be at least a 256-byte memory BAR to perform the DMA channel test. The find_mem_bar procedure in the altpcietb_bfm_driver_avmm does this.
- If a suitable BAR is found
in the previous step, the driver performs the following tasks:
- DMA read—The driver programs the DMA to read data from the BFM shared memory into the Endpoint memory. The descriptor control fields specify for the DMA to issue an MSI when the last descriptor has completed.
- DMA write—The
driver programs the DMA to write the data from its Endpoint memory back to
the BFM shared memory. The descriptor control fields are specified so that
the DMA completes the following steps to indicate transfer completion:
- The DMA issues an MSI when the last descriptor has completed.
- The data written back to BFM is checked against the data that was read from the BFM.
- The driver programs the DMA to perform a test that demonstrates downstream access of the DMA Endpoint memory.
13.4. Root Port BFM
13.4.1. Root Port BFM Overview
The basic Root Port BFM provides Verilog HDL task‑based interface to request transactions to issue on the PCI Express link. The Root Port BFM also handles requests received from the PCI Express link. The following figure shows the most important modules in the Root Port BFM.
These modules implement the following functionality:
- BFM Log Interface,altpcietb_bfm_log.v and altlpcietb_bfm_rp_<gen>_x8.v: The BFM log functions provides routine for writing commonly formatted messages to the simulator standard output and optionally to a log file. It also provides controls that stop simulation on errors. For details on these procedures, refer to BFM Log and Message Procedures.
- BFM Read/Write Request Functions, altpcietb_bfm_rp_<gen>_x8.sv: These functions provide the basic BFM calls for PCI Express read and write requests. For details on these procedures, refer to BFM Read and Write Procedures.
- BFM Log Interface, altpcietb_bfm_log.v and altlpcietb_bfm_rp_<gen>_x8.v: The BFM log functions provides routine for writing commonly formatted messages to the simulator standard output and optionally to a log file. It also provides controls that stop simulation on errors. For details on these procedures, refer to BFM Log and Message Procedures.
- BFM Configuration Functions, altpcietb_g3bfm_configure.v : These functions provide the BFM calls to request configuration of the PCI Express link and the Endpoint Configuration Space registers. For details on these procedures and functions, refer to BFM Configuration Procedures.
- BFM shared memory, altpcietb_g3bfm_shmem_common.v: This modules provides
the Root Port BFM shared memory. It implements the following functionality:
- Provides data for TX write operations
- Provides data for RX read operations
- Receives data for RX write operations
- Receives data for received completions
- BFM Request Interface, altpcietb_g3bfm_req_intf.v: This interface provides the low-level interface between the altpcietb_g3bfm_rdwr and altpcietb_bfm_configure procedures or functions and the Root Port RTL Model. This interface stores a write-protected data structure containing the sizes and the values programmed in the BAR registers of the Endpoint. It also stores other critical data used for internal BFM management. You do not need to access these files directly to adapt the testbench to test your Endpoint application.
- Avalon‑ST Interfaces, altpcietb_g3bfm_vc_intf_ast_common.v: These interface modules handle the Root Port interface model. They take requests from the BFM request interface and generate the required PCI Express transactions. They handle completions received from the PCI Express link and notify the BFM request interface when requests are complete. Additionally, they handle any requests received from the PCI Express link, and store or fetch data from the shared memory before generating the required completions.
13.4.2. Issuing Read and Write Transactions to the Application Layer
The Endpoint Application Layer issues read and write transactions by calling one of the ebfm_bar procedures in altpcietb_g3bfm_rdwr.v. The procedures and functions listed below are available in the Verilog HDL include file altpcietb_g3bfm_rdwr.v. The complete list of available procedures and functions is as follows:
- ebfm_barwr: writes data from BFM shared memory to an offset from a specific Endpoint BAR. This procedure returns as soon as the request has been passed to the VC interface module for transmission.
- ebfm_barwr_imm: writes a maximum of four bytes of immediate data (passed in a procedure call) to an offset from a specific Endpoint BAR. This procedure returns as soon as the request has been passed to the VC interface module for transmission.
- ebfm_barrd_wait: reads data from an offset of a specific Endpoint BAR and stores it in BFM shared memory. This procedure blocks waiting for the completion data to be returned before returning control to the caller.
- ebfm_barrd_nowt: reads data from an offset of a specific Endpoint BAR and stores it in the BFM shared memory. This procedure returns as soon as the request has been passed to the VC interface module for transmission, allowing subsequent reads to be issued in the interim.
These routines take as parameters a BAR number to access the memory space and the BFM shared memory address of the bar_table data structure that was set up by the ebfm_cfg_rp_ep procedure. (Refer to Configuration of Root Port and Endpoint.) Using these parameters simplifies the BFM test driver routines that access an offset from a specific BAR and eliminates calculating the addresses assigned to the specified BAR.
The Root Port BFM does not support accesses to Endpoint I/O space BARs.
13.4.3. Configuration of Root Port and Endpoint
Before you issue transactions to the Endpoint, you must configure the Root Port and Endpoint Configuration Space registers. Use ebfm_cfg_rp_ep in altpcietb_bfm_configure.v to configure these registers.
The ebfm_cfg_rp_ep procedure executes the following steps to initialize the Configuration Space:
- Sets the Root Port Configuration Space to enable the Root Port to send transactions on the PCI Express link.
- Sets the Root Port and
Endpoint PCI Express Capability Device Control registers as follows:
- Disables Error Reporting in both the Root Port and Endpoint. The BFM does not have error handling capability.
- Enables Relaxed Ordering in both Root Port and Endpoint.
- Enables Extended Tags for the Endpoint if the Endpoint has that capability.
- Disables Phantom Functions, Aux Power PM, and No Snoop in both the Root Port and Endpoint.
- Sets the Max Payload Size to the value that the Endpoint supports because the Root Port supports the maximum payload size.
- Sets the Root Port Max Read Request Size to 4 KB because the example Endpoint design supports breaking the read into as many completions as necessary.
- Sets the Endpoint Max Read Request Size equal to the Max Payload Size because the Root Port does not support breaking the read request into multiple completions.
- Assigns values to all the
Endpoint BAR registers. The BAR addresses are assigned by the algorithm outlined
below.
- I/O BARs are assigned smallest to largest starting just above the ending address of BFM shared memory in I/O space and continuing as needed throughout a full 32-bit I/O space.
- The 32-bit non-prefetchable memory BARs are assigned smallest to largest, starting just above the ending address of BFM shared memory in memory space and continuing as needed throughout a full 32-bit memory space.
- The value of the
addr_map_4GB_limit input to the ebfm_cfg_rp_ep procedure controls the
assignment of the 32-bit prefetchable and 64-bit prefetchable memory
BARS.
The default value of the addr_map_4GB_limit
is 0.
If the addr_map_4GB_limit input to the ebfm_cfg_rp_ep procedure is set to 0, then the ebfm_cfg_rp_ep procedure assigns the 32‑bit prefetchable memory BARs largest to smallest, starting at the top of 32-bit memory space and continuing as needed down to the ending address of the last 32-bit non-prefetchable BAR.
However, if the addr_map_4GB_limit input is set to 1, the address map is limited to 4 GB. The ebfm_cfg_rp_ep procedure assigns 32-bit and 64-bit prefetchable memory BARs largest to smallest, starting at the top of the 32-bit memory space and continuing as needed down to the ending address of the last 32-bit non-prefetchable BAR.
- If the addr_map_4GB_limit input to the ebfm_cfg_rp_ep
procedure is set to 0,
then
the ebfm_cfg_rp_ep procedure
assigns the 64-bit prefetchable memory BARs
smallest
to largest starting at the
4 GB address
assigning memory ascending above the
4 GB limit
throughout the full 64-bit memory space.
If the addr_map_4 GB_limit input to the ebfm_cfg_rp_ep procedure is set to 1, the ebfm_cfg_rp_ep procedure assigns the 32-bit and the 64-bit prefetchable memory BARs largest to smallest starting at the 4 GB address and assigning memory by descending below the 4 GB address to memory addresses as needed down to the ending address of the last 32-bit non-prefetchable BAR.
The above algorithm cannot always assign values to all BARs when there are a few very large (1 GB or greater) 32-bit BARs. Although assigning addresses to all BARs may be possible, a more complex algorithm would be required to effectively assign these addresses. However, such a configuration is unlikely to be useful in real systems. If the procedure is unable to assign the BARs, it displays an error message and stops the simulation.
- Based on the above BAR assignments, the ebfm_cfg_rp_ep procedure assigns the Root Port Configuration Space address windows to encompass the valid BAR address ranges.
- The ebfm_cfg_rp_ep procedure enables master transactions, memory address decoding, and I/O address decoding in the Endpoint PCIe* control register.
The ebfm_cfg_rp_ep procedure also sets up a bar_table data structure in BFM shared memory that lists the sizes and assigned addresses of all Endpoint BARs. This area of BFM shared memory is write-protected. Consequently, any application logic write accesses to this area cause a fatal simulation error.
BFM procedure calls to generate full PCIe* addresses for read and write requests to particular offsets from a BAR use this data structure. . This procedure allows the testbench code that accesses the Endpoint application logic to use offsets from a BAR and avoid tracking specific addresses assigned to the BAR. The following table shows how to use those offsets.
Offset (Bytes) |
Description |
---|---|
+0 |
PCI Express address in BAR0 |
+4 |
PCI Express address in BAR1 |
+8 |
PCI Express address in BAR2 |
+12 |
PCI Express address in BAR3 |
+16 |
PCI Express address in BAR4 |
+20 |
PCI Express address in BAR5 |
+24 |
PCI Express address in Expansion ROM BAR |
+28 |
Reserved |
+32 |
BAR0 read back value after being written with all 1’s (used to compute size) |
+36 |
BAR1 read back value after being written with all 1’s |
+40 |
BAR2 read back value after being written with all 1’s |
+44 |
BAR3 read back value after being written with all 1’s |
+48 |
BAR4 read back value after being written with all 1’s |
+52 |
BAR5 read back value after being written with all 1’s |
+56 |
Expansion ROM BAR read back value after being written with all 1’s |
+60 |
Reserved |
The configuration routine does not configure any advanced PCI Express capabilities such as the AER capability.
Besides the ebfm_cfg_rp_ep procedure in altpcietb_bfm_rp_gen3_x8.sv, routines to read and write Endpoint Configuration Space registers directly are available in the Verilog HDL include file. After the ebfm_cfg_rp_ep procedure runs the PCI Express I/O and Memory Spaces have the layout shown in the following three figures. The memory space layout depends on the value of the addr_map_4GB_limit input parameter. The following figure shows the resulting memory space map when the addr_map_4GB_limit is 1.
The following figure shows the resulting memory space map when the addr_map_4GB_limit is 0.
The following figure shows the I/O address space.
13.4.4. Configuration Space Bus and Device Numbering
Enumeration assigns the Root Port interface device number 0 on internal bus number 0. Use the ebfm_cfg_rp_ep to assign the Endpoint to any device number on any bus number (greater than 0). The specified bus number is the secondary bus in the Root Port Configuration Space.
13.4.5. BFM Memory Map
The BFM shared memory is 2 MBs. The BFM shared memory maps to the first 2 MBs of I/O space and also the first 2 MBs of memory space. When the Endpoint application generates an I/O or memory transaction in this range, the BFM reads or writes the shared memory.
13.5. BFM Procedures and Functions
The BFM includes procedures, functions, and tasks to drive Endpoint application testing. It also includes procedures to run the chaining DMA design example.
The BFM read and write procedures read and write data to BFM shared memory, Endpoint BARs, and specified configuration registers. The procedures and functions are available in the Verilog HDL. These procedures and functions support issuing memory and configuration transactions on the PCI Express link.
13.5.1. ebfm_barwr Procedure
The ebfm_barwr procedure writes a block of data from BFM shared memory to an offset from the specified Endpoint BAR. The length can be longer than the configured MAXIMUM_PAYLOAD_SIZE. The procedure breaks the request up into multiple transactions as needed. This routine returns as soon as the last transaction has been accepted by the VC interface module.
Location |
altpcietb_bfm_rdwr.v |
|
---|---|---|
Syntax |
ebfm_barwr(bar_table, bar_num, pcie_offset, lcladdr, byte_len, tclass) |
|
Arguments |
bar_table |
Address of the Endpoint bar_table structure in BFM shared memory. The bar_table structure stores the address assigned to each BAR so that the driver code does not need to be aware of the actual assigned addresses only the application specific offsets from the BAR. |
bar_num |
Number of the BAR used with pcie_offset to determine PCI Express address. |
|
pcie_offset |
Address offset from the BAR base. |
|
lcladdr |
BFM shared memory address of the data to be written. |
|
byte_len |
Length, in bytes, of the data written. Can be 1 to the minimum of the bytes remaining in the BAR space or BFM shared memory. |
|
tclass |
Traffic class used for the PCI Express transaction. |
13.5.2. ebfm_barwr_imm Procedure
The ebfm_barwr_imm procedure writes up to four bytes of data to an offset from the specified Endpoint BAR.
Location |
altpcietb_bfm_driver_rp.v |
|
---|---|---|
Syntax |
ebfm_barwr_imm(bar_table, bar_num, pcie_offset, imm_data, byte_len, tclass) |
|
Arguments |
bar_table |
Address of the Endpoint bar_table structure in BFM shared memory. The bar_table structure stores the address assigned to each BAR so that the driver code does not need to be aware of the actual assigned addresses only the application specific offsets from the BAR. |
bar_num |
Number of the BAR used with pcie_offset to determine PCI Express address. |
|
pcie_offset |
Address offset from the BAR base. |
|
imm_data |
Data to be written. In Verilog HDL, this argument is reg [31:0].In both languages, the bits written depend on the length as follows: Length Bits Written
|
|
byte_len |
Length of the data to be written in bytes. Maximum length is 4 bytes. |
|
tclass |
Traffic class to be used for the PCI Express transaction. |
13.5.3. ebfm_barrd_wait Procedure
The ebfm_barrd_wait procedure reads a block of data from the offset of the specified Endpoint BAR and stores it in BFM shared memory. The length can be longer than the configured maximum read request size; the procedure breaks the request up into multiple transactions as needed. This procedure waits until all of the completion data is returned and places it in shared memory.
Location |
altpcietb_bfm_driver_rp.v altpcietb_bfm_rdwr.v |
|
---|---|---|
Syntax |
ebfm_barrd_wait(bar_table, bar_num, pcie_offset, lcladdr, byte_len, tclass) |
|
Arguments |
bar_table |
Address of the Endpoint bar_table structure in BFM shared memory. The bar_table structure stores the address assigned to each BAR so that the driver code does not need to be aware of the actual assigned addresses only the application specific offsets from the BAR. |
bar_num |
Number of the BAR used with pcie_offset to determine PCI Express address. |
|
pcie_offset |
Address offset from the BAR base. |
|
lcladdr |
BFM shared memory address where the read data is stored. |
|
byte_len |
Length, in bytes, of the data to be read. Can be 1 to the minimum of the bytes remaining in the BAR space or BFM shared memory. |
|
tclass |
Traffic class used for the PCI Express transaction. |
13.5.4. ebfm_barrd_nowt Procedure
The ebfm_barrd_nowt procedure reads a block of data from the offset of the specified Endpoint BAR and stores the data in BFM shared memory. The length can be longer than the configured maximum read request size; the procedure breaks the request up into multiple transactions as needed. This routine returns as soon as the last read transaction has been accepted by the VC interface module, allowing subsequent reads to be issued immediately.
Location |
altpcietb_bfm_driver_rp.v altpcietb_bfm_rdwr.v |
|
---|---|---|
Syntax |
ebfm_barrd_nowt(bar_table, bar_num, pcie_offset, lcladdr, byte_len, tclass) |
|
Arguments |
bar_table |
Address of the Endpoint bar_table structure in BFM shared memory. |
bar_num |
Number of the BAR used with pcie_offset to determine PCI Express address. |
|
pcie_offset |
Address offset from the BAR base. |
|
lcladdr |
BFM shared memory address where the read data is stored. |
|
byte_len |
Length, in bytes, of the data to be read. Can be 1 to the minimum of the bytes remaining in the BAR space or BFM shared memory. |
|
tclass |
Traffic Class to be used for the PCI Express transaction. |
13.5.5. ebfm_cfgwr_imm_wait Procedure
The ebfm_cfgwr_imm_wait procedure writes up to four bytes of data to the specified configuration register. This procedure waits until the write completion has been returned.
Location |
altpcietb_bfm_driver_rp.v altpcietb_bfm_rdwr.v |
|
---|---|---|
Syntax |
ebfm_cfgwr_imm_wait(bus_num, dev_num, fnc_num, imm_regb_ad, regb_ln, imm_data, compl_status |
|
Arguments |
bus_num |
PCI Express bus number of the target device. |
dev_num |
PCI Express device number of the target device. |
|
fnc_num |
Function number in the target device to be accessed. |
|
regb_ad |
Byte-specific address of the register to be written. |
|
regb_ln |
Length, in bytes, of the data written. Maximum length is four bytes. The regb_ln and the regb_ad arguments cannot cross a DWORD boundary. |
|
imm_data |