PCIe Chapter 36: Dependencies, ID-Based Ordering, and Messages

Read row-passes-column literally

Columns are earlier transactions; rows are later transactions. The table asks whether the later can pass the earlier. Read the a/b explanations on pp.223–224 before applying an entry. In the author example, same-requester/same-TC posted data and notification writes without an applicable relaxation follow A2a: the later must not pass the earlier. That ordering does not independently define persistence or CPU memory-barrier requirements.

How do we use the table for two transactions?

Teaching assumptions: Each row is independent. Both transactions use the same Traffic Class (TC) and are compared at the same forwarding point. Put the earlier transaction in the Table 2-42 column, the later transaction in the row, then read the corresponding text beneath the table.

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

RO is Relaxed Ordering; IDO is ID-Based Ordering. In the second row inspect the later Read's IDO and compare Requester IDs, including Requester Segment in FLIT Mode. An enable setting alone does not replace inspection of the TLP attribute.

TLP

Transaction Layer Packet

Table 2-42 applies within one TC; Flow-Through IDE Streams have modified rules in §6.33.4. Permission to pass does not promise that passing occurs. Application visibility and synchronization require platform and device rules as well.

IDE

Integrity and Data Encryption

How does No Snoop relate to ordering?

No Snoop is a cache-coherency attribute. Base 6.0 §2.2.6.5 Table 2-13 distinguishes the default value 0, where hardware-enforced cache coherency is expected, from value 1, where it is not expected. No Snoop itself does not change Transaction ordering. To evaluate passing, use the Ordering Rules Table with the applicable Traffic Class, transaction types, and other attributes.

Device Control.Enable No Snoop permits a Function to set this attribute on its own Requests when the conditions are satisfied; it does not force every Request to use it. Even when enabled, the Function may set No Snoop only when it can guarantee that the transaction address is not stored in any system cache. The control may be hardwired to 0 and has a default value of 1. Check the control and the attribute on the actual packet separately.

Teaching example: Enable No Snoop=1 and a Memory Write with No Snoop=0 can coexist: permission to use the attribute does not require its use on this packet. If a packet instead has No Snoop=1, platform and software memory-management information is needed to assess the address condition; the bit alone does not establish that an application sees the latest data.

Configuration Requests, I/O Requests, Memory Requests used as Message Signaled Interrupts, and Message Requests except where specifically permitted must have No Snoop clear. Check these type-specific restrictions as well as the control.

PCI Express Base 6.0 §2.2.6.5 and Table 2-13, printed/PDF p.161; §7.5.3.4, Figure 7-25 and Table 7-21, pp.959–961. Platform caching and software synchronization require the applicable platform documentation.

Start with the communication model

Use Figure E-1 and Appendix E to distinguish one-entity communication from mixed host-memory/P2P interaction. E.4.1 shows how relaxed passing can change the final memory result in a multi-entity dependency. Appendix D examines receive-to-transmit resource dependencies; it does not define every platform’s cross-TC dependency rules. System mapping must respect the actual model.

Does permitted passing make a multi-device workload safe?

Teaching scenario based on Appendix E.4.1: Device Y writes host memory, then sends a peer-to-peer (P2P) write to notify Device Z. Once Z sees the notification, it writes the same memory location.

Use Figure E-1 to locate Y, Z, the Switch, and the Root Complex, then order the three transactions at the observation point. Assume Y and Z use the same TC for their writes and compare them at a common Root Complex processing point. The first two originate at Y; Z's later write has a different Requester ID. If Z's Posted Write has IDO set and the other conditions of Table 2-42 A2b hold, the Root Complex may allow it to pass Y's waiting write, changing the final memory value.

Requester IDs alone cannot express this cross-device data dependency. Evaluate the entities, TLPs, path, and synchronization before enabling IDO. The appendix mentions possible synchronization; the exact protocol is platform and device specific.

Appendix D covers a different issue: cross-TC packets can form circular dependencies on finite buffer resources, creating deadlock. An absence of general ordering across TCs does not eliminate system-level dependencies.

