The core transfers each request TLP received from the link over the completer request 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 always transferred during the first beat on the 512-bit interface. The formats of the descriptor for different request types are illustrated in the following figures.
The format of the following figure 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 the following figure is used for Vendor-Defined Messages (Type 0 or Type 1) only.
The format of the following figure is used for all ATS messages (Invalid Request, Invalid Completion, Page Request, PRG Response).
For all other messages, the descriptor takes the format of the following figure.
| Bit Index | Field Name | Description |
|---|---|---|
| 1:0 | 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.
|
| 63:2 | Address |
This field applies to memory, I/O and Atomic Op requests.
It provides the address from the TL header. This is the address of
the first Dword referenced by the request. The
When the transaction specifies a 32-bit address, bits [63:32] of this field is 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 |
| 78:75 | Request Type | Identifies the transaction type. The transaction types and their encodings are listed in Table 2. |
| 95:80 | Requester ID |
PCI Requester ID associated with the request. With the 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 user completer application must store this field and supply it back to the core with the completion data. |
| 103:96 | Tag | PCIe Tag associated with the request. When the request is a Non-Posted transaction, the user completer application must store this field and supply it back to the core with the completion data. This field can be ignored for memory writes and messages. |
| 111:104 | 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. |
| 114:112 | 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.
Note: In Root Port (RP) mode, BAR ID is always 000.
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). |
| 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 user 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 user 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 user completer application must store this field and supply it back to the core 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 user completer application must store this field and supply it back to the core with the completion data. |
| 114:112 | Message Routing | This field is defined for all messages. These bits provide the 3-bit Routing field r[2:0] from the TL header. |
| 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 provides the Destination ID of the message. |
| 63:32 | Vendor-Defined Header | This field applies to Vendor-Defined Messages only. It contains the bytes extracted from Dword 3 of the TL 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 TL header. |
| 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 |