We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

AR# 29468

LogiCORE Endpoint Block Plus v1.5 for PCI Express - Release Notes and Known Issues for 9.2i IP Update 2 (9.2i_IP2)


This Release Notes and Known Issues Answer Record is for the LogiCORE Endpoint Block Plus v1.5 for PCI Express released in 9.2i IP Update 2.

It contains the following information:

  • General Information
  • New Features
  • Bug Fixes
  • Known Issues

For installation instructions, general CORE Generator known issues, and design tools requirements, see (Xilinx Answer 29185).


General Information

Important Note: All users need to download and install the v1.5.2 patch found in (Xilinx Answer 30124).

This patch fixes some critical issues found in v1.5.

License Requirements

As of the ISE 9.1i sp4 IP Update 2 release, the LogiCORE Endpoint Block Plus for PCI Express requires a license to generate and implement the core.

There is no charge for this license.

To obtain the license, visit the product lounge at:


ES Silicon

Refer to (Xilinx Answer 24697) for information on targeting Virtex-5 engineering samples (ES) silicon with this core.

New Features

  • ISE 9.2i design tools support
  • Added support for up to 32 MSI vectors

New ports added to implement feature:

  • input cfg_interrupt_assert_n,
  • input [7:0] cfg_interrupt_di,
  • output [2:0] cfg_interrupt_mmenable,
  • output cfg_interrupt_msienable,
  • output [7:0] cfg_interrupt_do,

New ports added in v1.5.2, users must modify the core instantiation to add these additional ports.

  • Added new pin refclkout (output) to provide user access to a free running Reference clock (100 / 250 MHz).
  • Added new pin cfg_err_cpl_rdy_n (output) - a new throttle signal for the cfg_err interface.
  • Added new pin cfg_err_locked_n (input) - an error qualifying signal for cfg_err interface.
  • Increased width of trn_tbuf_av (output) from 3 bits to 4 bits. The 4th bit (trn_tbuf_av[3]) is a Look-Ahead Completion Queue buffer status.

Resolved Issues

This is a list of resolved issues as of the v1.5.2 patch.

All users need to install v1.5.2 as it contains critical bug fixes as listed below:

-CR434731: Receive Flow Control Credit Signals.

Core Receive Flow Control Credit Available signals: trn_rfc_{p,np}h_av[7:0] and trn_rfc_{p,np}d_av[11:0] now indicate the correct values.

-CR443006: TS2 link Upconfigure bit causing failure to link train.

Problem fixed where setting the Link Upconfigure bit in a TS2 caused the Integrated Hard Block for PCI Express to fail to link train.

-CR448355: Packets with Phantom Function not being passed to the User Application.

Issue resolved where packets using Phantom Functions were being dropped by the Block Plus Core.

-CR448685: Recording of Error Status assertions fixed.

Issue resolved where assertions of certain Error Status signals were not being recorded in certain cases, by the Block Plus Core.

-CR447613: "Advanced Flow Control Options" in GUI not being passed to netlist.

The Advanced Flow Control Option GUI choices were not propagated to the core netlist.
In addition, the INFINITECOMPLETIONS attribute on the block was always set to FALSE, regardless of the options selected in the GUI.
This caused the core to not be compliant.
A PCI Express endpoint is required to advertise infinite completion credits.
This problem is fixed so that the options selected in the GUI are passed to the netlist, correctly setting the posted and non-posted header credit and INFINITECOMPLETIONS attributes on the built-in block for PCI Express.

-CR448357: Completion Credit Advertised in Non-INFINITECOMPLETIONS Mode Incorrect.

The Completion Header and Data Credit advertised in Non-INFINITECOMPLETION Mode was incorrect.
The core continued to advertise INFINITE Credits, even though INFINITECOMPLETIONS was set to FALSE.
This problem is fixed by setting the VC0TOTALCREDITSCH and VC0TOTALCREDITSCD to the correct values when Non-INFINITECOMPLETIONS setting is chosen.

