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.