Xilinx PG023 Virtex 7 FPGA Gen3 Integrated Block For PCI Express, Product Guide Logi Core V3.0 V7 Pcie

User Manual: LogiCore PCI v3.0

Open the PDF directly: View PDF .
Page Count: 285

Download
Open PDF In Browser	View PDF

Virtex-7 FPGA Gen3
Integrated Block for
PCI Express
Product Guide

PG023 April 24, 2012

Table of Contents
Chapter 1: Overview
Feature Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Unsupported Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Chapter 2: Product Specification
Standards Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Resource Utilization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Block Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Port Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attribute Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration Space. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11
11
12
13
53
56

Chapter 3: Customizing and Generating the Core
GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Output Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Chapter 4: Designing with the Core
General Design Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Clocking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
AXI4-Stream Interface Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Clocking Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Interface Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Power Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Link Training: 2-Lane, 4-Lane, and 8-Lane Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Lane Reversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

Chapter 5: Constraining the Core
Required Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Device, Package, and Speed Grade Selections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Clock Frequencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Clock Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Clock Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Stacked Silicon Interconnect Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transceiver Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I/O Standard and Placement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

179
179
180
180
180
180
180
187

Chapter 6: Detailed Example Design
Directory and File Contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Demonstration Test Bench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

188
188
200
214
216

Appendix A: Debugging
Finding Help on Xilinx.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contacting Xilinx Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Debug Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hardware Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
FPGA Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simulation Debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

218
219
220
223
233
240

Appendix B: Attributes

Appendix C: Additional Resources
Xilinx Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Solution Centers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ordering Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

283
283
283
284
284
284

Notice of Disclaimer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

IP Facts

Introduction

LogiCORE IP Facts Table

The LogiCORE™ IP Virtex®-7 FPGA Gen3
Integrated Block for PCI Express® core is a
high-bandwidth, scalable, and reliable serial
interconnect building block solution for use
with all Virtex-7 XT and HT FPGAs except the
XC7VX485T. The Integrated Block for PCI
Express (PCIe®) solution supports 1-lane,
2-lane, 4-lane, and 8-lane Endpoint
configurations, including Gen1 (2.5 GT/s), Gen2
(5.0 GT/s) and Gen3 (8 GT/s) speeds. It is
compliant with PCI Express Base Specification,
rev. 3.0. This solution supports the AXI4-Stream
interface for the customer user interface.
PCI Express offers a serial architecture that
alleviates many limitations of parallel bus
architectures by using clock data recovery
(CDR) and differential signaling. Using CDR (as
opposed to source synchronous clocking)
lowers pin count, enables superior frequency
scalability, and makes data synchronization
easier. PCI Express technology, adopted by the
PCI-SIG® as the next generation PCI™, is
backward-compatible to the existing PCI
software model.
With higher bandwidth per pin, low overhead,
low latency, reduced signal integrity issues, and
CDR architecture, the Integrated Block sets the
industry standard for a high-performance,
cost-efficient PCIe solution.
The Virtex-7 FPGA Gen3 Integrated Block for
PCI Express solution is compatible with
industry-standard application form factors such
as the PCI Express Card Electromechanical
(CEM) v3.0 and the PCI Industrial Computer
Manufacturers Group (PICMG) 3.4
specifications.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

Core Specifics
Supported
Device
Family (1)

Virtex-7 XT and HT (2)

Supported
User Interfaces

AXI4-Stream

Resources

Provided with Core
Design Files

Verilog

Example
Design

Verilog

Test Bench

Verilog

Constraints
File

User Constraints File (UCF)

Simulation
Model

Verilog

Supported
S/W Drivers

N/A

Tested Design Tools
Design Entry
Tools

ISE Design Suite v14.1

Simulation (3)

Mentor Graphics ModelSim

Synthesis
Tools (3)

XST v14.1

Support
Provided by Xilinx @ www.xilinx.com/support

1. For a complete listing of supported devices, see the release
notes for this core.

2. Except for the XC7VX485T.
3. For the supported versions of the tools, see the ISE Design
Suite 14: Release Notes Guide.

www.xilinx.com

5
Product Specification

Features
The key features of the Virtex-7 FPGA Gen3 Integrated Block for PCI Express (8.0 GT/s) core are:
•

•

High-performance, highly flexible, scalable, and reliable, general-purpose I/O core
°

Compliant with the PCI Express Base Specification, rev. 3.0

Compatible with conventional PCI software model

GTH transceivers
°

2.5 GT/s, 5.0 GT/s, and 8.0 GT/s line speeds

1-lane, 2-lane, 4-lane, and 8-lane operation

•

Endpoint configuration

•

Multiple Function and Single-Root I/O Virtualization in the Endpoint configuration

•

2 Physical Functions

6 Virtual Functions

Standardized user interface(s)
°

Compliant to AXI4-Stream

Separate Requester, Completion, and Message interfaces

Flexible Data Alignment

Parity generation and checking on AXI4-Stream interfaces

Easy-to-use packet-based protocol

Full-duplex communication enabling

Optional back-to-back transactions to enable greater link bandwidth utilization

Support for flow control of data and discontinuation of an in-process transaction in
transmit direction

Support for flow control of data in receive direction

•

Compliant with PCI and PCI Express power management functions

•

Optional Tag Management feature

•

Maximum transaction payload of up to 1024 bytes

•

End-to-End Cyclic Redundancy Check (ECRC)

•

Advanced Error Reporting (AER)

•

Multi-Vector MSI for up to 32 vectors and MSI-X

•

Atomic Operations and TLP Processing Hints

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

Chapter 1

Overview
The LogiCORE™ IP Virtex®-7 FPGA Gen3 Integrated Block for PCI Express® core is a
reliable, high-bandwidth, scalable serial interconnect building block for use with Virtex-7
XT and HT FPGAs, except for the XC7VX485T. The core instantiates the Integrated Block
found in Virtex-7 XT and HT FPGAs.
The Virtex-7 FPGA Gen3 Integrated Block for PCI Express is a CORE Generator™ IP core,
included in the ISE® Design Suite. For detailed information about the core, see the Virtex-7
FPGA Gen3 Integrated Block for PCI Express product page.
Figure 1-1 shows the interfaces for the LogiCORE IP Virtex-7 FPGA Gen3 Integrated Block
for PCI Express core.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

X-Ref Target - Figure 1-1

6IRTEX &0'! 'EN
)NTEGRATED "LOCK FOR 0#)E
#OMPLETER
RE1UESTER
)NTERFACE

!8) 3TREAM %NHANCED )NTERFACE

#OMPLETER
#OMPLETION
)NTERFACE

2EQUESTER
RE1UESTER
)NTERFACE

2EQUESTER
#OMPLETION
)NTERFACE

5SER !PPLICATION

!8)
3TREAM
-ASTER

M?AXIS?CQ?

!8)
3TREAM
3LAVE

S?AXIS?CC?

!8)
3TREAM
-ASTER

!8)
3TREAM
3LAVE

S?AXIS?RQ?

!8)
3TREAM
-ASTER

4AG
!VAILBILITY
3TATUS

!8)
3TREAM
-ASTER

PCIE?TAG?AV;=

M?AXIS?RC?

0#)E
#OMPLETER
)NTERFACE

0#)E
2EQUESTER
)NTERFACE
!8)
3TREAM
3LAVE

CFG?MGMT?

#ONFIGURATION
-ANAGEMENT
)NTERFACE

CFG?MGMT?READ?DATA
CFG?MGMT?READ?WRITE?DONE

#ONFIGURATION 3TATUS
)NTERFACE

CFG?

#ONFIGURATION 2ECEIVED
-ESSAGE )NTERFACE

CFG?MSG?RECEIVED

CFG?MSG?TRANSMIT?

#ONFIGURATION 4RANSMIT
-ESSAGE )NTERFACE

CFG?MSG?TRANSMIT?DONE

&LOW #ONTROL 3TATUS

CFG?FC?
CFG?FC?SEL

0ER &UNCTION 3TATUS

CFG?PER?FUNC?STATUS?CONTROL
CFG?PER?FUNC?STATUS?DATA

#ONFIGURATION #ONTROL
)NTERFACE

CFG?

CFG?INTERRUPT?
#ONFIGURATION )NTERRUPT
#ONTROLLER )NTERFACE

CFG?INTERRUPT?MSI?
CFG?INTERRUPT?MSIX?
CFG?EXT?

#ONFIGURATION
%XTENDED )NTERFACE

USER?CLK
USER?RESET

SYS?CLK
SYS?RESET

PCI?EXP

CFG?EXT?READ?DATA
CFG?EXT?READ?DATA?VALID

#LOCK AND 2ESET
)NTERFACE

0#) %XPRESS
8

Figure 1-1:

Virtex-7 FPGA Gen3 Integrated Block for PCI Express Interfaces

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

Feature Summary

Feature Summary
The LogiCORE IP Virtex-7 FPGA Gen3 Integrated Block for PCI Express core is a
high-bandwidth, scalable, and flexible general-purpose I/O core for use with most Virtex-7
XT and HT FPGAs. The GTH transceivers in the Integrated Block for PCI Express (PCIe®)
solution support 1-lane, 2-lane, 4-lane, and 8-lane operation, running at 2.5 GT/s (Gen1),
5.0 GT/s (Gen2), and 8.0 GT/s (Gen3) line speeds. Endpoint configurations are supported.
The customer user interface is compliant with the AMBA® AXI4-Stream interface. This
interface supports separate Requester, Completion, and Message interfaces. It allows for
flexible data alignment and parity checking. Flow control of data is supported in the receive
and transmit directions. The transmit direction additionally supports discontinuation of
in-progress transactions. Optional back-to-back transactions utilize straddling to provide
greater link bandwidth.
The Virtex-7 FPGA supports two physical functions and six virtual functions.
The core is compliant with PCI and PCI Express power management functions.

Applications
The Integrated Block for PCI Express architecture enables a broad range of computing and
communications target applications, emphasizing performance, cost, scalability, feature
extensibility and mission-critical reliability. Typical applications include:
•

Data communications networks

•

Telecommunications networks

•

Broadband wired and wireless applications

•

Network interface cards

•

Chip-to-chip and backplane interface cards

•

Server add-in cards for various applications

Unsupported Features
The Integrated Block does not implement the Address Translation Service, but allows its
implementation in external soft logic.
Switch ports and the Resizable BAR Extended Capability are not supported.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

Licensing

Licensing
The LogiCORE IP Virtex-7 FPGA Gen3 Integrated Block for PCI Express core is included with
the CORE Generator tool. It is provided under the Xilinx End User License Agreement. No
license key is required.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

Chapter 2

Product Specification
Standards Compliance
The Virtex®-7 FPGA Gen3 Integrated Block for PCI Express® solution is compatible with
industry-standard application form factors such as the PCI Express Card Electromechanical
(CEM) v3.0 and the PCI Industrial Computer Manufacturers Group (PICMG) 3.4 specifications.

Resource Utilization
Resources required for the Virtex-7 FPGA Gen3 Integrated Block for PCIe® core have been
estimated for the Virtex-7 FPGA (Table 2-1). These values were generated using the Xilinx®
CORE Generator™ tools, v14.1. They are derived from post-synthesis reports, and might
change during MAP and PAR. The resources listed in Table 2-1 are for the default core
configuration.
Table 2-1:

Virtex-7 FPGA Gen3 Integrated Block for PCIe Resource Estimates

RX Request TX Replay Block RAM Usage
Lanes GTHE2 FF(1) LUT(1) CMPS(2) RX Completion Buffer Size Buffer Size
Buffer Size (KB)
RAMB18 RAMB36
(KB)
(KB)
1

566

832

957

1384

1740

2500

3399

4818

1281024

12
8

Notes:
1. Numbers are for the default core configuration. Actual LUT and FF utilization values vary based on specific
configurations.
2. Capability Maximum Payload Size (CMPS).

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

11
Product Specification

Block Selection

Block Selection
Table 2-2 lists which Virtex-7 FPGA Gen3 Integrated Blocks for PCIe are available for use in
FPGAs containing multiple Integrated Blocks. In some cases, not all Integrated Blocks can
be used due to lack of bonded transceiver sites adjacent to the Integrated Block.
Table 2-2:

Available Integrated Blocks for PCI Express

Device Selection

Integrated Block for PCI Express Location

Device

Package

X0Y0

X0Y1

XC7VX330T

FFG1157
FFG1761

✓

XC7VX415T

FFG1157
FFG1158
FFG1927

✓

XC7VX550T

XC7VX690T

XC7VX980T

FFG1158
FFG1927

✓

FFG1157
FFG1158
FFG1930

✓

FFG1926
FFG1928
FFG1933

✓

FLG1926
FLG1933

✓

FLG1928

✓

FLG1930
XC7VH290T

HCG1155

✓
✓

XC7VH580T

HCG1155
HCG1931
HCG1932

XC7VH870T

✓

FFG1761
FFG1926
FFG1927

FFG1930

XC7VX1140T

X0Y2

✓

HCG1931
HCG1932

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

✓

www.xilinx.com

X0Y3

✓

✓
✓

✓

12
Product Specification

Port Descriptions

Port Descriptions
This section provides detailed port descriptions for each interface.

Core Interfaces
In addition to status and control interfaces, the core has these four required AXI4-Stream
interfaces used to transfer and receive transactions:
•

The Completer reQuest (CQ) interface through which all received requests from the link
are delivered to the user application.

•

The Completer Completion (CC) interface through which completions generated by the
user application responses to the completer requests are transmitted. The user can
process all Non-Posted transactions as split transactions. That is, it can continue to
accept new requests on the Requester Completion interface while sending a
completion for a request.

•

The Requester reQuest (RQ) interface through which the user application generates
requests to remote PCIe® devices.

•

The Requester Completion (RC) interface through which the completions received from
the link in response to the user's requests are presented to the user application.

The core also provides these interfaces:
•

The Transmit Flow Control interface is used by the user application to request which
flow control information the core provides. This interface provides the Posted/
Non-Posted Header Flow Control Credits, Posted/Non-Posted Data Flow Control
Credits, the Completion Header Flow Control Credits, and the Completion Data Flow
Control Credits to the user application based upon the setting flow control select input
to the core.

•

The Configuration Management interface is used to read and write to the
Configuration Space Registers.

•

The Configuration Status interface provides information on how the core is configured,
such as the negotiated link width and speed, the power state of the core, and
configuration errors.

•

The Configuration Received Message interface indicates to the user logic that a
decodable message from the link, the parameters associated with the data, and the
type of message have been received.

•

The Configuration Transmit Message interface is used by the user application to
transmit messages to the core. The user application supplies the transmit message type
and data information to the core, which responds with the Done signal.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

13
Product Specification

Port Descriptions
•

The Per Function Status interface provides status data as requested by the user
application through the selected function.

•

The Configuration Control Interface signals allow a broad range of information
exchange between the user application and the core. The user application uses this
interface to set the configuration space; indicate if a correctable or uncorrectable error
has occurred; set the device serial number; set the Downstream Bus, Device, and
Function Number; and receive per function configuration information. This interface
also provides handshaking between the user application and the core when a Power
State change or function level reset occurs.

•

The Configuration Interrupt Controller interface allows the user application to set
Legacy PCIe interrupts, MSI interrupts, or MSI-X interrupts. The core provides the
interrupt status on the configuration interrupt sent and fail signals.

•

The Configuration Extended interface allows the core to transfer configuration
information with the user application when externally implemented configuration
registers are implemented.

•

The Clock and Reset interface, fundamental to the core’s operation, provides the
system level clock and reset to the core as well as the user application clock and reset
signal.

•

The PCI Express interface contains all of the differential transmit and receive pairs.

Completer reQuest (CQ) Interface
Table 2-3 defines the ports in the CQ interface of the Gen3 Integrated Block for PCI Express
core. In the Width column, DW denotes the configured data bus width (64, 128, or 256 bits)
Table 2-3:

CQ Interface Port Descriptions
Port

m_axis_cq_tdata

m_axis_cq_tuser

Direction

Description

Width

Output

Transmit Data from the Completer reQuest Interface.
Only the lower 128 bits are to be used when the
interface width is 128 bits, and only the lower 64 bits
are to be used when the interface width is 64 bits.
Bits [255:128] are set permanently to 0 by the core
when the interface width is configured as 128 bits, and
bits [255:64] are set permanently to 0 when the
interface width is configured as 64 bits.

Output

Completer reQuest User Data. This set of signals
contains sideband information for the TLP being
transferred. These signals are valid when
m_axis_cq_tvalid is High.
Table 2-4, page 16 describes the individual signals in
this set.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

14
Product Specification

Port Descriptions

Table 2-3:

CQ Interface Port Descriptions (Cont’d)
Port

m_axis_cq_tlast

m_axis_cq_tkeep

m_axis_cq_tvalid

m_axis_cq_tready

Direction

Description

Width

Output

TLAST indication for Completer reQuest Data. The core
asserts this signal in the last beat of a packet to
indicate the end of the packet. When a TLP is
transferred in a single beat, the core sets this bit in the
first beat of the transfer.

Output

TKEEP indication for Completer reQuest Data. The
assertion of bit i of this bus during a transfer indicates
to the client that Dword i of the m_axis_cq_tdata
bus contains valid data. The core sets this bit to 1
contiguously for all Dwords starting from the first
Dword of the descriptor to the last Dword of the
payload. Thus, m_axis_cq_tdata is set to all 1s in all
beats of a packet, except in the final beat when the
total size of the packet is not a multiple of the width of
the data bus (both in Dwords). This is true for both
Dword-aligned and address-aligned modes of payload
transfer.
Bits [7:4] of this bus are set permanently to 0 by the
core when the interface width is configured as 128 bits,
and bits [7:2] are set permanently to 0 when the
interface width is configured as 64 bits.

DW/32

Output

Completer reQuest Data Valid. The core asserts this
output whenever it is driving valid data on the
m_axis_cq_tdata bus. The core keeps the valid
signal asserted during the transfer of a packet. The
client application can pace the data transfer using the
m_axis_cq_tready signal.

Input

Completer reQuest Data Ready. Activation of this signal
by the client logic indicates to the core that the client
is ready to accept data. Data is transferred across the
interface when both m_axis_cq_tvalid and
m_axis_cq_tready are asserted in the same cycle.
If the client deasserts the ready signal when
m_axis_cq_tvalid is High, the core maintains the
data on the bus and keeps the valid signal asserted
until the client has asserted the ready signal.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

15
Product Specification

Port Descriptions

Table 2-3:

CQ Interface Port Descriptions (Cont’d)
Port

Direction

Description

Width

Input

Completer reQuest Non-Posted Request. This input is
used by the client application to request the delivery of
a Non-Posted request. The core implements a
credit-based flow control mechanism to control the
delivery of Non-Posted requests across the interface,
without blocking Posted TLPs.
This input to the core controls an internal credit count.
The credit count is incremented in each clock cycle
when pcie_cq_np_req is High, and decremented on
the delivery of each Non-Posted request across the
interface. The core temporarily stops delivering
Non-Posted requests to the client when the credit
count is zero. It continues to deliver any Posted TLPs
received from the link even when the delivery of
Non-Posted requests has been paused.
The client application can either provide a one-cycle
pulse on pcie_cq_np_req each time it is ready to
receive a Non-Posted request, or can keep it High
permanently if it does not need to exercise selective
backpressure on Non-Posted requests.
The assertion and deassertion of the
pcie_cq_np_req signal does not need to be aligned
with the packet transfers on the completer request
interface.

Output

Completer reQuest Non-Posted Request Count. This
output provides the current value of the credit count
maintained by the core for delivery of Non-Posted
requests to the client. The core delivers a Non-Posted
request across the completer request interface only
when this credit count is non-zero. This counter
saturates at a maximum limit of 32.
Because of internal pipeline delays, there can be
several cycles of delay between the core receiving a
pulse on the pcie_cq_np_req input and updating
the pcie_cq_np_req_count output in response.

pcie_cq_np_req

pcie_cq_np_req_count

Table 2-4:

Sideband Signal Descriptions in m_axis_cq_tuser

Bit Index

3:0

Name

first_be[3:0]

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

Width

Description

Byte enables for the first Dword of the payload. This
field reflects the setting of the First_BE bits in the
Transaction-Layer header of the TLP. For Memory Reads
and I/O Reads, these four bits indicate the valid bytes to
be read in the first Dword. For Memory Writes and I/O
Writes, these bits indicate the valid bytes in the first
Dword of the payload. For Atomic Operations and
Messages with a payload, these bits are set to all 1s.
This field is valid in the first beat of a packet, that is,
when sop and m_axis_cq_tvalid are both High.

www.xilinx.com

16
Product Specification

Port Descriptions

Table 2-4:

Sideband Signal Descriptions in m_axis_cq_tuser (Cont’d)

Bit Index

7:4

Name

last_be[3:0]

Width

Description

Byte enables for the last Dword. This field reflects the
setting of the Last_BE bits in the Transaction-Layer
header of the TLP. For Memory Reads, these four bits
indicate the valid bytes to be read in the last Dword of
the block of data. For Memory Writes, these bits
indicate the valid bytes in the ending Dword of the
payload. For Atomic Operations and Messages with a
payload, these bits are set to all 1s.
This field is valid in the first beat of a packet, that is,
when sop and m_axis_cq_tvalid are both High.

39:8

byte_en[31:0]

The client logic can optionally use these byte enable
bits to determine the valid bytes in the payload of a
packet being transferred. The assertion of bit i of this
bus during a transfer indicates to the client that byte i
of the m_axis_cq_tdata bus contains a valid payload
byte. This bit is not asserted for descriptor bytes.
Although the byte enables can be generated by client
logic from information in the request descriptor
(address and length) as well as the settings of the
first_be and last_be signals, the client has the
option to use these signals directly instead of
generating them from other interface signals.
When the payload size is more than two Dwords (eight
bytes), the one bit on this bus for the payload is always
contiguous. When the payload size is two Dwords or
less, the one bit can be non-contiguous.
For the special case of a zero-length memory write
transaction defined by the PCI Express specifications,
the byte_en bits are all 0s when the associated
one-DW payload is being transferred.
Bits [31:16] of this bus are set permanently to 0 by the
core when the interface width is configured as 128 bits,
and bits [31:8] are set permanently to 0 when the
interface width is configured as 64 bits.

sop

Start of packet. This signal is asserted by the core in the
first beat of a packet to indicate the start of the packet.
Use of this signal is optional for the client.

This signal is asserted by the core in the last beat of a
TLP, if it has detected an uncorrectable error while
reading the TLP payload from its internal FIFO memory.
The client application must discard the entire TLP when
such an error is signaled by the core.
This signal is never asserted when the TLP has no
payload. It is asserted only in a cycle when
m_axis_cq_tlast is High.
When the core is configured as an Endpoint, the error is
also reported by the core to the Root Complex to which
it is attached, using Advanced Error Reporting (AER).

discontinue

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

17
Product Specification

Port Descriptions

Table 2-4:

Sideband Signal Descriptions in m_axis_cq_tuser (Cont’d)

Bit Index
42

44:43

52:45

84:53

Name

Width

Description

This bit indicates the presence of a Transaction
Processing Hint (TPH) in the request TLP being
delivered across the interface. This bit is valid when sop
and m_axis_cq_tvalid are both High.

When a TPH is present in the request TLP, these two bits
provide the value of the PH[1:0] field associated with
the hint. These bits are valid when sop and
m_axis_cq_tvalid are both High.

When a TPH is present in the request TLP, this output
provides the 8-bit Steering Tag associated with the hint.
These bits are valid when sop and
m_axis_cq_tvalid are both High.

Odd parity for the 256-bit transmit data. Bit i provides
the odd parity computed for byte i of
m_axis_cq_tdata. Only the lower 16 bits are to be
used when the interface width is 128 bits, and only the
lower 8 bits are to be used when the interface width is
64 bits. Bits [31:16] are set permanently to 0 by the core
when the interface width is configured as 128 bits, and
bits [31:8] are set permanently to 0 when the interface
width is configured as 64 bits.

tph_present

tph_type[1:0]

tph_st_tag[7:0]

parity

Completer Completion (CC) Interface
Table 2-5 defines the ports in the CC interface of the Gen 3 Integrated Block for PCI Express
core. In the Width column, DW denotes the configured data bus width (64, 128, or 256 bits).
Table 2-5:

CC Interface Port Descriptions
Port

s_axis_cc_tdata

s_axis_cc_tuser

s_axis_cc_tlast

Direction

Description

Width

Input

Completer Completion Data bus. Completion data
from the client application to the core. Only the lower
128 bits are to be used when the interface width is 128
bits, and only the lower 64 bits are to be used when the
interface width is 64 bits.

Input

Completer Completion User Data. This set of signals
contain sideband information for the TLP being
transferred. These signals are valid when
s_axis_cc_tvalid is High.
Table 2-6, page 20 describes the individual signals in
this set.

Input

TLAST indication for Completer Completion Data. The
client application must assert this signal in the last
cycle of a packet to indicate the end of the packet.
When the TLP is transferred in a single beat, the client
must set this bit in the first cycle of the transfer.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

18
Product Specification

Port Descriptions

Table 2-5:

CC Interface Port Descriptions (Cont’d)
Port

s_axis_cc_tkeep

s_axis_cc_tvalid

s_axis_cc_tready

Direction

Description

Width

Input

TKEEP indication for Completer Completion Data. The
assertion of bit i of this bus during a transfer indicates
to the core that Dword i of the s_axis_cc_tdata bus
contains valid data. The client must set this bit to 1
contiguously for all Dwords starting from the first
Dword of the descriptor to the last Dword of the
payload. Thus, s_axis_cc_tdata must be set to all
1s in all beats of a packet, except in the final beat when
the total size of the packet is not a multiple of the
width of the data bus (both in Dwords). This is true for
both Dword-aligned and address-aligned modes of
payload transfer.
Bits [7:4] of this bus are not used by the core when the
interface width is configured as 128 bits, and bits [7:2]
are not used when the interface width is configured as
64 bits.

DW/32

Input

Completer Completion Data Valid. The client
application must assert this output whenever it is
driving valid data on the s_axis_cc_tdata bus. The
client must keep the valid signal asserted during the
transfer of a packet. The core paces the data transfer
using the s_axis_cc_tready signal.

Output

Completer Completion Data Ready. Activation of this
signal by the core indicates that it is ready to accept
data. Data is transferred across the interface when both
s_axis_cc_tvalid and s_axis_cc_tready are
asserted in the same cycle.
If the core deasserts the ready signal when the valid
signal is High, the client must maintain the data on the
bus and keep the valid signal asserted until the core
has asserted the ready signal.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

19
Product Specification

Port Descriptions

Table 2-6:

Sideband Signal Descriptions in s_axis_cc_tuser

Bit Index

32:1

Name

discontinue

parity

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

Width

Description

This signal can be asserted by the client
application during a transfer if it has detected an
error (such as an uncorrectable ECC error while
reading the payload from memory) in the data
being transferred and desires to abort the packet.
The core nullifies the corresponding TLP on the
link to avoid data corruption.
The client can assert this signal during any cycle
during the transfer. It can either choose to
terminate the packet prematurely in the cycle
where the error was signaled, or can continue
until all bytes of the payload are delivered to the
core. In the latter case, the core treats the error as
sticky for the following beats of the packet, even
if the client deasserts the discontinue signal
before the end of the packet.
The discontinue signal can be asserted only when
s_axis_cc_tvalid is High. The core samples
this signal only when s_axis_cc_tready is
High. Thus, when asserted, it should not be
deasserted until s_axis_cc_tready is High.
When the core is configured as an Endpoint, this
error is also reported by the core to the Root
Complex to which it is attached, using AER.

Odd parity for the 256-bit data. When parity
checking is enabled in the core, client logic must
set bit i of this bus to the odd parity computed for
byte i of s_axis_cc_tdata. Only the lower 16
bits are to be used when the interface width is 128
bits, and only the lower 8 bits are to be used when
the interface width is 64 bits.
On detection of a parity error, the core nullifies
the corresponding TLP on the link and reports it
as an Uncorrectable Internal Error.
The parity bits can be permanently tied to 0 if
parity check is not enabled in the core.

www.xilinx.com

20
Product Specification

Port Descriptions

Requester reQuest (RQ) Interface
Table 2-7 defines the ports in the RQ interface of the Gen3 Integrated Block for PCI Express
core. In the Width column, DW denotes the configured data bus width (64, 128, or 256 bits).
Table 2-7:

RQ Interface Port Descriptions
Port

s_axis_rq_tdata

s_axis_rq_tuser

s_axis_rq_tlast

s_axis_rq_tkeep

s_axis_rq_tready

Direction

Description

Width

Input

Requester reQuest Data bus. This input contains the
requester-side request data from the client application
to the core. Only the lower 128 bits are to be used
when the interface width is 128 bits, and only the lower
64 bits are to be used when the interface width is 64
bits.

Input

Requester reQuest User Data. This set of signals
contains sideband information for the TLP being
transferred. These signals are valid when
s_axis_rq_tvalid is High.
Table 2-8, page 23 describes the individual signals in
this set.

Input

TLAST Indication for Requester reQuest Data. The
client application must assert this signal in the last
cycle of a TLP to indicate the end of the packet. When
the TLP is transferred in a single beat, the client must
set this bit in the first cycle of the transfer.

Input

TKEEP Indication for Requester reQuest Data. The
assertion of bit i of this bus during a transfer indicates
to the core that Dword i of the s_axis_rq_tdata bus
contains valid data. The client must set this bit to 1
contiguously for all Dwords, starting from the first
Dword of the descriptor to the last Dword of the
payload. Thus, s_axis_rq_tdata must be set to all
1s in all beats of a packet, except in the final beat when
the total size of the packet is not a multiple of the
width of the data bus (both in Dwords). This is true for
both Dword-aligned and address-aligned modes of
payload transfer.
Bits [7:4] of this bus are not used by the core when the
interface width is configured as 128 bits, and bits [7:2]
are not used when the interface width is configured as
64 bits.

DW/32

Output

Requester reQuest Data Ready. Activation of this signal
by the core indicates that it is ready to accept data.
Data is transferred across the interface when both
s_axis_rq_tvalid and s_axis_rq_tready are
asserted in the same cycle.
If the core deasserts the ready signal when the valid
signal is High, the client must maintain the data on the
bus and keep the valid signal asserted until the core
has asserted the ready signal.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

21
Product Specification

Port Descriptions

Table 2-7:

RQ Interface Port Descriptions (Cont’d)
Port

s_axis_rq_tvalid

pcie_rq_seq_num

pcie_rq_seq_num_vld

pcie_rq_tag

pcie_rq_tag_vld

Direction

Description

Width

Input

Requester reQuest Data Valid. The client application
must assert this output whenever it is driving valid data
on the s_axis_rq_tdata bus. The client must keep
the valid signal asserted during the transfer of a
packet. The core paces the data transfer using the
s_axis_rq_tready signal.

Output

Requester reQuest TLP transmit sequence number. The
client can optionally use this output to track the
progress of the request in the core's transmit pipeline.
To use this feature, the client must provide a sequence
number for each request on the
s_axis_rq_seq_num[3:0] bus. The core outputs
this sequence number on the
pcie_rq_seq_num[3:0] output when the request
TLP has reached a point in the pipeline where a
Completion TLP from the client cannot pass it. This
mechanism enables the client to maintain ordering
between Completions sent to the completer
completion interface of the core and Posted requests
sent to the requester request interface. Data on the
pcie_rq_seq_num[3:0] output is valid when
pcie_rq_seq_num_vld is High.

Output

Requester reQuest TLP transmit sequence number
valid. This output is asserted by the core for one cycle
when it has placed valid data on
pcie_rq_seq_num[3:0].

Output

Requester reQuest Non-Posted tag. When tag
management for Non-Posted requests is performed by
the core (AXISTEN_IF_ENABLE_CLIENT_TAG is 0), this
output is used by the core to communicate the
allocated tag for each Non-Posted request received
from the client. The tag value on this bus is valid for
one cycle when pcie_rq_tag_vld is High. The client
must copy this tag and use it to associate the
completion data with the pending request.
There can be a delay of several cycles between the
transfer of the request on the s_axis_rq_tdata bus
and the assertion of pcie_rq_tag_vld by the core to
provide the allocated tag for the request. Meanwhile,
the client can continue to send new requests. The tags
for requests are communicated on this bus in FIFO
order, so the client can easily associate the tag value
with the request it transferred.

Output

Requester reQuest Non-Posted tag valid. The core
asserts this output for one cycle when it has allocated
a tag to an incoming Non-Posted request from the
requester request interface and placed it on the
pcie_rq_tag output.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

22
Product Specification

Port Descriptions

Table 2-8:
Bit Index

3:0

7:4

10:8

Sideband Signal Descriptions in s_axis_rq_tuser
Name

first_be[3:0]

last_be[3:0]

addr_offset[2:0]

discontinue

Width

Description

