The requester side of the core 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 user application, 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 up to 768 Non-Posted transactions. The returning Completions are matched with the pending requests using an 5-/8-/10-bit tag. There are two options for management of these tags:
- Internal Tag Management
- Internal Tag Management is enabled when the Enable Client
Tag option is not set in the AMD Vivado™
IDE, which is the default setting for the core. In this
mode, logic within the core is responsible for allocating the tag for each
Non-Posted request initiated from the requester side. The core maintains a list
of free tags and assigns one of them to each request when the user logic
initiates a Non-Posted transaction, and communicates the assigned tag value to
the user logic through the output
pcie_rq_tag0[9:0]
andpcie_rq_tag1[9:0]
. The value on this bus is valid when the core assertspcie_rq_tag_vld0
andpcie_rq_tag_vld1
. Use ofpcie_rq_tag_vld0
andpcie_rq_tag_vld1
are orthogonal to whether the Straddle option is enabled. The integrated block can use either thepcie_rq_tag_vld0
orpcie_rq_tag_vld1
port to showcase the valid tags. The user logic must copy the tag so that any Completions delivered by the core in response to the request can be matched to the request.In this mode, logic within the core checks for the Split Completion Table full condition, and backpressures a Non-Posted request from the user logic (using
s_axis_rq_tready
) if the total number of Non-Posted requests currently outstanding has reached its limit. - External Tag Management
- External Tag Management is enabled when the Enable Client Tag option is set in the AMD Vivado™ IDE. In this mode, the user logic is responsible for allocating the tag for each Non-Posted request initiated from the requester side. The user 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 core within the request descriptor. The core 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 core asserts pcie_rq_tag_vld
for one cycle for each Non-Posted request, after it has placed its allocated tag on
pcie_rq_tag
. When straddle option is enabled, the core are provide
up to two allocated tags in the same cycle on this interface. The states of the signals
pcie_rq_tag_vld
and pcie_rq_tag
must be
interpreted as follows:
- Assertion of
pcie_rq_tag_vld0
in any cycle indicates that the core has placed an allocated tag onpcie_rq_tag0[9:0]
. - Simultaneous assertion of
pcie_rq_tag_vld0
andpcie_rq_tag_vld1
in the same cycle indicates that the core has placed two allocated tags, the first onpcie_rq_tag0[9:0]
and the second onpcie_rq_tag1[9:0]
. The tag onpcie_rq_tag0[9:0]
corresponds to an earlier request sent by the user logic and the tag onpcie_rq_tag1[9:0]
corresponds to a later request. -
pcie_rq_tag_vld1
is never asserted whenpcie_rq_tag_vld0
is not asserted. That is, when there is only one tag to communicate in any cycle, it is always communicated onpcie_rq_tag0[9:0]
. - When straddle is not in use, only a single tag can be communicated in any cycle, and
pcie_rq_tag_vld1
is never asserted.
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. The user logic are, 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 user logic to associate the tag value with the request it transferred.