Field Name Header
Byte/Bit Function
Length 9:0 Byte 3 Bit 7:0 Byte 2 Bit 1:0
Indicates data payload size in DW. For completions, this field reflects the size of the data payload associated with this completion.
Attr 1:0 (Attributes)
Byte 2 Bit 5:4
Attribute 1: Relaxed Ordering Bit Attribute 0: No Snoop Bit
For a completion, both of these bits are set to same state as in the request.
EP Byte 2 Bit 6 If = 1, indicates the data payload is poisoned.
TD Byte 2 Bit 7 If = 1, indicates the presence of a digest field (1 DW) at the end of the TLP (preceding LCRC and END)
TC 2:0
(Transfer Class)
Byte 2 Bit 6:4
Indicates transfer class for the packet. For a completion, TC is set to same value as in the request.
Table 4-9. Completion Header Fields
Field Name Header
Byte/Bit Function
Type 4:0 Byte 0 Bit
4:0
TLP packet type field. Always set to 01010b for a completion.
Fmt 1:0 (Format)
Byte 0 Bit 6:5
Packet Format. Always a 3DW header 00b = Completion without data (Cpl) 10b = Completion with data (CplD) Byte Count Byte 7 Bit
7:0 Byte 6 Bit 3:0
This is the remaining byte count until a read request is satisfied. Generally, it is derived from the original request Length field. See "Data Returned For Read Requests:" on page 188 for special cases caused by multiple completions.
BCM
(Byte Count Modified)
Byte 6 Bit 4 Set = 1 only by PCI-X completers. Indicates that the byte count field (see previous field) reflects the first transfer payload rather than total payload remaining. See "Using The Byte Count Modified Bit" on page 188.
CS 2:0 (Completion Status Code)
Byte 6 Bit 7:5
These bits encoded by the completer to indicate success in fulfilling the request.
000b = Successful Completion (SC) 001b = Unsupported Request (UR) 010b = Config Req Retry Status (CR S) 100b = Completer abort. (CA)
others: reserved. See "Summary of Completion Status Codes
:" on page 187. Completer ID 15:0 Byte 5 Bit 7:0 Byte 4 Bit 7:0
Identifies the completer. While not needed for routing a completion, this information may be useful if debugging bus traffic.
Byte 4 7:0 = Completer Bus # Byte 5 7:3 = Completer Dev # Byte 5 2:0 = Completer Function # Lower Address
6:0
Byte 11 Bit 6:0
The lower 7 bits of address for the first enabled byte of data returned with a read. Calculated from request Length and Byte enables, it is used to determine next legal Read
Completion Boundary. See "Calculating Lower Address Field" on page 187.
Tag 7:0 Byte 10 Bit These bits are set to reflect the Tag received with the
Table 4-9. Completion Header Fields
Field Name Header
Byte/Bit Function
7:0 request. The requester uses them to associate inbound completion with an outstanding request.
Requester ID 15:0 Byte 9 Bit 7:0 Byte 8 Bit 7:0
Copied from the request into this field to be used in routing the completion back to the original requester.
Byte 4, 7:0 = Requester Bus # Byte 5, 7:3 = Requester Device # Byte 5, 2:0 = Requester Function #
Summary of Completion Status Codes
(Refer to Completion Status field in table Table 4-9 on page 185).
000b (SC) Successful Completion code indicates the original request completed properly at the target.
001b (UR) Unsupported Request code indicates original request failed at the target because it targeted an unsupported address, carried an unsupported address or
request, etc. This is handled as an uncorrectable error. See the "Unsupported Request" on page 365 for details.
010b (CRS) Configuration Request Retry Status indicates target was temporarily off-line and the attempt should be retried. (e.g. initialization delay after reset, etc.).
100b (CA) Completer Abort code indicates that completer is off-line due to an error (much like target abort in PCI). The error will be logged and handled as an
uncorrectable error.
Calculating The Lower Address Field (Byte 11, bits 7:0)
Refer to the Lower Address field in Table 4-9 on page 185. The Lower Address field is set up by the completer during completions with data (CplD) to reflect the address of the first enabled byte of data being returned in the completion payload. This must be calculated in hardware by considering both the DW start address and the byte enable pattern in the First DW Byte Enable field provided in the original request. Basically, the address is an offset from the DW start address:
If the First DW Byte Enable field is 1111b, all bytes are enabled in the first DW and the offset is 0. The byte start address is = DW start address.
If the First DW Byte Enable field is 1110b, the upper three bytes are enabled in the first DW and the offset is 1. The byte start address is = DW start address + 1.
If the First DW Byte Enable field is 1100b, the upper two bytes are enabled in the first DW and the offset is 2. The byte start address is = DW start address + 2.
If the First DW Byte Enable field is 1000b, only the upper byte is enabled in the first DW and the offset is 3. The byte start address is = DW start address + 3.
Once calculated, the lower 7 bits are placed in the Lower Address field of the completion header in the event the start address was not aligned on a Read Completion Boundary (RCB)
and the read completion must break off at the first RCB. Knowledge of the RCB is necessary because breaking a transaction must be done on RCBs which are based on start address--not transfer size.
Using The Byte Count Modified Bit
Refer to the Byte Count Modified Bit in Table 4-9 on page 185. This bit is only set by a PCI-X completer (e.g. a bridge from PCI Express to PCI-X) in a particular circumstance. Rules for its assertion include:
1. It is only set = 1 by a PCI-X completer if a read request is going to be broken into multiple completions
2. The BCM bit is only set for the first completion of the series. It is set to indicate that the first completion contains a Byte Count field that reflects the first completion payload rather than the total remaining (as it would in normal PCI Express protocol). The receiver then recognizes that the completion will be followed by others to satisfy the original request as required.
3. For the second and any other completions in the series, the BCM bit must be
deasserted and the Byte Count field will reflect the total remaining count--just as in normal PCI Express protocol.
4. PCI Express devices receiving completions with the BCM bit set must interpret this case properly.
5. The Lower Address field is set up by the completer during completions with data (CplD) to reflect the address of the first enabled byte of data being returned
Data Returned For Read Requests:
1. Completions for read requests may be broken into multiple completions, but total data transfer must equal size of original request
2. Completions for multiple requests may not be combined
3. IO and Configuration reads are always 1 DW, so will always be satisfied with a single completion
4. A completion with a Status Code other than SC (successful completion) terminates a transaction.
5. The Read Completion Boundary (RCB) must be observed when handling a read request with multiple completions. The RCB is 64 bytes or 128 bytes for the root complex; the value used should be visible in a configuration register.
6. Bridges and endpoints may implement a bit for selecting the RCB size (64 or 128 bytes) under software control.
7. Completions that do not cross an aligned RCB boundary must complete in one transfer. 8. Multiple completions for a single read request must return data in increasing address
order.
Receiver Completion Handling Rules:
1. A completion received without a match to an outstanding request is an Unexpected Completion. It will be handled as an error.
2. Completions with a completion status other than Successful Completion (SC) or Configuration Request Retry Status (CRS) will be handled as an error and buffer space associated with them will be released.
3. When the Root Complex receivers a CRS status during a configuration cycle, its
handling of the event is not defined except after reset (when a period is defined when it must allow it).
4. If CRS is received for a request other than configuration, it is handled as a Malformed TLP.
5. Completions received with status = a reserved code alias to Unsupported Requests. 6. If a read completion is received with a status other than Successful Completion (SC),
no data is received with the completion and a CPl (or CplLk) is returned in place of a CplD (or CplDLk).
7. In the event multiple completions are being returned for a read request, a completion status other than Successful Completion (SC) immediately ends the transaction. Device handling of data received prior to the error is implementation-specific.
8. In maintaining compatibility with PCI, a Root Complex may be required to synthesize a read value of a "1's" when a configuration cycle ends with a completion indicating an Unsupported Request. (This is analogous to master aborts which occur when PCI enumeration probes devices which are not in the system).
Message Requests
Message requests replace many of the interrupt, error, and power management sideband signals used on earlier bus protocols. All message requests use the 4DW header format, and are handled much the same as posted memory write transactions. Messages may be routed using address, ID, or implicit routing. The routing subfield in the packet header indicates the routing method to apply, and which additional header registers are in use (address registers, etc.). Figure 4-11 on page 190 depicts the message request header format.