Byte enables for the first Dword. This field must be set based on
the desired value of the First_BE bits in the Transaction-Layer
header of the request TLP. For Memory Reads, I/O Reads, and
Configuration Reads, these four bits indicate the valid bytes to
be read in the first Dword. For Memory Writes, I/O Writes, and
Configuration Writes, these bits indicate the valid bytes in the
first Dword of the payload.
The core samples this field in the first beat of a packet, when
s_axis_rq_tvalid and s_axis_rq_tready are both High.

Byte enables for the last Dword. This field must be set based on
the desired value of the Last_BE bits in the Transaction-Layer
header of the TLP. For Memory Reads of two Dwords or more,
these four bits indicate the valid bytes to be read in the last
Dword of the block of data. For Memory Writes of two Dwords
or more, these bits indicate the valid bytes in the last Dword of
the payload.
The core samples this field in the first beat of a packet, when
s_axis_rq_tvalid and s_axis_rq_tready are both High.

When the address-aligned mode is in use on this interface, the
client application must provide the byte lane number where the
payload data begins on the data bus, modulo 4, on this sideband
bus. This enables the core to determine the alignment of the
data block being transferred.
The core samples this field in the first beat of a packet, when
s_axis_rq_tvalid and s_axis_rq_tready are both High.
When the requester request interface is configured in the
Dword-alignment mode, this field must always be set to 0.

This signal can be asserted by the client application during a
transfer if it has detected an error in the data being transferred
and desires to abort the packet. The core nullifies the
corresponding TLP on the link to avoid data corruption.
The client can assert this signal in any cycle during the transfer.
It can either choose to terminate the packet prematurely in the
cycle where the error was signaled, or can continue until all
bytes of the payload are delivered to the core. In the latter case,
the core treats the error as sticky for the following beats of the
packet, even if the client deasserts the discontinue signal before
the end of the packet.
The discontinue signal can be asserted only when
s_axis_rq_tvalid is High. The core samples this signal only
when s_axis_rq_tready is High. Thus, when asserted, it
should not be deasserted until s_axis_rq_tready is High.
When the core is configured as an Endpoint, this error is also
reported by the core to the Root Complex to which it is
attached, using Advanced Error Reporting (AER).

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

23
Product Specification

Port Descriptions

Table 2-8:
Bit Index

14:13

23:16

27:24

59:28

Sideband Signal Descriptions in s_axis_rq_tuser (Cont’d)
Name

tph_present

tph_type[1:0]

tph_indirect_tag_en

tph_st_tag[7:0]

seq_num[3:0]

parity

Width

Description

This bit indicates the presence of a Transaction Processing Hint
(TPH) in the request TLP being delivered across the interface.
The core samples this field in the first beat of a packet, when
s_axis_rq_tvalid and s_axis_rq_tready are both High.
This bit must be permanently tied to 0 if the TPH capability is
not in use.

When a TPH is present in the request TLP, these two bits provide
the value of the PH[1:0] field associated with the hint. The core
samples this field in the first beat of a packet, when
s_axis_rq_tvalid and s_axis_rq_tready are both High.
These bits can be set to any value if tph_present is set to 0.

When this bit is set, the core uses the lower bits of
tph_st_tag[7:0] as an index into its Steering Tag Table, and
insert the tag from this location in the transmitted request TLP.
When this bit is 0, the core uses the value on
tph_st_tag[7:0] directly as the Steering Tag.
The core samples this bit in the first beat of a packet, when
s_axis_rq_tvalid and s_axis_rq_tready are both High.
This bit can be set to any value if tph_present is set to 0.

When a TPH is present in the request TLP, this output provides
the 8-bit Steering Tag associated with the hint. The core samples
this field in the first beat of a packet, when
s_axis_rq_tvalid and s_axis_rq_tready are both High.
These bits can be set to any value if tph_present is set to 0.

The client can optionally supply a 4-bit sequence number in this
field to keep track of the progress of the request in the core's
transmit pipeline. The core outputs this sequence number on its
pcie_rq_seq_num[3:0] output when the request TLP has
progressed to a point in the pipeline where a Completion TLP
from the client is not able to pass it.
The core samples this field in the first beat of a packet, when
s_axis_rq_tvalid and s_axis_rq_tready are both High.
This input can be hardwired to 0 when the client is not
monitoring the pcie_rq_seq_num[3:0] output of the core.

Odd parity for the 256-bit data. When parity checking is enabled
in the core, client logic must set bit i of this bus to the odd parity
computed for byte i of s_axis_rq_tdata. Only the lower
16 bits are to be used when the interface width is 128 bits, and
only the lower 8 bits are to be used when the interface width is
64 bits.
On detection of a parity error, the core nullifies the
corresponding TLP on the link and reports it as an Uncorrectable
Internal Error.
These bits can be set to 0 if parity checking is disabled in the
core.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

24
Product Specification

Port Descriptions

Requester Completion (RC) Interface
Table 2-9 defines the ports in the RC interface of the Gen3 Integrated Block for PCI Express
core. In the Width column, DW denotes the configured data bus width (64, 128, or 256 bits).
Table 2-9:

RC Interface Port Descriptions
Port

m_axis_rc_tdata

m_axis_rc_tuser

m_axis_rc_tlast

Direction

Description

Width

Output

Requester Completion Data bus. Transmit data from
the Core requester completion interface to the client
application. Only the lower 128 bits are used when the
interface width is 128 bits, and only the lower 64 bits
are used when the interface width is 64 bits.
Bits [255:128] are set permanently to 0 by the core
when the interface width is configured as 128 bits, and
bits [255:64] are set permanently to 0 when the
interface width is configured as 64 bits.

Output

Requester Completion User Data. This set of signals
contains sideband information for the TLP being
transferred. These signals are valid when
m_axis_rc_tvalid is High.
Table 2-10, page 27 describes the individual signals in
this set.

Output

TLAST indication for Requester Completion Data. The
core asserts this signal in the last beat of a packet to
indicate the end of the packet. When a TLP is
transferred in a single beat, the core sets this bit in the
first beat of the transfer. This output is used only when
the straddle option is disabled. When the straddle
option is enabled (for 256-bit interface), the core sets
this output permanently to 0.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

25
Product Specification

Port Descriptions

Table 2-9:

RC Interface Port Descriptions (Cont’d)
Port

m_axis_rc_tkeep

m_axis_rc_tvalid

m_axis_rc_tready

Direction

Description

Width

Output

TKEEP indication for Requester Completion Data. The
assertion of bit i of this bus during a transfer indicates
to the client that Dword i of the m_axis_rc_tdata
bus contains valid data. The core sets this bit to 1
contiguously for all Dwords starting from the first
Dword of the descriptor to the last Dword of the
payload. Thus, m_axis_cq_tdata is set to all 1s in all
beats of a packet, except in the final beat when the
total size of the packet is not a multiple of the width of
the data bus (both in Dwords). This is true for both
Dword-aligned and address-aligned modes of payload
transfer.
Bits [7:4] of this bus are set permanently to 0 by the
core when the interface width is configured as 128 bits,
and bits [7:2] are set permanently to 0 when the
interface width is configured as 64 bits.
These outputs are permanently set to all 1s when the
interface width is 256 bits and the straddle option is
enabled. The client logic must use the signals in
m_axis_rc_tuser in that case to determine the start
and end of Completion TLPs transferred over the
interface.

DW/32

Output

Requester Completion Data Valid. The core asserts this
output whenever it is driving valid data on the
m_axis_rc_tdata bus. The core keeps the valid
signal asserted during the transfer of a packet. The
client application can pace the data transfer using the
m_axis_rc_tready signal.

Input

Requester Completion Data Ready. Activation of this
signal by the client logic indicates to the core that the
client is ready to accept data. Data is transferred across
the interface when both m_axis_rc_tvalid and
m_axis_rc_tready are asserted in the same cycle.
If the client deasserts the ready signal when the valid
signal is High, the core maintains the data on the bus
and keeps the valid signal asserted until the client has
asserted the ready signal.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

26
Product Specification

Port Descriptions

Table 2-10:
Bit Index

31:0

37:34

Sideband Signal Descriptions in m_axis_rc_tuser
Name

byte_en

is_sof_0

is_sof_1

is_eof_0[3:0]

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

Width

Description

Start of a first Completion TLP. For 64-bit and 128-bit
interfaces, and for the 256-bit interface with no
straddling, is_sof_0 is asserted by the core in the first
beat of a packet to indicate the start of the TLP. On these
interfaces, only a single TLP can be started in a data
beat, and is_sof_1 is permanently set to 0. Use of this
signal is optional for the client when the straddle option
is not enabled.
When the interface width is 256 bits and the straddle
option is enabled, the core can straddle two Completion
TLPs in the same beat. In this case, the Completion TLPs
are not formatted as AXI4-Stream packets. The assertion
of is_sof_0 indicates a Completion TLP starting in the
beat. The first byte of this Completion TLP is in byte lane
0 if the previous TLP ended before this beat, or in byte
lane 16 if the previous TLP continues in this beat.

Start of a second Completion TLP. This signal is used
when the interface width is 256 bits and the straddle
option is enabled, when the core can straddle two
Completion TLPs in the same beat. The output is
permanently set to 0 in all other cases.
The assertion of is_sof_1 indicates a second
Completion TLP starting in the beat, with its first bye in
byte lane 16. The core starts a second TLP at byte
position 16 only if the previous TLP ended in one of the
byte positions 0-15 in the same beat; that is, only if
is_eof_0[0] is also set in the same beat.

End of a first Completion TLP and the offset of its last
Dword. These outputs are used only when the interface
width is 256 bits and the straddle option is enabled.
The assertion of the bit is_eof_0[0] indicates the end
of a first Completion TLP in the current beat. When this
bit is set, the bits is_eof_0[3:1] provide the offset of
the last Dword of this TLP.

www.xilinx.com

27
Product Specification

Port Descriptions

Table 2-10:
Bit Index

41:38

74:43

Sideband Signal Descriptions in m_axis_rc_tuser (Cont’d)
Name

is_eof_1[3:0]

discontinue

parity

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

Width

Description

End of a second Completion TLP and the offset of its last
Dword. These outputs are used only when the interface
width is 256 bits and the straddle option is enabled. The
core can then straddle two Completion TLPs in the same
beat. These outputs are reserved in all other cases.
The assertion of is_eof_1[0] indicates a second TLP
ending in the same beat. When bit 0 of is_eof_1 is set,
bits [3:1] provide the offset of the last Dword of the TLP
ending in this beat. Because the second TLP can only
end at a byte position in the range 27–31,
is_eof_1[3:1] can only take one of two values (6 or
7).
The offset for the last byte of the second TLP can be
determined from the starting address and length of the
TLP, or from the byte enable signals byte_en[31:0].
If is_eof_1[0] is High, the signals is_eof_0[0] and
is_sof_1 are also High in the same beat.

This signal is asserted by the core in the last beat of a
TLP, if it has detected an uncorrectable error while
reading the TLP payload from its internal FIFO memory.
The client application must discard the entire TLP when
such an error is signaled by the core.
This signal is never asserted when the TLP has no
payload. It is asserted only in the last beat of the payload
transfer; that is, when is_eof_0[0] is High.
When the straddle option is enabled, the core does not
start a second TLP if it has asserted discontinue in a
beat.
When the core is configured as an Endpoint, the error is
also reported by the core to the Root Complex to which
it is attached, using Advanced Error Reporting (AER).

Odd parity for the 256-bit transmit data. Bit i provides
the odd parity computed for byte i of
m_axis_rc_tdata. Only the lower 16 bits are used
when the interface width is 128 bits, and only the lower
8 bits are used when the interface width is 64 bits. Bits
[31:16] are set permanently to 0 by the core when the
interface width is configured as 128 bits, and bits [31:8]
are set permanently to 0 when the interface width is
configured as 64 bits.

www.xilinx.com

28
Product Specification

Port Descriptions

Transmit Flow Control Interface
Table 2-11 defines the ports in the Transmit Flow Control interface of the Integrated Block
for PCI Express core.
Table 2-11:

Transmit Flow Control Interface Port Descriptions
Port

pcie_tfc_nph_av

pcie_tfc_npd_av

Direction

Description

Width

Output

Transmit flow control Non-Posted header credits
available. This output indicates the currently available
header credit for Non-Posted TLPs on the transmit side
of the core. Client logic can check this output before
transmitting a Non-Posted request on the requester
request interface, to avoid blocking the interface when
no credit is available. The encodings are:
• 00: No credits available
• 01: 1 credit available
• 10: 2 credits available
• 11: 3 or more credits available
Because of pipeline delays, the value on this output
does not include the credit consumed by the
Non-Posted requests sent by the client in the last two
clock cycles. The client logic must adjust the value on
this output by the credit consumed by the Non-Posted
requests it sent in the previous two clock cycles, if any.

Output

Transmit flow control Non-Posted data credits
available. This output indicates the currently available
payload credit for Non-Posted TLPs on the transmit
side of the core. Client logic can check this output
before transmitting a Non-Posted request on the
requester request interface, to avoid blocking the
interface when no credit is available. The encodings
are:
• 00: No credits available
• 01: 1 credit available
• 10: 2 credits available
• 11: 3 or more credits available
Because of pipeline delays, the value on this output
does not include the credit consumed by the
Non-Posted requests sent by the client in the last two
clock cycles. The client logic must adjust the value on
this output by the credit consumed by the Non-Posted
requests it sent in the previous two clock cycles, if any.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

29
Product Specification

Port Descriptions

Configuration Management Interface
Table 2-12 defines the ports in the Configuration Management interface of the Integrated
Block for PCI Express core.
Table 2-12:

Configuration Management Interface Port Descriptions
Port

Direction

cfg_mgmt_addr

Input

Read/Write Address. Address into the Configuration
and Management register space. Address is Dword
aligned.

cfg_mgmt_write

Input

Write Enable. Asserted for a write operation. Active
High.

cfg_mgmt_write_data

Input

Write data. Write data is used to configure the
Configuration and Management registers.

cfg_mgmt_byte_enable

Input

Byte Enable. Byte enable for write data, where
cfg_mgmt_byte_enable[0] corresponds to
cfg_mgmt_write_data[7:0], and so on.

cfg_mgmt_read

Input

Read Enable. Asserted for a read operation. Active
High.

cfg_mgmt_read_data

Output

Read data out. Read data provides the configuration of
the Configuration and Management registers.

cfg_mgmt_read_write_done

Output

Read/Write operation complete. Asserted for 1 cycle
when operation is complete. Active High.

Type 1 RO, Write. When the core is configured in the
Root Port mode, asserting this input during a write to
a Type-1 PCI™ Config Register forces a write into
certain read-only fields of the register (see description
of RC-mode Config registers). This input has no effect
when the core is in the Endpoint mode, or when writing
to any register other than a Type-1 Config Register.

cfg_mgmt_type1_cfg_reg_access

Input

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

Description

www.xilinx.com

Width

30
Product Specification

Port Descriptions

Configuration Status Interface
Table 2-13 defines the ports in the Configuration Status interface of the Integrated Block
for PCI Express core.
Table 2-13:

Configuration Status Interface Port Descriptions
Port

cfg_phy_link_down

cfg_phy_link_status

cfg_negotiated_width

cfg_current_speed

cfg_max_payload

Direction

Description

Width

Output

Configuration Link Down. Status of the PCI Express link
based on Physical Layer LTSSM.
• 1b: Link is Down (LinkUp state variable is 0b)
• 0b: Link is Up (LinkUp state variable is 1b)
Note: Per the PCI Express Base Specification, rev. 3.0,
LinkUp is 1b in the Recovery, L0, L0s, L1, and L2
cfg_ltssm states. In the Configuration state, LinkUp can
be 0b or 1b. It is always 0b when the Configuration
state is reached via Detect > Polling > Configuration.
LinkUp is 1b if the configuration state is reached via
any other state transition.

Output

Configuration Link Status. Status of the PCI Express
link.
• 00b: No receivers detected
• 01b: Link training in progress
• 10b: Link up, DL initialization in progress
• 11b: Link up, DL initialization completed

Output

Configuration Link Status. Negotiated Link Width: PCI
Express Link Status Register, Negotiated Link Width
field. This field indicates the negotiated width of the
given PCI Express Link and is valid when
cfg_phy_link_status[1:0] == 11b (DL
Initialization is complete).

Output

Current Link Speed. This signal outputs the current link
speed from Link Status register bits 1 down to 0. This
field indicates the negotiated Link speed of the given
PCI Express Link.
• 001b: 2.5 GT/s PCI Express Link
• 010b: 5.0 GT/s PCI Express Link
• 100b: 8.0 GT/s PCI Express Link

Output

Max_Payload_Size. This signal outputs the maximum
payload size from Device Control Register bits 7 down
to 5. This field sets the maximum TLP payload size. As
a Receiver, the user logic must handle TLPs as large as
the set value. As a Transmitter, the user logic must not
generate TLPs exceeding the set value.
• 000b: 128 bytes maximum payload size
• 001b: 256 bytes maximum payload size
• 010b: 512 bytes maximum payload size
• 011b: 1024 bytes maximum payload size
• 100b: 2048 bytes maximum payload size
• 101b: 4096 bytes maximum payload size

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

31
Product Specification

Port Descriptions

Table 2-13:

Configuration Status Interface Port Descriptions (Cont’d)
Port

cfg_max_read_req

cfg_function_status

cfg_vf_status

cfg_function_power_state

Direction

Description

Width

Output

Max_Read_Request_Size. This signal outputs the
maximum read request size from Device Control
register bits 14 down to 12. This field sets the
maximum Read Request size for the user logic as a
Requester. The user logic must not generate Read
Requests with size exceeding the set value.
• 000b: 128 bytes maximum Read Request size
• 001b: 256 bytes maximum Read Request size
• 010b: 512 bytes maximum Read Request size
• 011b: 1024 bytes maximum Read Request size
• 100b: 2048 bytes maximum Read Request size
• 101b: 4096 bytes maximum Read Request size

Output

Configuration Function Status. These outputs indicate
the states of the Command Register bits in the PCI
configuration space of each Function. These outputs
are used to enable requests and completions from the
host logic. The assignment of bits is as follows:
• Bit 0: Function 0 I/O Space Enable
• Bit 1: Function 0 Memory Space Enable
• Bit 2: Function 0 Bus Master Enable
• Bit 3: Function 0 INTx Disable
• Bit 4: Function 1 I/O Space Enable
• Bit 5: Function 1 Memory Space Enable
• Bit 6: Function 1 Bus Master Enable
• Bit 7: Function 1 INTx Disable

Output

Configuration Virtual Function Status. These outputs
indicate the status of Virtual Functions, two bits each
per Virtual Function.
• Bit 0: Virtual Function 0: Configured/Enabled by
software
• Bit 1: Virtual Function 0: PCI Command Register, Bus
Master Enable, and so on.

Output

Configuration Function Power State. These outputs
indicate the current power state of the Physical
Functions. Bits [2:0] capture the power state of
Function 0, and bits [5:3] capture that of Function 1.
The possible power states are:
• 000: D0_uninitialized
• 001: D0_active
• 010: D1
• 100: D3_hot

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

32
Product Specification

Port Descriptions

Table 2-13:

Configuration Status Interface Port Descriptions (Cont’d)
Port

cfg_vf_power_state

cfg_link_power_state

cfg_err_cor_out

cfg_err_nonfatal_out

cfg_err_fatal_out

Direction

Description

Width

Output

Configuration Virtual Function Power State. These
outputs indicate the current power state of the Virtual
Functions. Bits [2:0] capture the power state of Virtual
Function 0, and bits [5:3] capture that of Virtual
Function 1, and so on. The possible power states are:
• 000: D0_uninitialized
• 001: D0_active
• 010: D1
• 100: D3_hot

Output

Current power state of the PCI Express link:
• 00: L0
• 01: L0s
• 10: L1
• 11: L2/Reserved

Output

Correctable Error Detected. In the Endpoint mode, the
core activates this output for one cycle when it has
detected a correctable error and its reporting is not
masked. In a multi-Function Endpoint, this is the logical
OR of the correctable error status bits in the Device
Status Registers of all Functions. In the Root Port mode,
this output is activated on detection of a local
correctable error, when its reporting is not masked.
This output does not respond to any errors signaled by
remote devices using PCI Express error messages.
These error messages are delivered to the user through
the message interface.

Output

Non-Fatal Error Detected. In the Endpoint mode, the
core activates this output for one cycle when it has
detected a non fatal error and its reporting is not
masked. In a multi-Function Endpoint, this is the logical
OR of the non fatal error status bits in the Device Status
Registers of all Functions. In the Root Port mode, this
output is activated on detection of a local non-fatal
error, when its reporting is not masked. This output
does not respond to any errors signaled by remote
devices using PCI Express error messages. These error
messages are delivered to the user through the
message interface.

Output

Fatal Error Detected. In the Endpoint mode, the core
activates this output for one cycle when it has detected
a fatal error and its reporting is not masked. In a
multi-Function Endpoint, this is the logical OR of the
fatal error status bits in the Device Status Registers of
all Functions. In the Root Port mode, this output is
activated on detection of a local fatal error, when its
reporting is not masked. This output does not respond
to any errors signaled by remote devices using PCI
Express error messages. These error messages are
delivered to the user through the message interface.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

33
Product Specification

Port Descriptions

Table 2-13:

Configuration Status Interface Port Descriptions (Cont’d)
Port

cfg_local_error

cfg_ltr_enable

cfg_ltssm_state

Direction

Description

Width

Output

Local Error Conditions. Output is High when any of the
local error conditions listed in Local Error Status
Register occur. Each of the conditions can be
selectively masked by setting the corresponding bits in
the Local Interrupt Mask Register.

Output

Latency Tolerance Reporting Enable. The state of this
output reflects the setting of the LTR Mechanism
Enable bit in the Device Control 2 Register of Physical
Function 0. When the core is configured as an Endpoint
user logic uses this output to enable the generation of
LTR messages. This output is not to be used when the
core is configured as a Root Port.

Output

Current LTSSM State. Shows the current LTSSM state:
Detect.Quiet 00
Detect.Active 01
Polling.Active 02
Polling.Compliance 03
Polling.Configuration 04
Configuration.Linkwidth.Start 05
Configuration.Linkwidth.Accept 06
Configuration.Lanenum.Accept 07
Configuration.Lanenum.Wait 08
Configuration.Complete 09
Configuration.Idle 0A
Recovery.RcvrLock 0B
Recovery.Speed 0C
Recovery.RcvrCfg 0D
Recovery.Idle 0E
L0 10
Rx_L0s.Entry 11
Rx_L0s.Idle 12
Rx_L0s.FTS 13
Tx_L0s.Entry 14
Tx_L0s.Idle 15
Tx_L0s.FTS 16
L1.Entry 17
L1.Idle 18
L2.Idle 19
L2.TransmitWake 1A

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

34
Product Specification

Port Descriptions

Table 2-13:

Configuration Status Interface Port Descriptions (Cont’d)
Port

cfg_rcb_status

cfg_dpa_substate_change

cfg_obff_enable

Direction

Description

Width

Output

RCB Status. Provides the setting of the Read
Completion Boundary (RCB) bit in the Link Control
Register of each Physical Function. In the Endpoint
mode, bit 0 indicates the RCB for PF 0, and so on. In the
RC mode, bit 0 indicates the RCB setting of the Link
Control Register of the RP, bit 1 is reserved.
For each bit, a value of 0 indicates an RCB of 64 bytes
and a value of 1 indicates 128 bytes.

Output

Dynamic Power Allocation Substate Change. In the
Endpoint mode, the core generates a one-cycle pulse
on one of these outputs when a Configuration Write
transaction writes into the Dynamic Power Allocation
Control Register to modify the DPA power state of the
device. A pulse on bit 0 indicates such a DPA event for
PF 0 and so on. These outputs are not active in the
Root Port mode.

Output

Optimized Buffer Flush Fill Enable. This output reflects
the setting of the OBFF Enable field in the Device
Control 2 Register.
• 00: OBFF disabled
• 01: OBFF enabled using message signaling, Variation
A
• 10: OBFF enabled using message signaling, Variation
B
• 11: OBFF enabled using WAKE# signaling.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

35
Product Specification

Port Descriptions

Table 2-13:

Configuration Status Interface Port Descriptions (Cont’d)
Port

cfg_pl_status_change

cfg_tph_requester_enable

cfg_tph_st_mode

cfg_vf_tph_requester_enable

cfg_vf_tph_st_mode

Direction

Description

Width

Output

This output is used by the core in the Root Port mode
to signal one of the following link training-related
events:
(a) The link bandwidth changed as a result of the
change in the link width or operating speed and the
change was initiated locally (not by the link partner),
without the link going down. This interrupt is enabled
by the Link Bandwidth Management Interrupt Enable
bit in the Link Control Register. The status of this
interrupt can be read from the Link Bandwidth
Management Status bit of the Link Status Register; or
(b) The link bandwidth changed autonomously as a
result of the change in the link width or operating
speed and the change was initiated by the remote
node. This interrupt is enabled by the Link
Autonomous Bandwidth Interrupt Enable bit in the Link
Control Register. The status of this interrupt can be
read from the Link Autonomous Bandwidth Status bit
of the Link Status Register; or
(c) The Link Equalization Request bit in the Link Status
2 Register was set by the hardware because it received
a link equalization request from the remote node. This
interrupt is enabled by the Link Equalization Interrupt
Enable bit in the Link Control 3 Register. The status of
this interrupt can be read from the Link Equalization
Request bit of the Link Status 2 Register.
The pl_interrupt output is not active when the core
is configured as an Endpoint.

Output

Bit 0 of this output reflect the setting of the TPH
Requester Enable bit [8] of the TPH Requester Control
Register in the TPH Requester Capability Structure of
Physical Function 0. Bit 1 corresponds to Physical
Function 1.

Output

Bits [2:0] of this output reflect the setting of the ST
Mode Select bits in the TPH Requester Control Register
of Physical Function 0. Bits [5:3] reflect the setting of
the same register field of PF 1.

Output

Each of the six bits of this output reflects the setting of
the TPH Requester Enable bit 8 of the TPH Requester
Control Register in the TPH Requester Capability
Structure of the corresponding Virtual Function.

Output

Bits [2:0] of this output reflect the setting of the ST
Mode Select bits in the TPH Requester Control Register
of Virtual Function 0. Bits [5:3] reflect the setting of the
same register field of VF 1, and so on.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

36
Product Specification

Port Descriptions

Configuration Received Message Interface
Table 2-14 defines the ports in the Configuration Received Message interface of the
Integrated Block for PCI Express core.
Table 2-14:

Configuration Received Message Interface Port Descriptions
Port

cfg_msg_received

cfg_msg_received_data

cfg_msg_received_type

Direction

Description

Width

Output

Configuration Received a Decodable Message. The
core asserts this output for one or more consecutive
clock cycles when it has received a decodable message
from the link. The duration of its assertion is
determined by the type of message. The core transfers
any parameters associated with the message on the
cfg_msg_data[7:0]output in one or more cycles
when cfg_msg_received is High. Table 4-8,
page 136 lists the number of cycles of
cfg_msg_received assertion, and the parameters
transferred on cfg_msg_data[7:0] in each cycle, for
each type of message.
The core inserts at least a one-cycle gap between two
consecutive messages delivered on this interface.
This output is active only when the
AXISTEN_IF_ENABLE_RX_MSG_INTFC attribute is set.

Output

This bus is used to transfer any parameters associated
with the Received Message. The information it carries
in each cycle for various message types is listed in
Table 4-8, page 136.

Output

Received message type. When cfg_msg_received is
High, these five bits indicate the type of message
being signaled by the core. The various message types
are listed in Table 4-7, page 135.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

37
Product Specification

Port Descriptions

Configuration Transmit Message Interface
Table 2-15 defines the ports in the Configuration Transmit Message interface of the
Integrated Block for PCI Express core.
Table 2-15:

Configuration Transmit Message Interface Port Descriptions
Port

Direction

Description

Width

Input

Configuration Transmit Encoded Message. This signal
is asserted together with cfg_msg_transmit_type,
which supplies the encoded message type and
cfg_msg_transmit_data, which supplies optional
data associated with the message, until
cfg_msg_transmit_done is asserted in response.

Input

Configuration Transmit Encoded Message Type.
Indicates the type of PCI Express message to be
transmitted. Encodings supported are:
• 000b: Latency Tolerance Reporting (LTR)
• 001b: Optimized Buffer Flush/Fill (OBFF)
• 010b: Set Slot Power Limit (SSPL)
• 011b: Power Management (PM PME)
• 100b -111b: Reserved

cfg_msg_transmit_data

Input

Configuration Transmit Encoded Message Data.
Indicates message data associated with particular
message type.
• 000b: LTR - cfg_msg_transmit_data[31] <
Snoop Latency Req.,
cfg_msg_transmit_data[28:26] < Snoop
Latency Scale, cfg_msg_transmit_data[25:16]
< Snoop Latency Value,
cfg_msg_transmit_data[15] < No-Snoop
Latency Requirement,
cfg_msg_transmit_data[12:10] < No-Snoop
Latency Scale, cfg_msg_transmit_data[9:0] <
No-Snoop Latency Value.
• 001b: OBFF - cfg_msg_transmit_data[3:0] <
OBFF Code.
• 010b: SSPL - cfg_msg_transmit_data[9:0] <
{Slot Power Limit Scale, Slot Power Limit Value}.
• 011b: PM_PME - cfg_msg_transmit_data[1:0]
< PF1, PF0; cfg_msg_transmit_data[9:4] <
VF5, VF4, VF3, VF2, VF1, VF0, where one or more PFs
or VFs can signal PM_PME simultaneously.
• 100b - 111b: Reserved

cfg_msg_transmit_done

Output

Configuration Transmit Encoded Message Done.
Asserted in response to cfg_mg_transmit assertion,
for 1 cycle after the request is complete.

cfg_msg_transmit

cfg_msg_transmit_type

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

38
Product Specification

Port Descriptions

Configuration Flow Control Interface
Table 2-16 defines the ports in the Configuration Flow Control interface of the Integrated
Block for PCI Express core.
Table 2-16:

Configuration Flow Control Interface Port Descriptions
Port

cfg_fc_ph

cfg_fc_pd

cfg_fc_nph

cfg_fc_npd

cfg_fc_cplh

cfg_fc_cpld

Direction

Description

Width

Output

Posted Header Flow Control Credits. This output
provides the number of Posted Header Flow Control
Credits. This multiplexed output can be used to bring
out various flow control parameters and variables
related to Posted Header Credit maintained by the
core. The flow control information to bring out on this
core is selected by the cfg_fc_sel[2:0] input.

Output

Posted Data Flow Control Credits. This output provides
the number of Posted Data Flow Control Credits. This
multiplexed output can be used to bring out various
flow control parameters and variables related to
Posted Data Credit maintained by the core. The flow
control information to bring out on this core is
selected by the cfg_fc_sel[2:0] input.

Output

Non-Posted Header Flow Control Credits. This output
provides the number of Non-Posted Header Flow
Control Credits. This multiplexed output can be used to
bring out various flow control parameters and
variables related to Non-Posted Header Credit
maintained by the core. The flow control information
to bring out on this core is selected by the
cfg_fc_sel[2:0] input.

Output

Non-Posted Data Flow Control Credits. This output
provides the number of Non-Posted Data Flow Control
Credits. This multiplexed output can be used to bring
out various flow control parameters and variables
related to Non-Posted Data Credit maintained by the
core. The flow control information to bring out on this
core is selected by the cfg_fc_sel[2:0] input.

Output

Completion Header Flow Control Credits. This output
provides the number of Completion Header Flow
Control Credits. This multiplexed output can be used to
bring out various flow control parameters and
variables related to Completion Header Credit
maintained by the core. The flow control information
to bring out on this core is selected by the
cfg_fc_sel[2:0] input.

Output

Completion Data Flow Control Credits. This output
provides the number of Completion Data Flow Control
Credits. This multiplexed output can be used to bring
out various flow control parameters and variables
related to Completion Data Credit maintained by the
core. The flow control information to bring out on this
core is selected by the cfg_fc_sel[2:0].

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

39
Product Specification

Port Descriptions

Table 2-16:

Configuration Flow Control Interface Port Descriptions (Cont’d)
Port

cfg_fc_sel

Direction

Description

Width

Input

