PCIe Chapter 5: From a Read or Write to a PCIe Transaction

Simulated data: Packet fields and values are created for teaching and do not represent a particular device or platform.

Trace a read request and its completion

Intermediate ports are omitted. The request and completion follow their respective routing rules; later sections expand split completions and request boundaries.

An MMIO (Memory-Mapped I/O) read starts with a host request and returns device data. PCIe carries these exchanges in TLPs (Transaction Layer Packets). Chapter 4 supplies the configured address path; this example follows a four-byte read.

Specification route: Transaction classes in Table 2-1 → request identity and Memory Request format → Completion format → fragmentation and boundaries.

After resource allocation, an access still has to become a Request and find its way back as a Completion. This chapter follows an MMIO read through routing, transaction identity, length, and byte selection, then explains why one Request may receive several Completions.

MMIO: Memory-Mapped I/O, mapped device-register access

Full Chinese tutorial · Course roadmap · 繁體中文

Identify the transaction before expecting a response

A Transaction Layer Packet (TLP) carries a transaction. The Requester issues it and the Completer services its target; these roles change with the transaction. Memory Requests route by address, while Completions return by the original Requester ID. Requester ID and Tag identify an outstanding transaction. One Requester must not reuse a Tag across simultaneous outstanding Requests requiring Completion. Base 6.0 also defines larger-Tag capabilities and enables, so Tags are not universally eight bits.

Common transactions and successful responses
Transaction	Request class	Successful response
Memory Read	Non-Posted	One or more CplD packets.
Ordinary Memory Write	Posted	No ordinary Completion.
Configuration / I/O Read	Non-Posted	CplD.
Configuration / I/O Write	Non-Posted	Cpl.
Message Request	Posted	No Transaction Layer Completion; a higher protocol may define a response.

Configuration routes by ID, I/O by I/O address, and Messages use their specified address, ID, or implicit routing. Absence of a Completion for ordinary MWr does not justify retrying it or prove device work has completed. Work results follow the device interface.

Sources and reading order

Base 6.0 Table 2-1 (pp.116–117), Table 2-3 (pp.120–122), Figures 2-27/2-28 (pp.152–154); §2.2.7.1 (pp.162–165), §2.2.8 (pp.170–171), and Table 2-42 (pp.222–223).

Translate a 4-byte read into packet fields

Assume a platform Requester ID of 0x0000 and Tag 0x12 for a 4-byte read at 0x80004120. This ID is a platform assumption, not something inferred directly from the Root Port BDF. MRd uses Fmt=000b, Type=00000b, Length=1 DW, First BE=1111b, and Last BE=0000b, without a Request data payload. The 3 DW header follows the 32-bit target address format, not the width of the data being read.

BDF: Bus/Device/Function
DW: Double Word, a four-byte unit

The successful CplD uses Fmt=010b and Type=01010b, preserves Requester ID/Tag, and supplies Completer ID=0x0300. Length=1 DW, Status=SC, Byte Count=4, and Lower Address=0x20. If the four valid bytes are 78 56 34 12 and the example Register is defined as little-endian, the value is 0x12345678.

A separate legal 6-byte read of 0x80004121–0x80004126 uses aligned address 0x80004120, Length=2, First BE=1110b, and Last BE=0111b. The successful response occupies 2 DW but contains six valid bytes: Byte Count=6 and Lower Address=0x21. Disabled non-Prefetchable bytes must not be read at the Completer. The device interface must permit this access.

Field lookup

Figure 2-31 (p.163) → Figure 2-26/Table 2-10 (pp.150–151) → Figure 2-73 (p.196) → Tables 2-37, 2-40, and 2-41 (pp.197, 217–218). Table 2-4 (p.122) defines Length units and the zero encoding: for applicable data transactions, zero means 1024 DW.

Byte Count need not equal this packet's payload size