Quiesce all relevant traffic before renumbering

Section 6.4 requires blocking new device requests and driver accesses, completing work serviced by the device, completing issued non-posted requests, and ensuring posted requests reached their destinations. Transactions Pending covers only part of that work. Coordinate with the driver and track outstanding traffic before changing IDs; a cleared control bit is not proof of full quiescence.

What must stop before changing a Bus Number?

Teaching scenario: A driver prepares to reconfigure an Endpoint. Under §6.4, coordinate with the driver to stop new device-generated Requests and new software Requests to the device, then establish that Requests being serviced by the device have completed.

Device Status.Transactions Pending addresses completion of Non-Posted Requests issued by that function. It does not by itself establish delivery of earlier Posted Writes. Check their destination using the relevant TC, ordering attributes, and device synchronization mechanism.

Section 6.4 describes host reads of the device flushing device writes to system memory using TC0; other TCs need suitable synchronization. This specific path still requires the RO, IDO, and platform memory conditions to be respected. P2P traffic needs an explicit synchronization protocol between devices even with TC0.

Use Message Code Usage as an index

Table F-1 maps a message purpose to code, routing, and Msg/MsgD, then points to its defining section. Use it to return to page requests, invalidation, or LTR formats. The table itself warns that newer messages defined elsewhere may not be captured by this Base 6.0 edition.

LTR

Latency Tolerance Reporting

How does a code lead to its full format?

Teaching scenario: Appendix F Table F-1 lists Invalidate Request as Message Code 0000 0001b, Routing 010b, type MsgD. Follow its reference to §10.3.1 for the message fields and handling conditions.

For Function Readiness Status (FRS), Table F-2 lists PCI-SIG-Defined VDM Subtype 0000 1001b. That is a subtype, not the general Message Code in Table F-1. Continue to §2.2.8.6.3 and Chapter 34 for the associated readiness events and queue.

The tables are indexes for Base 6.0 and may omit messages or subtypes introduced in other specifications. Use the referenced definition for full applicability.

Which fields identify a Vendor_Defined Message?

Start with Table 2-28: Message Code 7Eh identifies Vendor_Defined Type 0 and 7Fh identifies Type 1. This message classification is separate from whether the TLP carries data: either type can use Msg without payload or MsgD with payload.

TLP

Transaction Layer Packet

Choose Figure 2-47 for Non-Flit Mode or Figure 2-48 for Flit Mode, then inspect Vendor ID and Routing. In the generic format, bytes 8–9 contain Destination ID for Route by ID and are otherwise Reserved. A specific message can define the same location differently: the Hierarchy ID Message places Hierarchy ID there even though its routing is broadcast. Vendor ID occupies bytes 10–11; bytes 12–15 are available to the message definition. For Vendor ID 0001h and Message Code 7Fh, continue to §2.2.8.6.1 and the mode-specific Figures 2-49/2-50. Find the PCI-SIG Defined VDM by Subtype: 09h, for example, is FRS; see Chapter 34 for its events and scope.

FRS

Function Readiness Status

At a Completer that does not support the message, Type 0 triggers Unsupported Request detection and reporting; Type 1 is silently discarded. This is Completer handling: absence at an intermediate capture point does not establish arrival. Switches must forward received messages with Routing 000b, 010b or 011b; 100b terminates locally.

Attr is not Reserved in the generic format, but an individual message can impose more specific rules: FRS reserves Attr. Generic VDM Requester ID is implementation-specific in Non-Flit Mode and must identify the Requester in Flit Mode; PCI-SIG Defined VDMs separately require the associated Requester value. PCIe-to-PCI/PCI-X Bridge messages interoperating with PCI-X Device ID Messages also require the bridge specification's additional constraints.

Edition and sources

This chapter uses PCI Express Base Specification Revision 6.0 (6.0-1.0-PUB). Document and PDF page numbers match. Example configurations and values are author assumptions, not device measurements.