Flow Control Informational Select. These inputs select
the type of flow control to bring out on the cfg_fc_*
outputs of the core. The various flow control
parameters and variables that can be accessed for the
different settings of these inputs are:
• 000: Receive credits currently available to the link
partner
• 001: Receive credit limit
• 010: Receive credits consumed
• 011: Available space in receive buffer
• 100: Transmit credits available
• 101: Transmit credit limit
• 110: Transmit credits consumed
• 111: Reserved
Note: Infinite credit for transmit credits available
(cfg_fc_sel == 3'b100) is signaled as 8'h80, 12'h800
for header and data credits, respectively. For all other
cfg_fc_sel selections, infinite credit is signaled as
8'h00, 12'h000, respectively, for header and data
categories.

Per Function Status Interface
Table 2-17 defines the ports in the Per Function Status interface of the Integrated Block for
PCI Express core.
Table 2-17:

Per Function Status Interface Port Descriptions
Port

cfg_per_func_status_control

cfg_per_func_status_data

Direction

Input

Output

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

Description

Width

Configuration Per Function Control. Controls
information presented on the multi-function output
cfg_per_func_status_data. Supported
encodings are 000b, 001b, 010b, 011b, 100b, and
101b. All other encodings are reserved.

Configuration Per Function Status Data. Provides a
16-bit status output for the selected function.
Information presented depends on the values of
cfg_per_func_status_data and
cfg_per_function_number.

www.xilinx.com

40
Product Specification

Port Descriptions

Configuration Control Interface
Table 2-18 defines the ports in the Configuration Control interface of the Integrated Block
for PCI Express core.
Table 2-18:

Configuration Control Interface Port Descriptions
Port

Direction

cfg_hot_reset_in

Input

cfg_hot_reset_out

cfg_config_space_enable

cfg_per_function_update_done

cfg_per_function_number

cfg_per_function_output_request

cfg_dsn

Description

Width

Configuration Hot Reset In. In RP mode, assertion
transitions LTSSM to hot reset state, active High.

Output

Configuration Hot Reset Out. In EP mode, assertion
indicates that EP has transitioned to the hot reset state,
active High.

Input

Configuration Configuration Space Enable. When this
input is set to 0 in the Endpoint mode, the core
generates a CRS Completion in response to
Configuration Requests. This port should be held
deasserted when the core configuration registers are
loaded from the DRP due to a change in attributes. This
prevents the core from responding to Configuration
Requests before all the registers are loaded. This input
can be High when the power-on default values of the
Configuration Registers do not need to be modified
before Configuration space enumeration. This input is
not applicable for Root Port mode.

Output

Configuration per Function Update Complete.
Asserted in response to
cfg_per_function_output_request assertion,
for one cycle after the request is complete.

Input

Configuration Per Function Target Function Number.
The user provides the function number (0-7), where
value 0–1 corresponds to PF0–1, and value 2–7
corresponds to VF0–5, and asserts
cfg_per_function_output_request to obtain
per function output values for the selected function.

Input

Configuration Per Function Output Request. When this
port is asserted with a function number value on
cfg_per_function_number, the core presents
information on per-function configuration output pins
and asserts cfg_update_done when complete.

Input

Configuration Device Serial Number. Indicates the
value that should be transferred to the Device Serial
Number Capability on PF0. Bits [31:0] are transferred to
the first (Lower) Dword (byte offset 0x4h of the
Capability), and bits [63:32] are transferred to the
second (Upper) Dword (byte offset 0x8h of the
Capability). If this value is not statically assigned, the
user must pulse user_cfg_input_update after it is
stable.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

41
Product Specification

Port Descriptions

Table 2-18:

Configuration Control Interface Port Descriptions (Cont’d)
Port

cfg_ds_bus_number

cfg_ds_device_number

cfg_ds_function_number

cfg_power_state_change_ack

Direction

Description

Width

Input

Configuration Downstream Bus Number.
• Downstream Port
Provides the bus number portion of the Requester
ID (RID) of the Downstream Port. This is used in TLPs
generated inside the core, such as UR Completions
and Power-management messages; it does not affect
TLPs presented on the TRN interface.
• Upstream Port
No role.

Input

Configuration Downstream Device Number:
• Downstream Port
Provides the device number portion of the RID of
the Downstream Port. This is used in TLPs generated
inside the core, such as UR Completions and
Power-management messages; it does not affect
TLPs presented on the TRN interface.
• Upstream Port
No role.

Input

Configuration Downstream Function Number.
• Downstream Port
Provides the function number portion of the RID of
the Downstream Port. This is used in TLPs generated
inside the core, such as UR Completions and
Power-management messages; it does not affect
TLPs presented on the TRN interface.
• Upstream Port
No role.

Input

Configuration Power State Ack. The user must assert
this input to the core for one cycle in response to the
assertion of cfg_power_state_change_interrupt,
when it is ready to transition to the low-power state
requested by the configuration write request. The
client can permanently hold this input High if it does
not need to delay the return of the completions for the
configuration write transactions, causing power-state
changes.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

42
Product Specification

Port Descriptions

Table 2-18:

Configuration Control Interface Port Descriptions (Cont’d)
Port

cfg_power_state_change_interrupt

cfg_err_cor_in

cfg_err_uncor_in

cfg_flr_done

Direction

Description

Width

Output

Power State Change Interrupt. The core asserts this
output when the power state of a Physical or Virtual
Function is being changed to the D1 or D3 states by a
write into its Power Management Control Register. The
core holds this output High until the user asserts the
cfg_power_state_change_ack input to the core.
While cfg_power_state_change_interrupt
remains High, the core does not return completions for
any pending configuration read or write transaction
received by the core. The purpose is to delay the
completion for the configuration write transaction that
caused the state change until the user is ready to
transition to the low-power state. When
cfg_power_state_change_interrupt is
asserted, the Function number associated with the
configuration write transaction is provided on the
cfg_snp_function_number[7:0] output. When
the client asserts cfg_power_state_change_ack,
the new state of the Function that underwent the state
change is reflected on
cfg_function_power_state (for PFs) or the
cfg_vf_power_state (for VFs) outputs of the core.

Input

Correctable Error Detected: The user can activate this
input for one cycle to indicate a correctable error
detected within the user logic that needs to be
reported as an internal error through the PCI Express
Advanced Error Reporting mechanism. In response, the
core sets the Corrected Internal Error Status bit in the
AER Correctable Error Status Register of all enabled
Functions, and also sends an error message if enabled
to do so. This error is not considered Function-specific.

Input

Uncorrectable Error Detected. The user can activate
this input for one cycle to indicate a uncorrectable
error detected within the user logic that needs to be
reported as an internal error through the PCI Express
Advanced Error Reporting mechanism. In response, the
core sets the uncorrected Internal Error Status bit in the
AER Uncorrectable Error Status Register of all enabled
Functions, and also sends an error message if enabled
to do so. This error is not considered Function-specific.

Input

Function Level Reset Complete. The user must assert
bit i of this bus when the reset operation of Function i
completes. This causes the core to deassert
cfg_flr_in_process for Function i and to
re-enable configuration accesses to the Function.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

43
Product Specification

Port Descriptions

Table 2-18:

Configuration Control Interface Port Descriptions (Cont’d)
Port

cfg_vf_flr_done

cfg_flr_in_process

cfg_vf_flr_in_process

cfg_req_pm_transition_l23_ready

cfg_link_training_enable

Direction

Description

Width

Input

Function Level Reset for virtual Function is Complete.
The user must assert bit i of this bus the reset
operation of Virtual Function i completes. This causes
the core to deassert cfg_vf_flr_in_process for
Function i and to re-enable configuration accesses to
the Virtual Function.

Output

Function Level Reset In Process. The core asserts bit i
of this bus when the host initiates a reset of Function i
through its FLR bit in the configuration space. The core
continues to hold the output High until the user sets
the corresponding cfg_flr_done input for the
corresponding Function to indicate the completion of
the reset operation.

Output

Function Level Reset In Process for Virtual Function.
The core asserts bit i of this bus when the host initiates
a reset of Virtual Function i though its FLR bit in the
configuration space. The core continues to hold the
output High until the user sets the corresponding
cfg_vf_flr_done input for the corresponding
Function to indicate the completion of the reset
operation.

Input

When the core is configured as an Endpoint, the user
can assert this input to transition the power
management state of the core to L23_READY (see
Chapter 5 of the PCI Express Specification for a detailed
description of power management). This is done after
the PCI Functions in the core are placed in the D3 state
and after the client acknowledges the PME_Turn_Off
message from the Root Complex. Asserting this input
causes the link to transition to the L2 state, and
requires a hard reset to resume operation. This input
can be hardwired to 0 if the link is not required to
transition to L2. This input is not used in Root Complex
mode.

Input

This input must be set to 1 to enable the Link Training
Status State Machine (LTSSM) to bring up the link.
Setting it to 0 forces the LTSSM to stay in the
Detect.Quiet state.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

44
Product Specification

Port Descriptions

Configuration Interrupt Controller Interface
Table 2-19 defines the ports in the Configuration Interrupt Controller interface of the
Integrated Block for PCI Express core.
Table 2-19:

Configuration Interrupt Controller Interface Port Descriptions
Port

Direction

Description

Width

Input

Configuration INTx Vector. When the core is configured
as EP, these four inputs are used by the client
application to signal an interrupt from any of its PCI
Functions to the RC using the Legacy PCI Express
Interrupt Delivery mechanism of PCI Express. These
four inputs correspond to INTA, INTB, INTC, and INTD.
Asserting one of these signals causes the core to send
out an Assert_INTx message, and deasserting the
signal causes the core to transmit a Deassert_INTx
message.

Output

Configuration INTx Sent. A pulse on this output
indicates that the core has sent an INTx Assert or
Deassert message in response to a change in the state
of one of the cfg_interrupt_int inputs.

cfg_interrupt_pending

Input

Configuration INTx Interrupt Pending (active High). Per
Function indication of a pending interrupt.
cfg_interrupt_pending[0] corresponds to
Function #0.

cfg_interrupt_msi_enable

Output

Configuration Interrupt MSI Function Enabled.
Indicates that Message Signaling Interrupt (MSI)
messaging is enabled per Function.

cfg_interrupt_msi_vf_enable

Output

Configuration Interrupt MSI on VF Enabled. Indicates
that MSI messaging is enabled, per Virtual Function.

Input

Configuration Interrupt MSI Vector. When the core is
configured in the Endpoint mode to support MSI
interrupts, these inputs are used to signal the 32
distinct interrupt conditions associated with a PCI
Function (Physical or Virtual) from the user logic to the
core. The Function number must be specified on the
cfg_interrupt_function_number input. After
placing the Function number on the input
cfg_interrupt_function_number, the user logic
must activate one of these signals for one cycle to
transmit an interrupt. The user logic must not activate
more than one of the 32 interrupt inputs in the same
cycle. The core internally registers the interrupt
condition on the 0-to-1 transition of any bit in
cfg_interrupt_msi_int. After asserting an
interrupt, the user logic must wait for the
cfg_interrupt_msi_sent or
cfg_interrupt_msi_fail indication from the core
before asserting a new interrupt.

cfg_interrupt_int

cfg_interrupt_sent

cfg_interrupt_msi_int

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

45
Product Specification

Port Descriptions

Table 2-19:

Configuration Interrupt Controller Interface Port Descriptions (Cont’d)
Port

Direction

Description

Width

Output

Configuration Interrupt MSI Interrupt Sent. The core
generates a one-cycle pulse on this output to signal
that an MSI interrupt message has been transmitted on
the link. The user logic must wait for this pulse before
signaling another interrupt condition to the core.

Output

Configuration Interrupt MSI Interrupt Operation
Failed. A one-cycle pulse on this output indicates that
an MSI-X interrupt message was aborted before
transmission on the link. The client must retransmit the
MSI interrupt in this case.

Output

Configuration Interrupt MSI Function Multiple
Message Enable. When the core is configured in the
Endpoint mode to support MSI interrupts, these
outputs are driven by the “Multiple Message Enable”
bits of the MSI Control Registers associated with
Physical Functions. These bits encode the number of
allocated MSI interrupt vectors for the corresponding
Function. Bits [2:0] correspond to Physical Function 0.

cfg_interrupt_msi_pending_status

Input

Configuration Interrupt MSI Pending Status. These
inputs provide the status of the MSI pending interrupts
for the Physical Functions. The setting of these pins
determines the value read from the MSI Pending Bits
Register of the corresponding PF. Bits [31:0] belong to
PF 0, bits [63:32] to PF 1.

cfg_interrupt_msi_mask_update

Output

Configuration Interrupt MSI Function Mask Updated.
Asserted for one cycle when any enabled functions in
the MSI Mask Register change value.

cfg_interrupt_msi_select

Input

Configuration Interrupt MSI Select. Values
0000b-0001b correspond to PF0-1 selection, and
values 0010b-0111b correspond to VF0-5 selection.
cfg_interrupt_msi_data[31:0] presents the
value of the MSI Mask register from the selected
function. When this input is driven to 1111b,
cfg_interrupt_msi_data[17:0] presents the
“Multiple Message Enable” bits of the MSI Control
Registers associated with all Virtual Functions. These
bits encode the number of allocated MSI interrupt
vectors for the corresponding Function.
cfg_interrupt_msi_data[2:0] correspond to
Virtual Function 0, and so on.

cfg_interrupt_msi_data

Output

Configuration Interrupt MSI Data. The value presented
depends on cfg_interrupt_msi_select.

cfg_interrupt_msix_enable

Output

Configuration Interrupt MSI-X Function Enabled. When
asserted, indicates that the Message Signaling
Interrupt (MSI-X) messaging is enabled, per Function.

cfg_interrupt_msix_mask

Output

Configuration Interrupt MSI-X Function Mask.
Indicates the state of the Function Mask bit in the
MSI-X Message Control field, per Function.

cfg_interrupt_msi_sent

cfg_interrupt_msi_fail

cfg_interrupt_msi_mmenable

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

46
Product Specification

Port Descriptions

Table 2-19:

Configuration Interrupt Controller Interface Port Descriptions (Cont’d)
Port

Direction

cfg_interrupt_msix_vf_enable

Output

Configuration Interrupt MSI-X on VF Enabled. When
asserted, indicates that Message Signaling Interrupt
(MSI-X) messaging is enabled, per Virtual Function.

cfg_interrupt_msix_vf_mask

Output

Configuration Interrupt MSI-X VF Mask. Indicates the
state of the Function Mask bit in the MSI-X Message
Control field, per Virtual Function.

Input

Configuration Interrupt MSI-X Address. When the core
is configured to support MSI-X interrupts, this bus is
used by the client logic to communicate the address to
be used for an MSI-X message.

Input

Configuration Interrupt MSI-X Data. When the core is
configured to support MSI-X interrupts, this bus is
used by the client logic to communicate the data to be
used for an MSI-X message.

Input

Configuration Interrupt MSI-X Data Valid. This signal
indicates that valid information has been placed on the
cfg_interrupt_msix_address[63:0] and
cfg_interrupt_msix_data[31:0] buses, and the
originating Function number has been placed on
cfg_interrupt_function_number[3:0]. The
core internally registers the associated address and
data from cfg_interrupt_msix_address and
cfg_interrupt_msix_data on the 0-to-1
transition of this valid signal. After asserting an
interrupt, the client logic must wait for the
cfg_interrupt_msix_sent or
cfg_interrupt_msix_fail indication from the
core before asserting a new interrupt.

Output

Configuration Interrupt MSI-X Interrupt Sent. The core
generates a one-cycle pulse on this output to indicate
that it has accepted the information placed on the
cfg_interrupt_msix_address[63:0] and
cfg_interrupt_msix_data[31:0] buses, and an
MSI-X interrupt message has been transmitted on the
link. The user application must wait for this pulse
before signaling another interrupt condition to the
core.

Output

Configuration Interrupt MSI-X Interrupt Operation
Failed. A one-cycle pulse on this output indicates that
the interrupt controller has failed to transmit MSI-X
interrupt on the link. The client must retransmit the
MSI-X interrupt in this case.

Input

Configuration Interrupt MSI/MSI-X TLP Attr. These bits
provide the setting of the Attribute bits to be used for
the MSI/MSI-X interrupt request. Bit 0 is the No Snoop
bit, and bit 1 is the Relaxed Ordering bit. Bit 2 is the
ID-Based Ordering bit. The core samples these bits on
a 0-to-1 transition on cfg_interrupt_msi_int or
cfg_interrupt_msix_int.

cfg_interrupt_msix_address

cfg_interrupt_msix_data

cfg_interrupt_msix_int

cfg_interrupt_msix_sent

cfg_interrupt_msix_fail

cfg_interrupt_msi_attr

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

Description

www.xilinx.com

Width

47
Product Specification

Port Descriptions

Table 2-19:

Configuration Interrupt Controller Interface Port Descriptions (Cont’d)
Port

cfg_interrupt_msi_tph_present

cfg_interrupt_msi_tph_type

cfg_interrupt_msi_tph_st_tag

cfg_interrupt_msi_function_number

Direction

Description

Width

Input

Configuration Interrupt MSI/MSI-X TPH Present.
Indicates the presence of a Transaction Processing Hint
(TPH) in the MSI/MSI-X interrupt request. The user
application must set this bit while asserting
cfg_interrupt_msi_int or
cfg_interrupt_msix_int, if it includes a TPH in
the MSI or MSI-X transaction.

Input

Configuration Interrupt MSI/MSI-X TPH Type: When
cfg_interrupt_msi_tph_present is 1'b1, these
two bits supply the two-bit type associated with the
hint. The core samples these bits on a 0-to-1 transition
on cfg_interrupt_msi_int or
cfg_interrupt_msix_int.

Input

Configuration Interrupt MSI/MSI-X TPH Steering Tag.
When cfg_interrupt_msi_tph_present is 1'b1,
the Steering Tag associated with the Hint must be
placed on
cfg_interrupt_msi_tph_st_tag[7:0]. Setting
cfg_interrupt_msi_tph_st_tag[8] to 1b
activates the Indirect Tag mode. In the Indirect Tag
mode, the core uses bits [5:0] of
cfg_interrupt_msi_tph_st_tag as an index into
its Steering Tag Table (STT) in the TPH Capability
Structure (STT is limited to 64 entries per Function),
and inserts the tag from this location in the transmitted
request MSI/X TLP. Setting
cfg_interrupt_msi_tph_st_tag[8] to 0b
activates the Direct Tag mode. In the Direct Tag mode,
the core inserts
cfg_interrupt_msi_tph_st_tag[7:0] directly
as the Tag in the transmitted MSI/X TLP. The core
samples these bits on a 0-to-1 transition on any
cfg_interrupt_msi_int bits or
cfg_interrupt_msix_int.

Input

Configuration MSI/MSI-X Initiating Function. Indicates
the Endpoint function number initiating the MSI or
MSI-X transaction:
• 0: PF0
• 1: PF1
• 2: VF0
• 3: VF1
• 4: VF2
...
• 7: VF5

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

48
Product Specification

Port Descriptions

Configuration Extend Interface
Table 2-20 defines the ports in the Configuration Extend interface of the Integrated Block
for PCI Express core.
Table 2-20:

Configuration Extend Interface Port Descriptions
Port

Direction

Description

Width

cfg_ext_read_received

Output

Configuration Extend Read Received. The core asserts
this output when it has received a configuration read
request from the link. When neither user-implemented
legacy or extended configuration space is enabled,
receipt of a configuration read results in a one-cycle
assertion of this signal, together with valid
cfg_ext_register_number and
cfg_ext_function_number. When
user-implemented legacy, extended configuration
space, or both are enabled, for the
cfg_ext_register_number ranges, 0x10-0x1f or
0x100-0x3ff, respectively, this signal is asserted,
until user logic presents cfg_ext_read_data and
cfg_ext_read_data_valid. For
cfg_ext_register_number ranges outside
0x10-0x1f or 0x100-0x3ff, receipt of a
configuration read always results in a one-cycle
assertion of this signal.

cfg_ext_write_received

Output

Configuration Extend Write Received. The core
generates a one-cycle pulse on this output when it has
received a configuration write request from the link.

Output

Configuration Extend Register Number. The 10-bit
address of the configuration register being read or
written. The data is valid when
cfg_ext_read_received or
cfg_ext_write_received is High.

cfg_ext_function_number

Output

Configuration Extend Function Number. The 8-bit
Function Number corresponding to the configuration
read or write request. The data is valid when
cfg_ext_read_received or
cfg_ext_write_received is High.

cfg_ext_write_data

Output

Configuration Extend Write Data. Data being written
into a configuration register. This output is valid when
cfg_snp_write_received is High.

cfg_ext_write_byte_enable

Output

Configuration Extend Write Byte Enable. Byte enables
for a configuration write transaction.

cfg_ext_register_number

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

49
Product Specification

Port Descriptions

Table 2-20:

Configuration Extend Interface Port Descriptions (Cont’d)
Port

cfg_ext_read_data

cfg_ext_read_data_valid

Direction

Description

Width

Input

Configuration Extend Read Data. The user can provide
data from an externally implemented configuration
register to the core through this bus. The core samples
this data on the next positive edge of the clock after it
sets cfg_snp_read_received High, if the user has
set cfg_snp_read_data_valid.

Input

Configuration Extend Read Data Valid. The user asserts
this input to the core to supply data from an externally
implemented configuration register. The core samples
this input data on the next positive edge of the clock
after it sets cfg_snp_read_received High.

Clock and Reset Interface
Table 2-21 defines the ports in the Clock and Reset interface of the Integrated Block for PCI
Express core.
Table 2-21:

Clock and Reset Interface Port Descriptions
Port

Direction

Description

Width

user_clk

Output

User clock output (62.5, 125, or 250 MHz). This clock
has a fixed frequency and is configured in the CORE
Generator™ software.

user_reset

Output

This signal is deasserted synchronously with respect to
user_clk. It is deasserted and asserted
asynchronously with sys_reset assertion.

sys_clk

Input

Reference clock. This clock has a selectable frequency
of 100 MHz, 125 MHz, or 250 MHz.

sys_reset

Input

Fundamental reset input to the core (asynchronous,
active High).

PCI Express Interface
The PCI Express (PCI_EXP) interface consists of differential transmit and receive pairs
organized in multiple lanes. A PCI Express lane consists of a pair of transmit differential
signals (pci_exp_txp, pci_exp_txn) and a pair of receive differential signals
{pci_exp_rxp, pci_exp_rxn}. The 1-lane core supports only Lane 0, the 2-lane core
supports lanes 0–1, the 4-lane core supports lanes 0-3, and the 8-lane core supports lanes
0–7. Transmit and receive signals of the PCI_EXP interface are defined in Table 2-22.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

50
Product Specification

Port Descriptions

Table 2-22:

PCI Express Interface Signals for 1-, 2-, 4- and 8-Lane Cores

Lane
Number

Name

Direction

Description

pci_exp_txp0

Output

PCI Express Transmit Positive: Serial Differential Output 0 (+)

pci_exp_txn0

Output

PCI Express Transmit Negative: Serial Differential Output 0 (–)

pci_exp_rxp0

Input

PCI Express Receive Positive: Serial Differential Input 0 (+)

pci_exp_rxn0

Input

PCI Express Receive Negative: Serial Differential Input 0 (–)

1-Lane Cores
0

2-Lane Cores
0

pci_exp_txp0

Output

PCI Express Transmit Positive: Serial Differential Output 0 (+)

pci_exp_txn0

Output

PCI Express Transmit Negative: Serial Differential Output 0 (–)

pci_exp_rxp0

Input

PCI Express Receive Positive: Serial Differential Input 0 (+)

pci_exp_rxn0

Input

PCI Express Receive Negative: Serial Differential Input 0 (–)

pci_exp_txp1

Output

PCI Express Transmit Positive: Serial Differential Output 1 (+)

pci_exp_txn1

Output

PCI Express Transmit Negative: Serial Differential Output 1 (–)

pci_exp_rxp1

Input

PCI Express Receive Positive: Serial Differential Input 1 (+)

pci_exp_rxn1

Input

PCI Express Receive Negative: Serial Differential Input 1 (–)

4-Lane Cores
0

pci_exp_txp0

Output

PCI Express Transmit Positive: Serial Differential Output 0 (+)

pci_exp_txn0

Output

PCI Express Transmit Negative: Serial Differential Output 0 (–)

pci_exp_rxp0

Input

PCI Express Receive Positive: Serial Differential Input 0 (+)

pci_exp_rxn0

Input

PCI Express Receive Negative: Serial Differential Input 0 (–)

pci_exp_txp1

Output

PCI Express Transmit Positive: Serial Differential Output 1 (+)

pci_exp_txn1

Output

PCI Express Transmit Negative: Serial Differential Output 1 (–)

pci_exp_rxp1

Input

PCI Express Receive Positive: Serial Differential Input 1 (+)

pci_exp_rxn1

Input

PCI Express Receive Negative: Serial Differential Input 1 (–)

pci_exp_txp2

Output

PCI Express Transmit Positive: Serial Differential Output 2 (+)

pci_exp_txn2

Output

PCI Express Transmit Negative: Serial Differential Output 2 (–)

pci_exp_rxp2

Input

PCI Express Receive Positive: Serial Differential Input 2 (+)

pci_exp_rxn2

Input

PCI Express Receive Negative: Serial Differential Input 2 (–)

pci_exp_txp3

Output

PCI Express Transmit Positive: Serial Differential Output 3 (+)

pci_exp_txn3

Output

PCI Express Transmit Negative: Serial Differential Output 3 (–)

pci_exp_rxp3

Input

PCI Express Receive Positive: Serial Differential Input 3 (+)

pci_exp_rxn3

Input

PCI Express Receive Negative: Serial Differential Input 3 (–)

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

51
Product Specification

Port Descriptions

Table 2-22:

PCI Express Interface Signals for 1-, 2-, 4- and 8-Lane Cores (Cont’d)

Lane
Number

Name

Direction

Description

pci_exp_txp0

Output

PCI Express Transmit Positive: Serial Differential Output 0 (+)

pci_exp_txn0

Output

PCI Express Transmit Negative: Serial Differential Output 0 (–)

pci_exp_rxp0

Input

PCI Express Receive Positive: Serial Differential Input 0 (+)

pci_exp_rxn0

Input

PCI Express Receive Negative: Serial Differential Input 0 (–)

pci_exp_txp1

Output

PCI Express Transmit Positive: Serial Differential Output 1 (+)

pci_exp_txn1

Output

PCI Express Transmit Negative: Serial Differential Output 1 (–)

pci_exp_rxp1

Input

PCI Express Receive Positive: Serial Differential Input 1 (+)

pci_exp_rxn1

Input

PCI Express Receive Negative: Serial Differential Input 1 (–)

pci_exp_txp2

Output

PCI Express Transmit Positive: Serial Differential Output 2 (+)

pci_exp_txn2

Output

PCI Express Transmit Negative: Serial Differential Output 2 (–)

pci_exp_rxp2

Input

PCI Express Receive Positive: Serial Differential Input 2 (+)

pci_exp_rxn2

Input

PCI Express Receive Negative: Serial Differential Input 2 (–)

pci_exp_txp3

Output

PCI Express Transmit Positive: Serial Differential Output 3 (+)

pci_exp_txn3

Output

PCI Express Transmit Negative: Serial Differential Output 3 (–)

pci_exp_rxp3

Input

PCI Express Receive Positive: Serial Differential Input 3 (+)

pci_exp_rxn3

Input

PCI Express Receive Negative: Serial Differential Input 3 (–)

pci_exp_txp4

Output

PCI Express Transmit Positive: Serial Differential Output 4 (+)

pci_exp_txn4

Output

PCI Express Transmit Negative: Serial Differential Output 4 (–)

pci_exp_rxp4

Input

PCI Express Receive Positive: Serial Differential Input 4 (+)

pci_exp_rxn4

Input

PCI Express Receive Negative: Serial Differential Input 4 (–)

pci_exp_txp5

Output

PCI Express Transmit Positive: Serial Differential Output 5 (+)

pci_exp_txn5

Output

PCI Express Transmit Negative: Serial Differential Output 5 (–)

pci_exp_rxp5

Input

PCI Express Receive Positive: Serial Differential Input 5 (+)

pci_exp_rxn5

Input

PCI Express Receive Negative: Serial Differential Input 5 (–)

pci_exp_txp6

Output

PCI Express Transmit Positive: Serial Differential Output 6 (+)

pci_exp_txn6

Output

PCI Express Transmit Negative: Serial Differential Output 6 (–)

pci_exp_rxp6

Input

PCI Express Receive Positive: Serial Differential Input 6 (+)

pci_exp_rxn6

Input

PCI Express Receive Negative: Serial Differential Input 6 (–)

pci_exp_txp7

Output

PCI Express Transmit Positive: Serial Differential Output 7 (+)

pci_exp_txn7

Output

PCI Express Transmit Negative: Serial Differential Output 7 (–)

pci_exp_rxp7

Input

PCI Express Receive Positive: Serial Differential Input 7 (+)

pci_exp_rxn7

Input

PCI Express Receive Negative: Serial Differential Input 7 (–)

8-Lane Cores
0

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

52
Product Specification

Attribute Descriptions

Attribute Descriptions
Client Interface
Table 2-23 lists the configuration attributes controlling the operation of the client interface
of the Virtex-7 FPGA Gen3 Integrated Block for PCI Express.
Table 2-23:

Configuration Attributes of the Integrated Block Client Interface
Attribute Name

Width

Description

CRM_USER_CLK_FREQ[1:0]

Defines the frequency of the user clock.
• 00: 62.5 MHz
• 01: 125 MHz
• 10: 250 MHz
• 11: Reserved

CRM_CORE_CLK_FREQ_500

Defines the frequency of the core clock.
• 0: 250 MHz
• 1: 500 MHz

PL_LINK_CAP_MAX_LINK_SPEED[1:0]

Defines the maximum speed of the PCIe link.
• 00: 2.5 GT/s
• 01: 5.0 GT/s
• 10: 8.0 GT/s
• 11: Reserved

PL_LINK_CAP_MAX_LINK_WIDTH[3:0]

Maximum Link Width. Valid settings are:
• 0001b: x1
• 0010b: x2
• 0100b: x4
• 1000b: x8
All other encodings are reserved. This setting is
propagated to all layers in the core.

AXISTEN_IF_WIDTH[1:0]

Configures the width of the AXI4-Stream interfaces.
• 00: 64 bits
• 01: 128 bits
• 10: 256 bits
• 11: Reserved

AXISTEN_IF_CQ_ALIGNMENT_MODE

Defines the data alignment mode for the completer
request interface.
• 0: Dword-aligned Mode
• 1: Address-aligned Mode

AXISTEN_IF_CC_ALIGNMENT_MODE

Defines the data alignment mode for the completer
completion interface.
• 0: Dword-aligned Mode
• 1: Address-aligned Mode

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

53
Product Specification

Attribute Descriptions

Table 2-23:

Configuration Attributes of the Integrated Block Client Interface (Cont’d)
Attribute Name

Width

Description

AXISTEN_IF_RQ_ALIGNMENT_MODE

Defines the data alignment mode for the requester
request interface.
• 0: Dword-aligned Mode
• 1: Address-aligned Mode

AXISTEN_IF_RC_ALIGNMENT_MODE

Defines the data alignment mode for the requester
completion interface.
• 0: Dword-aligned Mode
• 1: Address-aligned Mode

AXISTEN_IF_RC_STRADDLE

This attribute enables the straddle option on the
requester completion interface.
• 0: Straddle option disabled
• 1: Straddle option enabled

AXISTEN_IF_RQ_PARITY_CHECK

This attribute enables parity checking on the
requester request interface.
• 0: Parity check disabled
• 1: Parity check enabled

AXISTEN_IF_CC_PARITY_CHECK

This attribute enables parity checking on the
completer completion interface.
• 0: Parity check disabled
• 1: Parity check enabled

AXISTEN_IF_ENABLE_RX_MSG_INTFC

This attribute controls how the core delivers a
message received from the link.
When this attribute is set to 0, the core delivers the
received message TLPs on the completer request
interface using the AXI4-Stream protocol. In this
mode, the user can select the message types to
receive using the AXISTEN_IF_ENABLE_MSG_ROUTE
attributes. The receive message interface remains
disabled in this mode.
When this attribute is set to 1, the core internally
decodes messages received from the link, and
signals them to the user by activating the
cfg_msg_received signal on the receive message
interface. The core does not transfer any message
TLPs on the completer request interface. The
settings of the AXISTEN_ENABLE_MSG_ROUTE
attributes have no effect on the operation of the
receive message interface in this mode.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

54
Product Specification

Attribute Descriptions

Table 2-23:

Configuration Attributes of the Integrated Block Client Interface (Cont’d)
Attribute Name

Width

Description

AXISTEN_IF_ENABLE_MSG_ROUTE[17:0]

When the AXISTEN_IF_ENABLE_RX_MSG_INTFC
attribute is set to 0, these attributes can be used to
select the specific message types that the user
wants to receive on the completer request interface.
Setting a bit to 1 enables the delivery of the
corresponding type of messages on the interface,
and setting it to 0 results in the core filtering the
message.
Table 2-24 defines the attribute bit definitions
corresponding to the various message types.

AXISTEN_IF_ENABLE_CLIENT_TAG

When this attribute is FALSE, tag management for
Non-Posted transactions initiated from the
requester request interface is performed by the
Integrated Block. That is, for each Non-Posted
request, the core allocates the tag for the
transaction and communicates it to the client.
Setting this attribute to TRUE disables the internal
tag management, allowing the user to supply the
tag to be used for each request. The user must
present the Tag field in the Request descriptor
header in the range 0–31 when the
PF0_DEV_CAP_EXT_TAG_SUPPORTED attribute is
FALSE, while the Tag field can be in the range 0–63
when the PF0_DEV_CAP_EXT_TAG_SUPPORTED
attribute is TRUE.

Table 2-24:

AXISTEN_IF_ENABLE_MSG_ROUTE Attribute Bit Descriptions

Bit Index

Message Type

ERR_COR

ERR_NONFATAL

ERR_FATAL

Assert_INTA and Deassert_INTA

Assert_INTB and Deassert_INTB

Assert_INTC and Deassert_INTC

Assert_INTD and Deassert_INTD

PM_PME

PME_TO_Ack

PME_Turn_Off

PM_Active_State_Nak

Set_Slot_Power_Limit

Latency Tolerance Reporting (LTR)

Optimized Buffer Flush/Fill (OBFF)

Unlock

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

55
Product Specification

Configuration Space

Table 2-24:

AXISTEN_IF_ENABLE_MSG_ROUTE Attribute Bit Descriptions (Cont’d)

Bit Index

Message Type

Vendor_Defined Type 0

Vendor_Defined Type 1

Invalid Request, Invalid Completion, Page Request, PRG Response

Configuration Space
The PCI configuration space consists of three primary parts, illustrated in Table 2-25. These
include:
•

•

Legacy PCI v3.0 Type 0/1 Configuration Space Header
°

Type 0 Configuration Space Header used by Endpoint applications (see Table 2-26)

Type 1 Configuration Space Header used by Root Port applications (see Table 2-27)

Legacy Extended Capability Items
°

PCIe Capability Item

Power Management Capability Item

Message Signaled Interrupt (MSI) Capability Item

MSI-X Capability Item (optional)

PCIe Capabilities
°

Advanced Error Reporting Extended Capability Structure (AER)

Alternate Requestor ID (ARI) (optional)

Device Serial Number Extended Capability Structure (DSN) (optional)

Power Budgeting Enhanced

Capability Header (PB) (optional)

Resizable BAR (RBAR) (optional)

Latency Tolerance Reporting (LTR) (optional)

Dynamic Power Allocation (DPA) (optional)

Single Root I/O Virtualization (SR-IOV) (optional)

Transaction Processing Hints (TPH) (optional)

Virtual Channel Extended Capability Structure (VC) (optional)

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

56
Product Specification

Configuration Space
•

PCIe Extended Capabilities
°

Device Serial Number Extended Capability Structure (optional)

Virtual Channel Extended Capability Structure (optional)

Advanced Error Reporting Extended Capability Structure (optional)

The core implements up to four legacy extended capability items.
For more information about enabling this feature, see Chapter 3, Customizing and
Generating the Core.
The core optionally implements up to ten PCI Express Extended Capabilities. The remaining
PCI Express Extended Capability Space is available for users to implement. The starting
address of the space available to users begins at 3DCh. If you choose to implement registers
in this space, you can select the starting location of this space, and this space must be
implemented in the User Application.
For more information about enabling this feature, see PCIe Extended Capabilities in
Chapter 3.
Table 2-25:

Common PCI Configuration Space Header
31

Device ID

Vendor ID

000h

Status

Command

004h

Class Code
BIST

Header

Lat Timer

Rev ID

008h

Cache Ln

00Ch
010h
014h
018h
01Ch

Header Type Specific

020h

(see Table 2-26 and Table 2-27)

024h
028h
02Ch
030h
CapPtr

034h
038h

Intr Pin
Reserved

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

Intr Line

03Ch
040h07Ch

57
Product Specification

Configuration Space

Table 2-25:

Common PCI Configuration Space Header (Cont’d)
31

PM Capability
Data

0
NxtCap

PM Cap

Reserved

PMCSR

084h

Reserved
Customizable (1)

MSI Control

088h08Ch
NxtCap

MSI Cap

090h

Message Address (Lower)

094h

Message Address (Upper)

098h

Reserved

Message Data

09Ch

Mask Bits

0A0h

Pending Bits

0A4h
0A8h0ACh

Reserved
Optional(3)

080h

MSl-X Control

NxtCap

MSl-X Cap

0B0h

Table

0B4h

Table Offset

BIR
PBA Offset

PBA
BIR
Reserved

PE Capability

0BCh
NxtCap

PE Cap

PCI Express Device Capabilities
Device Status
PCI Express Link Capabilities

0C8h
0CCh

Link Status
Root Port

0C0h
0C4h

Device Control

Link Control

Only(2)

0B8h

Slot Capabilities

0D0h
0D4h

Slot Status

Slot Control

0D8h

Root Capabilities

Root Control

0DCh

Root Status

0E0h

PCI Express Device Capabilities 2

0E4h

Device Status 2

Device Control 2
PCI Express Link Capabilities 2

Link Status 2

0ECh
Link Control 2

Unimplemented Configuration Space
(Returns 0x00000000 )

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

0E8h

0F0h
0F4h0FCh

58
Product Specification

Configuration Space

Table 2-25:

Common PCI Configuration Space Header (Cont’d)
31

Always Enabled

16
Next Cap

Cap. Ver.

PCI Express Extended Cap. ID (AER)

100h

Uncorrectable Error Status Register

104h

Uncorrectable Error Mask Register

108h

Uncorrectable Error Severity Register

10Ch

Correctable Error Status Register

110h

Correctable Error Mask Register

114h

Advanced Error Cap. & Control Register

118h

Header Log Register 1

11Ch

Header Log Register 2

120h

Header Log Register 3

124h

Header Log Register 4

128h

Reserved

12Ch

Root Error Command Register

130h

Root Error Status Register

134h

Error Source ID Register

138h

Reserved

13Ch

Optional, Root
Port only(3)

Optional(3)(4)

Next Cap

Cap.
Ver.

PCI Express Extended Capability - Alternate
Requester ID (ARI)

Control

Next Function

Function Groups

Reserved
Optional(3)

Optional(3)

Next Cap

Cap.
Ver.

PCI Express Extended Capability - DSN

150h

PCI Express Device Serial Number (1st)

154h

PCI Express Device Serial Number (2nd)

158h

Reserved

15Ch

Next Cap

Cap.
Ver.

Reserved

PCI Express Extended Capability - Power
Budgeting Enhanced Capability Header
DS

Power Budget Data - State D0, D1, D3, ...

Cap.
Ver.
No-Snoop

www.xilinx.com

164h

16Ch

Reserved
Next Cap

160h

168h

Power Budget Capability

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

144h
148h14Ch

Reserved

Optional(3)

140h

170h1B4h

PCI Express Extended Capability ID Latency Tolerance Reporting (LTR)

1B8h

Snoop

1BCh

59
Product Specification

Configuration Space

Table 2-25:

Common PCI Configuration Space Header (Cont’d)
31

Optional(3)

16
Next Cap

Cap.
Ver.

0
PCI Express Extended Capability ID Dynamic Power Allocation

Capability Register

1C4h

Latency Indicator

1C8h

Control

Status

1CCh

Power Allocation Array Register 0

1D0h

Power Allocation Array Register 1

1D4h

Reserved
Optional(3)

Next Cap

Cap.
Ver.

1D8h1FCh

PCI Express Extended Capability ID - Single
Root I/O Virtualization (SR-IOV)
Capability Register

Optional(3)

1C0h

200h

204h

SR-IOV Status (not supported)

Control

208h

Total VFs

Initial VFs

20Ch

Function Dependency Link

Number VFs

210h

VF Stride

First VF Offset

214h

VF Device ID

Reserved

218h

Next Cap

Supported Page Sizes

21Ch

System Page Size

220h

VF Base Address Register 0

224h

VF Base Address Register 1

228h

VF Base Address Register 2

22Ch

VF Base Address Register 3

230h

VF Base Address Register 4

234h

VF Base Address Register 5

238h

Reserved

23Ch

Reserved

240h270h

Cap.
Ver.

PCI Express Extended Capability ID Transaction Processing Hints (TPH)
Capability Register

278h

Requester Control Register

27Ch

Reserved

Steering Tag Upper
Reserved

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

274h

www.xilinx.com

Steering Tag Lower

280h
284h 2FCh

60
Product Specification

Configuration Space

Table 2-25:

Common PCI Configuration Space Header (Cont’d)
31

Optional(3)

16
Next Cap

Cap.
Ver.

0
PCI Express Extended Capability ID Secondary PCIe Extended Capability

Lane Control (not supported)

304h

Reserved

Lane Error Status

308h

Lane Equalization Control Register 0

30Ch

Lane Equalization Control Register 1

310h

Lane Equalization Control Register 2

314h

Lane Equalization Control Register 3

318h

Reserved
Optional(3)

300h

Next Cap

Cap.
Ver.

31Ch3BCh
PCI Express Extended
Capability - VC

3C0h

Port VC Capability Register 1

3C4h

Port VC Capability Register 2

3C8h

Port VC Status

Port VC Control

3CCh

VC Resource Capability Register 0

3D0h

VC Resource Control Register 0

3D4h

VC Resource Status Register 0

3D8h
400hFFFh

Reserved

Notes:
1. The MSI Capability Structure varies depending on the selections in the CORE Generator tool GUI.
2. Reserved for Endpoint configurations (returns 0x00000000).
3. The layout of the PCI Express Extended Configuration Space (100h-FFFh) can change dependent on which
optional capabilities are enabled. This table represents the Extended Configuration space layout when all optional
extended capability structures, except RBAR, are enabled.
4. Enabled by default if the SR-IOV option is enabled.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

61
Product Specification

Configuration Space

Table 2-26:

Type 0 PCI Configuration Space Header

Device ID

Vendor ID

00h

Status

Command

04h

Class Code
BIST

Header

Lat Timer

Rev ID

08h

Cache Ln

0Ch

Base Address Register 0

10h

Base Address Register 1

14h

Base Address Register 2

18h

Base Address Register 3

1Ch

Base Address Register 4

20h

Base Address Register 5

24h

Cardbus CIS Pointer

28h

Subsystem ID

Subsystem Vendor ID

2Ch

Expansion ROM Base Address

30h

Reserved

CapPtr
Reserved

Max Lat

Table 2-27:

Min Gnt

34h
38h

Intr Pin

Intr Line

3Ch

Type 1 PCI Configuration Space Header

Device ID

Vendor ID

00h

Status

Command

04h

Class Code
BIST

Header

Second Lat Timer

Lat Timer

Rev ID

08h

Cache Ln

0Ch

Base Address Register 0

10h

Base Address Register 1

14h

Sub Bus Number

Secondary Status

Second Bus Number

Primary Bus Number

18h

I/O Limit

I/O Base

1Ch

Memory Limit

Memory Base

20h

Prefetchable Memory Limit

Prefetchable Memory Base

24h

Prefetchable Base Upper 32 Bits

28h

Prefetchable Limit Upper 32 Bits

2Ch

I/O Limit Upper 16 Bits

I/O Base Upper 16 Bits

Reserved

30h

CapPtr

Expansion ROM Base Address
Bridge Control

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

Intr Pin

www.xilinx.com

34h
38h

Intr Line

3Ch

62
Product Specification

Chapter 3

Customizing and Generating the Core
This chapter includes information on using Xilinx tools to customize and generate the core.

GUI
The LogiCORE™ IP Virtex®-7 FPGA Gen3 Integrated Block for PCI Express® core is a fully
configurable and highly customizable solution. The Virtex-7 FPGA Gen3 Integrated Block
for PCI Express is customized using the CORE Generator™ tool.
Note: The screen captures in this chapter are conceptual representatives of their subjects and
provide general information only. For the latest information, see the CORE Generator tool.

Customizing the Core using the CORE Generator Tool
The CORE Generator tool GUI for the Virtex-7 FPGA Gen3 Integrated Block for PCI Express
consists of these screens:
•

Page 1: Basic Parameter Settings

•

Page 2: Interface Settings

•

Pages 3 and 4: Identity Settings (PF0 and PF1)

•

Pages 5 and 6: Base Address Registers (PF0 and PF1)

•

Pages 7 and 8: SRIOV Config (PF0 and PF1)

•

Pages 9 and 10: SRIOV Base Address Registers (PF0 and PF1)

•

Page 11: Interrupt Capabilities (all PFs and VFs)

•

Page 12: Power Management Registers

•

Pages 13 and 14: PCIe Extended Capabilities

Basic Parameter Settings
The initial customization screen shown in Figure 3-1 is used to define the basic parameters
for the core, including the component name, reference clock frequency, and silicon type.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

GUI

X-Ref Target - Figure 3-1

Figure 3-1:

Page 1: Integrated Block for PCI Express Parameters

Component Name
Base name of the output files generated for the core. The name must begin with a letter and
can be composed of these characters: a to z, 0 to 9, and “_.”

PCIe Device / Port Type
Indicates the PCI Express logical device type.

Xilinx Development Board
Selects the Xilinx Development Board to enable the generation of Xilinx Development
Board specific constraints files.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

GUI

Integrated Block for PCIe Location
Selects from the available Integrated Blocks to enable generation of location-specific
constraint files and pinouts. This selection is used in the default example design scripts.
This option is not available if a Xilinx Development Board is selected.

Additional Constraints
Allows generation of additional constraints files for other blocks available in the device.
This option is not available if a Xilinx Development Board is selected.

Reference Clock Frequency
Selects the frequency of the reference clock provided on sys_clk. For important
information about clocking the Virtex-7 FPGA Gen3 Integrated Block for PCI Express, see
Clocking, page 94.

Slot Clock Configuration
Enables the Slot Clock Configuration bit in the Link Status register. Selecting this option
means the link is synchronously clocked. See Clocking, page 94 for more information on
clocking options.

Silicon Type
Selects the silicon type.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

GUI

Interface Settings
The Interface Settings page is shown in Figure 3-2.
X-Ref Target - Figure 3-2

Figure 3-2:

Page 2: Interface Settings

Number of Lanes
The Virtex-7 FPGA Gen3 Integrated Block for PCI Express requires the selection of the initial
lane width. Table 3-1 defines the available widths and associated generated core. Wider
lane width cores can train down to smaller lane widths if attached to a smaller lane-width
device. See Link Training: 2-Lane, 4-Lane, and 8-Lane Components, page 177 for more
information.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

GUI

Table 3-1:

Lane Width and Product Generated

Lane Width

Product Generated

1-Lane Virtex-7 FPGA Gen3 Integrated Block for PCI Express

2-Lane Virtex-7 FPGA Gen3 Integrated Block for PCI Express

4-Lane Virtex-7 FPGA Gen3 Integrated Block for PCI Express

8-Lane Virtex-7 FPGA Gen3 Integrated Block for PCI Express

Link Speed
The Virtex-7 FPGA Gen3 Integrated Block for PCI Express allows the selection of Maximum
Link Speed supported by the device. Table 3-2 defines the lane widths and link speeds
supported by the device. Higher link speed cores are capable of training to a lower link
speed if connected to a lower link speed capable device.
Table 3-2:

Lane Width and Link Speed

Lane Width

Link Speed

2.5 Gb/s, 5 Gb/s, 8 Gb/s

Interface Width
The Virtex-7 FPGA Gen3 Integrated Block for PCI Express allows the selection of Interface
Width, as defined in Table 3-3. The default interface width set in the CORE Generator tool
GUI is the lowest possible interface width.
Table 3-3:

Lane Width, Link Speed, and Interface Width
Lane Width

Link Speed
(Gb/s)

Interface Width (Bits)

2.5, 5.0, 8.0

2.5, 5.0

8.0

64, 128

2.5

5.0

64, 128

8.0

128, 256

2.5

64, 128

5.0

128 256

8.0

256

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

GUI

Requestor Completion Straddle
The Virtex-7 FPGA Gen3 Integrated Block for PCI Express provides an option to straddle
packets on the Requestor Completion interface when the interface width is 256 bits. See
Straddle Option for 256-Bit Interface, page 169.

Alignment Mode
When a payload is present, there are two options for aligning the first byte of the payload
with respect to the datapath. See Data Alignment Options, page 101.

Physical Function 1 Enable
The Virtex-7 FPGA Gen3 Integrated Block for PCI Express implements an additional Physical
Function.

MPS
This field indicates the maximum payload size that the device or function can support for
TLPs. This is the value advertised to the system in the Device Capabilities Register.

Extended Tag
This field indicates the maximum supported size of the Tag field as a Requester. Options are
8-bit Tag field support (when selected) or 5-bit Tag field support (when deselected).

SRIOV Enable
The Integrated Block implements the Single Root Port I/O Virtualization PCIe extended
capability. When this capability is enabled, the SRIOV capability is implemented for both
PF0 and PF1 (if selected).

Number of Functions
The Integrated Block implements up to six Virtual Functions that are associated to either
PF0 or PF1 (if enabled).

Function Level Reset
The Integrated Block enables you to reset a specific device function. This mechanism is only
applicable to Endpoint configurations.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

GUI

Identity Settings (PF0 and PF1)
The Identity Settings pages are shown in Figure 3-3 and Figure 3-4. These settings
customize the IP initial values, class code, and Cardbus CIS pointer information. The page
for Physical Function 1 (PF1) is only displayed when PF1 is enabled.
X-Ref Target - Figure 3-3

Figure 3-3:

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

Page 3: Identity Settings (PF0)

www.xilinx.com

GUI

X-Ref Target - Figure 3-4

Figure 3-4:

Page 4: Identity Settings (PF1)

ID Initial Values
•

Vendor ID: Identifies the manufacturer of the device or application. Valid identifiers
are assigned by the PCI Special Interest Group to guarantee that each identifier is
unique. The default value, 10EEh, is the Vendor ID for Xilinx. Enter a vendor
identification number here. FFFFh is reserved.

•

Device ID: A unique identifier for the application; the default value, which depends on
the configuration selected, is 70h. This field can be any value;
change this value for the application.

•

Revision ID: Indicates the revision of the device or application; an extension of the
Device ID. The default value is 00h; enter values appropriate for the application.

•

Subsystem Vendor ID: Further qualifies the manufacturer of the device or application.
Enter a Subsystem Vendor ID here; the default value is 10EE. Typically, this value is the
same as Vendor ID. Setting the value to 0000h can cause compliance testing issues.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

GUI
•

Subsystem ID: Further qualifies the manufacturer of the device or application. This
value is typically the same as the Device ID; the default value depends on the lane
width and link speed selected. Setting the value to 0000h can cause compliance testing
issues.

Class Code
The Class Code identifies the general function of a device, and is divided into three
byte-size fields:
•

Base Class: Broadly identifies the type of function performed by the device.

•

Sub-Class: More specifically identifies the device function.

•

Interface: Defines a specific register-level programming interface, if any, allowing
device-independent software to interface with the device.

Class code encoding can be found at www.pcisig.com.

Class Code Look-up Assistant
The Class Code Look-up Assistant provides the Base Class, Sub-Class and Interface values
for a selected general function of a device. This Look-up Assistant tool only displays the
three values for a selected function. The user must enter the values in Class Code for these
values to be translated into device settings.

Base Address Registers (PF0 and PF1)
The Base Address Registers (BARs) screens shown in Figure 3-5 and Figure 3-6 set the base
address register space for the Endpoint configuration. Each BAR (0 through 5) configures
the Physical Function’s BAR Aperture Size and Control attributes as described in Table B-1.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

GUI

X-Ref Target - Figure 3-5

Figure 3-5:

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

Page 5: Base Address Register (PF0)

www.xilinx.com

GUI

X-Ref Target - Figure 3-6

Figure 3-6:

Page 6: Base Address Register (PF1)

Base Address Register Overview
The Virtex-7 FPGA Gen3 Integrated Block for PCI Express in Endpoint configuration
supports up to six 32-bit BARs or three 64-bit BARs, and the Expansion ROM BAR. The
Virtex-7 FPGA Gen3 Integrated Block for PCI Express in Root Port configuration supports up
to two 32-bit BARs or one 64-bit BAR, and the Expansion ROM BAR.
BARs can be one of two sizes:
•

32-bit BARs: The address space can be as small as 16 bytes or as large as 2 gigabytes.
Used for Memory to I/O.

•

64-bit BARs: The address space can be as small as 128 bytes or as large as 8 exabytes.
Used for Memory only.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

GUI
All BAR registers share these options:
•

Checkbox: Click the checkbox to enable the BAR; deselect the checkbox to disable the
BAR.

•

Type: BARs can either be I/O or Memory.
°

•

I/O: I/O BARs can only be 32-bit; the Prefetchable option does not apply to I/O
BARs. I/O BARs are only enabled for the Legacy PCI Express Endpoint core.
Memory: Memory BARs can be either 64-bit or 32-bit and can be prefetchable.
When a BAR is set as 64 bits, it uses the next BAR for the extended address space
and makes the next BAR inaccessible to the user.

Size: The available Size range depends on the PCIe® Device/Port Type and the Type of
BAR selected. Table 3-4 lists the available BAR size ranges.

Table 3-4:

BAR Size Ranges for Device Configuration

PCIe Device / Port Type
PCI Express Endpoint

Legacy PCI Express Endpoint

BAR Type

BAR Size Range

32-bit Memory

128 Bytes – 2 Gigabytes

64-bit Memory

128 Bytes – 8 Exabytes

32-bit Memory

16 Bytes – 2 Gigabytes

64-bit Memory

16 Bytes – 8 Exabytes

I/O

16 Bytes – 2 Gigabytes

•

Prefetchable: Identifies the ability of the memory space to be prefetched.

•

Value: The value assigned to the BAR based on the current selections.

For more information about managing the Base Address Register settings, see Managing
Base Address Register Settings.
Expansion ROM Base Address Register
If selected, the Expansion ROM is activated and can be a value from 2 KB to 4 GB. According
to the PCI 3.0 Local Bus Specification, the maximum size for the Expansion ROM BAR should
be no larger than 16 MB. Selecting an address space larger than 16 MB might result in a
non-compliant core.

Managing Base Address Register Settings
Memory, I/O, Type, and Prefetchable settings are handled by setting the appropriate GUI
settings for the desired base address register.
Memory or I/O settings indicate whether the address space is defined as memory or I/O.
The base address register only responds to commands that access the specified address
space. Generally, memory spaces less than 4 KB in size should be avoided. The minimum I/O
space allowed is 16 bytes; use of I/O space should be avoided in all new designs.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

GUI
Prefetchability is the ability of memory space to be prefetched. A memory space is
prefetchable if there are no side effects on reads (that is, data is not destroyed by reading,
as from a RAM). Byte write operations can be merged into a single double word write, when
applicable.
When configuring the core as an Endpoint for PCIe (non-Legacy), 64-bit addressing must be
supported for all BARs (except BAR5) that have the prefetchable bit set. 32-bit addressing
is permitted for all BARs that do not have the prefetchable bit set. The prefetchable bit
related requirement does not apply to a Legacy Endpoint. The minimum memory address
range supported by a BAR is 128 bytes for a PCI Express Endpoint and 16 bytes for a Legacy
PCI Express Endpoint.
Disabling Unused Resources
For best results, disable unused base address registers to conserve system resources. A base
address register is disabled by deselecting unused BARs in the GUI.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

GUI

SRIOV Config (PF0 and PF1)
The SRIOV Config screen is shown in Figure 3-7.

X-Ref Target - Figure 3-7

Figure 3-7:

Page 7: SRIOV Config (PF0 and PF1)

SRIOV Capability Version
Indicates the 4-bit SRIOV Capability Version for the Physical Function.

SRIOV Function Select
Indicates the number of Virtual Functions associated to the Physical Function. A maximum
of six Virtual Functions are available to PF0 and PF1.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

GUI

SRIOV Functional Dependency Link
Indicates the SRIOV Functional Dependency Link for the Physical Function. The
programming model for a device can have vendor-specific dependencies between sets of
Functions. The Function Dependency Link field is used to describe these dependencies.

SRIOV First VF Offset
Indicates the offset of the first Virtual Function for the Physical Function.

SRIOV VF Device ID
Indicates the 16-bit Device ID for all Virtual Functions associated with the Physical Function.

SRIOV Supported Page Size
Indicates the page size supported by the Physical Function. This Physical Function supports
a page size of 2n+12, if bit n of the 32-bit register is set.

SRIOV Base Address Registers (PF0 and PF1)
The SRIOV Base Address Registers (BARs) screens shown in Figure 3-8 and Figure 3-9 set
the base address register space for the Endpoint configuration. Each BAR (0 through 5)
configures the SRIOV BAR Aperture Size and SRIOV Control attributes as described in
Table B-1.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

GUI

X-Ref Target - Figure 3-8

Figure 3-8:

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

Page 8: SRIOV Base Address Register (PF0)

www.xilinx.com

GUI

X-Ref Target - Figure 3-9

Figure 3-9:

Page 9: SRIOV Base Address Register (PF1)

SRIOV Base Address Register Overview
The Virtex-7 FPGA Gen3 Integrated Block for PCI Express in Endpoint configuration
supports up to six 32-bit BARs or three 64-bit BARs. The Virtex-7 FPGA Gen3 Integrated
Block for PCI Express in Root Port configuration supports up to two 32-bit BARs or one
64-bit BAR.
SRIOV BARs can be one of two sizes:
•

32-bit BARs: The address space can be as small as 16 bytes or as large as 2 gigabytes.
Used for Memory to I/O.

•

64-bit BARs: The address space can be as small as 128 bytes or as large as 8 exabytes.
Used for Memory only.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

GUI
All SRIOV BAR registers share these options:
•

Checkbox: Click the checkbox to enable the BAR; deselect the checkbox to disable the
BAR.

•

Type: SRIOV BARs can either be I/O or Memory.
°

•

Size: The available Size range depends on the PCIe® Device/Port Type and the Type of
BAR selected. Table 3-4 lists the available BAR size ranges.

Table 3-5:

SRIOV BAR Size Ranges for Device Configuration

PCIe Device / Port Type
PCI Express Endpoint

Legacy PCI Express Endpoint

BAR Type

BAR Size Range

32-bit Memory

128 Bytes – 2 Gigabytes

64-bit Memory

128 Bytes – 8 Exabytes

32-bit Memory

16 Bytes – 2 Gigabytes

64-bit Memory

16 Bytes – 8 Exabytes

I/O

16 Bytes – 2 Gigabytes

•

Prefetchable: Identifies the ability of the memory space to be prefetched.

•

Value: The value assigned to the BAR based on the current selections.

For more information about managing the SRIOV Base Address Register settings, see
Managing Base Address Register Settings.

Managing SRIOV Base Address Register Settings
Memory, I/O, Type, and Prefetchable settings are handled by setting the appropriate GUI
settings for the desired base address register.
Memory or I/O settings indicate whether the address space is defined as memory or I/O.
The base address register only responds to commands that access the specified address
space. Generally, memory spaces less than 4 KB in size should be avoided. The minimum I/O
space allowed is 16 bytes; use of I/O space should be avoided in all new designs.
Prefetchability is the ability of memory space to be prefetched. A memory space is
prefetchable if there are no side effects on reads (that is, data is not destroyed by reading,
as from a RAM). Byte write operations can be merged into a single double word write, when
applicable.
When configuring the core as an Endpoint for PCIe (non-Legacy), 64-bit addressing must be
supported for all SRIOV BARs (except BAR5) that have the prefetchable bit set. 32-bit

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

GUI
addressing is permitted for all SRIOV BARs that do not have the prefetchable bit set. The
prefetchable bit related requirement does not apply to a Legacy Endpoint. The minimum
memory address range supported by a BAR is 128 bytes for a PCI Express Endpoint and
16 bytes for a Legacy PCI Express Endpoint.
Disabling Unused Resources
For best results, disable unused base address registers to conserve system resources. A base
address register is disabled by deselecting unused BARs in the GUI.

Interrupt Capabilities
The Interrupt Capabilities screen shown in Figure 3-10 sets the Legacy Interrupt Settings
and MSI Capabilities for all applicable Physical and Virtual Functions. The MSI-X
Capabilities screen shown in Figure 3-11 sets the MSI-X Capabilities.
X-Ref Target - Figure 3-10

Figure 3-10:

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

Page 10: Interrupt Capabilities

www.xilinx.com

GUI

X-Ref Target - Figure 3-11

Figure 3-11:

Page 11: MSI-X Interrupt Capabilities

Legacy Interrupt Settings
•

Enable INTX: Enables the ability of the PCI Express function to generate INTx
interrupts.

•

Interrupt PIN: Indicates the mapping for Legacy Interrupt messages. A setting of
“None” indicates no Legacy Interrupts are used.

MSI Capabilities
•

Enable MSI Capability Structure: Indicates that the MSI Capability structure exists.
Note: Although it is possible not to enable MSI or MSI-X, the result would be a non-compliant
core. The PCI Express Base Specification requires that MSI, MSI-X, or both be enabled.

•

64 bit Address Capable: Indicates that the function can send a 64-bit Message
Address.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

GUI
•

Multiple Message Capable: Selects the number of MSI vectors to request from the
Root Complex.

•

Per Vector Masking Capable: Indicates that the function supports MSI per-vector
Masking.

MSI-X Capabilities
•

Enable MSIx Capability Structure: Indicates that the MSI-X Capability structure exists.
Note: This Capability Structure needs at least one Memory BAR to be configured. The user must
maintain the MSI-X Table and Pending Bit Array in the user application.

•

MSIx Table Settings: Defines the MSI-X Table Structure.
°

Table Size: Specifies the MSI-X Table Size.

Table Offset: Specifies the Offset from the Base Address Register that points to the
Base of the MSI-X Table.

•

BAR Indicator: Indicates the Base Address Register in the Configuration Space that
is used to map the function’s MSI-X Table, onto Memory Space. For a 64-bit Base
Address Register, this indicates the lower DWORD.

MSIx Pending Bit Array (PBA) Settings: Defines the MSI-X Pending Bit Array (PBA)
Structure.
°

PBA Offset: Specifies the Offset from the Base Address Register that points to the
Base of the MSI-X PBA.

PBA BAR Indicator: Indicates the Base Address Register in the Configuration Space
that is used to map the function’s MSI-X PBA, onto Memory Space.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

GUI

Power Management Registers
The Power Management Registers screen shown in Figure 3-12 includes settings for the
Power Management Registers, power consumption, and power dissipation options. These
settings apply to both Physical Functions, if PF1 is enabled.
X-Ref Target - Figure 3-12

Figure 3-12:

Page 12: Power Management Registers

•

D1 Support: When selected, this option indicates that the function supports the D1
Power Management State. See section 3.2.3 of the PCI Bus Power Management Interface
Specification Revision 1.2.

•

PME Support From: When this option is selected, it indicates the power states in which
the function can assert cfg_pm_wake. See section 3.2.3 of the PCI Bus Power
Management Interface Specification Revision 1.2.

•

Device Capability Register 2 Settings: Specifies options for AtomicOps and TPH
Completer Support. See the Device Capability Register 2 description in Chapter 7 of the

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

GUI
PCI Express Base Specification for more information. These settings apply to both
Physical Functions, if PF1 is enabled.
•

BRAM Configuration Options: Can specify the number of receive block RAMs used for
the solution. The table displays the number of receiver credits available for each packet
type.

PCIe Extended Capabilities
The PCIe Extended Capabilities screens shown in Figure 3-13 and Figure 3-14 allow you to
enable PCI Express Extended Capabilities. The Advanced Error Reporting Capability (offset
0x100h) is always enabled. The customization GUI sets up the link list based on the
capabilities enabled. After enabling, you must configure the capability by setting the
applicable attributes in the core top-level defined in Output Generation, page 87. Refer to
Appendix B, Attributes for parameters applicable to each capability.
X-Ref Target - Figure 3-13

Figure 3-13:

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

Page 13: PCIe Extended Capabilities

www.xilinx.com

GUI

X-Ref Target - Figure 3-14

Figure 3-14:

Page 14: PCIe Extended Capabilities 2

Device Serial Number Capability
•

Device Serial Number Capability: An optional PCIe Extended Capability containing a
unique Device Serial Number. When this Capability is enabled, the DSN identifier must
be presented on the Device Serial Number input pin of the port. This Capability must
be turned on to enable the Virtual Channel and Vendor Specific Capabilities

Virtual Channel Capability
•

Virtual Channel Capability: An optional PCIe Extended Capability which allows the
user application to be operated in TCn/VC0 mode. Checking this allows Traffic Class
filtering to be supported. This capability only exists for Physical Function 0.

•

Reject Snoop Transactions (Root Port Configuration Only): When enabled, any
transactions for which the No Snoop attribute is applicable, but is not set in the TLP
header, can be rejected as an Unsupported Request.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

Output Generation

AER Capability
•

Enable AER Capability: An optional PCIe Extended Capability that allows Advanced
Error Reporting. This capability is always enabled.

Additional Optional Capabilities
•

Enable ARI: An optional PCIe Extended Capability that allows Alternate Requestor ID.
This capability is automatically enabled if SRIOV is enabled.

•

Enable PB: An optional PCIe Extended Capability that implements the Power Budgeting
Enhanced Capability Header.

•

Enable RBAR: An optional PCIe Extended Capability that implements the Resizable BAR
Capability.

•

Enable LTR: An optional PCIe Extended Capability that implements the Latency
Tolerance Reporting Capability.

•

Enable DPA: An optional PCIe Extended Capability that implements Dynamic Power
Allocation Capability.

•

Enable TPH: An optional PCIe Extended Capability that implements Transaction
Processing Hints Capability.

Output Generation
The Virtex-7 FPGA Gen3 Integrated Block for PCI Express example design directories and
their associated files are defined in the sections that follow. Click a directory name to go to
the desired directory and its associated files.

Example Design

Top-level project directory; name is user-defined
topdirectory

/
Core release notes readme file
/doc
Product documentation
/example_design
Verilog or VHDL design files
/implement
Implementation script files
implement/results
Contains implement script results

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

Output Generation
implement/xst
Contains synthesis results, when XST is chosen as the synthesis tool
/source
Core source files
/simulation
Simulation scripts
simulation/dsport (for Endpoint configuration only)
Root Port Bus Functional Model
simulation/functional
Functional simulation files
simulation/tests (for Endpoint configuration only)
Test command files

The project directory contains all the CORE Generator tool project files.
Table 3-6:

Project Directory
Name

Description

.xco

CORE Generator software project-specific option file;
can be used as an input to the CORE Generator tool.

_flist.txt

List of files delivered with core.

.{veo|vho}

Verilog or VHDL instantiation template.

_xmdf.tcl

Xilinx standard IP Core information file used by Xilinx
design tools.

_synth.{v|vhd}

Verilog/VHDL top-level solution wrapper for the
Virtex-7 FPGA Gen3 Integrated Block for PCI Express.
This file receives user-specific settings and sets
parameters accordingly

/
The component name directory contains the release notes in the readme file provided with
the core, which can include tool requirements, updates, and issue resolution.
Table 3-7:

Component Name Directory
Name

Description
/

pcie3_7x_v1_1_readme.txt

Release notes file.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

Output Generation

/doc
The doc directory contains the PDF documentation provided with the core.
Table 3-8:

Doc Directory
Name

Description
//doc

pg023_v7_pcie_gen3.pdf

Virtex-7 FPGA Gen3 Integrated Block for PCI Express Product Guide

/example_design
The example_design directory contains the example design files provided with the core.
Table 3-9 shows the directory contents for an Endpoint configuration core.
Table 3-9:

Example Design Directory: Endpoint Configuration
Name

Description

//example_design

xilinx_pcie_3_0_ep_7x_01_lane_
gen1_xc7vx690t-ffg1761-3-PCIE_
X0Y0.ucf

Example design UCF. Filename varies by Device/Port
Type, lane width, maximum link speed, part, package,
Integrated Block for PCI Express block location, and
Xilinx Development Board selected.

xilinx_pcie_3_0_ep_xt.v

Verilog top-level PIO example design file.

pcie_app_7vx.v
PIO_INTR_CTRL.v
EP_MEM.v[hd]
PIO.v[hd]
PIO_EP.v[hd]
PIO_EP_MEM_ACCESS.v[hd]
PIO_TO_CTRL.v[hd]
PIO_RX_ENGINE.v[hd]
PIO_TX_ENGINE.v[hd]

PIO example design files.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

Output Generation

/implement
The implement directory contains the core implementation script files.
Table 3-10:

Implement Directory
Name

Description

//implement

implement.bat
implement.sh

DOS and Linux implementation scripts.

xilinx_pcie_3_0_7vx_ep.prj

XST file list for the core.

xilinx_pcie_3_0_7vx_ep.xst

XST command file.

xilinx_pcie_3_0_7vx_ep.xcf

XST synthesis constraints file.

implement/results
The results directory is created by the implement script. The implement script results are placed in the
results directory.

Table 3-11:

Results Directory
Name

Description

//implement/results

Implement script result files.
Back to Top

implement/xst
The xst directory is created by the XST script. The synthesis results are placed in the xst
directory.
Table 3-12:

XST Results Directory
Name

Description

//implement/xst

XST result files.
Back to Top

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

Output Generation

/source
The source directory contains the generated core source files.
Table 3-13:

Source Directory
Name

Description
//source

pcie_3_0_7vx.v

Verilog top-level core wrapper for the Virtex-7
FPGA Gen3 Integrated Block for PCI Express.

pcie_top.v

AXI4-Stream solution wrapper for the Virtex-7
FPGA Gen3 Integrated Block for PCI Express.

pcie_7vx.v

Solution Wrapper for the Virtex-7 FPGA Gen3
Integrated Block for PCI Express.

pcie_init_ctrl_7vx.v

Initialization Controller for Virtex-7 FPGA
Gen3 Integrated Block for PCI Express

pcie_pipe_pipeline.v
pcie_pipe_lane.v
pcie_pipe_misc.v

PIPE module for the Virtex-7 FPGA Gen3
Integrated Block for PCI Express.

pcie_bram_7vx.v
pcie_bram_7vx_16k.v
pcie_bram_7vx_8k.v
pcie_bram_7vx_cpl.v
pcie_bram_7vx_rep.v
pcie_bram_7vx_rep_8k.v
pcie_bram_7vx_req.v

Block RAM module for the Virtex-7 FPGA Gen3
Integrated Block for PCI Express.

gt_top.v

GTH wrapper for the Virtex-7 FPGA Gen3
Integrated Block for PCI Express.

gt_wrapper.v
pipe_clock.v
pipe_drp.v
pipe_rate.v
pipe_reset.v
pipe_sync.v
pipe_user.v
pipe_wrapper.v

GTH module for the Virtex-7 FPGA GTH
transceivers.

pipe_eq.v
rxeq_scan.v
qpll_drp.v
qpll_reset.v
qpll_wrapper.v

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

Output Generation

/simulation
The simulation directory contains the simulation source files provided with the core.

simulation/dsport
The dsport directory contains the files for the Root Port model test bench.
Table 3-14:

dsport Directory: Endpoint Configuration
Name

Description

//simulation/dsport

pcie_2_1_rp_v7.v[hd]
pci_exp_expect_tasks.v
pci_exp_usrapp_cfg.v[hd]
pci_exp_usrapp_com.v
pci_exp_usrapp_pl.v[hd]
pci_exp_usrapp_rx.v[hd]
pci_exp_usrapp_tx.v[hd]
xilinx_pcie_2_1_rport_v7.v[hd]
test_interface.vhd

Root Port model files.

simulation/functional
The functional directory contains functional simulation scripts provided with the core.

Table 3-15:

Functional Directory
Name

Description

//simulation/functional

board.f

List of files for RTL simulations.

simulate_mti.do

Simulation script for ModelSim.

simulate_ncsim.sh

Simulation script for Cadence IES (Verilog only).

simulate_vcs.sh

Simulation script for VCS (Verilog only).

xilinx_lib_vcs.f

Points to the required SecureIP Model.

board_common.v
(Endpoint configuration only)

Contains test bench definitions (Verilog only).

board.v [hd]

Top-level simulation module.

sys_clk_gen_ds.v[hd]
(Endpoint configuration only)

System differential clock source.

sys_clk_gen.v [hd]

System clock source.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

Output Generation

simulation/tests
Note: This directory exists for Endpoint configuration only.
The tests directory contains test definitions for the example test bench.
Table 3-16:

Tests Directory
Name

Description

//simulation/tests

sample_tests.v
tests.v[hd]

Test definitions for example test bench.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

Chapter 4

Designing with the Core
This chapter includes guidelines and additional information to make designing with the
core easier.

General Design Guidelines
See the 7 Series FPGAs Clocking Resources User Guide, 7 Series FPGAs GTX/GTH Transceivers
User Guide, and 7 Series FPGAs SelectIO™ Resources User Guide [Ref 3] for more information
on clock, transceiver, and I/O placement rules. Pay special attention to clocking conflicts or
errors that might result from choosing I/O and transceivers that do not follow these guides.
Failure to adhere to these guides will result in build errors and data integrity errors.

Clocking
The input system clock signal of the Virtex®-7 FPGA Gen3 Integrated Block for PCI Express
is called ref_clk. The core requires a 100 MHz, 125 MHz, or 250 MHz clock input. The
clock frequency used must match the clock frequency selection in the CORE Generator™
tool GUI.
In a typical PCI Express® solution, the PCI Express reference clock is a spread spectrum
clock (SSC), provided at 100 MHz. In most commercial PCI Express systems, SSC cannot be
disabled. For more information regarding SSC and PCI Express, see Section 4.3.7.1.1 of the
PCI Express Base Specification, rev. 3.0.

Synchronous and Non-Synchronous Clocking
There are two ways to clock the PCI Express system:
•

Using synchronous clocking, where a shared clock source is used for all devices.

•

Using non-synchronous clocking, where each device has its own clock source. Spread
spectrum clocking (SSC) and active state power management (ASPM) must not be used
in systems with non-synchronous clocking.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

Clocking
IMPORTANT: The most commonly used clocking methodology is synchronous clocking. All add-in card

designs must use synchronous clocking due to the characteristics of the provided reference clock. For
devices using the Slot clock, the “Slot Clock Configuration” setting in the Link Status Register must be
enabled in the CORE Generator tool GUI. See Clocking Requirements, page 104 and the 7 Series FPGAs
GTX/GTH Transceivers User Guide for additional information regarding reference clock requirements.

For synchronous clocked systems, each link partner device shares the same clock source.
Figure 4-1 and Figure 4-3 show a system using a 100 MHz reference clock. When using
the 125 MHz or the 250 MHz reference clock option, an external PLL must be used to do
a multiply of 5/4 and 5/2 to convert the 100 MHz clock to 125 MHz and 250 MHz,
respectively, as illustrated in Figure 4-2 and Figure 4-4.
Even if the device is part of an embedded system, if the system uses commercial PCI
Express root complexes or switches along with typical motherboard clocking schemes,
synchronous clocking should still be used as shown in Figure 4-1 and Figure 4-2.
Figure 4-1 through Figure 4-4 illustrate high-level representations of the board layouts.
Designers must ensure that proper coupling, termination, and so forth are used when
laying out the board.
Note: Figure 4-1 through Figure 4-4 are high-level representations of the board layout. Ensure that
proper coupling, termination, and so forth are used when laying out a board.
X-Ref Target - Figure 4-1

%MBEDDED 3YSTEM "OARD

0#) %XPRESS
3WITCH OR 2OOT
#OMPLEX
$EVICE

0#)E ,INK
0#)E ,INK

'4(
4RANSCEIVERS

6IRTEX 84(4 &0'!
%NDPOINT

-(Z
-(Z

0#) %XPRESS
#LOCK /SCILLATOR

Figure 4-1:

Embedded System Using 100 MHz Reference Clock

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

Clocking

X-Ref Target - Figure 4-2

%MBEDDED 3YSTEM "OARD

0#) %XPRESS
3WITCH OR 2OOT
#OMPLEX
$EVICE

0#)E ,INK
0#)E ,INK

'4(
4RANSCEIVERS

6IRTEX 84(4 &0'!
%NDPOINT

-(Z

-(Z
-(Z

0#) %XPRESS
#LOCK /SCILLATOR

%XTERNAL 0,,
X

Figure 4-2:

Embedded System Using 125/250 MHz Reference Clock

X-Ref Target - Figure 4-3

0#) %XPRESS !DD )N #ARD

6IRTEX 84(4 &0'!
%NDPOINT
-(Z WITH 33#
0#) %XPRESS #LOCK

0#)E ,INK

'4(
4RANSCEIVERS

0#) %XPRESS #ONNECTOR
0#)E ,INK

0#)E ,INK

Figure 4-3:

Open System Add-In Card Using 100 MHz Reference Clock

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

Resets

X-Ref Target - Figure 4-4

0#) %XPRESS !DD )N #ARD

%XTERNAL 0,,

-(Z

6IRTEX 84(4 &0'!
%NDPOINT

0#)E ,INK

-(Z WITH 33#
0#) %XPRESS #LOCK

0#)E ,INK

'4(
4RANSCEIVERS

0#)E ,INK

0#) %XPRESS #ONNECTOR

Figure 4-4:

Open System Add-In Card Using 125/250 MHz Reference Clock

Resets
The LogiCORE™ IP Virtex-7 FPGA Gen3 Integrated Block for PCI Express core resets the
system using sys_reset, an asynchronous, active-Low reset signal asserted during the PCI
Express Fundamental Reset. Asserting this signal causes a hard reset of the entire core,
including the GTH transceivers. After the reset is released, the core attempts to link train
and resume normal operation. In a typical Endpoint application, for example an add-in card,
a sideband reset signal is normally present and should be connected to sys_reset. For
Endpoint applications that do not have a sideband system reset signal, the initial hardware
reset should be generated locally. Four reset events can occur in PCI Express:
•

Cold Reset. A Fundamental Reset that occurs at the application of power. The
sys_reset signal is asserted to cause the cold reset of the core.

•

Warm Reset. A Fundamental Reset triggered by hardware without the removal and
re-application of power. The sys_reset signal is asserted to cause the warm reset to
the core.

•

Hot Reset. In-band propagation of a reset across the PCI Express Link through the
protocol, resetting the entire Endpoint device. In this case, sys_reset is not used. In
the case of Hot Reset, the cfg_hot_reset_out signal is asserted to indicate the
source of the reset.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

AXI4-Stream Interface Description
•

Function-Level Reset: In-band propagation of a reset across the PCI Express Link
through the protocol, resetting only a specific function. In this case, the core asserts
the bit of either cfg_flr_in_process and/or cfg_vf_flr_in_process that
corresponds to the function being reset. Logic associated with the function being reset
must assert the corresponding bit of cfg_flr_done or cfg_vf_flr_done to
indicate it has completed the reset process. Support for function-level reset is indicated
via the PF0_DEV_CAP_FUNCTION_LEVEL_RESET_CAPABLE parameter.

The User Application interface of the core has an output signal called user_reset. This
signal is deasserted synchronously with respect to user_clk. The user_reset signal is
asserted as a result of any of these conditions:
•

Fundamental Reset: Occurs (cold or warm) due to assertion of sys_reset.

•

PLL within the Core Wrapper: Loses lock, indicating an issue with the stability of the
clock input.

•

Loss of Transceiver PLL Lock: Any transceiver loses lock, indicating an issue with the PCI
Express Link.

The user_reset signal is deasserted synchronously with user_clk after all of the listed
conditions are resolved, allowing the core to attempt to train and resume normal operation.
Note: Systems designed to the PCI Express electro-mechanical specification provide a sideband

reset signal, which uses 3.3V signaling levels—see the Virtex-7 FPGA data sheet to understand the
requirements for interfacing to such signals.

AXI4-Stream Interface Description
This section provides a detailed description of the features, parameters, and signals
associated with the client-side interfaces of the Virtex-7 FPGA Gen3 Integrated Block for PCI
Express.

Overview of Features
Figure 4-5 illustrates the client-side interface of the Virtex-7 FPGA Gen3 Integrated Block
for PCI Express.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

AXI4-Stream Interface Description

X-Ref Target - Figure 4-5

#OMPLETER 2EQUEST
)NTERFACE
!8)
-ASTER

0#)E #OMPLETER
)NTERFACE

28 -ESSAGE
)NTERFACE

CFG ?MSG ?

#OMPLETER #OMPLETION
)NTERFACE
!8)
3LAVE

6IRTEX &0'!
'EN
)NTEGRATED "LOCK
FOR 0#)E

M?AXIS ?CQ ?

S?AXIS ?CC ?

4AG !VAILABILITY
3TATUS
&LOW #ONTROL
3TATUS

0#)E 2EQUESTER
)NTERFACE

0#)E
#OMPLETER
)NTERFACE

!8)
-ASTER

#LIENT
!PPLICATION

2EQUESTER 2EQUEST
)NTERFACE
!8)
3LAVE

!8)
3LAVE