Now assume the Endpoint reads 256 bytes from valid DMA address 0x40001000, using Requester ID=0x0300 and Tag=0x13, with BME and mappings ready. Its maximum read request is 512 bytes; the Completer's effective payload limit and RCB are 128 bytes, with compatible path receive limits. The Length=64 DW Request can receive:

DMA: Direct Memory Access, device access to memory

Author-created split successful response
Data range	Length	Byte Count	Lower Address
0x40001000–0x4000107F	32 DW	256 bytes	0x00
0x40001080–0x400010FF	32 DW	128 bytes	0x00

Both responses have SC, BCM=0, and the same Requester ID/Tag. Byte Count includes the current fragment and the data still to follow. One Request's responses stay in increasing address order; responses for different Transaction IDs may pass each other and must not be combined into one Completion.

A separate restriction prohibits a Memory Request from crossing 4 KiB. Reading 32 bytes at 0x40001FF0 reaches 0x4000200F and requires two 16-byte Requests. A Receiver may check this boundary; if its implemented check detects a violation, it treats the TLP as Malformed. The absence of an error record does not establish that the Request was legal. This example is an ordinary Non-Flit Mode Memory Read; Chapter 15 covers AtomicOp alignment separately.

TLP: Transaction Layer Packet

An unsuccessful read Completion carries no valid read data and terminates the Request. UR/CA are not zero data, and RRS is not a general MMIO retry status.

Splitting and boundaries

§2.2.7.1 (pp.162–163); §2.3.1.1 (pp.214–218); §2.4.1 D5a/D5b (p.224) and §2.4.2 (p.228). RCB constrains Completion splitting, while the 4 KiB rule constrains Requests.

How do we separate replies when two devices use the same Tag?

Match each Completion to its Request using both Requester ID and Tag, then inspect Status, Length, Byte Count, and Lower Address to reconstruct the data range. Grouping first shows which bytes belong to which read.

Simulated data: two reads in one trace

Keep the 256-byte DMA read from the previous section and assume Endpoint 04:00.0 issues another read at the same time. Both use Tag 0x13, with different Requester IDs. The example uses Non-Flit Mode, TC0 and BCM=0; all bytes are enabled, payloads match Length, and both Completions have SC and EP=0. B's maximum read request and the effective Completion payload limit on its path are at least 128 bytes; other path and address-mapping conditions are satisfied.

DMA: Direct Memory Access, device access to memory

The observation point is between the Root Port and Switch. Assume the table lists decoded logical transactions, including both Requests and the shown Completions, with Replay duplicates already excluded. Traffic after the capture ended is unknown. Scroll the table horizontally on narrow screens.

Group by Requester ID and Tag
Record	Requester ID / Tag	Requested range or Completion fields
Request A	0x0300 / 0x13	Reads 0x40001000–0x400010FF, 256 bytes.
Request B	0x0400 / 0x13	Reads 0x40002000–0x4000207F, 128 bytes.
Completion A1	0x0300 / 0x13	Length=32 DW, Byte Count=256, Lower Address=0x00.
Completion B1	0x0400 / 0x13	Length=32 DW, Byte Count=128, Lower Address=0x00.

Match first: A1 has 0x0300 / 0x13 and belongs to A; B1 has 0x0400 / 0x13 and belongs to B. Their Tags match, but their Transaction IDs differ. Each Requester must keep the Tag unique among its own outstanding Requests requiring Completion; the Tag need not be unique across the system.

Then check ranges: With all bytes enabled, A1 carries 32 DW, or 128 bytes, corresponding to 0x40001000–0x4000107F. Byte Count=256 includes these bytes and the 128 still to follow. This trace has not shown A’s 0x40001080–0x400010FF. B1 covers B’s complete 128-byte range and cannot fill A’s gap.

