Transaction Descriptor Overview

The Transaction Descriptor is a mechanism for carrying Transaction information between the
Requester and the Completer. Transaction Descriptors are composed of three fields:
Transaction ID – identifies outstanding Transactions
Attributes field – specifies characteristics of the Transaction
Traffic Class (TC) field – associates Transaction with type of required service
Figure 2-12 shows the fields of the Transaction Descriptor. Note that these fields are shown
together to highlight their relationship as parts of a single logical entity. The fields are not
contiguous in the packet header.

Figure 2-12: Transaction Descriptor

First/Last DW Byte Enables Rules

Byte Enables are included with Memory, I/O, and Configuration Requests. This section defines the corresponding rules. Byte Enables, when present in the Request header, are located in byte 7 of the header (see Figure 2-11). For Memory Read Requests that have the TH bit Set, the Byte Enable fields are repurposed to carry the ST[7:0] field, and values for the Byte Enables are implied as defined below. Such Requests must only be issued when it is acceptable to complete the Requests as if all bytes for requested payload were enabled.

For Memory Reads that have the TH bit Set, the following values are implied for the Byte
Enables.
• If the Length field for this Request indicates a length of 1 DW, then the value for the 1st DW
Byte Enables is implied to be 1111b and the value for the Last DW Byte Enables is implied
to be 0000b.
• If the Length field for this Request indicates a length of greater than 1 DW, then the value
for the 1st DW Byte Enables and the Last DW Byte Enables is implied to be 1111b.

The 1st DW BE[3:0] field contains Byte Enables for the first (or only) DW referenced by a
Request.
• If the Length field for a Request indicates a length of greater than 1 DW, this field must not
equal 0000b.
􀂉 The Last DW BE[3:0] field contains Byte Enables for the last DW of a Request.
• If the Length field for a Request indicates a length of 1 DW, this field must equal 0000b.
• If the Length field for a Request indicates a length of greater than 1 DW, this field must not
equal 0000b.
􀂉 For each bit of the Byte Enables fields:
 • a value of 0b indicates that the corresponding byte of data must not be written or, if nonprefetchable, must not be read at the Completer.
• a value of 1b indicates that the corresponding byte of data must be written or read at the
Completer.
􀂉 Non-contiguous Byte Enables (enabled bytes separated by non-enabled bytes) are permitted in the 1st DW BE field for all Requests with length of 1 DW.
• Non-contiguous Byte Enable examples: 1010b, 0101b, 1001b, 1011b, 1101b
􀂉 Non-contiguous Byte Enables are permitted in both Byte Enables fields for QW aligned
Memory Requests with length of 2 DW (1 QW).
􀂉 All non-QW aligned Memory Requests with length of 2 DW (1 QW) and Memory Requests with
length of 3 DW or more must enable only bytes that are contiguous with the data between the first and last DW of the Request.
• Contiguous Byte Enables examples:
1st DW BE: 1100b, Last DW BE: 0011b
1st DW BE: 1000b, Last DW BE: 0111b
􀂉 Table 2-9 shows the correspondence between the bits of the Byte Enables fields, their location in the Request header, and the corresponding bytes of the referenced data.

A Write Request with a length of 1 DW with no bytes enabled is permitted, and has no effect at the Completer.
􀂉 If a Read Request of 1 DW specifies that no bytes are enabled to be read (1st DW BE[3:0] field = 0000b), the corresponding Completion must specify a Length of 1 DW, and include a data payload of 1 DW
• The contents of the data payload within the Completion packet is unspecified and may be
any value
􀂉 Receiver/Completer behavior is undefined for a TLP violating the Byte Enables rules specified in this section.
􀂉 Receivers may optionally check for violations of the Byte Enables rules specified in this section. If a Receiver implementing such checks determines that a TLP violates one or more Byte Enables rules, the TLP is a Malformed TLP
• If Byte Enables rules are checked, a violation is a reported error associated with the
Receiving Port (see Section 6.2)

The flush semantic has wide application, and all Completers must implement the functionality associated with this semantic. Because a Requester may use the flush semantic without comprehending the characteristics of the Completer, Completers must ensure that zero-length reads do not have side-effects. This is really just a specific case of the rule that in a non-prefetchable space, non-enabled bytes must not be read at the Completer. Note that the flush applies only to traffic in the same Traffic Class as the zero-length Read.

Routing and Addressing Rules

There are three principal mechanisms for TLP routing: address, ID, and implicit. This section defines the rules for the address and ID routing mechanisms. Implicit routing is used only with Message Requests, and is covered in Section 2.2.8.

Address Based Routing Rules

Address routing is used with Memory and I/O Requests.
Two address formats are specified, a 64-bit format used with a 4 DW header (see Figure 2-7) and a 32-bit format used with a 3 DW header (see Figure 2-8).

Figure 2-8: 32-bit Address Routing

For Memory Read, Memory Write, and AtomicOp Requests, the Address Type (AT) field is encoded as shown in Table 2-5, with full descriptions contained in the Address Translation Services Specification, Revision 1.0. For all other Requests, the AT field is reserved.

Table 2-5: Address Type (AT) Field Encodings

 

Address mapping to the TLP header is shown in Table 2-6.

Table 2-6: Address Field Mapping

Memory Read, Memory Write, and AtomicOp Requests can use either format.
• For Addresses below 4 GB, Requesters must use the 32-bit format. The behavior of the receiver is not specified if a 64-bit format request addressing below 4 GB (i.e., with the upper 32 bits of address all 0) is received.
I/O Read Requests and I/O Write Requests use the 32-bit format.
All agents must decode all address bits in the header - address aliasing is not allowed.

ID Based Routing Rules

ID routing is used with Configuration Requests,with ID Routed Messages, and with
Completions. This specification defines Vendor_Defined Messages that are ID Routed (Section 2.2.8.6). Other specifications define additional ID Routed Messages.

ID routing uses the Bus, Device, and Function Numbers (as applicable) to specify the destination for the TLP:
• For non-ARI Routing IDs, Bus, Device, and (3-bit) Function Number to TLP header
mapping is shown in Table 2-7.
• For ARI Routing IDs, the Bus and (8-bit) Function Number to TLP header mapping is shown in Table 2-8.

Two ID routing formats are specified, one used with a 4 DW header (see Figure 2-9) and one used with a 3 DW header (see Figure 2-10).
• Header field locations are the same for both formats, and are given in Table 2-7

Table 2-7: Header Field Locations for non-ARI ID Routing

Table 2-8: Header Field Locations for ARI ID Routing

Figure 2-9: ID Routing with 4 DW Header

Figure 2-10: ID Routing with 3 DW Header

TLP Digest Rules

For any TLP, a value of 1b in the TD field indicates the presence of the TLP Digest field including an ECRC value at the end of the TLP
• A TLP where the TD field value does not correspond with the observed size (accounting for the data payload, if present) is a Malformed TLP
♦ This is a reported error associated with the Receiving Port (see Section 6.2)
If an intermediate or ultimate PCI Express Receiver of the TLP does not support ECRC checking, the Receiver must ignore the TLP Digest4
• If the Receiver of the TLP supports ECRC checking, the Receiver interprets the value in the TLP Digest field as an ECRC value, according to the rules in Section 2.7.1