S?AXIS ?RQ ?

!8)
-ASTER

PCIE ?TAG ?AV;=
PCIE ?TFC ?
CFG ?FC ?

0#)E
2EQUESTER
)NTERFACE

2EQUESTER #OMPLETION
)NTERFACE

!8)
-ASTER

M?AXIS ?RC ?

!8)
3LAVE

Figure 4-5:

Block Diagram of Gen3 Integrated Block Client Interfaces

The interface is organized as four separate interfaces through which data can be transferred
between the PCIe link and the client application:
•

A PCIe Completer reQuest (CQ) interface through which requests arriving from the link
are delivered to the client application.

•

A PCIe Completer Completion (CC) interface through which the client application can
send back responses to the completer requests. The client can process all Non-Posted

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

AXI4-Stream Interface Description
transactions as split transactions. That is, it can continue to accept new requests on the
completer request interface while sending a completion for a request.
•

A PCIe Requester reQuest (RQ) interface through which the client application can
generate requests to remote PCIe devices attached to the link.

•

A PCIe Requester Completion (RC) interface through which the Integrated Block returns
the completions received from the link (in response to the client's requests as PCIe
requester) to the client application.

Each of the four interfaces is based on the AMBA4® AXI4-Stream Protocol Specification.
The width of these interfaces can be configured as 64, 128, or 256 bytes, and the user clock
frequencies can be selected as 62.5, 125, or 250 MHz, depending on the number of lanes
and PCIe generation chosen by the user. Table 4-1 lists the valid combinations of interface
width and user clock frequency for the different link widths and link speeds supported by
the Integrated Block. All four AXI4-Stream interfaces are configured with the same width in
all cases.
In addition, the Integrated Block contains two interfaces through which status information
is communicated to the PCIe master side of the client application:
•

