In our previous lectures, we unpacked the generic TLP header and how payloads and Byte Enables work. Now, it is time to look at the specific rules applied to the unique transaction types moving across the PCIe fabric.
While many generic fields apply to all packets, certain transaction variants handle their headers quite differently. Let’s break down the rules for four critical TLP formats: IO Requests, Memory Requests, Configuration Requests, and Completions.
1. IO Requests (Legacy Support)
While the PCIe specification actually discourages the use of IO transactions, they are supported to accommodate legacy devices and software. Although IO transactions can technically access a 32-bit range, many systems restrict IO access to the lower 16 bits (64KB). When forming an IO Request, the following specific rules apply:
- Header & Size: They always use a 3 Double Word (3DW) header. Because no more than 4 bytes can be transferred at a time, the Length field is always exactly 1 DW.
- Byte Enables: Since the payload is strictly 1 DW, the Last DW Byte Enables must be set to
0000b, while the First DW Byte Enables dictate which specific bytes are used. - Strict Priority & Ordering: The Traffic Class (TC) for IO requests is always set to zero, ensuring they never interfere with high-priority packets. Furthermore, performance attributes like Relaxed Ordering and No Snoop are completely ignored (always set to 0).
2. Memory Requests
Memory transactions are the heavy lifters of PCIe data movement and include Read Requests (which require Completions) and Write Requests. Because they can move massive amounts of data, they have highly optimized rules:
- Header Size: Memory Requests can use either a 3DW header for 32-bit addressing or a 4DW header for 64-bit addressing,.
- The 4KB Boundary: A strict rule in PCIe is that a memory data transfer is never permitted to cross a 4KB address boundary,.
- Payloads & Posting: The data payload size can range anywhere from 0 to exactly 1024 DW (4KB). To maximize performance, all memory-mapped writes are handled as posted transactions.
- Quality of Service (QoS): Unlike IO Requests, Memory Requests fully support QoS features, utilizing up to 8 Traffic Classes (TC0–TC7). They can also leverage the Relaxed Ordering and No Snoop attributes to optimize delivery and bypass processor cache checks.
3. Configuration Requests
Configuration requests are used by the host to discover and configure devices in the topology. PCIe maintains backward compatibility with PCI by using both Type 0 and Type 1 configuration cycles. A Type 1 cycle propagates downstream until it reaches the target bridge, which then seamlessly converts it into a Type 0 cycle.
- Addressing: These packets always use a 3DW header and are routed using the target Completer ID (Bus, Device, and Function numbers) rather than a memory address,.
- Rigid Formatting: Similar to IO requests, Configuration requests have a strict Length of 1 DW, a Traffic Class of zero, and do not utilize Relaxed Ordering or No Snoop attributes.
4. Completions
When a device issues a Non-Posted Request (like a Memory Read, IO Read/Write, or Configuration request), the target must eventually respond with a Completion. A completion can simply report status without data (Cpl), or it can return requested data (CplD),.
- Inherited Fields: To ensure the completion makes it back properly, many header fields use the exact same values as the original request, including the Traffic Class, Attribute bits, and the original Requester ID.
- Completion Status Code: Byte 6 of the completion header includes a vital 3-bit status code. This tells the requester if the transaction was a Successful Completion (SC), an Unsupported Request (UR), a Configuration Request Retry Status (CRS), or a Completer Abort (CA),,.
- Tracking Data Deliveries: If a large memory read requires multiple completions, the header uses a Byte Count field to indicate the total payload bytes remaining, and a Lower Address field to reflect the byte-aligned starting address of the data currently being returned,.