-CR451148: Transceiver wrapper update for latency and link training issues.

Update GTP wrapper to (a) Use TXBUFFERBYPASS mode to reduce transmit path latency; (b) Fix link training failure (trains down to less than capability link width) associated with multiple warm resets during platform startup.

-CR466933: Provide a free running 100 / 250 MHz clock on the core boundary.

Provided new output signal - refclkout, which is a free running reference clock - 100 / 250 MHz based on Reference Clock Frequency selection in CORE Generator GUI.
This clock signal is derived from PCIe Lane #0 GTP/GTX REFCLKOUT output, and is available on FPGA global clock network (BUFG output).

-CR453282: Some MSIs sent by CFG_INTERRUPT interface not being transmitted by Core.

Issue resolved where some MSI Message Requests on the cfg_interrupt interface are acknowledged by the interface, but the corresponding MSI Messages are not transmitted by the core.

-CR454305: CFG_ERR throttle signal.

Added a throttle signal cfg_err_cpl_rdy_n to prevent internal buffers from overflowing when the user asserts cfg_err_ur_n or cfg_err_cpl_abort_n.

-CR454821: Core drops NP TLPs when trn_rdst_rdy_n is de-asserted.

Issue resolved where the core was dropping Non-Posted TLPs when trn_rdst_rdy_n is deasserted.

-CR455709: trn_reset_n is incorrectly asserted when connected component TX enters L0s.

Issue resolved where trn_reset_n was incorrectly asserted when the connected component's transmitter entered L0s.

-CR453280: Non-compliance in responding to MRdLk requests with CplLk responses.

Issue resolved. Added a signal cfg_err_locked_n. This signal is used to further qualify the cfg_err_* signals.
When this signal is asserted, this indicates that the transaction that caused the error (cfg_err_* assertion) was a locked transaction.

-CR454642-TX locks up when TX Cpl Buffer is full and a new CfgRd0/CfgWr0 is received.

Issue resolved. Added a signal trn_tbuf_av[3]. A value of 1b indicates that the core can accept Completion Transactions on the Transaction Interface.
A value of 0b indicates the core cannot accept Completion Transactions, but can still accept Posted or Non-Posted Transactions depending on the assertion of the corresponding trn_tbuf_av bit.

-GUI issue where Non-Infinite Completions not being set correctly.

Issue resolved where non-infinite completion credits were not being set correctly.

-CR454689: Excessive NP Rx Latency in Non-Streaming mode.

Issue resolved where Non-Posted TLPs were suffering excessive latency on receive path when trn_rnp_ok_n is asserted and trn_rdst_rdy_n modulated.

-CR468263: Link Training Issues.

Link training issue resolved where the 8 lane core trains to a 4 lane / a 2 lane / a 1 lane endpoint.

Known Issues

There are three main components to the Endpoint Block Plus Wrapper for PCI Express:

  • Virtex-5 FPGA Integrated Block for PCI Express
  • Virtex-5 FPGA GTP Transceivers
  • Block Plus Wrapper FPGA fabric logic

There are known issues and restrictions for each of these components as described below:

Virtex-5 FPGA Integrated Block for PCI Express Known Restrictions

Please refer to the "Virtex-5 Integrated Endpoint Block for PCI Express Designs User Guide"

(UG197) - v1.2, December 13, 2007, found at: http://www.xilinx.com/support/documentation/user_guides/ug197.pdf
for a list of Known Restrictions for the Integrated Block. This information is found in Chapter 4, in the "Known Restrictions" section, on page 76.

Virtex-5 FPGA GTP Transceivers

The following are known issues regarding the GTP Transceivers interfacing to the Integrated Block for PCI Express.

- Transceiver Exit from Rx.L0s

When the GTP transceiver exits from Rx.L0s, up to eight symbol times of valid data following the SKP symbol in the FTS-FTS-COM-SKP channel bonding sequence will be ignored by the block.