A flow control status interface that provides information on currently available transmit
credit, so that the client application can schedule requests based on available credit.

•

A tag availability status interface that provides information on the number of tags
available to assign to Non-Posted requests, so that the client can schedule requests
without the risk of being blocked by all tags being in use within the PCIe controller.

Finally, the Integrated Block also has a received message interface, through which it can
optionally provide indications to the user logic when a message is received from the link
(instead of transferring the entire message to the client over the CQ interface).
Table 4-1:

Data Width and Clock Frequency Settings for the Client Interfaces

PCI Express Generation/
Maximum Link Speed

Maximum Link
Width Capability
x1

Gen1 (2.5 GT/s)

x4
x8

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

AXI4-Stream
Interface Width

User Clock
Frequency (MHz)

64 bits

62.5

64 bits

125

64 bits

250

64 bits

62.5

64 bits

125

64 bits

250

64 bits

125

64 bits

250

64 bits

250

128 bits

125

100

AXI4-Stream Interface Description

Table 4-1:

Data Width and Clock Frequency Settings for the Client Interfaces (Cont’d)

PCI Express Generation/
Maximum Link Speed

Maximum Link
Width Capability
x1

Gen2 (5.0 GT/s)

x2
x4
x8
x1

Gen3 (8.0 GT/s)

x2
x4
x8

AXI4-Stream
Interface Width

User Clock
Frequency (MHz)

64 bits

62.5

64 bits

125

64 bits

250

64 bits

125

64 bits

250

64 bits

250

128 bits

125

128 bits

250

256 bits

125

64 bits

125

64 bits

250

64 bits

250

128 bits

125

128 bits

250

256 bits

125

256 bits

250

Data Alignment Options
A transaction layer packet (TLP) is transferred on each of the AXI4-Stream interfaces as a
descriptor followed by payload data (when the TLP has a payload). The descriptor has a
fixed size of 16 bytes on the request interfaces and 12 bytes on the completion interfaces.
On its transmit side (towards the link), the Integrated Block assembles the TLP header from
the parameters supplied by the client application in the descriptor. On its receive side
(towards the client), the Integrated Block extracts parameters from the headers of received
TLP and constructs the descriptors for delivering to the client application. Each TLP is
transferred as a packet, as defined in the AXI4-Stream Interface Protocol.
When a payload is present, there are two options for aligning the first byte of the payload
with respect to the datapath.
1. Dword-aligned mode: In this mode, the descriptor bytes are followed immediately by
the payload bytes in the next Dword position, whenever a payload is present.
2. Address-Aligned Mode: In this mode, the payload can begin at any byte position on the
datapath. For data transferred from the Integrated Block to the client, the position of the
first byte is determined as:
n = A mod w

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

101

AXI4-Stream Interface Description
where A is the memory or I/O address specified in the descriptor (for message and
configuration requests, the address is taken as 0), and w is the configured width of the
data bus in bytes. Any gap between the end of the descriptor and the start of the first
byte of the payload is filled with null bytes.
For data transferred from the Integrated Block to the client application, the data alignment
is determined based on the starting address where the data block is destined to in client
memory. For data transferred from the client application to the Integrated Block, the client
must explicitly communicate the position of the first byte to the Integrated Block using the
tuser sideband signals when the address-aligned mode is in use.
In the address-aligned mode, the payload and descriptor are not allowed to overlap. That is,
the transmitter begins a new beat to start the transfer of the payload after it has transmitted
the descriptor. The transmitter fills any gaps between the last byte of the descriptor and the
first byte of the payload with null bytes.
The CORE Generator tool customization GUI applies the data alignment option globally to
all four interfaces. However, advanced users can select the alignment mode independently
for each of the four AXI4-Stream interfaces. This is done by setting the corresponding
alignment mode parameter, with the constraint that the Requester Completion (RC)
interface can be set to the address-aligned mode only when the Requester reQuest (RQ)
interface is configured in the address-aligned mode. See Interface Operation, page 105 for
more details on address alignment and example diagrams.

Straddle Option on Requester Completion Interface
When the Requester Completion (RC) interface is configured for a width of 256 bits, half of
the datapath would remain unused when delivering Completion TLPs with a payload size of
one Dword or less, if only a single TLP were allowed to be sent in the same beat. If such
small back-to-back TLPs were to continue for a long time, this could cause the Completion
FIFO in the Integrated Block to overflow. The RC interface provides a straddle option to
alleviate this issue. See Figure 4-59 for waveforms showing this option.
The straddle option, available only on the 256-bit wide RC interface, is enabled through the
CORE Generator tool customization GUI. See Interface Settings, page 66 for instructions on
enabling the option in the GUI. When this option is enabled, the Integrated Block can start
a new Completion TLP on byte lane 16 when the previous TLP has ended at or before byte
lane 15 in the same beat. Thus, with this option enabled, it is possible for the Integrated
Block to send two Completion TLPs entirely in the same beat on the RC interface, if neither
of them has more than one Dword of payload.
The straddle setting is only available when the interface width is set to 256 bits and the RC
interface is set to Dword-aligned mode.
Table 4-2 lists the valid combinations of interface width, addressing mode, and the straddle
option.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

102

AXI4-Stream Interface Description

Table 4-2:

Valid Combinations of Interface Width, Alignment Mode, and Straddle

Interface Width

Alignment Mode

Straddle Option

Description

64 bits

Dword-aligned

Not applicable

64-bit, Dword-aligned

64 bits

Address-aligned

Not applicable

64-bit, Address-aligned

128 bits

Dword-aligned

Not applicable

128-bit, Dword-aligned

128 bits

Address-aligned

Not applicable

128-bit, Address-aligned

256 bits

Dword-aligned

Disabled

256-bit, Dword-aligned, straddle
disabled

256 bits

Dword-aligned

Enabled

256-bit, Dword-aligned, straddle
enabled (only allowed for the Requester
Completion interface)

256 bits

Address-aligned

Not applicable

256-bit, Address-aligned

Receive Transaction Ordering
The Virtex-7 FPGA Gen3 Integrated Block for PCI Express contains logic on its receive side to
ensure that TLPs received from the link and delivered on its completer request interface and
requester completion interface do not violate the PCI Express transaction ordering
constraints. The ordering actions performed by the Integrated Block are based on the
following key rules:
•

Posted requests must be able to pass Non-Posted requests on the Completer reQuest
(CQ) interface. To enable this capability, the Integrated Block implements a flow control
mechanism on the CQ interface through which client logic can control the flow of
Non-Posted requests without affecting Posted requests. The client logic signals the
availability of a buffer to receive a Non-Posted request by asserting the
pcie_cq_np_req signal.
The Integrated Block delivers a Non-Posted request to the client only when the available
credit is non-zero. The Integrated Block continues to deliver Posted requests while the
delivery of Non-Posted requests has been paused for lack of credit. When no
backpressure is applied by the credit mechanism for the delivery of Non-Posted
requests, the Integrated Block delivers Posted and Non-Posted requests in the same
order as received from the link. For more information on controlling the flow of
Non-Posted requests, see Selective Flow Control for Non-Posted Requests, page 123.

•

PCIe ordering requires that a completion TLP not be allowed to pass a Posted request,
except in the following cases:
°

Completions with the Relaxed Ordering attribute bit set can pass Posted requests

Completions with the ID-based ordering bit set can pass a Posted request if the
completion's Completer ID is different from the Posted request's Requestor ID.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

103

Clocking Requirements
The Integrated Block does not start the transfer of a Completion TLP received from the link
on the Requester Completion (RC) interface until it has completely transferred all Posted
TLPs that arrived before it, unless one of the two rules applies.
After a TLP has been transferred completely to the client side, it is the responsibility of the
client application to enforce ordering constraints whenever needed.

Transmit Transaction Ordering
On the transmit side, the Integrated Block receives TLPs from the user on two different
interfaces: the Requester reQuest (RQ) interface and the Completer Completion (CC)
interface. The Integrated Block does not re-order transactions received from each of these
interfaces. It is difficult to predict how the requester-side requests and completer-side
completions are ordered in the transmit pipeline of the Integrated Block, after these have
been multiplexed into a single traffic stream. In cases where completion TLPs must maintain
ordering with respect to requests, client logic can supply a 4-bit sequence number with any
request that needs to maintain strict ordering with respect to a Completion transmitted
from the CC interface, on the seq_num[3:0] inputs within the s_axis_rq_tuser bus.
The Integrated Block places this sequence number on its pcie_rq_seq_num[3:0] output
and assert pcie_rq_seq_num_vld when the request TLP has reached a point in the
transmit pipeline at which no new completion TLP from the client can pass it. This
mechanism can be used in the following situations to maintain TLP order:
•

The client logic requires ordering to be maintained between a request TLP and a
completion TLP that follows it. In this case, client logic must wait for the sequence
number of the requester request to appear on the pcie_rq_seq_num[3:0] output
before starting the transfer of the completion TLP on the target completion interface.

•

The client logic requires ordering to be maintained between a request TLP and
MSI/MSI-X TLP signaled through the MSI Message interface. In this case, the client
logic must wait for the sequence number of the requester request to appear on the
pcie_rq_seq_num[3:0] output before signaling MSI or MSI-X on the MSI Message
interface.

Clocking Requirements
All client interface signals of the Virtex-7 FPGA Gen3 Integrated Block for PCI Express are
timed with respect to the user clock (user_clk), which can have a frequency of 62.5, 125,
or 250 MHz, depending on the link speed and link width configured (see Table 4-1).

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

104

Interface Operation

Interface Operation
This section describes the operation of the client-side interfaces of the Virtex-7 FPGA Gen3
Integrated Block for PCI Express.

Completer Interface
This interface maps the transactions (memory, I/O read/write, messages, Atomic
Operations) received from the PCIe link into transactions on the Completer reQuest (CQ)
interface based on the AXI4-Stream protocol. The completer interface consists of two
separate interfaces, one for data transfers in each direction. Each interface is based on the
AXI4-Stream protocol, and its width can be configured as 64, 128, or 256 bits. The CQ
interface is for transfer of requests (with any associated payload data) to the client
application, and the Completer Completion (CC) interface is for transferring the Completion
data (for a Non-Posted request) from the client application for forwarding on the link. The
two interfaces operate independently. That is, the Integrated Block can transfer new
requests over the CQ interface while receiving a Completion for a previous request.

Completer Request Descriptor Formats
The Integrated Block transfers each request TLP received from the link over the CQ interface
as an independent AXI4-Stream packet. Each packet starts with a descriptor and can have
payload data following the descriptor. The descriptor is always 16 bytes long, and is sent in
the first 16 bytes of the request packet. The descriptor is transferred during the first two
beats on a 64-bit interface, and in the first beat on a 128-bit or 256-bit interface.
The formats of the descriptor for different request types are illustrated in Figure 4-6,
Figure 4-7, Figure 4-8, and Figure 4-9. The format of Figure 4-6 applies when the request
TLP being transferred is a memory read/write request, an I/O read/write request, or an
Atomic Operation request. The format of Figure 4-7 is used for Vendor-Defined Messages
(Type 0 or Type 1) only. The format of Figure 4-8 is used for all ATS messages (Invalid
Request, Invalid Completion, Page Request, PRG Response). For all other messages, the
descriptor takes the format of Figure 4-9.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

105

Interface Operation

X-Ref Target - Figure 4-6

!DDRESS ;=
!DDRESS 4YPE !4

2 !TTR

4ARGET &UNCTION

4AG

"US

$EVICE&UNCTION 2
2EQUESTER )$

$WORD COUNT

"!2 )$
"!2 !PERTURE

Figure 4-6:

2EQ 4YPE

Completer Request Descriptor Format for Memory, I/O, and Atomic Op Requests

X-Ref Target - Figure 4-7

6ENDOR )$

6ENDOR $EFINED (EADER "YTES

"US

$EVICE &UNCTION

$ESTINATION )$
4, (EADER
"YTE

4, (EADER
"YTE

2 !TTR

-SG #ODE

4AG

"US

-ESSAGE
2OUTING

Figure 4-7:

$EVICE &UNCTION 2

$WORD COUNT

2EQUESTER )$
2EQ 4YPE

Completer Request Descriptor Format for Vendor-Defined Messages

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

106

Interface Operation

X-Ref Target - Figure 4-8

4,0 (EADER "YTES
4, (EADER
"YTE

4, (EADER
"YTE

2 !TTR

-SG #ODE

"US

4AG

$EVICE &UNCTION 2

$WORD #OUNT

2EQUESTER )$

-ESSAGE
2OUTING

2EQ 4YPE

Figure 4-8:

Completer Request Descriptor Format for ATS Messages

X-Ref Target - Figure 4-9

2
/"&& #ODE
FOR /"&& MESSAGE
2ESERVED FOR OTHERS

.O 3NOOP ,ATENCY
FOR ,42 MESSAGE
2ESERVED FOR OTHERS

3NOOP ,ATENCY
FOR ,42 MESSAGE
2ESERVED FOR OTHERS

2 !TTR

-SG #ODE

"US

4AG

-ESSAGE
2OUTING

Figure 4-9:

$EVICE &UNCTION 2
2EQUESTER )$

$WORD #OUNT
2EQ 4YPE

Completer Request Descriptor Format for All Other Messages

Table 4-3 describes the individual fields of the completer request descriptor.
Table 4-3:

Completer Request Descriptor Fields

Bit Index

1:0

Field Name

Description

Address Type

This field is defined for memory transactions and Atomic
Operations only. It contains the AT bits extracted from the TL
header of the request.
00: Address in the request is untranslated
01: Transaction is a Translation Request
10: Address in the request is a translated address
11: Reserved

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

107

Interface Operation

Table 4-3:

Completer Request Descriptor Fields (Cont’d)

Bit Index

Field Name

Description

Address

This field applies to memory, I/O, and Atomic Op requests. It
provides the address from the TLP header. This is the address
of the first Dword referenced by the request. The First_BE
bits from m_axis_cq_tuser must be used to determine
the byte-level address.
When the transaction specifies a 32-bit address, bits [63:32]
of this field are 0.

74:64

Dword Count

These 11 bits indicate the size of the block (in Dwords) to be
read or written (for messages, size of the message payload).
Its range is 0 - 256 Dwords. For I/O accesses, the Dword count
is always 1.
For a zero length memory read/write request, the Dword
count is 1, with the First_BE bits set to all 0s.

78:75

Request Type

Identifies the transaction type. The transaction types and
their encodings are listed in Table 4-4.

Requester ID

PCI Requester ID associated with the request. With legacy
interpretation of RIDs, these 16 bits are divided into an 8-bit
bus number [95:88], 5-bit device number [87:83], and 3-bit
Function number [82:80]. When ARI is enabled, bits [95:88]
carry the 8-bit bus number and [87:80] provide the Function
number.
When the request is a Non-Posted transaction, the client
completer application must store this field and supply it back
to the Integrated Block with the completion data.

Tag

PCIe Tag associated with the request. When the request is a
Non-Posted transaction, the client logic must store this field
and supply it back to the Integrated Block with the
completion data. This field can be ignored for memory writes
and messages.

Target Function

This field is defined for memory, I/O, and Atomic Op requests
only. It provides the Function number the request is targeted
at, determined by the BAR check. When ARI is in use, all 8 bits
of this field are valid. Otherwise, only bits [106:104] are valid.

BAR ID

This field is defined for memory, I/O, and Atomic Op requests
only. It provides the matching BAR number for the address in
the request.
• 000: BAR 0 (VF-BAR 0 for VFs)
• 001: BAR 1 (VF-BAR 1 for VFs)
• 010: BAR 2 (VF-BAR 2 for VFs)
• 011: BAR 3 (VF-BAR 3 for VFs)
• 100: BAR 4 (VF-BAR 4 for VFs)
• 101: BAR 5 (VF-BAR 5 for VFs)
• 110: Expansion ROM Access
For 64-bit transactions, the BAR number is given as the lower
address of the matching pair of BARs (that is, 0, 2, or 4).

63:2

95:80

103:96

111:104

114:112

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

108

Interface Operation

Table 4-3:

Completer Request Descriptor Fields (Cont’d)

Bit Index

Field Name

Description

120:115

BAR Aperture

This 6-bit field is defined for memory, I/O, and Atomic Op
requests only. It provides the aperture setting of the BAR
matching the request. This information is useful in
determining the bits to be used by the client in addressing its
memory or I/O space. For example, a value of 12 indicates
that the aperture of the matching BAR is 4K, and the client
can therefore ignore bits [63:12] of the address.
For VF BARs, the value provided on this output is based on
the memory space consumed by a single VF covered by the
BAR.

123:121

Transaction Class
(TC)

PCIe Transaction Class (TC) associated with the request.
When the request is a Non-Posted transaction, the client
completer application must store this field and supply it back
to the Integrated Block with the completion data.

126:124

Attributes

These bits provide the setting of the Attribute bits associated
with the request. Bit 124 is the No Snoop bit and bit 125 is
the Relaxed Ordering bit. Bit 126 is the ID-Based Ordering bit,
and can be set only for memory requests and messages.
When the request is a Non-Posted transaction, the client
completer application must store this field and supply it back
to the Integrated Block with the completion data.

15:0

Snoop Latency

This field is defined for LTR messages only. It provides the
value of the 16-bit Snoop Latency field in the TLP header of
the message.

31:16

No-Snoop Latency

This field is defined for LTR messages only. It provides the
value of the 16-bit No-Snoop Latency field in the TLP header
of the message.

OBFF Code

This field is defined for OBFF messages only. The OBFF Code
field is used to distinguish between various OBFF cases:
• 1111b: “CPU Active” – System fully active for all device
actions including bus mastering and interrupts
• 0001b: “OBFF” – System memory path available for device
memory read/write bus master activities
• 0000b: “Idle” – System in an idle, low power state
All other codes are reserved.

35:32

This field is defined for all messages. It contains the 8-bit
Message Code extracted from the TLP header.
Appendix F of the PCI Express Base Specification, rev. 3.0
provides a complete list of the supported Message Codes.

111:104

Message Code

114:112

Message Routing

15:0

Destination ID

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

This field is defined for all messages. These bits provide the
3-bit Routing field r[2:0] from the TLP header.
This field applies to Vendor-Defined Messages only. When
the message is routed by ID (that is, when the Message
Routing field is 010 binary), this field provides the
Destination ID of the message.

www.xilinx.com

109

Interface Operation

Table 4-3:

Completer Request Descriptor Fields (Cont’d)

Bit Index

Field Name

Description

63:32

Vendor-Defined
Header

This field applies to Vendor-Defined Messages only. It
contains the bytes extracted from Dword 3 of the TLP header.

63:0

ATS Header

This field is applicable to ATS messages only. It contains the
bytes extracted from Dwords 2 and 3 of the TLP header.

Table 4-4:

Transaction Types

Request Type
(binary)

Description

0000

Memory Read Request

0001

Memory Write Request

0010

I/O Read Request

0011

I/O Write Request

0100

Memory Fetch and Add Request

0101

Memory Unconditional Swap Request

0110

Memory Compare and Swap Request

0111

Locked Read Request (allowed only in Legacy Devices)

1000

Type 0 Configuration Read Request (on Requester side only)

1001

Type 1 Configuration Read Request (on Requester side only)

1010

Type 0 Configuration Write Request (on Requester side only)

1011

Type 1 Configuration Write Request (on Requester side only)

1100

Any message, except ATS and Vendor-Defined Messages

1101

Vendor-Defined Message

1110

ATS Message

1111

Reserved

Completer Request Interface Operation
Figure 4-10 illustrates the signals associated with the completer request interface of the
core. The core delivers each TLP on this interface as an AXI4-Stream packet. The packet
starts with a 128-bit descriptor, followed by data in the case of TLPs with a payload.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

110

Interface Operation

X-Ref Target - Figure 4-10

#LIENT
!PPLICATION

6IRTEX &0'! 'EN
)NTEGRATED "LOCK FOR 0#)E
M?AXIS?CQ?TDATA;=
M?AXIS?CQ?TPARITY;=
M?AXIS?CQ?TVALID
M?AXIS?CQ?TREADY

0#)E #OMPLETER
2EQUEST )NTERFACE

