This Release Note and Known Issues Answer Record is for the LogiCORE Endpoint v3.5 for PCI Express released in 9.1i IP Update 3, 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 (Xilinx Answer 24847).
Updates for the pci_exp_1_lane_32b_ep, pci_exp_4_lane_32b_ep, and pci_exp_8_lane_64b_ep Cores
These cores are delivered through CORE Generator and are updated as part of 9.1i IP Update 3.
Updates for the pci_exp_1_lane_64b_ep and pci_exp_4_lane_64b_ep Cores
If you are using the pci_exp_1_lane_64b_ep and pci_exp_4_lane_64b_ep, download a new ZIP file containing this update from the PCI Express Lounge at:
The zip file release is v3.5.
- Virtex-5 LXT Support.
--Limited initial part/package support.
--The Xilinx LogiCORE warranty does not cover production usage with ES silicon.
- CR 432373: Fixed issue where Ack/Nak Latency timer fails if MPS is changed by configuration access
- CR 435139: Fixed issue where Set Slot Power Limit Messages were not decoded correctly
- Refer to the "readme_pci_express.txt" file delivered with the core for known issues at the time of the release.
- Some x4 and x8 designs targeting Virtex-5 might not meet timing using the default implementation script. To fix this issue, add the continuous extra effort level for PAR by adding "-xe c" as an option for PAR. For more information on using this option, see the "Development System Reference Guide" in the Software Manuals at:
- MPS change results in lost ACK/NAK from core. Changing the Maximum Payload Size might result in core failing to ACK or NAK outstanding TLPs when upstream bandwidth is fully utilized.
Impact: Might result in the resending of TLPs unnecessarily.
Work-around: Host should not change MPS when there is downstream traffic that has not been acknowledged by the core.
- Virtex-5 only - If the core receives a Configuration Read/Write to Extended Configuration Space that is implemented by the user, and the core is directed to L1 before the user can respond with a completion, then the completion might not be sent until the core is transitioned to L0.
Impact: Might result in a completion timeout.
Work-around: Disable non-D0 states if implementing Extended Config Space.
- Virtex-5 x4 Core might only wait 5 us between ASPM L1 requests if ASPM L1 entry is enabled and the host rejects a core request to move into Active State L1. The core might only wait five microseconds before sending another request to move into Active State L1. The specification states that an endpoint should wait at least 10 microseconds before reinitiating a request.
Impact: Might result in host refusing to respond to a subsequent Active State L1 request.
Work-around: ASPM L1 entry can be disabled in the Link Control register.
- See (Xilinx Answer 25225) regarding an error ("ERROR:Place:543") that might occur during the MAP phase.
- See (Xilinx Answer 25362) regarding choosing more than one MSI vector in the CORE Generator GUI.
- Packets implementing Phantom Functions are not properly passed to the user application. If the function number field is anything other than 000, the TLP is discarded by the Endpoint core. A solution to this problem is under investigation.