7.2. Overview of the Testbench
This testbench simulates up to x16 variants. However, the provided BFM only supports x1 to x8 links. It supports x16 variants by downtraining to x8. To simulate all lanes of a x16 variant, you can create a simulation model to use in a testbench along with a third party BFM such as the Avery BFM. For more information refer to AN-811: Using the Avery BFM for PCI Express Gen3x16 Simulation on Intel Stratix 10 Devices.
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.
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 is the user-specified Endpoint variation.
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. The Avalon® -MM bridge itself ignores Vendor Defined Messages.
- It can only handle received read requests that are less than or equal to the currently set Maximum Payload Size. You can set this parameter in the parameter editor by going to IP Settings > PCI Express/PCI Capabilities > Device > Maximum payload size. 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 multi-function designs.
Did you find the information on this page useful?