0#)E
#OMPLETER 3IDE
)NTERFACE

M?AXIS?CQ?TKEEP;=
M?AXIS?CQ?TLAST
SOP
!8) 3TREAM
-ASTER

FIRST?BE;=

!8) 3TREAM
3LAVE

LAST?BE;=
BYTE?EN;=
DISCONTINUE
TPH?PRESENT
TPH?TYPE;=
TPH?ST?TAG;=
M?AXIS?CQ?TUSER;=
PCIE?CQ?NP?REQ
PCIE?CQ?NP?REQ?COUNT;=

Figure 4-10:

Completer Request Interface Signals

The completer request interface supports two distinct data alignment modes, selected by
the attribute AXISTEN_IF_CQ_ALIGNMENT_MODE. In the Dword-aligned mode, the first
byte of valid data appears in lane n = (16 + A mod 4) mod w, where:
•

A is the byte-level starting address of the data block being transferred

•

w is the width of the interface in bytes

In the address-aligned mode, the data always starts in a new beat after the descriptor has
ended, and its first valid byte is on lane n = A mod w, where w is the width of the interface
in bytes. For memory, I/O, and Atomic Operation requests, address A is the address
contained in the request. For messages, the address is always taken as 0 for the purpose of
determining the alignment of its payload.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

111

Interface Operation

Completer Memory Write Operation
The timing diagrams in Figure 4-11, Figure 4-12, and Figure 4-13 illustrate the
Dword-aligned transfer of a memory write TLP received from the link across the Completer
reQuest (CQ) interface, when the interface width is configured as 64, 128, and 256 bits,
respectively. For illustration purposes, the starting Dword address of the data block being
written into client memory is assumed to be (m * 32 + 1), for an integer m > 0. Its size is
assumed to be n Dwords, for some n = k * 32 + 29, k > 0.
In both Dword-aligned and address-aligned modes, the transfer starts with the
16 descriptor bytes, followed immediately by the payload bytes. The m_axis_cq_tvalid
signal remains asserted over the duration of the packet. The client can prolong a beat at any
time by deasserting m_axis_cq_tready. The AXI4-Stream interface signals
m_axis_cq_tkeep (one per Dword position) indicate the valid Dwords in the packet
including the descriptor and any null bytes inserted between the descriptor and the
payload. That is, the tkeep bits are set to 1 contiguously from the first Dword of the
descriptor until the last Dword of the payload. During the transfer of a packet, the tkeep bits
can be 0 only in the last beat of the packet, when the packet does not fill the entire width
of the interface. The m_axis_cq_tlast signal is always asserted in the last beat of the
packet.
The CQ interface also includes the First Byte Enable and the Last Enable bits in the
m_axis_cq_tuser bus. These are valid in the first beat of the packet, and specify the valid
bytes of the first and last Dwords of payload.
The m_axi_cq_tuser bus also provides several informational signals that can be used to
simplify the logic associated with the client side of the interface, or to support additional
features. The sop signal is asserted in the first beat of every packet, when its descriptor is
on the bus. The byte enable outputs byte_en[31:0] (one per byte lane) indicate the valid
bytes in the payload. The bits of byte_en are asserted only when a valid payload byte is in
the corresponding lane (that is, not asserted for descriptor or padding bytes between the
descriptor and payload). The asserted byte enable bits are always contiguous from the start
of the payload, except when the payload size is two Dwords or less. For cases of one-Dword
and two-Dword writes, the byte enables can be non-contiguous. Another special case is
that of a zero-length memory write, when the Integrated Block transfers a one-Dword
payload with all byte_en bits set to 0. Thus, the client logic can, in all cases, use the
byte_en signals directly to enable the writing of the associated bytes into memory.
In the Dword-aligned mode, there can be a gap of zero, one, two, or three byte positions
between the end of the descriptor and the first payload byte, based on the address of the
first valid byte of the payload. The actual position of the first valid byte in the payload can
be determined either from first_be[3:0] or byte_en[31:0] in the
m_axis_cq_tuser bus.
When a Transaction Processing Hint is present in the received TLP, the Integrated Block
transfers the parameters associated with the hint (TPH Steering Tag and Steering Tag Type)
on signals within the m_axis_cq_tuser bus.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

112

Interface Operation

X-Ref Target - Figure 4-11

USER?CLK
M?AXIS?CQ?TDATA;=

$%3# $%3# $7

M?AXIS?CQ?TDATA;=

$%3# $%3# $7

$7 N

M?AXIS?CQ?TVALID
M?AXIS?CQ?TREADY
M?AXIS?CQ?TKEEP;=

,!34?"%

M?AXIS?CQ?TLAST
FIRST?BE M?AXIS?CQ?TUSER;=

&)234 "%

LAST?BE M?AXIS?CQ?TUSER;=

,!34 "%

BYTE?EN;= M?AXIS?CQ?TUSER;=

&)234?"%

SOP M?AXIS?CQ?TUSER;=
DISCONTINUE M?AXIS?CQ?TUSER;=
8

Figure 4-11:

Timing Diagram for a Memory Write Transaction on the Completer Request Interface
(Dword-Aligned Mode, Interface Width = 64 Bits)

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

113

Interface Operation

X-Ref Target - Figure 4-12

USER?CLK
M?AXIS?CQ?TDATA;=

$%3# $7

M?AXIS?CQ?TDATA;=

$%3# $7

M?AXIS?CQ?TDATA;=

$%3# $7

M?AXIS?CQ?TDATA;=

$%3# $7

,!34?"%

$7 N

M?AXIS?CQ?TVALID
M?AXIS?CQ?TREADY
M?AXIS?CQ?TKEEP;=
M?AXIS?CQ?TLAST
FIRST?BE M?AXIS?CQ?TUSER;=

&)234 "%

LAST?BE M?AXIS?CQ?TUSER;=

,!34 "%

BYTE?EN;= M?AXIS?CQ?TUSER;=

&)234?"%

SOP M?AXIS?CQ?TUSER;=
DISCONTINUE M?AXIS?CQ?TUSER;=
8

Figure 4-12:

Timing Diagram for a Memory Write Transaction on the Completer Request Interface
(Dword-Aligned Mode, Interface Width = 128 Bits)

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

114

Interface Operation

X-Ref Target - Figure 4-13

USER?CLK
M?AXIS?CQ?TDATA;=

$%3# $7

M?AXIS?CQ?TDATA;=

$%3# $7

M?AXIS?CQ?TDATA;=

$%3# $7

M?AXIS?CQ?TDATA;=

$%3# $7

M?AXIS?CQ?TDATA;=

$7 N

M?AXIS?CQ?TVALID
M?AXIS?CQ?TREADY
M?AXIS?CQ?TKEEP;=

X&&

M?AXIS?CQ?TLAST
FIRST?BE M?AXIS?CQ?TUSER;=

&)234 "%

LAST?BE M?AXIS?CQ?TUSER;=

,!34 "%

BYTE?EN;= M?AXIS?CQ?TUSER;=

,!34?"%

BYTE?EN;= M?AXIS?CQ?TUSER;=

&)234 "%

BYTE?EN; M?AXIS?CQ?TUSER;=

BYTE?EN;= M?AXIS?CQ?TUSER;=

SOP M?AXIS?CQ?TUSER;=
DISCONTINUE M?AXIS?CQ?TUSER;=
8

Figure 4-13:

Timing Diagram for a Memory Write Transaction on the Completer Request Interface
(Dword-Aligned Mode, Interface Width = 256 Bits)

The timing diagrams in Figure 4-14, Figure 4-15, and Figure 4-16 illustrate the
address-aligned transfer of a memory write TLP received from the link across the CQ
interface, when the interface width is configured as 64, 128 and 256 bits, respectively. For
the purpose of illustration, the starting Dword address of the data block being written into
client memory is assumed to be (m * 32 + 1), for an integer m > 0. Its size is assumed to be
n Dwords, for some n = k * 32 + 29, k > 0.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

115

Interface Operation
In the address-aligned mode, the delivery of the payload always starts in the beat following
the last byte of the descriptor. The first byte of the payload can appear on any byte lane,
based on the address of the first valid byte of the payload. The keep outputs
m_axis_cq_tkeep remain High in the gap between the descriptor and the payload. The
actual position of the first valid byte in the payload can be determined either from the least
significant bits of the address in the descriptor or from the byte enable bits
byte_en[31:0] in the m_axis_cq_tuser bus.
For writes of two Dwords or less, the 1s on byte_en cannot be contiguous from the start
of the payload. In the case of a zero-length memory write, the Integrated Block transfers a
one-Dword payload with the byte_en bits all set to 0 for the payload bytes.
X-Ref Target - Figure 4-14

USER?CLK
M?AXIS?CQ?TDATA;=
M?AXIS?CQ?TDATA;=

$%3# $%3#
$%3# $%3# $7

$7 N

M?AXIS?CQ?TVALID
M?AXIS?CQ?TREADY
M?AXIS?CQ?TKEEP;=

M?AXIS?CQ?TLAST
FIRST?BE M?AXIS?CQ?TUSER;=

&)234 "%

LAST?BE M?AXIS?CQ?TUSER;=

,!34 "%

BYTE?EN;= M?AXIS?CQ?TUSER;=
BYTE?EN;= M?AXIS?CQ?TUSER;=

&)234?"%

X&
X&

,!34?"%

SOP M?AXIS?CQ?TUSER;=
DISCONTINUE M?AXIS?CQ?TUSER;=
8

Figure 4-14:

Timing Diagram for a Memory Write Transaction on the Completer Request Interface
(Address-Aligned Mode, Interface Width = 64 Bits)

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

116

Interface Operation

X-Ref Target - Figure 4-15

USER?CLK
M?AXIS?CQ?TDATA;=

$%3#

$7 N
$7 N

M?AXIS?CQ?TDATA;=

$%3# $7

M?AXIS?CQ?TDATA;=

$%3# $7

M?AXIS?CQ?TDATA;=

$%3# $7

M?AXIS?CQ?TVALID
M?AXIS?CQ?TREADY
M?AXIS?CQ?TKEEP;=

M?AXIS?CQ?TLAST
FIRST?BE M?AXIS?CQ?TUSER;=

&)234 "%

LAST?BE M?AXIS?CQ?TUSER;=

,!34 "%

BYTE?EN;= M?AXIS?CQ?TUSER;=

&)234?"%

X&
X&

,!34?"%

SOP M?AXIS?CQ?TUSER;=
DISCONTINUE M?AXIS?CQ?TUSER;=
8

Figure 4-15:

Timing Diagram for a Memory Write Transaction on the Completer Request Interface
(Address-Aligned Mode, Interface Width = 128 Bits)

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

117

Interface Operation

X-Ref Target - Figure 4-16

USER?CLK
M?AXIS?CQ?TDATA;=

$%3#

$7 N

M?AXIS?CQ?TDATA;=

$%3# $7

$7 N

M?AXIS?CQ?TDATA;=

$%3# $7

$7 N

M?AXIS?CQ?TDATA;=

$%3# $7

$7 N

M?AXIS?CQ?TDATA;=

$7 N

M?AXIS?CQ?TDATA;=

$7 N

M?AXIS?CQ?TDATA;=

M?AXIS?CQ?TVALID
M?AXIS?CQ?TREADY
M?AXIS?CQ?TKEEP;=

X&&

M?AXIS?CQ?TLAST
FIRST?BE M?AXIS?CQ?TUSER;=

&)234 "%

LAST?BE M?AXIS?CQ?TUSER;=

,!34 "%

BYTE?EN;= M?AXIS?CQ?TUSER;=

&)234 "%

BYTE?EN;= M?AXIS?CQ?TUSER;=

BYTE?EN; M?AXIS?CQ?TUSER;=

,!34 "%

BYTE?EN;= M?AXIS?CQ?TUSER;=

SOP M?AXIS?CQ?TUSER;=
DISCONTINUE M?AXIS?CQ?TUSER;=
8

Figure 4-16:

Timing Diagram for a Memory Write Transaction on the Completer Request Interface
(Address-Aligned Mode, Interface Width = 256 Bits)

Completer Memory Read Operation
A memory read request is transferred across the completer request interface in the same
manner as a memory write request, except that the AXI4-Stream packet contains only the
16-byte descriptor. The timing diagrams in Figure 4-17, Figure 4-18, and Figure 4-19
illustrate the transfer of a memory read TLP received from the link across the completer
request interface, when the interface width is configured as 64, 128, and 256 bits,

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

118

Interface Operation
respectively. The packet occupies two consecutive beats on the 64-bit interface, while it is
transferred in a single beat on the 128- and 256-bit interfaces. The m_axis_cq_tvalid
signal remains asserted over the duration of the packet. The client can prolong a beat at any
time by deasserting m_axis_cq_tready. The sop signal in the m_axis_cq_tuser bus is
asserted when the first descriptor byte is on the bus.
X-Ref Target - Figure 4-17

USER?CLK
M?AXIS?CQ?TDATA;=

$%3#

M?AXIS?CQ?TDATA;=

$%3#

M?AXIS?CQ?TVALID
M?AXIS?CQ?TREADY
M?AXIS?CQ?TKEEP;=

M?AXIS?CQ?TLAST
FIRST?BE M?AXIS?CQ?TUSER;=

&)234 "%

LAST?BE M?AXIS?CQ?TUSER;=

,!34 "%

BYTE?EN;= M?AXIS?CQ?TUSER;=

SOP M?AXIS?CQ?TUSER;=
DISCONTINUE M?AXIS?CQ?TUSER;=
8

Figure 4-17:

Timing Diagram for a Memory Read Transaction on the Completer Request Interface
(Interface Width = 64 Bits)

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

119

Interface Operation

X-Ref Target - Figure 4-18

USER?CLK
M?AXIS?CQ?TDATA;=

$%3#

M?AXIS?CQ?TDATA;=

$%3#

M?AXIS?CQ?TDATA;=

$%3#

M?AXIS?CQ?TDATA;=

$%3#

M?AXIS?CQ?TVALID
M?AXIS?CQ?TREADY
M?AXIS?CQ?TKEEP;=
M?AXIS?CQ?TLAST
FIRST?BE M?AXIS?CQ?TUSER;=

&)234 "%

LAST?BE M?AXIS?CQ?TUSER;=

,!34 "%

BYTE?EN;= M?AXIS?CQ?TUSER;=

SOP M?AXIS?CQ?TUSER;=
DISCONTINUE M?AXIS?CQ?TUSER;=
8

Figure 4-18:

Timing Diagram for a Memory Read Transaction on the Completer Request Interface
(Interface Width = 128 Bits)

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

120

Interface Operation

X-Ref Target - Figure 4-19

USER?CLK
M?AXIS?CQ?TDATA;=

$%3#

M?AXIS?CQ?TDATA;=

$%3#

M?AXIS?CQ?TDATA;=

$%3#

M?AXIS?CQ?TDATA;=

$%3#

M?AXIS?CQ?TDATA;=
M?AXIS?CQ?TVALID
M?AXIS?CQ?TREADY
M?AXIS?CQ?TKEEP;=
M?AXIS?CQ?TLAST
FIRST?BE M?AXIS?CQ?TUSER;=

&)234 "%

LAST?BE M?AXIS?CQ?TUSER;=

,!34 "%

BYTE?EN;= M?AXIS?CQ?TUSER;=

SOP M?AXIS?CQ?TUSER;=
DISCONTINUE M?AXIS?CQ?TUSER;=
8

Figure 4-19:

Timing Diagram for a Memory Read Transaction on the Completer Request Interface
(Interface Width = 256 Bits)

The byte enable bits associated with the read request for the first and last Dwords are
supplied by the Integrated Block on the m_axis_cq_tuser sideband bus. These bits are
valid when the first descriptor byte is being transferred, and must be used by the client to
determine the byte-level starting address and the byte count associated with the request.
For the special cases of one-Dword and two-Dword reads, the byte enables can be
non-contiguous. The byte enables are contiguous in all other cases. A zero-length memory
read is sent on the CQ interface with the Dword count field in the descriptor set to 1 and the
first and last byte enables set to 0.
The client must respond to each memory read request with a Completion. The data
requested by the read can be sent as a single Completion or multiple Split Completions.
These Completions must be sent via the Completer Completion (CC) interface of the
Integrated Block. The Completions for two distinct requests can be sent in any order, but
the Split Completions for the same request must be in order. The operation of the CC
interface is described in Completer Completion Interface Operation, page 125.

I/O Write Operation
The transfer of an I/O write request on the CQ interface is similar to that of a memory write
request with a one-Dword payload. The transfer starts with the 128-bit descriptor, followed
by the one-Dword payload. When the Dword-aligned mode is in use, the payload Dword

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

121

Interface Operation
immediately follows the descriptor. When the address-alignment mode is in use, the
payload Dword is supplied in a new beat after the descriptor, and its alignment in the
datapath is based on the address in the descriptor. The First Byte Enable bits in the
m_axis_cq_tuser indicate the valid bytes in the payload. The byte enable bits byte_en
also provide this information.
Because an I/O write is a Non-Posted transaction, the client logic must respond to it with a
Completion containing no data payload. The Completions for I/O requests can be sent in
any order. Errors associated with the I/O write transaction can be signaled to the requester
by setting the Completion Status field in the completion descriptor to CA (Completer
Abort) or UR (Unsupported Request), as is appropriate. The operation of the Completer
Completion interface is described in Completer Completion Interface Operation, page 125.

I/O Read Operation
The transfer of an I/O read request on the CQ interface is similar to that of a memory read
request, and involves only the descriptor. The length of the requested data is always one
Dword, and the First Byte Enable bits in m_axis_cq_tuser indicate the valid bytes to be
read.
The client logic must respond to an I/O read request with a one-Dword Completion (or a
Completion with no data in the case of an error). The Completions for two distinct I/O read
requests can be sent in any order. Errors associated with an I/O read transaction can be
signaled to the requester by setting the Completion Status field in the completion
descriptor to CA (Completer Abort) or UR (Unsupported Request), as is appropriate. The
operation of the Completer Completion interface is described in Completer Completion
Interface Operation, page 125.

Atomic Operations on the Completer Request Interface
The transfer of an Atomic Op request on the completer request interface is similar to that of
a memory write request. The payload for an Atomic Op can range from one Dword to eight
Dwords, and its starting address is always aligned on a Dword boundary. The transfer starts
with the 128-bit descriptor, followed by the payload. When the Dword-aligned mode is in
use, the first payload Dword immediately follows the descriptor. When the
address-alignment mode is in use, the payload starts in a new beat after the descriptor, and
its alignment is based on the address in the descriptor. The m_axis_cq_tkeep output
indicates the end of the payload. The byte_en signals in m_axis_cq_tuser also indicate
the valid bytes in the payload. The First Byte Enable and Last Byte Enable bits in
m_axis_cq_tuser should not be used for Atomic Operations.
Because an Atomic Operation is a Non-Posted transaction, the client logic must respond to
it with a Completion containing the result of the operation. Errors associated with the
operation can be signaled to the requester by setting the Completion Status field in the
completion descriptor to Completer Abort (CA) or Unsupported Request (UR), as is
appropriate. The operation of the Completer Completion interface is described in
Completer Completion Interface Operation, page 125.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

122

Interface Operation

Message Requests on the Completer Request Interface
The transfer of a message on the CQ interface is similar to that of a memory write request,
except that a payload might not always be present. The transfer starts with the 128-bit
descriptor, followed by the payload, if present. When the Dword-aligned mode is in use, the
payload immediately follows the descriptor. When the address-alignment mode is in use,
the first Dword of the payload is supplied in a new beat after the descriptor, and always
starts in byte lane 0. The client can determine the end of the end of the payload from the
states of the m_axis_cq_tlast and m_axis_cq_tkeep signals. The byte_en signals in
m_axis_cq_tuser also indicate the valid bytes in the payload. The First Byte Enable and
Last Byte Enable bits in m_axis_cq_tuser should not be used for Message transactions.
The AXISTEN_IF_ENABLE_RX_MSG_INTFC parameter must be set to 0 to enable the
delivery of messages through the CQ interface. When this parameter is set to 0, the
component bits of the AXISTEN_IF_ENABLE_MSG_ROUTE[17:0] parameter can be used
to select the specific message types that the user wants delivered over the CQ interface.
Setting a parameter bit to 1 enables the delivery of the corresponding type of messages on
the interface, and setting it to 0 results in the Integrated Block filtering the message.
When AXISTEN_IF_ENABLE_RX_MSG_INTFC is set to 1, no messages are delivered on the
CQ interface. Indications of received message are instead sent through a dedicated receive
message interface (see Receive Message Interface, page 135).

Aborting a Transfer
For any request that includes an associated payload, the Integrated Block can signal an
error in the transferred payload by asserting the discontinue signal in the
m_axis_cq_tuser bus in the last beat of the packet (along with m_axis_cq_tlast).
This occurs when the Integrated Block has detected an uncorrectable error while reading
data from its internal memories. The client application must discard the entire packet when
it has detected discontinue asserted in the last beat of a packet. This condition is
considered a fatal error in the Integrated Block.

Selective Flow Control for Non-Posted Requests
The PCI Express Base Specification requires that the Completer Request interface continue to
deliver Posted transactions even when the client is unable to accept Non-Posted
transactions. To enable this capability, the Integrated Block implements a credit-based flow
control mechanism on the CQ interface through which client logic can control the flow of
Non-Posted requests without affecting Posted requests. The client logic signals the
availability of buffers for receive Non-Posted requests using the pcie_cq_np_req signal.
The Gen3 Integrated Block delivers a Non-Posted request to the client only when the
available credit is non-zero. The Integrated Block continues to deliver Posted requests while
the delivery of Non-Posted requests has been paused for lack of credit. When no
backpressure is applied by the credit mechanism for the delivery of Non-Posted requests,
the Integrated Block delivers Posted and Non-Posted requests in the same order as received
from the link.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

123

Interface Operation
The Integrated Block maintains an internal credit counter to track the credit available for
Non-Posted requests on the completer request interface. The following algorithm is used to
keep track of the available credit:
•

On reset, the counter is set to 0.

•

After the Integrated Block comes out of reset, in every clock cycle:
°

•

If pcie_cq_np_req is High and no Non-Posted request is being delivered this
cycle, the credit count is incremented by 1, unless it has already reached its
saturation limit of 32.

If pcie_cq_np_req is Low and a Non-Posted request is being delivered this cycle,
the credit count is decremented by 1, unless it is already 0.

Otherwise, the credit count remains unchanged.

The Integrated Block starts delivery of a Non-Posted TLP to the client only if the credit
count is greater than 0.

The client application can either provide a one-cycle pulse on pcie_cq_np_req each time
it is ready to receive a Non-Posted request, or can keep it permanently asserted if it does
not need to exercise selective backpressure of Non-Posted requests. If the credit count is
always non-zero, the Integrated Block delivers Posted and Non-Posted requests in the same
order as received from the link. If it remains 0 for some time, Non-Posted requests can
accumulate in the Integrated Block's FIFO. When the credit count becomes non-zero later,
the Integrated Block first delivers the accumulated Non-Posted requests that arrived before
Posted requests already delivered to the client, and then reverts to delivering the requests
in the order received from the link.
The assertion and deassertion of the pcie_cq_np_req signal does not need to be aligned
with the packet transfers on the completer request interface.
The client can monitor the current value of the credit count on the output
pcie_cq_np_req_count[5:0]. The counter saturates at 32. Because of internal pipeline
delays, there can be several cycles of delay between the Integrated Block receiving a pulse
on the pcie_cq_np_req input and updating the pcie_cq_np_req_count output in
response. Thus, when the client has adequate buffer space available, it should provide the
credit in advance so that Non-Posted requests are not held up by the Integrated Block for
lack of credit.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

124

Interface Operation

Completer Completion Interface Operation
Figure 4-20 illustrates the signals associated with the completer completion interface of the
core. The core delivers each TLP on this interface as an AXI4-Stream packet.
X-Ref Target - Figure 4-20

#LIENT
!PPLICATION

6IRTEX &0'! 'EN
)NTEGRATED "LOCK FOR 0#)E
S?AXIS?CC?TDATA;=
S?AXIS?CC?TPARITY;=
S?AXIS?CC?TVALID
0#)E #OMPLETER
#OMPLETION )NTERFACE

!8) 3TREAM
3LAVE

S?AXIS?CC?TREADY

!8) 3TREAM
-ASTER

S?AXIS?CC?TLAST

0#)E
#OMPLETER 3IDE
)NTERFACE

DISCONTINUE

S?AXIS?CC?TUSER

Figure 4-20:

Completer Completion Interface Signals

The Virtex-7 FPGA Gen3 Integrated Block for PCI Express delivers each TLP on the
Completer Completion (CC) interface as an AXI4-Stream packet. The packet starts with a
96-bit descriptor, followed by data in the case of Completions with a payload.
The CC interface supports two distinct data alignment modes, selected by the
AXISTEN_IF_CC_ALIGNMENT_MODE parameter. In the Dword-aligned mode, the first byte
of valid data must be presented in lane n = (12 + A mod 4) mod w, where A is the byte-level
starting address of the data block being transferred (as conveyed in the Lower Address field
of the descriptor) and w the width of the interface in bytes (8, 16, or 32). In the
address-aligned mode, the data always starts in a new beat after the descriptor has ended.
When transferring the Completion payload for a memory or I/O read request, its first valid
byte is on lane n = A mod w. For all other Completions, the payload is aligned with byte lane
0.

Completer Completion Descriptor Format
The client application sends completion data for a completer request to the CC interface of
the Integrated Block as an independent AXI4-Stream packet. Each packet starts with a
descriptor and can have payload data following the descriptor. The descriptor is always
12 bytes long, and is sent in the first 12 bytes of the completion packet. The descriptor is
transferred during the first two beats on a 64-bit interface, and in the first beat on a 128or 256-bit interface. When the client application splits the completion data for a request

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

125

Interface Operation
into multiple Split Completions, it must send each Split Completion as a separate
AXI4-Stream packet, with its own descriptor.
The format of the completer completion descriptor is illustrated in Figure 4-21. The
individual fields of the completer request descriptor are described in Table 4-5.
X-Ref Target - Figure 4-21

"US

$EVICE&UNCTION 2

$WORD #OUNT

"YTE #OUNT

2EQUESTER )$
#OMPLETION 3TATUS

0OISONED #OMPLETION

!4 2 !DDRESS ;=

,OCKED 2EAD
#OMPLETION

!TTR

"US

$EVICE&UNCTION

4AG

#OMPLETER )$
&ORCE %#2#

Figure 4-21:

#OMPLETER )$ %NABLE

Completer Completion Descriptor Format

Table 4-5:

Completer Completion Descriptor Fields

Bit Index

Field Name

Description

6:0

Lower
Address

For memory read Completions, this field must be set to the least significant
7 bits of the starting byte-level address of the memory block being
transferred. For all other Completions, the Lower Address must be set to all
zeros.

Address Type

This field is defined for Completions of memory transactions and Atomic
Operations only. For these Completions, the client logic must copy the AT
bits from the corresponding request descriptor into this field. This field must
be set to 0 for all other Completions.

28:16

Byte Count

These 13 bits can have values in the range of 0 – 4096 bytes. If a Memory
Read Request is completed using a single Completion, the Byte Count value
indicates Payload size in bytes. This field must be set to 4 for I/O read
Completions and I/O write Completions. The byte count must be set to 1
while sending a Completion for a zero-length memory read, and a dummy
payload of 1 Dword must follow the descriptor.
The byte count must be set to 0 when sending a UR or CA Completion. For
each Memory Read Completion, the Byte Count field must indicate the
remaining number of bytes required to complete the Request, including the
number of bytes returned with the Completion.
If a Memory Read Request is completed using multiple Completions, the Byte
Count value for each successive Completion is the value indicated by the
preceding Completion minus the number of bytes returned with the
preceding Completion. The total number of bytes required to complete a
Memory Read Request is calculated as shown in Table 4-6, page 128.

Locked Read
Completion

9:8

This bit must be set when the Completion is in response to a Locked Read
request. It must be set to 0 for all other Completions.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

126

Interface Operation

Table 4-5:

Completer Completion Descriptor Fields (Cont’d)

Bit Index

Field Name

Description

Dword Count

These 11 bits indicate the size of the payload of the current packet in Dwords.
Its range is 0 - 1K Dwords. This field must be set to 1 for I/O read
Completions and 0 for I/O write Completions. The Dword count must be set
to 1 while sending a Completion for a zero-length memory read. The Dword
count must be set to 0 when sending a UR or CA Completion. In all other
cases, the Dword count must correspond to the actual number of Dwords in
the payload of the current packet.

Completion
Status

These bits must be set based on the type of Completion being sent. The only
valid settings are:
• 000: Successful Completion
• 001: Unsupported Request (UR)
• 100: Completer Abort (CA)

Poisoned
Completion

This bit can be used by the client to poison the Completion TLP being sent.
This bit must be set to 0 for all Completions, except when the client has
detected an error in the block of data following the descriptor and wants to
communicate this information using the Data Poisoning feature of PCI
Express.