This is due to a delay in the assertion of the RXCHANISALIGNED signal from the GTP.

If the packets are replayed by the upstream port and correctly ACKed by the integrated block, the link will stay up.

However, there is a chance that if the original missed data was an ACK, that the upstream component sends the ACK, goes back to L0s, wakes up to send the ACK, and then returns to L0s.

If this repeats continuously, this eventually triggers a link retrain.

However, no data is lost and the link eventually recovers, causing minimal to no impact on safe operation.

-TX Path Entering L0s and Packet Received.

When the TX path of core is entering L0s and a packet is transmitted by the link partner, the transition back to L0 to send an ACK is very long causing the link partner to replay the packet.

It results in two ACKs sent by the core (one for the original packet and one for the replayed packet).

This is due to the time it takes for the GTP to return to L0 from L0s.

There is no work-around at this time.

-GTP Reset

In simulation when the GTP is in reset, the TX outputs are held to the last logic value driven, instead of driving both TXp and TXn to either X, 1, or 0.

This might cause the link partner model to incorrectly interpret the behavior and see it as potential START of packet.

This has been reported using the Denali BMF, and it causes the Denali model to report errors as it interprets these values as potential START of packet.

The work-around is to turn off the Denali error reporting when GTP is in reset.

-Reporting 8B/10B Error

The GTP transceiver is required to signal an 8B/10B error by setting RXSTATUS[2:0] to 3'b100, RXDATA[7:0] to 8'hFE and RXCHARISK to 1.

The transceiver correctly sets RXSTATUS, but does not indicate the correct values on RXDATA and RXCHARISK.

As a result, an 8B/10B error manifests itself as an LCRC error and the integrated block transmits a NAK DLLP.

This does not cause any fatal errors, but results in a non-compliant response. Users can work around this by monitoring the GTP transceiver RXSTATUS output and using fabric logic to insert the correct values on the RXDATA and RXDATAK inputs to the integrated block.

-Channel Bonding on Exit from L0s

When the link transitions from L0s to L0, there is an issue with channel bonding on a multi-lane link.

A work-around for this issue is already included in the Block Plus Wrapper for PCI Express.

During implementation, MAP might report that latches are being used on a path similar to:


These latches are expected and are necessary for proper operation of the core.

-Simulating Electrical Idle

During simulation, it is necessary at certain times for each link partner to simulate driving electrical idle.

The Xilinx GTP transceivers expect to receive either a 1, 0, or X on the RXp and RXn lines, and not a High-Z to represent electrical idle.

If the link partner model transmits an High-Z to represent electrical idle, the design will fail to link up. To work around this problem, the user can either set the link partner model to driver a 1, 0, or X for electrical idle, or insert some logic in the testbench to "trap" the High-Z and replace it with an 1, 0, or X.

This is similar to what is performed in (Xilinx Answer 29294) for a similar problem when interfacing to the Xilinx downstream port model for simulation.

-Simulating GTP Reset

In simulation, when the GTP is in reset, the TX outputs are held to the last logic value driven instead of driving both TXp and TXn to either X, 1, or 0.
This might cause the link partner model to incorrectly interpret the behavior and see it as potential START of packet.
This has been reported using the Denali BMF, and it causes the Denali model to report errors as it interprets these values as potential START of packet.
The work-around is to turn off the Denali error reporting when GTP is in reset.

Block Plus Wrapper FPGA fabric logic

-CR 453280: The core's configuration port does not currently allow users to return a Completion Lock with status Unsupported Request. A Completion Lock is returned for Memory Read Lock request.

Memory Read Lock TLPs are not commonly used, so the occurrence of this issue is rare. This is fixed in v1.5.2 (Xilinx Answer 30124).

-CR 453975: It is possible that if the core's configuration port is used to continuously send completion TLPs for issues requiring a status other than Successful Completion, some of these TLPs might be lost.

This is because the core does not provide a throttle back mechanism on the configuration port similar to trn_tdst_rdy_n on the transmit port.

