PCIe Chapter 24: TPH, LTR, and OBFF Platform Coordination

Keep the participants in view

The topology is Root Port → Switch → Endpoints A and B, each with only Function 0 in D0. Basic Link operation and resource configuration are ready. The independent-Port background is in Chapter 1.

Simulated data: the topology, values and timings below were created for teaching and do not represent particular hardware. Assume that the relevant TPH (Request processing hints), LTR (service-latency reporting) and OBFF (platform activity hints) capabilities have each been checked along their required paths. The platform supplies valid steering values. WAKE# is unavailable on the Links used for the OBFF example, so Message signaling is used. These are separate assumptions, not consequences of finding one capability.

A device writes data that the host will soon read

Open Table 6-13, Processing Hint Mapping. The device-write/host-read usage model maps to Target, PH[1:0]=10b. This information does not change the Memory Write Transaction type or grant access rights.

Next, §6.17.2 defines the Steering Tag (ST), a system-specific value identifying a processing resource. Software obtains the appropriate platform value; a tag is not a universal CPU number. Section 6.17.4 requires the Requester, Completer and every intermediate routing element to support the associated capabilities. TPH Completer Supported is Device Capabilities 2 [13:12] for Root Ports and Endpoints; it is Reserved for Switch Functions, so it is not a per-Switch-port support test.

Connect capability, table and selected mode

Walk the Extended Capability list to ID=0017h, Version=1, and call the base T. Figure 7-289 locates the structure; Tables 7-258 and 7-259 decode its fields. Assume software has configured tags 0031h, 0042h, 0053h and 0064h.

ST Table Location=01b places the table in this structure. ST Table Size=3 is N−1 encoded, hence four entries. Figure 7-293 starts the table at T+0Ch with 2-byte entries. In Interrupt Vector Mode, valid MSI-X vector 2 selects entry 2 at T+0Ch+2×2=T+10h. Assume both the enabled vector range and the table cover that entry.

MSI-X

Message Signaled Interrupts Extension

Control 00000101h selects Interrupt Vector Mode and permits ordinary TPH, not Extended TPH. Extended TPH support is clear, so the entry's upper byte is RsvdP; ST Lower supplies 53h. This identifies the selected hint, not an observed cache destination or performance improvement.

With Location=10b, look in the MSI-X Table instead; a Function cannot place the table in both locations. No ST Mode requires zero tags and still permits Processing Hints. The specification recommends quiescing the Function or disabling the TPH Requester during table updates to avoid nondeterministic values. Preserve that recommendation strength.

MSI-X

Message Signaled Interrupts Extension

Base 6.0 §§6.17.2–6.17.4, pp.779–781; §7.9.13, Figures 7-289–7-294 and Tables 7-257–7-260, pp.1241–1245. Basic Request layout: Chapter 14.

First distinguish configuration registers from reported fields

LTR reports Endpoint Memory Read/Write service requirements for central platform power policy. It does not directly control Link or Switch-internal power management. Check Device Capabilities 2 [11], LTR Mechanism Supported, and Device Control 2 [10], LTR Mechanism Enable. Do not enable an Endpoint unless the Root Complex and all intermediate Switches support LTR. Enable devices closest to the Root Port first.

Figure 7-142 locates the LTR Extended Capability, ID=0018h, Version=1. With base L, Max Snoop Latency is L+04h and Max No-Snoop Latency is L+06h. These software-writable limits provide platform information; they are not a log of the latest device report. Ordinary multi-Function devices implement this structure only in Function 0. Root Ports and Switch Downstream Ports do not implement this structure, although they can support and process LTR through Device Capabilities 2/Control 2.

Author example: Max Snoop Latency=080Ah means Value=10 and Scale=010b: 10×1,024 ns=10,240 ns. Bits [15:13] are RsvdP; this register has no Requirement bit. In a Message, Snoop Latency=880Ah instead represents a valid 10,240 ns requirement. Do not copy 880Ah into the configuration register.

Base 6.0 §6.18, pp.781–782; §7.5.3.15, p.991; §7.5.3.16, p.996; §7.8.2, Figures 7-142–7-145 and Tables 7-126–7-128, pp.1101–1103.

Decode both reported traffic classes

Use Figure 2-57 for Non-Flit Mode, or Figure 2-58 after Flit processing and TLP reassembly. The base headers differ. Table 2-33 identifies Message Code=10h, Routing=100b, TC0 and no Data Payload. The two latency fields are in the Header, not a MsgD payload.

Figure 6-15, Latency Fields Format for LTR Messages, gives each 16-bit field: Requirement [15], Reserved [14:13], Scale [12:10] and Value [9:0]. Decode time only for Requirement=1. Permitted scales 000b–101b multiply by 1, 32, 1,024, 32,768, 1,048,576 or 33,554,432 ns.

A's No-Snoop Requirement=0 makes its retained Value and Scale irrelevant. It does not request zero latency. By contrast, Requirement=1 with Value=0 says that any delay affects the device and requests the best possible service; it is not a hardware promise of zero delay.

Base 6.0 §2.2.8.8, Table 2-33 and Figures 2-57/2-58, pp.187–188; §6.18, Figure 6-15, pp.781–782.

Why does the Switch report different values?

Routing=100b terminates at the adjacent receiver. Under §6.18 the Switch collects requirements from enabled Downstream Ports, takes separate minima for Snoop and No-Snoop, and subtracts all Switch-induced latency, Lswitch. Clamp a negative result to zero. Its Upstream Port transmits a conglomerated Message rather than forwarding A's original Message unchanged.