63:48

Requester ID

PCI Requester ID associated with the request (copied by the client from the
request).

71:64

Tag

PCIe Tag associated with the request (copied by the client from the request).

Target
Function/
Device
Number

Function number of the completer Function. The client must copy this value
from the Target Function field of the descriptor of the corresponding
request.
When ARI is in use, all 8 bits of this field must be set to the target Function
number. Otherwise, bits [74:72] must be set to the target Function number.
When ARI is not in use, and the Integrated Block is configured as a Root
Complex, the client must supply the 5-bit Device Number of the completer
on bits [79:75].
When ARI is not use and the Integrated Block is configured as an Endpoint,
the client can optionally supply a 5-bit Device Number of the completer on
bits [79:75]. The client must set the Completer ID Enable bit in the descriptor
if a Device Number is supplied on bits [79:75]. This value is used by the
Integrated Block when sending the Completion TLP, instead of the stored
value of the Device Number captured by the Integrated Block from
Configuration Requests.

Completer
Bus Number

Bus number associated with the completer Function. When the Integrated
Block is configured as a Root Complex, the client must supply the 8-bit Bus
Number of the completer in this field.
When the Integrated Block is configured as an Endpoint, the client can
optionally supply a Bus Number in this field. The client must set the
Completer ID Enable bit in the descriptor if a Bus Number is supplied in this
field. This value is used by the Integrated Block when sending the
Completion TLP, instead of the stored value of the Bus Number captured by
the Integrated Block from Configuration Requests.

42:32

45:43

79:72

87:80

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

127

Interface Operation

Table 4-5:

Completer Completion Descriptor Fields (Cont’d)

Bit Index

Field Name

Description

Completer ID
Enable

The purpose of this field is to enable the client to supply the bus and device
numbers to be used in the Completer ID. This field is applicable only to
Endpoint configurations.
If this field is 0, the Integrated Block uses the captured values of the bus and
device numbers to form the Completer ID. If this input is 1, the Integrated
Block uses the bus and device numbers supplied by the client in the
descriptor to form the Completer ID.

91:89

Transaction
Class (TC)

PCIe Transaction Class (TC) associated with the request. The client must copy
this value from the TC field of the associated request descriptor.

94:92

Attributes

PCIe attributes associated with the request (copied from the request). Bit 92
is the No Snoop bit, bit 93 is the Relaxed Ordering bit, and bit 94 is the
ID-Based Ordering bit.

Force ECRC

Force ECRC insertion. Setting this bit to 1 forces the Integrated Block to
append a TLP Digest containing ECRC to the Completion TLP, even when
ECRC is not enabled for the Function sending the Completion.

Table 4-6: Calculating Byte Count from Completer Request first_be[3:0], last_be[3:0], Dword
Count[10:0]
first_be[3:0]

last_be[3:0]

Total Byte Count

1xx1

0000

01x1

0000

1x10

0000

0011

0000

0110

0000

1100

0000

0001

0000

0010

0000

0100

0000

1000

0000

xxx1

1xxx

Dword_count*4

xxx1

01xx

(Dword_count*4)-1

xxx1

001x

(Dword_count*4)-2

xxx1

0001

(Dword_count*4)-3

xx10

1xxx

(Dword_count*4)-1

xx10

01xx

(Dword_count*4)-2

xx10

001x

(Dword_count*4)-3

xx10

0001

(Dword_count*4)-4

x100

1xxx

(Dword_count*4)-2

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

128

Interface Operation

Table 4-6: Calculating Byte Count from Completer Request first_be[3:0], last_be[3:0], Dword
Count[10:0] (Cont’d)
first_be[3:0]

last_be[3:0]

Total Byte Count

x100

01xx

(Dword_count*4)-3

x100

001x

(Dword_count*4)-4

x100

0001

(Dword_count*4)-5

1000

1xxx

(Dword_count*4)-3

1000

01xx

(Dword_count*4)-4

1000

001x

(Dword_count*4)-5

1000

0001

(Dword_count*4)-6

Completions with Successful Completion Status
The client must return a Completion to the CC interface of the Integrated Block for every
Non-Posted request it receives from the completer request interface. When the request
completes with no errors, the client must return a Completion with Successful Completion
(SC) status. Such a Completion might or might not contain a payload, depending on the
type of request. Furthermore, the data associated with the request can be broken up into
multiple Split Completions when the size of the data block exceeds the maximum payload
size configured. Client logic is responsible for splitting the data block into multiple Split
Completions when needed. The client must transfer each Split Completion over the
completer completion interface as a separate AXI4-Stream packet, with its own 12-byte
descriptor.
In the example timing diagrams of this section, the starting Dword address of the data block
being transferred (as conveyed in bits [6:2] of the Lower Address field of the descriptor) is
assumed to be (m * 8 + 1), for an integer m. The size of the data block is assumed to be n
Dwords, for some n = k * 32 + 28, k > 0.
The CC interface supports two data alignment modes: Dword-aligned and address-aligned.
The timing diagrams in Figure 4-22, Figure 4-23, and Figure 4-24 illustrate the
Dword-aligned transfer of a Completion from the client across the CC interface, when the
interface width is configured as 64, 128, and 256 bits, respectively. In this case, the first
Dword of the payload starts immediately after the descriptor. When the data block is not a
multiple of four bytes, or when the start of the payload is not aligned on a Dword address
boundary, the client must add null bytes to align the start of the payload on a Dword
boundary and make the payload a multiple of Dwords. For example, when the data block
starts at byte address 7 and has a size of 3 bytes, the client must add three null bytes before
the first byte and two null bytes at the end of the block to make it two Dwords long. Also,
in the case of non-contiguous reads, not all bytes in the data block returned are valid. In
that case, the client must return the valid bytes in the proper positions, with null bytes
added in gaps between valid bytes, when needed. The interface does not have any signals
to indicate the valid bytes in the payload. This is not required, as the requester is
responsible for keeping track of the byte enables in the request and discarding invalid bytes
from the Completion.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

129

Interface Operation
In the Dword-aligned mode, the transfer starts with the 12 descriptor bytes, followed
immediately by the payload bytes. The client must keep the s_axis_cc_tvalid signal
asserted over the duration of the packet. The Integrated Block treats the deassertion of
s_axis_cc_tvalid during the packet transfer as an error, and nullifies the corresponding
Completion TLP transmitted on the link to avoid data corruption.
The client must also assert the s_axis_cc_tlast signal in the last beat of the packet. The
Integrated Block can deassert s_axis_cc_tready in any cycle if it is not ready to accept
data. The client must not change the values on the CC interface during a clock cycle that the
Integrated Block has deasserted s_axis_cc_tready.
X-Ref Target - Figure 4-22

USER?CLK
S?AXIS?CC?TDATA;=
S?AXIS?CC?TDATA;=

$%3# $%3# $7

$%3# $7

$7 N

S?AXIS?CC?TVALID
S?AXIS?CC?TREADY
S?AXIS?CC?TKEEP;=

S?AXIS?CC?TLAST
DISCONTINUE S?AXIS?CC?TUSER;=
8

Figure 4-22:

Timing Diagram for the Transfer of a Normal Completion on the Completer Completion
Interface (Dword-Aligned Mode, Interface Width = 64 Bits)

X-Ref Target - Figure 4-23

USER?CLK
S?AXIS?CC?TDATA;=

$%3# $7

$7 N

S?AXIS?CC?TDATA;=

$%3# $7

$7 N

S?AXIS?CC?TDATA;=

$%3# $7

$7 N

S?AXIS?CC?TDATA;=

S?AXIS?CC?TVALID
S?AXIS?CC?TREADY
S?AXIS?CC?TKEEP;=

S?AXIS?CC?TLAST
DISCONTINUE S?AXIS?CC?TUSER;=
8

Figure 4-23:

Timing Diagram for the Transfer of a Normal Completion on the Completer Completion
Interface (Dword-Aligned Mode, Interface Width = 128 Bits)

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

130

Interface Operation

X-Ref Target - Figure 4-24

USER?CLK
S?AXIS?CC?TDATA;=

$%3# $7

$7 N

S?AXIS?CC?TDATA;=

$%3# $7

$7 N

S?AXIS?CC?TDATA;=

$%3# $7

$7 N

S?AXIS?CC?TDATA;=

$7 N

S?AXIS?CC?TDATA;=

$7 N

S?AXIS?CC?TDATA;=

$7 N

S?AXIS?CC?TDATA;=

$7 N

S?AXIS?CC?TDATA;=

S?AXIS?CC?TVALID
S?AXIS?CC?TREADY
S?AXIS?CC?TKEEP;=

X&&

S?AXIS?CC?TLAST
DISCONTINUE S?AXIS?CC?TUSER;=
8

Figure 4-24:

Timing Diagram for the Transfer of a Normal Completion on the Completer Completion
Interface (Dword-Aligned Mode, Interface Width = 256 Bits)

In the address-aligned mode, the delivery of the payload always starts in the beat following
the last byte of the descriptor. For memory read Completions, the first byte of the payload
can appear on any byte lane, based on the address of the first valid byte of the payload. For
all other Completions, the payload must start in byte lane 0.
The timing diagrams in Figure 4-25, Figure 4-26, and Figure 4-27 illustrate the
address-aligned transfer of a memory read Completion across the completer completion
interface, when the interface width is configured as 64, 128, and 256 bits, respectively. For
the purpose of illustration, the starting Dword address of the data block being transferred
(as conveyed in bits [6:2] of the Lower Address field of the descriptor) is assumed to be
(m * 8 +1 ), for some integer m. The size of the data block is assumed to be n Dwords, for
some n = k * 32 + 28, k > 0.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

131

Interface Operation

X-Ref Target - Figure 4-25

USER?CLK
S?AXIS?CC?TDATA;=
S?AXIS?CC?TDATA;=

$%3# $%3#
$%3#

$7
$7

$7 N

S?AXIS?CC?TVALID
S?AXIS?CC?TREADY
S?AXIS?CC?TKEEP;=

S?AXIS?CC?TLAST
DISCONTINUE S?AXIS?CC?TUSER;=
8

Figure 4-25:

Timing Diagram for the Transfer of a Normal Completion on the Completer Completion
Interface (Address-Aligned Mode, Interface Width = 64 Bits)

X-Ref Target - Figure 4-26

USER?CLK
S?AXIS?CC?TDATA;=

$%3#

S?AXIS?CC?TDATA;=

$%3# $7

S?AXIS?CC?TDATA;=

$%3# $7

S?AXIS?CC?TDATA;=

$7 N

S?AXIS?CC?TVALID
S?AXIS?CC?TREADY
S?AXIS?CC?TKEEP;=

S?AXIS?CC?TLAST
DISCONTINUE S?AXIS?CC?TUSER;=
8

Figure 4-26:

Timing Diagram for the Transfer of a Normal Completion on the Completer Completion
Interface (Address-Aligned Mode, Interface Width = 128 Bits)

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

132

Interface Operation

X-Ref Target - Figure 4-27

USER?CLK
S?AXIS?CC?TDATA;=

$%3#

$7 N

S?AXIS?CC?TDATA;=

$%3# $7

$7 N

S?AXIS?CC?TDATA;=

$%3# $7

$7 N

S?AXIS?CC?TDATA;=

$7 N

S?AXIS?CC?TDATA;=

$7 N

S?AXIS?CC?TDATA;=

S?AXIS?CC?TVALID
S?AXIS?CC?TREADY
S?AXIS?CC?TKEEP;=

X&&

S?AXIS?CC?TLAST
DISCONTINUE S?AXIS?CC?TUSER;=
8

Figure 4-27:

Timing Diagram for the Transfer of a Normal Completion on the Completer Completion
Interface (Address-Aligned Mode, Interface Width = 256 Bits)

Aborting a Completion Transfer
The client can abort the transfer of a Completion on the completer completion interface at
any time during the transfer of the payload by asserting the discontinue signal in the
s_axis_cc_tuser bus. The Integrated Block nullifies the corresponding TLP on the link to
avoid data corruption.
The client can assert this signal in any cycle during the transfer, when the Completion being
transferred has an associated payload. The client can either choose to terminate the packet
prematurely in the cycle where the error was signaled (by asserting s_axis_cc_tlast), or
can continue until all bytes of the payload are delivered to the Integrated Block. In the latter
case, the Integrated Block treats the error as sticky for the following beats of the packet,
even if the client deasserts the discontinue signal before reaching the end of the packet.
The discontinue signal can be asserted only when s_axis_cc_tvalid is High. The
Integrated Block samples this signal when s_axis_cc_tvalid and s_axis_cc_tready
are both asserted. Thus, after assertion, the discontinue signal should not be deasserted
until s_axis_cc_tready is asserted.
When the Integrated Block is configured as an Endpoint, this error is reported by the
Integrated Block to the Root Complex to which it is attached, as an Uncorrectable Internal
Error using the Advanced Error Reporting (AER) mechanisms.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

133

Interface Operation

Completions with Error Status (UR and CA)
When responding to a request received on the completer request interface with an
Unsupported Request (UR) or Completion Abort (CA) status, the client must send a
three-Dword completion descriptor in the format of Figure 4-21, followed by five additional
Dwords containing information on the request that generated the Completion. These five
Dwords are necessary for the Integrated Block to log information about the request in its
AER header log registers.
Figure 4-28 shows the sequence of information transferred when sending a Completion
with UR or CA status. The information is formatted as an AXI4-Stream packet with a total of
8 Dwords, which are organized as follows:
•

The first three Dwords contain the completion descriptor in the format of Figure 4-21.

•

The fourth Dword contains the state of the following signals in m_axis_cq_tuser,
copied from the request:

•

The First Byte Enable bits first_be[3:0] in m_axis_cq_tuser.

The Last Byte Enable bits last_be[3:0] in m_axis_cq_tuser.

Signals carrying information on Transaction Processing Hint: tph_present,
tph_type[1:0], and tph_st_tag[7:0] in m_axis_cq_tuser.

The four Dwords of the request descriptor received from the Integrated Block with the
request.

X-Ref Target - Figure 4-28

#OMPLETION $ESCRIPTOR $7

TPH?ST?TAG

TPH?TYPE;=

#OMPLETION $ESCRIPTOR $7

LAST?BE FIRST ?BE
TPH?PRESENT

2EQUEST $ESCRIPTOR $7

2EQUEST $ESCRIPTOR $7
8

Figure 4-28:

Composition of the AXI4-Stream Packet for UR and CA Completions

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

134

Interface Operation
The entire packet takes four beats on the 64-bit interface, two beats on the 128-bit
interface, and a single beat on the 256-bit interface. The packet is transferred in an identical
manner in both the Dword-aligned mode and the address-aligned mode, with the Dwords
packed together. The client must keep the s_axis_cc_tvalid signal asserted over the
duration of the packet. It must also assert the s_axis_cc_tlast signal in the last beat of
the packet. The Integrated Block can deassert s_axis_cc_tready in any cycle if it is not
ready to accept. The client must not change the values on the CC interface in any cycle that
the Integrated Block has deasserted s_axis_cc_tready.

Receive Message Interface
The Virtex-7 FPGA Gen3 Integrated Block for PCI Express provides a separate receive
message interface which the client can optionally use to receive indications of messages
received from the link. This interface is enabled by the
AXISTEN_IF_ENABLE_RX_MSG_INTFC parameter. When the receive message interface is
enabled, the Integrated Block signals the arrival of a message from the link by setting the
cfg_msg_received_type[4:0] output to indicate the type of message (see Table 4-7)
and pulsing the cfg_msg_received signal for one or more cycles. The duration of
assertion of cfg_msg_received is determined by the type of message received (see
Table 4-8). When cfg_msg_received is High, the Integrated Block transfers any
parameters associated with the message on the bus 8 bits at a time on the bus
cfg_msg_received_data. The parameters transferred on this bus in each cycle of
cfg_msg_received assertion for various message types are listed in Table 4-8. For
Vendor-Defined Messages, the Integrated Block transfers only the first Dword of any
associated payload across this interface. When larger payloads are in use, the completer
request interface should be used for the delivery of messages.
Table 4-7:

Message Type Encoding on Receive Message Interface

cfg_msg_received_type[4:0]

Message Type

ERR_COR

ERR_NONFATAL

ERR_FATAL

Assert_INTA

Deassert_ INTA

Assert_INTB

Deassert_ INTB

Assert_INTC

Deassert_ INTC

Assert_INTD

Deassert_ INTD

PM_PME

PME_TO_Ack

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

135

Interface Operation

Table 4-7:

Message Type Encoding on Receive Message Interface (Cont’d)

cfg_msg_received_type[4:0]

Message Type

PME_Turn_Off

PM_Active_State_Nak

Set_Slot_Power_Limit

Latency Tolerance Reporting (LTR)

Optimized Buffer Flush/Fill (OBFF)

Unlock

Vendor_Defined Type 0

Vendor_Defined Type 1

ATS Invalid Request

ATS Invalid Completion

ATS Page Request

ATS PRG Response

25 - 31

Reserved

Table 4-8:

Message Parameters on Receive Message Interface

Message Type

Number of Cycles of
cfg_msg_received
Assertion

Parameter Transferred on
cfg_msg_received_data[7:0]

ERR_COR, ERR_NONFATAL,
ERR_FATAL

Cycle 1: Requester ID, Bus Number
Cycle 2: Requester ID, Device/Function Number

Assert_INTx, Deassert_INTx

Cycle 1: Requester ID, Bus Number
Cycle 2: Requester ID, Device/Function Number

PM_PME, PME_TO_Ack,
PME_Turn_off,
PM_Active_State_Nak

Cycle 1: Requester ID, Bus Number
Cycle 2: Requester ID, Device/Function Number

Cycle
Cycle
Cycle
Cycle
Cycle
Cycle

1:
2:
3:
4:
5:
6:

Requester ID, Bus Number
Requester ID, Device/Function Number
bits [7:0] of payload
bits [15:8] of payload
bits [23:16] of payload
bits [31:24] of payload

Latency Tolerance
Reporting (LTR)

Cycle
Cycle
Cycle
Cycle
Cycle
Cycle

1:
2:
3:
4:
5:
6:

Requester ID, Bus Number
Requester ID, Device/Function Number
bits [7:0] of Snoop Latency
bits [15:8] of Snoop Latency
bits [7:0] of No-Snoop Latency
bits [15:8] of No-Snoop Latency

Optimized Buffer Flush/Fill
(OBFF)

Cycle 1: Requester ID, Bus Number
Cycle 2: Requester ID, Device/Function Number
Cycle 3: OBFF Code

Set_Slot_Power_Limit

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

136

Interface Operation

Table 4-8:

Message Parameters on Receive Message Interface (Cont’d)

Message Type

Number of Cycles of
cfg_msg_received
Assertion

Parameter Transferred on
cfg_msg_received_data[7:0]

Unlock

Cycle 1: Requester ID, Bus Number
Cycle 2: Requester ID, Device/Function Number

4 cycles when no data
present, 8 cycles when
data present.

Cycle
Cycle
Cycle
Cycle
Cycle
Cycle
Cycle
Cycle

1:
2:
3:
4:
5:
6:
7:
8:

Requester ID, Bus Number
Requester ID, Device/Function Number
Vendor ID[7:0]
Vendor ID[15:8]
bits [7:0] of payload
bits [15:8] of payload
bits [23:16] of payload
bits [31:24] of payload

Vendor_Defined Type 1

4 cycles when no data
present, 8 cycles when
data present.

Cycle
Cycle
Cycle
Cycle
Cycle
Cycle
Cycle
Cycle

1:
2:
3:
4:
5:
6:
7:
8:

Requester ID, Bus Number
Requester ID, Device/Function Number
Vendor ID[7:0]
Vendor ID[15:8]
bits [7:0] of payload
bits [15:8] of payload
bits [23:16] of payload
bits [31:24] of payload

ATS Invalid Request

Cycle 1: Requester ID, Bus Number
Cycle 2: Requester ID, Device/Function Number

ATS Invalid Completion

Cycle 1: Requester ID, Bus Number
Cycle 2: Requester ID, Device/Function Number

ATS Page Request

Cycle 1: Requester ID, Bus Number
Cycle 2: Requester ID, Device/Function Number

ATS PRG Response

Cycle 1: Requester ID, Bus Number
Cycle 2: Requester ID, Device/Function Number

Vendor_Defined Type 0

Figure 4-29 is a timing diagram showing the example of a Set_Slot_Power_Limit message on
the receive message interface. This message has an associated one-Dword payload. For this
message, the parameters are transferred over six consecutive cycles. The following
information appears on the cfg_msg_received_data bus in each cycle:
•

Cycle 1: Bus number of Requester ID

•

Cycle 2: Device/Function Number of Requester ID

•

Cycle 3: Bits [7:0] of the payload Dword

•

Cycle 4: Bits [15:8] of the payload Dword

•

Cycle 5: Bits [23:16] of the payload Dword

•

Cycle 6: Bits [31:24] of the payload Dword

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

137

Interface Operation

X-Ref Target - Figure 4-29

USER?CLK
CFG?MSG?RECEIVED
CFG?MSG?RECEIVED?TYPE;=
CFG?MSG?RECEIVED?DATA;=

X&
"US

$EV&N 0,;= 0,;= 0,;= 0,;=
8

Figure 4-29:

Example Timing Diagram for the Receive Message Interface

The Integrated Block inserts a gap of at least one clock cycle between successive pulses on
the cfg_msg_received output. There is no mechanism for the user to apply backpressure
on the message indications delivered through the receive message interface. When using
this interface, the client logic must always be ready to receive message indications.

Receive Message Interface Design Requirements
When configured as an Endpoint, the client application must implement one of the
following:
1. The client application must issue Non-Posted Requests that result in Completions with
the RO bit set.
2. The client application must not exceed the configured completion space.
This requirement ensures the RX Completion buffer does not overflow.

Requester Interface
The requester interface enables a client Endpoint application to initiate PCI transactions as
a bus master across the PCIe link to the host memory. For Root Complexes, this interface is
also used to initiate I/O and configuration requests. This interface can also be used by both
Endpoints and Root Complexes to send messages on the PCIe link. The transactions on this
interface are similar to those on the completer interface, except that the roles of the
Virtex-7 FPGA Gen3 Integrated Block for PCI Express and the client application are reversed.
Posted transactions are performed as single indivisible operations and Non-Posted
transactions as split transactions.
The requester interface consists of two separate interfaces, one for data transfer in each
direction. Each interface is based on the AXI4-Stream protocol, and its width can be
configured as 64, 128, or 256 bits. The Requester reQuest (RQ) interface is for transfer of
requests (with any associated payload data) from the client application to the Integrated
Block, and the Requester Completion (RC) interface is used by the Integrated Block to
deliver Completions received from the link (for Non-Posted requests) to the client
application. The two interfaces operate independently. That is, the client can transfer new
requests over the RQ interface while receiving a completion for a previous request.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

138

Interface Operation

Requester Request Interface Operation
On the RQ interface, the client delivers each TLP as an AXI4-Stream packet. The packet starts
with a 128-bit descriptor, followed by data in the case of TLPs with a payload. Figure 4-30
shows the signals associated with the requester request interface.
X-Ref Target - Figure 4-30

#LIENT
!PPLICATION

6IRTEX &0'! 'EN
)NTEGRATED "LOCK FOR 0#)E
S?AXIS?RQ?TDATA;=
S?AXIS?RQ?TPARITY;=
S?AXIS?RQ?TVALID
0#)E 2EQUESTER
2EQUEST )NTERFACE

S?AXIS?RQ?TREADY

0#)E
2EQUESTER
)NTERFACE

S?AXIS?RQ?TLAST
S?AXIS?RQ?TKEEP;=
FIRST?BE;=
LAST?BE;=
ADDR?OFFSET;=
DISCONTINUE
TPH?PRESENT
TPH?TYPE;=
!8) 3TREAM
3LAVE

TPH?ST?TAG;=

!8) 3TREAM
-ASTER

TPH?INDIRECT?TAG?EN
SEQ?NUM;=
S?AXIS?RQ?TUSER;=

PCIE?RQ?TAG;=
PCIE?RQ?TAG?VLD
PCIE?TFC?NPH;=
PCIE?TFC?NPD;=
PCIE?RQ?TAG?AV;=
PCIE?RQ?SEQ?NUM;=
PCIE?RQ?SEQ?NUM?VLD

Figure 4-30:

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

Requester Request Interface

www.xilinx.com

139

Interface Operation
The RQ interface supports two distinct data alignment modes for transferring payloads,
selected by the AXISTEN_IF_RQ_ALIGNMENT_MODE parameter. In the Dword-aligned
mode, the client logic must provide the first Dword of the payload immediately after the
last Dword of the descriptor. It must also set the bits in first_be[3:0] to indicate the
valid bytes in the first Dword and the bits in last_be[3:0] (both part of the bus
s_axis_rq_tuser) to indicate the valid bytes in the last Dword of the payload. In the
address-aligned mode, the client must start the payload transfer in the beat following the
last Dword of the descriptor, and its first Dword can be in any of the possible Dword
positions on the datapath. The client communicates the offset of the first Dword on the
datapath using the addr_offset[2:0] signals in s_axis_rq_tuser. As in the case of
the Dword-aligned mode, the client must also set the bits in first_be[3:0] to indicate
the valid bytes in the first Dword and the bits in last_be[3:0] to indicate the valid bytes
in the last Dword of the payload.
When the Transaction Processing Hint Capability is enabled in the Integrated Block, the
client can provide an optional Hint with any memory transaction using the tph_* signals
included in the s_axis_rq_tuser bus. To supply a Hint with a request, the client logic
must assert tph_present in the first beat of the packet, and provide the TPH Steering Tag
and Steering Tag Type on tph_st_tag[7:0] and tph_st_type[1:0], respectively.
Instead of supplying the value of the Steering Tag to be used, the client also has the option
of providing an indirect Steering Tag. This is done by setting the tph_indirect_tag_en
signal to 1 when tph_present is asserted, and placing an index on tph_st_tag[7:0],
instead of the tag value. The Integrated Block then reads the tag stored in its Steering Tag
Table associated with the requester Function at the offset specified in the index and inserts
it in the request TLP.

Requester Request Descriptor Formats
The client must transfer each request to be transmitted on the link to the RQ interface of
the Integrated Block as an independent AXI4-Stream packet. Each packet must start with a
descriptor and can have payload data following the descriptor. The descriptor is always 16
bytes long, and must be sent in the first 16 bytes of the request packet. The descriptor is
transferred during the first two beats on a 64-bit interface, and in the first beat on a 128-bit
or 256-bit interface.
The formats of the descriptor for different request types are illustrated in Figure 4-31
through Figure 4-35. The format of Figure 4-31 applies when the request TLP being
transferred is a memory read/write request, an I/O read/write request, or an Atomic
Operation request. The format in Figure 4-32 is used for Configuration Requests. The
format in Figure 4-33 is used for Vendor-Defined Messages (Type 0 or Type 1) only. The
format in Figure 4-34 is used for all ATS messages (Invalid Request, Invalid Completion,
Page Request, PRG Response). For all other messages, the descriptor takes the format
shown in Figure 4-35.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

140

Interface Operation

X-Ref Target - Figure 4-31

!DDRESS;=
!DDRESS 4YPE !4

!TTR

"US

$EVICE&UNCTION

4AG

"US

&ORCE %#2#

$EVICE&UNCTION

$WORD #OUNT

2EQUESTER )$

#OMPLETER )$

2EQ 4YPE
0OISONED 2EQUEST

2EQUESTER )$ %NABLE

Figure 4-31:

Requester Request Descriptor Format for Memory, I/O, and Atomic Op Requests

X-Ref Target - Figure 4-32

%XT 2EG
2EG .UMBER
2ESERVED
.UMBER

2ESERVED

!TTR

"US

$EVICE&UNCTION

4AG

"US

2EQUESTER )$

#OMPLETER )$
&ORCE %#2#

2EQUESTER )$ %NABLE

Figure 4-32:

$EVICE&UNCTION

["US .UMBER;=
$EVICE .UMBER;=
&UNCTION .UMBER;=]

$WORD COUNT
2EQ 4YPE
0OISONED 2EQUEST
8

Requester Request Descriptor Format for Configuration Requests

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

141

Interface Operation

X-Ref Target - Figure 4-33

"US

6ENDOR )$

6ENDOR $EFINED (EADER "YTES

$EVICE &UNCTION

$ESTINATION )$
4, (EADER
"YTE

4, (EADER
"YTE

!TTR

&ORCE %#2#

-SG #ODE

"US

4AG

2EQUESTER )$

-ESSAGE
2OUTING
2EQUESTER )$ %NABLE

Figure 4-33:

$EVICE &UNCTION

$WORD #OUNT
2EQ 4YPE
0OISONED 2EQUEST
8

Requester Request Descriptor Format for Vendor-Defined Messages

X-Ref Target - Figure 4-34

4, (EADER "YTES
4, (EADER
"YTE

4, (EADER
"YTE

!TTR

&ORCE %#2#

-SG #ODE

4AG

"US

-ESSAGE
2OUTING
2EQUESTER )$ %NABLE

Figure 4-34:

$EVICE &UNCTION
2EQUESTER )$

$WORD #OUNT
2EQ 4YPE
0OISONED 2EQUEST
8

Requester Request Descriptor Format for ATS Messages

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

142

Interface Operation

X-Ref Target - Figure 4-35

2
/"&& #ODE
FOR /"&& MESSAGE
2ESERVED FOR OTHERS

.O 3NOOP ,ATENCY
FOR ,42 MESSAGE
2ESERVED FOR OTHERS

3NOOP ,ATENCY
FOR ,42 MESSAGE
2ESERVED FOR OTHERS

!TTR

&ORCE %#2#

-SG #ODE

"US

4AG

-ESSAGE
2OUTING
2EQUESTER )$ %NABLE

Figure 4-35:

$EVICE&UNCTION
2EQUESTER )$

$WORD #OUNT
2EQ 4YPE
0OISONED 2EQUEST
8

Requester Request Descriptor Format for all other Messages

Table 4-9 describes the individual fields of the completer request descriptor.
Table 4-9:

Requester Request Descriptor Fields

Bit Index

1:0

63:2

74:64

Field Name

Description

Address Type

This field is defined for memory transactions and Atomic
Operations only. The Integrated Block copies this field into
the AT of the TL header of the request TLP.
• 00: Address in the request is untranslated
• 01: Transaction is a Translation Request
• 10: Address in the request is a translated address
• 11: Reserved

Address

This field applies to memory, I/O, and Atomic Op requests.
This is the address of the first Dword referenced by the
request. The client must also set the First_BE and Last_BE
bits in s_axis_rq_tuser to indicate the valid bytes in the
first and last Dwords, respectively.
When the transaction specifies a 32-bit address, bits [63:32]
of this field must be set to 0.

Dword Count

These 11 bits indicate the size of the block (in Dwords) to be
read or written (for messages, size of the message payload).
The valid range for Memory Write Requests is 0-256 Dwords.
Memory Read Requests have a valid range of 1-1024
Dwords. For I/O accesses, the Dword count is always 1.
For a zero length memory read/write request, the Dword
count must be 1, with the First_BE bits set to all zeros.
The Integrated Block does not check the setting of this field
against the actual length of the payload supplied (for
requests with payload), nor against the maximum payload
size or read request size settings of the Integrated Block.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

143

Interface Operation

Table 4-9:

Requester Request Descriptor Fields (Cont’d)

Bit Index

Field Name

78:75

Request Type

87:80

85:88

103:96

Description
Identifies the transaction type. The transaction types and
their encodings are listed in Table 4-4.

Poisoned Request

This bit can be used by the client to poison the request TLP
being sent. This feature is supported on all request types
except Type 0 and Type 1 Configuration Write Requests. This
bit must be set to 0 for all requests, except when the client
has detected an error in the block of data following the
descriptor and wants to communicate this information using
the Data Poisoning feature of PCI Express.
This feature is supported on all request types except Type 0
and Type 1 Configuration Write Requests.

Requester
Function/Device
Number

Function number of the Requester Function. When ARI is in
use, all 8 bits of this field must be set to the Function
number. Otherwise, bits [84:82] must be set to the completer
Function number.
When ARI is not in use, and the Integrated Block is
configured as a Root Complex, the client must supply the
5-bit Device Number of the requester on bits [87:83].
When ARI is not use, and the Integrated Block is configured
as an Endpoint, the client can optionally supply a 5-bit
Device Number of the requester on bits [87:83]. The client
must set the Requester ID Enable bit in the descriptor if a
Device Number is supplied on bits [87:83]. This value is used
by the Integrated Block when sending the Request TLP,
instead of the stored value of the Device Number captured
by the Integrated Block from Configuration Requests.

Requester Bus
Number

Bus number associated with the requester Function. When
the Integrated Block is configured as a Root Complex, the
client must supply the 8-bit Bus Number of the requester in
this field.
When the Integrated Block is configured as an Endpoint, the
client can optionally supply a Bus Number in this field. The
client must set the Requester ID Enable bit in the descriptor
if a Bus Number is supplied in this field. This value is used
by the Integrated Block when sending the Request TLP,
instead of the stored value of the Bus Number captured by
the Integrated Block from Configuration Requests.