Both Lower Address values are 0x00 because the low seven bits of each starting address are zero. The field alone cannot reconstruct a full address. Completer ID and complete endpoint records are absent, so B’s data coverage still needs other Completion fields and Requester acceptance checked. A’s remaining data may appear later, be missing from the capture, or not yet have returned; this evidence does not establish Timeout or identify a failed component.

Reading route: Figure 2-28 defines Transaction ID; Figure 2-73 locates Requester ID, Tag, Status, Byte Count and Lower Address in the Completion. Then use §2.3.1.1 for Byte Count and increasing-address rules. Completions with different Transaction IDs may pass each other; that permission does not mean they always reorder. For a full validation also inspect Completer ID, TC, Attributes, payload length, and applicability. (Base 6.0, printed/PDF pp.153, 196–198, 215, 218, 224.)

TC: Traffic Class

Can a larger Tag use any value in its bit width?

Figure 2-28 combines Requester ID and Tag to identify an outstanding transaction. Within one PCIe Hierarchy, outstanding Non-Posted Requests for the same Requester ID need distinct Tags regardless of Traffic Class. To use a larger range, also apply Table 2-11 to the Requester settings, Completer capability, and routing path. Flit Mode has additional Segment identification rules across Hierarchies, outside this example.

The left three columns are 14-Bit Tag Requester Enable, 10-Bit Tag Requester Enable, and Extended Tag Field Enable. The right columns use the greatest Tag capability common to the Completer and its path. Confirm that the Requester itself supports and is permitted to use the feature before selecting a column. An enabled control does not prove Completer support or guarantee a specific number of simultaneous requests.

Teaching example: These rows are independent configurations. The Requester, destination and routing path support the capabilities used in each case; no VF or Phantom Function is used. The second row's path carrying 14-bit Tags operates in Flit Mode.

VF: Virtual Function

On a phone, scroll the table horizontally to see all columns.

14-bit / 10-bit / Extended Enable	8-bit Completer/path	10-bit Completer/path	14-bit Completer/path
0 / 1 / 1	0–255	256–1023	256–1023
1 / 1 / 0	0–31	256–1023	1024–16383

In the first row, a 10-bit Completer/path uses the Table 2-11 range starting at 256; it is not a general rule that every value below 1024 belongs to that 10-bit range. An 8-bit Completer/path in that row uses 0–255. A 5-bit Completer/path always uses 0–31.

Extended Tag Field Enable is in Device Control within the PCI Express Capability; 10-Bit Tag Requester Enable is in Device Control 2; 14-Bit Tag Requester Enable is in Device Control 3 within the Device 3 Extended Capability. Walk the appropriate capability and check applicability; VFs have separate controls in the PF. Changing the 10-bit or 14-bit Requester Enable while that Function has outstanding Non-Posted Requests has undefined results.

PF: Physical Function

When Requests to larger- and smaller-Tag-capable targets are concurrent, use the permitted range for each path and prevent a larger Tag truncated by an unsupported Completer from aliasing an outstanding smaller Tag. Check the entire path before sending rather than inferring its capability from a later abnormal Completion.

PCI Express Base 6.0 §2.2.6.2, Figure 2-28 and Table 2-11, printed/PDF pp.153–156; §7.5.3.4, Table 7-21, p.960; §§7.5.3.15–7.5.3.16, Tables 7-33–7-34, pp.991 and 997; §§7.7.9.2–7.7.9.3, Tables 7-108–7-109, pp.1073 and 1075.

Why inspect low bits when larger and smaller Tags are concurrent?

The previous table selects permitted values before sending. Section 2.2.6.2 also requires a Requester using larger and smaller Tags concurrently to prevent an outstanding larger Tag from aliasing a smaller one if an insufficiently capable Completer responds to the larger-Tag Request.

Teaching example: One Requester ID has two outstanding Reads: Tag 100h to path A, which it assumes supports 10-bit Tags, and Tag 00h to 8-bit path B. Full path support for A has not been verified. The original Tags differ, but both have low 8 bits 00h.

