IP-AGX-PCIE/4 Altera, IP-AGX-PCIE/4 Datasheet - Page 230

• Manufacturer Part Number: IP-AGX-PCIE/4
• Description: IP CORE - PCI Express X1 And X4 Lanes For Arria GX
• Manufacturer: Altera

Specifications of IP-AGX-PCIE/4

• Software Application: IP CORE, Interface And Protocols, PCI
• Supported Families: Arria GX, Cyclone II, HardCopy II, Stratix II
• Core Architecture: FPGA
• Core Sub-architecture: Arria, Cyclone, Stratix
• Rohs Compliant: NA
• Lead Free Status / RoHS Status: na

15–2
Endpoint Testbench
PCI Express Compiler User Guide
1
Your application layer design may need to handle at least the following scenarios that
are not possible to create with the Altera testbench and the root port BFM:
■
■
■
■
■
■
The chaining DMA design example provided with the IP core handles all of the above
behaviors, even though the provided testbench cannot test them.
To run the testbench at the Gen1 data rate, you must have the Stratix II GX device
family installed. To run the testbench at the Gen2 data rate, you must have the
Stratix IV GX device family installed.
Additionally PCI Express link monitoring and error injection capabilities are limited
to those provided by the IP core’s test_in and test_out signals. The testbench and
root port BFM do not NAK any transactions.
The testbench is provided in the subdirectory <variation_name>_examples
/chaining_dma/testbench in your project directory. The testbench top level is named
<variation_name>_chaining_testbench.
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 IP core passes these messages on to the application layer which
in most cases should ignore them, but in all cases using the descriptor/data
interface must issue an rx_ack to clear the message from the RX buffer.
It can only handle received read requests that are less than or equal to the
currently set Maximum payload size option specified on Buffer Setup page using
the parameter editor. Many systems are capable of handling larger read requests
that are then returned in multiple completions.
It always returns a single completion for every read request. Some systems split
completions on every 64-byte address boundary.
It always returns completions in the same order the read requests were issued.
Some systems generate the completions out-of-order.
It is unable to generate zero-length read requests that some systems generate as
flush requests following some write transactions. The application layer must be
capable of generating the completions to the zero length read requests.
It uses fixed credit allocation.
Chapter 15: Testbench and Design Example
December 2010 Altera Corporation
Endpoint Testbench