Tag

PCIe Tag associated with the request. For Posted
transactions, the Integrated Block always uses the value
from this field as the tag for the request.
For Non-Posted transactions, the Integrated Block uses the
value from this field if the
AXISTEN_IF_ENABLE_CLIENT_TAG parameter is set (that
is, when tag management is performed by the client). If this
parameter is not set, tag management logic in the
Integrated Block generates the tag to be used, and the value
in the tag field of the descriptor is not used.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

144

Interface Operation

Table 4-9:

Requester Request Descriptor Fields (Cont’d)

Bit Index

Field Name

Description

Completer ID

This field is applicable only to Configuration requests and
messages routed by ID. For these requests, this field
specifies the PCI Completer ID associated with the request
(these 16 bits are divided into an 8-bit bus number, 5-bit
device number, and 3-bit function number in the legacy
interpretation mode. In the ARI mode, these 16 bits are
treated as an 8-bit bus number + 8-bit Function number.).

120

Requester ID Enable

The purpose of this field is to enable the client to supply the
bus and device numbers to be used in the Requester ID. This
field is applicable only to Endpoints.
If this field is 0, the Integrated Block uses the captured
values of the bus and device numbers to form the Requester
ID. If this input is 1, the Integrated Block uses the bus and
device numbers supplied by the client in the descriptor to
form the Requester ID.

123:121

Transaction Class
(TC)

119:104

PCIe Transaction Class (TC) associated with the request.

Attributes

These bits provide the setting of the Attribute bits
associated with the request. Bit 124 is the No Snoop bit and
bit 125 is the Relaxed Ordering bit. Bit 126 is the ID-Based
Ordering bit, and can be set only for memory requests and
messages.
The Integrated Block forces the attribute bits to 0 in the
request sent on the link if the corresponding attribute is not
enabled in the Function's PCI Express Device Control
Register.

127

Force ECRC

Force ECRC insertion. Setting this bit to 1 forces the
Integrated Block to append a TLP Digest containing ECRC to
the Request TLP, even when ECRC is not enabled for the
Function sending request.

15:0

Snoop Latency

This field is defined for LTR messages only. It provides the
value of the 16-bit Snoop Latency field in the TLP header of
the message.

31:16

No-Snoop Latency

This field is defined for LTR messages only. It provides the
value of the 16-bit No-Snoop Latency field in the TLP header
of the message.

OBFF Code

The OBFF Code field is used to distinguish between various
OBFF cases:
• 1111b: “CPU Active” – System fully active for all device
actions including bus mastering and interrupts
• 0001b: “OBFF” – System memory path available for device
memory read/write bus master activities
• 0000b: “Idle” – System in an idle, low power state
All other codes are reserved.

126:124

35:32

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

145

Interface Operation

Table 4-9:

Requester Request Descriptor Fields (Cont’d)

Bit Index

Field Name

Description

111:104

Message Code

This field is defined for all messages. It contains the 8-bit
Message Code to be set in the TL header.
Appendix F of the PCI Express Base Specification, rev. 3.0
provides a complete list of the supported Message Codes.

114:112

Message Routing

This field is defined for all messages. The Integrated Block
copies these bits into the 3-bit Routing field r[2:0] of the TLP
header of the Request TLP.

15:0

Destination ID

This field applies to Vendor-Defined Messages only. When
the message is routed by ID (that is, when the Message
Routing field is 010 binary), this field must be set to the
Destination ID of the message.

63:32

Vendor-Defined
Header

63:0

ATS Header

This field applies to Vendor-Defined Messages only. It is
copied into Dword 3 of the TLP header.
This field is applicable to ATS messages only. It contains the
bytes that the Integrated Block copies into Dwords 2 and 3
of the TLP header.

Requester Memory Write Operation
In both Dword-aligned, the transfer starts with the sixteen descriptor bytes, followed
immediately by the payload bytes. The client must keep the s_axis_rq_tvalid signal
asserted over the duration of the packet. The Integrated Block treats the deassertion of
s_axis_rq_tvalid during the packet transfer as an error, and nullifies the corresponding
Request TLP transmitted on the link to avoid data corruption.
The client must also assert the s_axis_rq_tlast signal in the last beat of the packet. The
Integrated Block can deassert s_axis_rq_tready in any cycle if it is not ready to accept
data. The client must not change the values on the RQ interface during cycles when the
Integrated Block has deasserted s_axis_rq_tready. The AXI4-Stream interface signals
m_axis_cq_tkeep (one per Dword position) must be set to indicate the valid Dwords in
the packet including the descriptor and any null bytes inserted between the descriptor and
the payload. That is, the tkeep bits must be set to 1 contiguously from the first Dword of the
descriptor until the last Dword of the payload. During the transfer of a packet, the tkeep bits
can be 0 only in the last beat of the packet, when the packet does not fill the entire width
of the interface.
The requester request interface also includes the First Byte Enable and the Last Enable bits
in the s_axis_rq_tuser bus. These must be set in the first beat of the packet, and
provides information of the valid bytes in the first and last Dwords of the payload.
The client must limit the size of the payload transferred in a single request to the maximum
payload size configured in the Integrated Block, and must ensure that the payload does not
cross a 4 Kbyte boundary. For memory writes of two Dwords or less, the 1s in first_be
and last_be can be non-contiguous. For the special case of a zero-length memory write
request, the client must provide a dummy one-Dword payload with first_be and

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

146

Interface Operation
last_be both set to all 0s. In all other cases, the 1 bits in first_be and last_be must be
contiguous.
The timing diagrams in Figure 4-36, Figure 4-37, and Figure 4-38 illustrate the
Dword-aligned transfer of a memory write request from the client across the requester
request interface, when the interface width is configured as 64, 128, and 256 bits,
respectively. For illustration purposes, the size of the data block being written into client
memory is assumed to be n Dwords, for some n = k * 32 + 29, k > 0.
X-Ref Target - Figure 4-36

USER?CLK
S?AXIS?RQ?TDATA;=

$%3# $%3# $7

S?AXIS?RQ?TDATA;=

$%3# $%3# $7

$7 N

S?AXIS?RQ?TVALID
S?AXIS?RQ?TREADY
S?AXIS?RQ?TKEEP;=

S?AXIS?RQ?TLAST
FIRST?BE S?AXIS?RQ?TUSER;=

&)234 "%

LAST?BE S?AXIS?RQ?TUSER;=

,!34 "%

DISCONTINUE S?AXIS?RQ?TUSER;=
8

Figure 4-36:

Timing Diagram for a Memory Write Transaction on the Requester Request Interface
(Dword-Aligned Mode, Interface Width = 64 Bits)

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

147

Interface Operation

X-Ref Target - Figure 4-37

USER?CLK
S?AXIS?RQ?TDATA;=

$%3# $7

S?AXIS?RQ?TDATA;=

$%3# $7

S?AXIS?RQ?TDATA;=

$%3# $7

S?AXIS?RQ?TDATA;=

$%3# $7

$7 N

S?AXIS?RQ?TVALID
S?AXIS?RQ?TREADY
S?AXIS?RQ?TKEEP;=

S?AXIS?RQ?TLAST
FIRST?BE S?AXIS?RQ?TUSER;=

&)234 "%

LAST?BE S?AXIS?RQ?TUSER;=

,!34 "%

DISCONTINUE S?AXIS?RQ?TUSER;=
8

Figure 4-37:

Timing Diagram for a Memory Write Transaction on the Requester Request Interface
(Dword-Aligned Mode, Interface Width = 128 Bits)

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

148

Interface Operation

X-Ref Target - Figure 4-38

USER?CLK
S?AXIS?RQ?TDATA;=

$%3# $7

S?AXIS?RQ?TDATA;=

$%3# $7

S?AXIS?RQ?TDATA;=

$%3# $7

S?AXIS?RQ?TDATA;=

$%3# $7

S?AXIS?RQ?TDATA;=

$7 N

S?AXIS?RQ?TVALID
S?AXIS?RQ?TREADY
S?AXIS?RQ?TKEEP;=

X&&

S?AXIS?RQ?TLAST
FIRST?BE S?AXIS?RQ?TUSER;=

&)234 "%

LAST?BE S?AXIS?RQ?TUSER;=

,!34 "%

DISCONTINUE M?AXIS?CQ?TUSER;=
8

Figure 4-38:

Timing Diagram for a Memory Write Transaction on the Requester Request Interface
(Dword-Aligned Mode, Interface Width = 256 Bits)

The timing diagrams in Figure 4-39, Figure 4-40, and Figure 4-41 illustrate the
address-aligned transfer of a memory write request from the client across the RQ interface,
when the interface width is configured as 64, 128, and 256 bits, respectively. For illustration
purposes, the starting Dword offset of the data block being written into client memory is
assumed to be (m * 32 + 1), for some integer m > 0. Its size is assumed to be n Dwords, for
some n = k * 32 + 29, k > 0.
In the address-aligned mode, the delivery of the payload always starts in the beat following
the last byte of the descriptor. The first Dword of the payload can appear at any Dword
position. The client must communicate the offset of the first Dword of the payload on the
datapath using the addr_offset[2:0] signal in s_axis_rq_tuser. The client must
also set the bits in first_be[3:0] to indicate the valid bytes in the first Dword and the
bits in last_be[3:0] to indicate the valid bytes in the last Dword of the payload.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

149

Interface Operation

X-Ref Target - Figure 4-39

USER?CLK
S?AXIS?RQ?TDATA;=
S?AXIS?RQ?TDATA;=

$%3# $%3#
$%3# $%3# $7

$7 N

S?AXIS?RQ?TVALID
S?AXIS?RQ?TREADY
S?AXIS?RQ?TKEEP;=

S?AXIS?RQ?TLAST
FIRST?BE S?AXIS?RQ?TUSER;=

&)234 "%

LAST?BE S?AXIS?RQ?TUSER;=

,!34 "%

ADD?OFFSET;= S?AXIS?RQ?TUSER;=

DISCONTINUE S?AXIS?RQ?TUSER;=
8

Figure 4-39:

Timing Diagram for a Memory Write Transaction on the Requester Request Interface
(Address-Aligned Mode, Interface Width = 64 Bits)

X-Ref Target - Figure 4-40

USER?CLK
S?AXIS?RQ?TDATA;=

$%3#

$7 N
$7 N

S?AXIS?RQ?TDATA;=

$%3# $7

S?AXIS?RQ?TDATA;=

$%3# $7

S?AXIS?RQ?TDATA;=

$%3# $7

S?AXIS?RQ?TVALID
S?AXIS?RQ?TREADY
S?AXIS?RQ?TKEEP;=

S?AXIS?RQ?TLAST
FIRST?BE S?AXIS?RQ?TUSER;=

&)234 "%

LAST?BE S?AXIS?RQ?TUSER;=

,!34 "%

ADD?OFFSET;= S?AXIS?RQ?TUSER;=

DISCONTINUE S?AXIS?RQ?TUSER;=
8

Figure 4-40:

Timing Diagram for a Memory Write Transaction on the Requester Request Interface
(Address-Aligned Mode, Interface Width = 128 Bits)

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

150

Interface Operation

X-Ref Target - Figure 4-41

USER?CLK
S?AXIS?RQ?TDATA;=

$%3#

$7 N

S?AXIS?RQ?TDATA;=

$%3# $7

$7 N

S?AXIS?RQ?TDATA;=

$%3# $7

$7 N

S?AXIS?RQ?TDATA;=

$%3# $7

$7 N

S?AXIS?RQ?TDATA;=

$7 N

S?AXIS?RQ?TDATA;=

$7 N

S?AXIS?RQ?TDATA;=

S?AXIS?RQ?TVALID
S?AXIS?RQ?TREADY
S?AXIS?RQ?TKEEP;=

X&&

S?AXIS?RQ?TLAST
FIRST?BE S?AXIS?RQ?TUSER;=

&)234 "%

LAST?BE S?AXIS?RQ?TUSER;=

,!34 "%

ADD?OFFSET;= S?AXIS?RQ?TUSER;=

DISCONTINUE S?AXIS?RQ?TUSER;=
8

Figure 4-41:

Timing Diagram for a Memory Write Transaction on the Requester Request Interface
(Address-Aligned Mode, Interface Width = 256 Bits)

Non-Posted Transactions with No Payload
Non-Posted transactions with no payload (memory read requests, I/O read requests,
Configuration read requests) are transferred across the RQ interface in the same manner as
a memory write request, except that the AXI4-Stream packet contains only the 16-byte
descriptor. The timing diagrams in Figure 4-42, Figure 4-43, and Figure 4-44 illustrate the
transfer of a memory read request across the RQ interface, when the interface width is
configured as 64, 128, and 256 bits, respectively. The packet occupies two consecutive beats
on the 64-bit interface, while it is transferred in a single beat on the 128- and 256-bit
interfaces. The s_axis_rq_tvalid signal must remain asserted over the duration of the
packet. The Integrated Block can deassert s_axis_rq_tready to prolong the beat. The
s_axis_rq_tlast signal must be set in the last beat of the packet, and the bits in
s_axis_rq_tkeep[7:0] must be set in all Dword positions where a descriptor is present.
The valid bytes in the first and last Dwords of the data block to be read must be indicated
using first_be[3:0] and last_be[3:0], respectively. For the special case of a
zero-length memory read, the length of the request must be set to one Dword, with both
first_be[3:0] and last_be[3:0] set to all 0s. Additionally when in address-aligned

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

151

Interface Operation
mode, addr_offset[2:0] in s_axis_rq_tuser specifies the desired starting
alignment of data returned on the Requester Completion interface. The alignment is not
required to be correlated to the address of the request.
X-Ref Target - Figure 4-42

USER?CLK
S?AXIS?RQ?TDATA;=

$%3#

S?AXIS?RQ?TDATA;=

$%3#

S?AXIS?RQ?TVALID
S?AXIS?RQ?TREADY
S?AXIS?RQ?TKEEP;=

S?AXIS?RQ?TLAST
FIRST?BE S?AXIS?RQ?TUSER;=

&)234 "%

LAST?BE S?AXIS?RQ?TUSER;=

,!34 "%

DISCONTINUE S?AXIS?RQ?TUSER;=
8

Figure 4-42:

Timing Diagram for a Memory Read Transaction on the Requester Request
Interface (Interface Width = 64 Bits)

X-Ref Target - Figure 4-43

USER?CLK
S?AXIS?RQ?TDATA;=

$%3#

S?AXIS?RQ?TDATA;=

$%3#

S?AXIS?RQ?TDATA;=

$%3#

S?AXIS?RQ?TDATA;=

$%3#

S?AXIS?RQ?TVALID
S?AXIS?RQ?TREADY
S?AXIS?RQ?TKEEP;=

S?AXIS?RQ?TLAST
FIRST?BE S?AXIS?RQ?TUSER;=

&)234 "%

LAST?BE S?AXIS?RQ?TUSER;=

,!34 "%

DISCONTINUE S?AXIS?RQ?TUSER;=
8

Figure 4-43:

Timing Diagram for a Memory Read Transaction on the Requester Request
Interface (Interface Width = 128 Bits)

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

152

Interface Operation

X-Ref Target - Figure 4-44

USER?CLK
S?AXIS?RQ?TDATA;=

$%3#

S?AXIS?RQ?TDATA;=

$%3#

S?AXIS?RQ?TDATA;=

$%3#

S?AXIS?RQ?TDATA;=

$%3#

S?AXIS?RQ?TDATA;=
S?AXIS?RQ?TVALID
S?AXIS?RQ?TREADY
S?AXIS?RQ?TKEEP;=
S?AXIS?RQ?TLAST
FIRST?BE S?AXIS?RQ?TUSER;=

&)234 "%

LAST?BE S?AXIS?RQ?TUSER;=

,!34 "%

DISCONTINUE S?AXIS?RQ?TUSER;=
8

Figure 4-44:

Timing Diagram for a Memory Read Transaction on the Requester Request
Interface (Interface Width = 256 Bits)

Non-Posted Transactions with a Payload
The transfer of a Non-Posted request with payload (an I/O write request, Configuration
write request, or Atomic Operation request) is similar to the transfer of a memory request,
with the following changes in how the payload is aligned on the datapath:
•

In the Dword-aligned mode, the first Dword of the payload follows the last Dword of
the descriptor, with no gaps between them.

•

In the address-aligned mode, the payload must start in the beat following the last
Dword of the descriptor. The payload can start at any Dword position on the datapath.
The offset of its first Dword must be specified using the addr_offset[2:0] signal.

For I/O and Configuration write requests, the valid bytes in the one-Dword payload must be
indicated using first_be[3:0]. For Atomic Operation requests, all bytes in the first and
last Dwords are assumed valid.

Message Requests on the Requester Interface
The transfer of a message on the RQ interface is similar to that of a memory write request,
except that a payload might not always be present. The transfer starts with the 128-bit
descriptor, followed by the payload, if present. When the Dword-aligned mode is in use, the
first Dword of the payload must immediately follow the descriptor. When the
address-alignment mode is in use, the payload must start in the beat following the
descriptor, and must be aligned to byte lane 0. The addr_offset input to the Integrated

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

153

Interface Operation
Block must be set to 0 for messages when the address-aligned mode is in use. The
Integrated Block determines the end of the payload from s_axis_rq_tlast and
s_axis_rq_tkeep signals. The First Byte Enable and Last Byte Enable bits (first_be and
last_be) are not used for message requests.

Aborting a Transfer
For any request that includes an associated payload, the client can abort the request at any
time during the transfer of the payload by asserting the discontinue signal in the
s_axis_rq_tuser bus. The Integrated Block nullifies the corresponding TLP on the link to
avoid data corruption.
The client can assert this signal in any cycle during the transfer, when the request being
transferred has an associated payload. The client can either choose to terminate the packet
prematurely in the cycle where the error was signaled (by asserting s_axis_rq_tlast), or
can continue until all bytes of the payload are delivered to the Integrated Block. In the latter
case, the Integrated Block treats the error as sticky for the following beats of the packet,
even if the client deasserts the discontinue signal before reaching the end of the packet.
The discontinue signal can be asserted only when s_axis_rq_tvalid is High. The
Integrated Block samples this signal when s_axis_rq_tvalid and s_axis_rq_tready
are both High. Thus, after assertion, the discontinue signal should not be deasserted until
s_axis_rq_tready is High.
When the Integrated Block is configured as an Endpoint, this error is reported by the
Integrated Block to the Root Complex it is attached to, as an Uncorrectable Internal Error
using the Advanced Error Reporting (AER) mechanisms.

Tag Management for Non-Posted Transactions
The requester side of the Integrated Block maintains the state of all pending Non-Posted
transactions (memory reads, I/O reads and writes, configuration reads and writes, Atomic
Operations) initiated by the client, so that the completions returned by the targets can be
matched against the corresponding requests. The state of each outstanding transaction is
held in a Split Completion Table in the requester side of the interface, which has a capacity
of 64 Non-Posted transactions. The returning Completions are matched with the pending
requests using a 6-bit tag. There are two options for management of these tags.
•

Internal Tag Management: This mode of operation is selected by setting the
AXISTEN_IF_ENABLE_CLIENT_TAG parameter to FALSE, which is the default setting
for the core. In this mode, logic within the Integrated Block is responsible for allocating
the tag for each Non-Posted request initiated from the requester side. The Integrated
Block maintains a list of free tags and assigns one of them to each request when the
client initiates a Non-Posted transaction, and communicates the assigned tag value to
the client via the output pcie_rq_tag[5:0]. The value on this bus is valid when the
Integrated Block asserts pcie_rq_tag_vld. The client logic must copy this tag so

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

154

Interface Operation
that any Completions delivered by the Integrated Block in response to the request can
be matched to the request.
In this mode, logic within the Integrated Block checks for the Split Completion Table full
condition, and backpressures a Non-Posted request from the client (using
s_axis_rq_tready) if the total number of Non-Posted requests currently outstanding
has reached its limit (64).
•

External Tag Management: This mode of operation is selected by setting the
AXISTEN_IF_ENABLE_CLIENT_TAG parameter to 1. In this mode, the client logic is
responsible for allocating the tag for each Non-Posted request initiated from the
requester side. The client logic must choose the tag value without conflicting with the
tags of all other Non-Posted transactions outstanding at that time, and must
communicate this chosen tag value to the Integrated Block via the request descriptor.
The Integrated Block still maintains the outstanding requests in its Split Completion
Table and matches the incoming Completions to the requests, but does not perform
any checks for the uniqueness of the tags, or for the Split Completion Table full
condition.

When internal tag management is in use, the Integrated Block asserts pcie_rq_tag_vld
for one cycle for each Non-Posted request, after it has placed its allocated tag on
pcie_rq_tag[5:0]. There can be a delay of several cycles between the transfer of the
request on the RQ interface and the assertion of pcie_rq_tag_vld by the Integrated
Block to provide the allocated tag for the request. The client can, meanwhile, continue to
send new requests. The tags for requests are communicated on the pcie_rq_tag bus in
FIFO order, so it is easy for the client to associate the tag value with the request it
transferred.

Avoiding Head-of-Line Blocking for Posted Requests
The Integrated Block can hold a Non-Posted request received on its RQ interface for lack of
transmit credit or lack of available tags. This could potentially result in head-of-line (HOL)
blocking for Posted transactions. The Integrated Block provides a mechanism for the client
logic to avoid this situation through these signals:
•

•

pcie_tfc_nph_av[1:0]: These outputs indicate the Header Credit currently
available for Non-Posted requests, where:
°

00 = no credit available

01 = 1 credit

10 = 2 credits

11 = 3 or more credits

pcie_tfc_npd_av[1:0]: These outputs indicate the Data Credit currently available
for Non-Posted requests, where:
°

00 = no credit available

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

155

Interface Operation

01 = 1 credit

10 = 2 credits

11 = 3 or more credits

The client logic can optionally check these outputs before transmitting Non-Posted
requests. Because of internal pipeline delays, the information on these outputs is delayed
by two user clock cycles from the cycle in which the last byte of the descriptor is transferred
on the RQ interface. Thus the client logic must adjust these values, taking into account any
Non-Posted requests transmitted in the two previous clock cycles. Figure 4-45 illustrates
the operation of these signals for the 256-bit interface. In this example, the Integrated Block
initially had three Non-Posted Header Credits and two Non-Posted Data Credits, and had
three free tags available for allocation. Request 1 from the client had a one-Dword payload,
and therefore consumed one header and data credit each, and also one tag. Request 2 in
the next clock cycle consumed one header credit, but no data credit. When the client
presents Request 3 in the following clock cycle, it must adjust the available credit and
available tag count by taking into account requests 1 and 2. If Request 3 consumes one
header credit and one data credit, both available credits are 0 two cycles later, as also the
number of available tags.
Figure 4-46 and Figure 4-47 illustrate the timing of the credit and tag available signals for
the same example, for interface width of 128 bits and 64 bits, respectively.
X-Ref Target - Figure 4-45

USER?CLK
S?AXIS?RQ?DATA;=

.0 2EQ

S?AXIS?RQ?DATA?TVALID
S?AXIS?RQ?DATA?READY
S?AXIS?RQ?DATA?TLAST
PCIE?TFC?NPH;=

PCIE?TFC?NPD;=

PCIE?RQ?TAG?AV;=

X
X

X
8

Figure 4-45:

Operation of Credit and Tag Availability Signals on the Requester Request
Interface (Interface Width = 256 Bits)

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

156

Interface Operation

X-Ref Target - Figure 4-46

USER?CLK
S?AXIS?RQ?DATA;=

.0 2EQ

S?AXIS?RQ?DATA?TVALID
S?AXIS?RQ?DATA?READY
S?AXIS?RQ?DATA?TLAST
PCIE?TFC?NPH;=

PCIE?TFC?NPD;=

PCIE?RQ?TAG?AV;=

X
X

X
8

Figure 4-46:

Operation of Credit and Tag Availability Signals on the Requester Request
Interface (Interface Width = 128 Bits)

X-Ref Target - Figure 4-47

USER?CLK
S?AXIS?RQ?DATA;=

.0 2EQ

S?AXIS?RQ?DATA?TVALID
S?AXIS?RQ?DATA?READY
S?AXIS?RQ?DATA?TLAST
PCIE?TFC?NPH;=

PCIE?TFC?NPD;=

PCIE?RQ?TAG?AV;=

X
X

X
8

Figure 4-47:

Operation of Credit and Tag Availability Signals on the Requester Request Interface
(Interface Width = 64 Bits)

Maintaining Transaction Order
The Integrated Block does not change the order of requests received from the client on its
requester interface when it transmits them on the link. In cases where the client would like
to have precise control of the order of transactions sent on the RQ interface and the CC
interface (typically to avoid Completions from passing Posted requests when using strict
ordering), the Integrated Block provides a mechanism for the client to monitor the progress
of a Posted transaction through its pipeline, so that it can determine when to schedule a
Completion on the completer completion interface without the risk of passing a specific
Posted request transmitted from the requester request interface,
When transferring a Posted request (memory write transactions or messages) across the
requester request interface, the client can provide an optional 4-bit sequence number to
the Integrated Block on its seq_num[3:0] input within s_axis_rq_tuser. The sequence

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

157

Interface Operation
number must be valid in the first beat of the packet. The client can then monitor the
pcie_rq_seq_num[3:0] output of the Integrated Block for this sequence number to
appear. When the transaction has reached a stage in the internal transmit pipeline of the
Integrated Block where a Completion cannot pass it, the Integrated Block asserts
pcie_rq_seq_num_valid for one cycle and provides the sequence number of the Posted
request on the pcie_rq_seq_num[3:0] output. Any Completions transmitted by the
Integrated Block after the sequence number has appeared on pcie_rq_seq_num[3:0]
cannot pass the Posted request in the internal transmit pipeline.

Requester Completion Interface Operation
Completions for requests generated by client logic are presented on the Integrated Block's
Request Completion (RC) interface. See Figure 4-48 for an illustration of signals associated
with the requester completion interface. When straddle is not enabled, the Integrated Block
delivers each TLP on this interface as an AXI4-Stream packet. The packet starts with a 96-bit
descriptor, followed by data in the case of Completions with a payload.
X-Ref Target - Figure 4-48

#LIENT
!PPLICATION

6IRTEX &0'! 'EN
)NTEGRATED "LOCK FOR 0#)E
M?AXIS?RC?TDATA;=
M?AXIS?RC?TPARITY;=
0#)E 2EQUESTER
#OMPLETION )NTERFACE

0#)E
2EQUESTER
)NTERFACE

M?AXIS?RC?TVALID
M?AXIS?RC?TREADY
M?AXIS?RC?TKEEP;=
M?AXIS?RC?TLAST
!8) 3TREAM
-ASTER

BYTE?EN;=

!8) 3TREAM
3LAVE

IS?SOF?
IS?SOF?
IS?EOF?;=
IS?EOF?;=
DISCONTINUE
M?AXIS?RC?TUSER;=
8

Figure 4-48:

Requester Completion Interface

The RC interface supports two distinct data alignment modes for transferring payloads,
selected by the AXISTEN_IF_RC_ALIGNMENT_MODE parameter. In the Dword-aligned
mode, the Integrated Block transfers the first Dword of the Completion payload

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

158

Interface Operation
immediately after the last Dword of the descriptor. In the address-aligned mode, the
Integrated Block starts the payload transfer in the beat following the last Dword of the
descriptor, and its first Dword can be in any of the possible Dword positions on the
datapath. The alignment of the first Dword of the payload is determined by address offset
provided by the client when it sent the request to the Integrated Block (that is, the setting
of the addr_offset[2:0] input of the RQ interface). Thus, the address-aligned mode can
be used on the RC interface only if the RQ interface is also configured to use the
address-aligned mode.

Requester Completion Descriptor Format
The RC interface of the Integrated Block sends completion data received from the link to the
client application as AXI4-Stream packets. Each packet starts with a descriptor and can have
payload data following the descriptor. The descriptor is always 12 bytes long, and is sent in
the first 12 bytes of the completion packet. The descriptor is transferred during the first two
beats on a 64-bit interface, and in the first beat on a 128- or 256-bit interface. When the
completion data is split into multiple Split Completions, the Integrated Block sends each
Split Completion as a separate AXI4-Stream packet, with its own descriptor.
The format of the Requester Completion descriptor is illustrated in Figure 4-49. The
individual fields of the RC descriptor are described in Table 4-10.
X-Ref Target - Figure 4-49

"US

$EVICE&UNCTION 2
2EQUESTER )$

$WORD COUNT

,OCKED 2EAD
#OMPLETION

2EQUEST #OMPLETED

0OISONED #OMPLETION
#OMPLETION 3TATUS

!DDRESS ;=

"YTE #OUNT

%RROR #ODE

2 !TTR

"US

$EVICE &UNCTION
#OMPLETER )$

Figure 4-49:
Table 4-10:
Bit Index

11:0

4AG
8

Requester Completion Descriptor Format

Requester Completion Descriptor Fields
Field Name

Description

Lower Address

This field provides the 12 least significant bits of the first byte
referenced by the request. The Integrated Block returns this address
from its Split Completion Table, where it stores the address and other
parameters of all pending Non-Posted requests on the requester side.
When the Completion delivered has an error, only bits [6:0] of the
address should be considered valid.
This is a byte-level address.

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

www.xilinx.com

159

Interface Operation

Table 4-10:
Bit Index

Requester Completion Descriptor Fields (Cont’d)
Field Name

Description

Error Code

Completion error code. These three bits encode error conditions
detected from error checking performed by the Integrated Block on
received Completions. Its encodings are:
• 0000: Normal termination (all data received).
• 0001: The Completion TLP is Poisoned.
• 0010: Request terminated by a Completion with UR, CA or CRS
status.
• 0011: Request terminated by a Completion with no data, or the byte
count in the Completion was higher than the total number of bytes
expected for the request.
• 0100: The current Completion being delivered has the same tag of
an outstanding request, but its Requester ID, TC, or Attr fields did
not match with the parameters of the outstanding request.
• 0101: Error in starting address. The low address bits in the
Completion TLP header did not match with the starting address of
the next expected byte for the request.
• 0110: Invalid tag. This Completion does not match the tags of any
outstanding request.
• 1001: Request terminated by a Completion time-out. The other
fields in the descriptor, except bit [30], the requester Function
[55:48], and the tag field [71:64], are invalid in this case, because the
descriptor does not correspond to a Completion TLP.
• 1000: Request terminated by a Function-Level Reset (FLR) targeted
at the Function that generated the request. The other fields in the
descriptor, except bit [30], the requester Function [55:48], and the
tag field [71:64], are invalid in this case, because the descriptor does
not correspond to a Completion TLP.

28:16

Byte Count

These 13 bits can have values in the range of 0 – 4096 bytes. If a
Memory Read Request is completed using a single Completion, the
Byte Count value indicates Payload size in bytes. This field must be set
to 4 for I/O read Completions and I/O write Completions. The byte
count must be set to 1 while sending a Completion for a zero-length
memory read, and a dummy payload of 1 Dword must follow the
descriptor.
The byte count must be set to 0 when sending a UR or CA Completion.
For each Memory Read Completion, the Byte Count field must indicate
the remaining number of bytes required to complete the Request,
including the number of bytes returned with the Completion.
If a Memory Read Request is completed using multiple Completions,
the Byte Count value for each successive Completion is the value
indicated by the preceding Completion minus the number of bytes
returned with the preceding Completion.

Locked Read
Completion

15:12

Virtex-7 FPGA Integrated Block for PCIe
PG023 April 24, 2012

This bit is set to 1 when the Completion is in response to a Locked
Read request. It is set to 0 for all other Completions.

www.xilinx.com

160

Interface Operation

Table 4-10:
Bit Index

42:32

Requester Completion Descriptor Fields (Cont’d)
Field Name

Description

Request
Completed

The Integrated Block asserts this bit in the descriptor of the last
Completion of a request. The assertion of the bit can indicate normal
termination of the request (because all data has been received) or
abnormal termination because of an error condition. The client logic
can use this indication to clear its outstanding request status.
When tags are assigned by the client, the client logic should not
re-assign a tag allocated to a request until it has received a
Completion Descriptor from the Integrated Block with a matching tag
field and the Request Completed bit set to 1.

Dword Count

These 11 bits indicate the size of the payload of the current packet in
Dwords. Its range is 0 - 1K Dwords. This field is set to 1 for I/O read
Completions and 0 for I/O write Completions. The Dword count is also
set to 1 while transferring a Completion for a zero-length memory
read. In all other cases, the Dword count corresponds to the actual
number of Dwords in the payload of the current packet.
These bits reflect the setting of the Completion Status field of the
received Completion TLP. The valid settings are:
• 000: Successful Completion
• 001: Unsupported Request (UR)
• 010: Configuration Request Retry Status (CRS)
• 100: Completer Abort (CA)

45:43

Completion Status

Poisoned
Completion

This bit is set to indicate that the Poison bit in the Completion TLP was
set. Data in the packet should then be considered corrupted.