Suppose A's Request encounters an error and an intermediate component without 10-bit Completer capability responds, losing the upper Tag bits in this response and returning 00h. Matching that response only to Requester ID and the low Tag can confuse A's abnormal response with B's result. This is an assumed failure example, not a claim that all components truncate identically.

The p.159 implementation note Using Larger Tags and Smaller Tags Concurrently gives one partition: reserve low 8-bit values 00h–0Fh for smaller Tags and do not use those low values in larger 10-bit Tags. Each of these 16 low values corresponds to three valid 10-bit high-bit combinations; removing 48 from the original 768 leaves 720 10-bit values, alongside 16 smaller values.

This is one implementation approach, not a required universal partition. The requirement is to prevent the alias; actual concurrency also depends on device resources and path conditions. Use Table 2-11 from the previous section first to select the permitted range for each Request.

PCI Express Base 6.0 §2.2.6.2, printed/PDF pp.154–155; Implementation Note: Using Larger Tags and Smaller Tags Concurrently, p.159; Table 2-11, pp.155–156.

Where does a cross-Hierarchy Completion return?

The earlier examples match a Requester ID and Tag within one PCIe Hierarchy. In Flit Mode across Hierarchies, Segment information also helps the path identify the destination Hierarchy. Chapter 3's Segment capture example explains how a Function obtains its Segment.

[Simulated data] This teaching example does not represent a particular device or platform. Endpoint A is in Segment 02h and Endpoint B is in Segment 03h; both have Segment Captured set. A sends a Non-Posted Memory Read to B. Assume every Link is in Flit Mode, address routing and platform peer-to-peer support have been established, and the Root Complex (RC) passes this Request without taking ownership. A's OHC-C carries Requester Segment 02h with Requester Segment Valid (RSV) set.

B receives the address-routed Request. Its captured Segment 03h differs from the received Requester Segment 02h, so every associated Completion must include OHC-A5. For a Successful Completion with Lower Address[1:0] equal to 00b, Figure 2-11 gives:

OHC-A5 in byte order
Byte	Example	Meaning
0	`02h`	Destination Segment: A's Hierarchy.
1	`03h`	Completer Segment captured by B.
2	`80h`	Destination Segment Valid (DSV) is set; Reserved bits are zero.
3	`00h`	Lower Address[1:0] and Successful Completion Status are zero.

The bytes are 02 03 80 00. The Destination Segment directs the return through the RC to A's Hierarchy. The Requester still matches the Completion using Requester ID and Tag and checks Status and the data range. A Requester must not qualify the Destination Segment field in received Completions.

For a non-IDE Memory Request, including the Requester Segment can be optional. If B receives a Non-Posted Memory Request without it, any OHC-A5 in B's associated Completion has DSV clear and Destination Segment 00h. RC ownership follows different identification and restoration rules, so this no-ownership example is not universal.

Read Figure 2-13 in §2.2.1.2 for Requester Segment and RSV, then the Requester, Completer and RC rules in that section. Use Figure 2-11 to decode the Completion's OHC-A5 and §2.2.9.2 for when it is required. Check the observation point, Link modes, Segment Captured and RC ownership before drawing a conclusion about the transaction.

PCI Express Base Specification Revision 6.0, §2.2.1.2, Figures 2-11 and 2-13, document/PDF pp. 133–134 and 138–141; §2.2.9.2, p. 199.

Check the distinction

Is a 128-byte first response with Byte Count=256 incorrect?

No. The count includes the next 128 bytes still needed for the Request. Length describes this fragment's payload.

Does “Base 6.0” alone justify decoding every packet with Figure 2-31?

No. This chapter selects Non-Flit Mode. Flit Mode uses the different header definitions in §2.2.1.2.

The next chapter examines DMA addresses and visibility beyond packet validity. All cited pages use Base 6.0 document/PDF numbering. Verified 2026-10-28.

Jia-Chang

Human

Comments

Write a comment ...