This problem occurs most often when the user is simultaneously transmitting TLPs on the TRN transmit port. The core must internally arbitrate between the configuration port-generated TLPs and the transmit port TLPs.

This might cause the core's internal buffer for the configuration generated TLPs to fill and any other requested TLPs to be lost.

There is no danger in losing TLPs generated on the TRN transmit interface. This is fixed in v1.5.2 (Xilinx Answer 30124).

-CR 453282: If the user generates MSI packets on the interrupt port, it is possible that some of the MSI TLPs might not get transmitted depending on what other traffic is being generated by the user. If the user is generating MSI at or around the same time as they are using the configuration port to generate errors and sending TLPs on the transmit port, the MSI packets could be dropped. This results from an error in the arbitration logic between the three data paths. This is fixed in v1.5.2 (Xilinx Answer 30124).

- CR 456000 - Link capability register bits 10 and 11 are set incorrectly. These bits indicate the level of active state power management support. They should be set to 01 instead of 11. This is scheduled to be fixed in v1.7. To fix this issue, you can override the attribute on the Virtex-5 Block for PCI Express by adding the following to the UCF file:

INST "ep/BU2/U0/pcie_ep0/pcie_blk/pcie_ep" LINKCAPABILITYASPMSUPPORT = "01";

- CR 454821: Non-posted packets can get lost on the receive path through the Block Plus Core through an overflow scenario that can occur if you toggle trn_rdst_rdy_n. This is fixed in v1.5.2 (Xilinx Answer 30124).

- CR 454689: Non-posted packets can appear as dropped (when there is a heavy flow of both posted and non-posted packets) when you toggle trn_rdst_rdy_n. The packet is not actually lost, but is held in the Block Plus core's internal FIFO.

This is a slightly different issue than the one listed directly above in which the packet is actually lost. In this case, the NP packet is eventually drained if the flow of posted packets ceases or lessens.

Toggling trn_rdst_rdy_n, causes the core to give preference to the posted packet queue. Technically, this is not illegal because posted packets are allowed to bypass non-posted packets.

However, this is a problem because the non-posted packet might not be provided to the user application in a timely fashion to allow a completion to be returned, which causes a completion timeout to occur on the requesting device.

To work around this issue, do not toggle trn_rdst_rdy_n, and use a local memory to queue up the packets. This is fixed in v1.5.2 (Xilinx Answer 30124).

-CR455709: When the link partner transitions to L0s and drives electrical idle, the GTP transceiver requires a reset in order to achieve symbol lock when the link moves back to L0.

When the Block Plus Core resets the GTP it is causing trn_reset_n to assert.

This is because the RESETDONE output of the GTP factors into the trn_reset_n control logic and when the GTP is reset it causes RESETDONE to toggle causing trn_reset_n to go low.

This is fixed in v1.5.2 (Xilinx Answer 30124).

-CR468263: Link training issues might occur where the 8 lane core trains to a 4 lane, 2 lane, or 1 lane core.

This is fixed in v1.5.2 (Xilinx Answer 30124).

PIO Example Design

- CR 454038: The example design PME Turnoff control module for VHDL called "PIO_TO_CTRL.vhd" contains an incorrect reset. The reset is active Low, but is treated as active High, as follows:

if (rst_n = '1') then


Which should read:


if (rst_n = '0') then


This affects only the VHDL example design; it does not affect the actual Block Plus Core.

-When using the v1.5.2 patch, new ports are included on the core. One of these is trn_tbuf_av[3]. The generated Verilog example design does not increase the width of this bus to 4. To fix this, open the file xilinx_pci_exp_defines.v in the simulation directory and change this parameter to 4:


-CR 444221- The PIO RX engine file contains two PIO_64_RX_MEM_RD64_FMT_TYPE state declarations. This should not cause a problem as the synthesis tool ignores the second definition. If it does cause issues, remove the second declaration in the FSM.

