Chapter 5.6 – Request and Completion TLPs in PCI Express

(Formats, Fields, and Flow Examples)

1. Introduction

In PCI Express, every operation begins with a Request TLP and, if it’s a non-posted request, is followed by one or more Completion TLPs from the recipient.

The Request and Completion mechanism enables asynchronous, full-duplex communication, eliminating the wait-states and arbitration delays that plagued traditional parallel PCI buses.

2. Classification of Requests

Requests in PCIe are categorized based on their function and completion behavior:

Type	Example TLPs	Completion Expected?	Direction
Posted	Memory Write, Message	❌ No	Requester → Completer
Non-Posted	Memory Read, I/O Read, Configuration Read	✅ Yes	Requester ↔ Completer
Completion	Completion, Completion with Data	—	Completer → Requester

💡 Posted = No response required, Non-posted = Must be acknowledged with a completion.

3. Request TLP Structure

Every Request TLP contains:

A Header describing the operation (Format/Type, Address, Attributes)
Optional Payload (for write operations)
Optional Digest (ECRC) for end-to-end integrity

Example 1: Memory Write (Posted Request)

DW0: [Fmt=10, Type=00000, TC, TD, EP, Attr, Length]

DW1: [Requester ID, Tag, Last BE, First BE]

DW2–DW3: [Address]

Payload: Data

Optional: ECRC

Example 2: Memory Read (Non-Posted Request)

DW0: [Fmt=00, Type=00000, TC, TD, EP, Attr, Length]

DW1: [Requester ID, Tag, Last BE, First BE]

DW2–DW3: [Address]

(No Payload)

Optional: ECRC

Both packets are transmitted downstream (from Requester → Completer).

4. Completion TLPs Overview

A Completion TLP is sent in response to a Non-Posted Request, carrying either:

Status information only, or
Status + Requested data

Completion Type	Description	Data Payload
Cpl	Completion without data	❌ No
CplD	Completion with data	✅ Yes
CplDL	Completion with data + Locked transaction	✅ Yes

5. Completion Header Fields

Completion headers reuse many common TLP header fields, but also include unique ones:

Field	Purpose
Completer ID	Identifies the device sending the completion
Completion Status	Indicates success or error type
BCM (Byte Count Modified)	Flags modified byte count
Byte Count	Number of valid bytes returned
Requester ID	Echoed from original request
Tag	Matches the completion to its request
Lower Address	Byte alignment offset for returned data

6. Completion Status Codes

Code	Meaning	Description
000b	Successful Completion (SC)	Request completed successfully
001b	Unsupported Request (UR)	Completer doesn’t support the requested operation
010b	Configuration Request Retry Status (CRS)	Indicates configuration not yet ready (software retries later)
011b	Completer Abort (CA)	Completer unable to process request due to internal error

7. Lower Address Field

When a Completion returns data, the Lower Address field identifies the byte offset of the first valid byte in the payload relative to a DW boundary.

Example:

Original Read Address = 0x0000_0002
Lower Address = 2
Returned data starts at byte offset 2 in the first word.

This ensures proper byte alignment during reassembly of read data.

8. Completion Flow Example – Memory Read

Step 1: Requester Sends a Memory Read

Type: Memory Read (Non-Posted)
Tag: 0x4A
Address: 0x0000_2004
Length: 8 DWs (32 bytes)

Step 2: Completer Receives and Processes

Decodes address and verifies access permissions.
Reads 32 bytes from memory.

Step 3: Completer Sends a CplD

Type: Completion with Data
Status: Successful
Requester ID: Echoed from request
Tag: 0x4A
Byte Count: 32
Lower Address: 4

Step 4: Requester Matches Completion

Uses Tag and Requester ID to match.
Reassembles data and delivers it to application logic.
Removes Tag from outstanding list.

🔁 This asynchronous request–completion cycle allows multiple outstanding reads to overlap, maximizing bandwidth.

9. Completion with Error Example

If the completer encounters an unsupported address range:

Completer sends Completion (Cpl) with:
- Status = Unsupported Request (UR)
- No Data Payload
Requester reports an AER (Advanced Error Reporting) event if enabled.

10. Byte Count and BCM Field

The Byte Count field specifies the number of valid bytes in the completion payload.

Normally = Length × 4 (for full DW data)
Modified Byte Count (BCM=1) indicates that Byte Count differs from the expected value — often due to boundary trimming or partial completions.

11. Completion with Data Example (CplD)

Let’s decode a simple completion:

Field	Value	Description
Fmt	10b	With Data
Type	01010b	Completion
Completion Status	000b	Successful
BCM	0	Normal
Byte Count	0x10	16 bytes
Requester ID	0008h	From Request
Tag	1Ah	Matches Request
Lower Address	00h	Data starts at byte 0
Payload	16 bytes of read data

12. Ordering Rules Between Requests and Completions

Posted requests (e.g., writes) may bypass non-posted requests (reads) to optimize throughput.
Completions must always return in Tag order per Requester ID.
PCIe switches and bridges ensure that completion packets aren’t reordered relative to their originating request.

🔧 Hardware Verification Tip:
Assertions like “completion matches tag of request” and “completions never reorder” are standard checks in PCIe testbenches.

13. Real-World Analogy

Think of a PCIe read as an online order:

You (Requester) send an order (Memory Read).
The seller (Completer) acknowledges and ships the package (Completion with Data).
You track it using your order number (Tag).
If it can’t be delivered (UR/CA), the seller sends a notification.

This asynchronous, tag-based system keeps everything traceable and efficient.

NOTES

Request TLPs initiate operations; Completions close the loop.
Tags ensure completions map correctly to outstanding requests.
Completion headers contain status, byte count, and lower address for alignment.
Errors are communicated via completion status codes.

Proper tag handling is vital for protocol compliance and throughput optimization.