Assume a fixed Lswitch=1,024 ns and no other valid sources. A sets the tighter Snoop requirement; only B supplies a No-Snoop requirement:

A platform Snoop service time of 9,216 ns plus 1,024 ns in the Switch matches A's 10,240 ns report. If B's Port goes DL_Down, invalidate B's old values. Snoop remains constrained by A; No-Snoop now has no requirement and its upstream Requirement must be clear.

For Requirement=1 and Value=0, the Switch uses zero regardless of Scale. A zero conglomerated result must have both Value and Scale zero. A Not Permitted Scale is not an arithmetic operand: §6.18 treats that source as effectively infinite for Switch aggregation. The normal example uses only permitted encodings.

If Lswitch changes with operating mode, it must not exceed 20% of the downstream minimum unless even the lowest-latency mode exceeds that bound, in which case that mode must be used. A multi-Function device similarly selects the lowest requirements per traffic class; Snoop and No-Snoop may come from different Functions.

Base 6.0 §6.18, pp.782–784; Table 2-33, p.187.

Track updates and the service interval

During a sequence of Requests, the RC must comprehend an updated requirement before servicing a subsequent Request; the new value must take effect within the previously reported latency. The Implementation Note recommends reporting a tighter requirement early enough to allow that old latency interval, and a looser one after the final Request needing the preceding value.

If the latest effective Message reported a requirement, a PMCSR Write directing the device to non-D0 requires a Message clearing both Requirement bits before the transition. Clearing LTR Mechanism Enable through a Configuration Write also requires withdrawal; the FLR rule is marked MUST@FLIT in this edition and needs its mode qualification. DL_Down invalidates a Downstream Port's old reports and resets that Port's LTR Mechanism Enable to its default.

FLR

Function Level Reset

The RC is strongly encouraged, not required, to honor requested service latencies. Non-Posted service latency ends at the start of the first Completion, not at the end of all Split Completions. The Posted definition concerns a credit-blocked Request and return of credits permitting transmission to continue. Clock PM may add clock-restoration delay; Figures 6-16 and 6-17 connect those timing components and update scheduling. Link exit details remain in Chapter 10.

Base 6.0 §6.18, pp.782–787; Figure 6-16 CLKREQ# and Clock Power Management, p.785; Figure 6-17 Use of LTR and Clock Power Management, p.786; §7.5.3.16, p.996.

Why may a low-power Link have no activity Message?

Figure 6-19 shows topology segments using WAKE# or Messages, with Switch conversion between them. Here WAKE# is unavailable on the relevant Links and the platform has established Message delivery support. Endpoint capability alone is insufficient to enable the mechanism.

Device Capabilities 2 [19:18] reports supported signaling; Device Control 2 [14:13] selects it: 00b disabled, 01b Message Variation A, 10b Message Variation B, 11b WAKE#. A and B are alternative configurations of the same Downstream Port:

Thus, seeing no indication during L1 can be required by Variation A. Read the actual egress Port's Enable and the contemporaneous Link state. For Variation B, inspect the return to L0 followed by Message transmission. Each segment handles the indication; this is not one unchanged end-to-end broadcast.

OBFF recommends enabling all Upstream Ports before Downstream Ports; Root Ports must be enabled after all other Ports. This differs from LTR's closest-to-Root-Port-first order. Initial OBFF configuration must assume CPU Active until the first observed transition, regardless of the current logical WAKE# level.

Base 6.0 §6.19, Figure 6-19, pp.787–790; §7.5.3.15, p.992; §7.5.3.16, p.997.

Interpret the received indication

Use Figure 2-59 or 2-60 for the mode and Table 2-34 for Message Code=12h, Routing=100b, TC0 and no Data Payload. Only Downstream transmission is permitted. Requester ID is the transmitting Port's ID on that segment. Figure 6-18 maps codes to WAKE# patterns; actual WAKE# electrical requirements require the applicable Card Electromechanical specification.

A receiver enabled for OBFF Message signaling must treat a Reserved OBFF Code as CPU Active. At an unsupported or disabled Port, the Message is an Unsupported Request. Receiving a Message while enabled for WAKE# signaling has undefined behavior.

Non-D0 Functions must not respond to OBFF/CPU Active indications. A working Function may still issue bus mastering or interrupt traffic whenever otherwise enabled. The platform is recommended not to return to Idle within 10 μs of opening an activity window, while Endpoints are recommended not to assume any particular window duration. This does not guarantee a 10 μs window on every occurrence.

Base 6.0 §2.2.8.9, Table 2-34 and Figures 2-59/2-60, pp.188–189; §6.19, Figure 6-18 Codes and Equivalent WAKE# Patterns, pp.787–790.

Choose the next lookup from the actual question

For an unexpected data-placement result, follow PH, ST Mode, table selection, Requester Enable and target/path support. For inconsistent latency reports, follow Support/Enable, reported fields, aggregation and update history. For a missing activity indication, follow signaling selection, egress Variation, Link state and receiver configuration. Then examine platform policy and measured effects.

“LTR enabled, so the Link should enter L1” conflates central-resource requirements with ASPM's own support, controls and entry conditions. “ST=53h, therefore data is in CPU 53's cache” requires a platform tag mapping and evidence of the processing result. A decoded hint tells you what information was supplied, not that every intended optimization occurred.

Edition and source boundaries

PCI Express Base Specification Revision 6.0 (6.0-1.0-PUB) is the technical source. Printed and PDF-viewer page numbers match. All topology, register and timing examples are author-created; no hardware writes or performance measurements were performed. No external website supplies technical claims in this chapter.