-CR 466393 - The PIO TX engine state PIO_64_TX_CPL_QW1 final else statement points to the PIO_64_TX_CPLD_QW1 state. Instead, it should point to PIO_64_TX_CPL_QW1. It should remain in the PIO_64_TX_CPL_QW1 until one of the previous conditions is satisfied and then it returns to the initial state, PIO_64_TX_RST_STATE.


- See (Xilinx Answer 29294) regarding long simulation times for link training.

UCF Files

- CR 452484: Some x1 and x4 UCF files use MGT Clock input pins beside unused MGTs. The UCF files are structured such that the x1 and x4 are subsets of the x8 UCF files. In the x8 UCF files, all of the GTPs beside the clock input pins are always in use, but in some x1 and x4 designs, this might not be the case. The GTP User Guide states that the clock should not be input beside an unused MGT.

This can cause unpredictable clock issues. It is recommended that you use the CORE Generator RocketIO wizard to create a dummy GTP incantation for the GTP beside the clock input if it is not being used by PCI Express.

Refer to the GTP User Guide (UG196) for more information:


The Block Plus Core UCF files are being corrected so that this does not occur.

- Some x1, x4, and x8 designs might not meet timing with the default MAP and PAR settings.

To obtain timing closure, designers might be required to use multiple PAR seeds or floorplanning. By using Multi-Pass Place and Route (MPPR), designers can try multiple cost tables to meet timing.

For more information on using MPPR, see the Development System Reference Guide in the Software Manuals found at:


Designers might also need to floorplan and add advanced placement constraints for both their design and the core to meet timing.

-UCF files for targeting the LX155T and LX20T can be found at this link:



- CR 456008: User Guide states that trn_rsrc_dsc_n will assert if communication with the link partner is lost.

This is a mistake; trn_rsrc_dsc_n is tied High inside the Block Plus Core. To achieve functionality similar to trn_rsrc_dsc_n, you must use the trn_lnk_up_n Core output, to reset any framing state machines interfacing to the core, including any logic that is in the process of receiving or presenting a TLP to the core when a "Link Down" event occurs.

Specifically, if the Block Plus Core is exposed to, Link-Down (recovery failure related to reliability reasons), Warm Reset (PERST# assertion), Hot Reset (in-band), or Link Disable (in-band), then trn_lnk_up_n is deasserted for several microseconds (actual time is determined by the cause of link-down), which should be used to return all the logic interfacing with the core to its quiescent (reset) state.

-Table 5-2 is missing entries on the FF1136 package.

For the XC5VLX50T, XC5VLX85T, XC5VSX50T, the x4 entry should have Lane 0/1 on X0Y3 and Lane 2/3 on X0Y2 and the x8 entry should have Lane 4/5 on the X0Y1 and Lane 6/7 on X0Y0.

For the XC5VLX110T and XC5VSX95T, the x4 entry should have Lane 0/1 on X0Y4 and Lane 2/3 on X0Y3 and the x8 entry should have Lane 0/1 on the X0Y4, Lane 2/3 on the X0Y3, Lane 4/5 on the X0Y2 and Lane 6/7 on X0Y1.

Revision History

02/22/2008 - Updated to include GTP known issues, reference to UG197, new information for v1.5.2 patch, and created Documentation heading in the Known Issues section.

01/23/2008 - Added 451148, 44422, and 466393

01/08/2008 - Added link for LX155T and LX20T UCF files.

12/20/2007 - Grouped Known Issues for easier reading. Added reference to 29972. Add CR 455709.

12/14/2007 - Added CRs 454869, 454821, 456008, 456000, 452484.

11/14/2007 - Added CRs 454038, 453280, 453975, 453282.

10/12/2007 - Initial Release of Answer Record.

AR# 29468
Date Created 09/28/2007
Last Updated 10/01/2015
Status Active
Type Release Notes
  • ISE - 9.2i
  • Endpoint Block Plus Wrapper for PCI Express