AR# 30120


Endpoint Block Plus Wrapper for PCI Express v1.6 and v1.6.1- Release Notes and Known Issues for ISE 10.1 Initial IP Update (IP_10.1.0)


This Release Note and Known Issues Answer Record is for the Endpoint Block Plus Wrapper v1.6 and v1.6.1 released in the ISE 10.1 Initial IP Update (IP_10.1.0) and 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 the IP Release Notes Guide at:


General Information

IMPORTANT: All users must download and install the v1.6.1 patch found in (Xilinx Answer 30124).

This patch fixes some critical issues in v1.6.

The resolved issues and known issues below are as of v1.6.1 and are not relevant to v1.6.

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 10.1 software support
  • Added support for Virtex-5 FXT devices
  • Added UCFs for new Virtex-5 LXT (20, 155) parts
  • Added GUI configurable GTP/GTX transmitter settings
  • Added new pin cfg_err_cpl_rdy_n - a new throttle signal for cfg_err interface.

Resolved Issues

- CR451293: Example design cleanup

Removed the `define usage for module names that prevented example design usage in ISE environment. 

- CR449622: Simulation link up issue

Issue resolved in which the core does not link up when running the default simulation for a x8 core. 

- CR445024: PIO example design fails memory byte test in hardware platform

PIO Example Design returns CplD with corrupted data when non-DWORD accesses are made. 

- CR448940: Work construct needs to be defined in cds.lib for NC-Sim simulation

When running NC-Sim, the script file does not add the work library construct to the cds.lib file. 

Instructions to resolve are provided in the Getting Start Guide and the User Guide.

- CR456831: Error in Perl script for x8 VHDL flow

Incorrect search pattern in Perl script for the 8 lane VHDL flow.

- CR458537: TX Transmission Issues Due to Lack of Data Credits

Work-around implemented for the "TX Transmission Issues Due to Lack of Data Credits" known restriction in the integrated block.

This issue caused the integrated block to hang under certain conditions.

The work-around ensures these conditions do not occur.

You do not have to make changes to your logic since this fix is entirely within the Block Plus wrapper. 

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

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

(UG197 - v1.2, December 13, 2007), for a list of Known Restrictions for the Integrated Block.

This information is included in Chapter 4, in the "Known Restrictions" section, on page 76.

This guide is located at:

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, then the upstream component can send the ACK, go back to L0s, wake up to send the ACK, and then return 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.
To work around this issue, 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.
You 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, you 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.
To work around this issue, turn off the Denali error reporting when GTP is in reset.

Block Plus Wrapper FPGA fabric logic

- 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 468765 - See (Xilinx Answer 30668)

-CR 469909 - The v1.6.1 Block Plus Endpoint Wrapper for PCI Express uses the TX Buffer Bypass mode for all device configurations (LXT, SXT, and FXT).
When using TX Buffer Bypass, it is possible that as the parts temperature significantly increases or decreases, the TX phase alignment performed initially might fail, causing link failure or other stability problems.
This issue will be fixed for LXT and SXT in the v1.8 release, and the FXT fix will be in a later version (date still to be determined).
If this problem is experienced, issuing a system reset (asserting the sys_reset_n input to the wrapper) will cause TX phase alignment to initiate again.

PIO Example Design

- 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 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.
Xilinx recommends 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, you might be required to use multiple PAR seeds or floorplanning.
By using Multi-Pass Place and Route (MPPR), you 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:

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


- CR 456008: User Guide states that trn_rsrc_dsc_n asserts 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.

Revision History

04/16/2008 - Added CR458537 to Resolved Issues. Added CR469909 to Known Issues.

04/03/2008 - Added CR468765.

03/24/2008 - Initial Release of Answer Record.

AR# 30120
日期 10/01/2015
状态 Active
Type 版本说明
People Also Viewed