PCIe Chapter 25: PTM Roles, Exchanges, and Precision

Define the clocks and participants

The Root Port → Switch → Endpoint topology has two Links. The Switch requests time upstream and supplies it downstream; Endpoint PTM Messages do not traverse the Switch to reach the Root Port. Figure 6-23 explains this division. Port background is in Chapter 1.

Simulated data: the topology, values and timing were created for teaching and do not represent hardware measurements. The Root Port is the PTM Root. The Switch and single-Function Endpoint support ePTM (Enhanced Precision Time Management). Basic transport is ready; the Switch has valid master time. The two-dialog example uses Non-Flit Mode, with no Replay, duplicate, Reset or context-invalidation event.

All values are normalized to ns. For this short calculation assume equal, stable clock rates, no drift and symmetric one-way transit delays. These are example assumptions, not measured properties of arbitrary Links.

Follow capability discovery into the actual roles

Walk the Extended Capability list to ID=001Fh, Version=1. Figure 7-310, PTM Capability Structure, locates Capability at P+04h and Control at P+08h relative to base P. Figure 7-312/Table 7-275 then decode the roles:

The Root Port supplies and responds with time. The Switch supports both Requester and Responder roles. Its Root capability does not select it as Root: this example keeps its Root Select clear and uses the upstream source. The Endpoint's Local Clock Granularity is RsvdP because Root Capable is clear; a zero read there does not mean that the Endpoint has no local clock.

One Capability controls the entire Switch. Switch Downstream Ports must not implement independent PTM Capabilities. With a multi-Function Upstream Port, the controlling Function need not be the Switch Upstream Port Function. Locate the real controlling structure before attributing its behavior to downstream Ports.

Base 6.0 §7.9.15 Precision Time Management Extended Capability (PTM Capability), pp.1260–1264; Figures 7-310–7-312, Tables 7-274/7-275.

Select the source and enable the hierarchy

Figure 7-313/Table 7-276 separates PTM Enable [0], Root Select [1] and Effective Granularity [15:8]. Root Port Control=00000003h enables it as Root. The Switch has PTM Enable=1 and Root Select=0: it obtains upstream time and responds downstream.

Enable the associated Downstream Port's PTM control before the Upstream Port's control on each Link. Here configure the Root Port, then enable the Switch, then the Endpoint. The Switch's single Enable also controls downstream responder behavior; do not search each downstream Port for a separate Control structure.

Endpoint software must program Effective Granularity from the maximum Local Clock Granularity reported by the PTM Root and intervening Time Sources: max(4 ns, 8 ns)=8 ns. Endpoint Control=00000801h therefore means Enable=1, Root Select=0 and Effective Granularity=08h. The field conveys expected accuracy information; it does not adjust the clock or bound every source of error.

Special encodings matter. Local Clock Granularity=00h means a Time Source has no local clock and propagates upstream timing; FFh means greater than 254 ns. If an intervening Switch reports 00h, Effective Granularity=00h means unknown. Do not treat that unknown as an ordinary zero and discard it when taking a maximum.

Base 6.0 §6.21.3, p.800; §§7.9.15.2–7.9.15.3, Tables 7-275/7-276, pp.1262–1264.

Why does the second dialog need the first?

Focus on Link 2: Endpoint Upstream Port as Requester, Switch Downstream Port as Responder. In Figure 6-22, t1/t4 belong to the Requester and t2/t3 to the Responder; primes identify the next dialog.

The first Request finds no valid preceding history, so the Switch returns Response, completing the dialog without timing data. Both sides still retain their local timestamps. After receiving Response, the Requester must wait at least 1 μs before another Request. This case waits 3,000−1,600=1,400 ns.

On the second Request, the Switch has the previous turnaround t3−t2=200 ns and the current receipt time t2′=5,200 ns in the master domain, so it returns ResponseD. Those fields refer to different dialogs. The current turnaround t3′−t2′=320 ns belongs to a later response; it cannot replace the 200 ns carried now.

Base 6.0 §6.21.2, Figure 6-22, pp.797–798; §6.21.3.1, p.801; §6.21.3.2, p.803.

Locate the fields before interpreting Propagation Delay

Table 2-35 identifies Request as Msg/Code52h, Response as Msg/Code53h, and ResponseD as MsgD/Code53h. Code53h alone does not distinguish a timing-data response. All use TC0 and local Routing=100b. Requester ID is the transmitting Port's ID on that segment.

Use Figure 2-61 for Non-Flit Request/Response and Figure 2-62 for Non-Flit ResponseD. ResponseD carries 64-bit PTM Master Time in Header bytes 8–15 and 32-bit Propagation Delay in a 1 DW Data Payload. In Flit Mode, perform transport processing and TLP reassembly before using Figures 2-63/2-64; the base Header format differs.

DW

Double Word, a four-byte unit

TLP

Transaction Layer Packet

Despite its name, Propagation Delay carries the preceding responder turnaround interval, t3−t2, under §6.21.3.2. Data bytes 00 00 00 C8 use this edition's Interpretation A: byte0 is the most significant byte, yielding 000000C8h=200 ns. The Master Time field is 0000000000001450h=5,200 ns. One-way Link transit time still needs calculation from the Requester's stored round trip.

Reversing those payload bytes yields C8000000h=3,355,443,200 ns, larger than this case's 600 ns round trip. Check byte order, field boundaries, dialog association and both Ports' configuration before accepting a negative calculated delay. Optional PTM Propagation Delay Adaptation supports compatibility with older Interpretation B; capable Switches control interpretation independently per Port. This example assumes both ends use A.

Base 6.0 §2.2.8.10, Table 2-35 and Figures 2-61–2-64, pp.190–192; §6.21.3, pp.800–801; §6.21.3.2, p.803.

Convert a local event into the master domain

Subtract the previous responder turnaround from the previous local round trip. Under the symmetry assumption, half the remainder estimates one-way transit time. Equation 6-2 subtracts it from current t2′ to obtain master time at current t1′:

The final row additionally assumes a local event at 4,000 ns, with the same valid context and clock-rate relationship. Local 3,000 ns maps to master 5,000 ns; adding the local 1,000 ns interval gives master 6,000 ns. This is an author deduction under the short, drift-free case assumptions. An implementation must track rate differences and context refresh; the 2,000 ns offset is not permanent.

Using the current 320 ns turnaround with the previous 600 ns round trip would give a false 140 ns one-way estimate and master time 5,060 ns at t1′. The 60 ns error comes from mixing dialogs. Keeping only the latest ResponseD while losing t1/t4 likewise leaves missing inputs, not zero-valued inputs.

Base 6.0 §6.21.2, Equation 6-2, p.797; PTM Theory and Operation Implementation Note and Figure 6-23 Precision Time Measurement Example, p.799. Numeric inputs and event conversion are author-created.

Why can Replay invalidate timing even when delivery is deduplicated?

Reliable transport avoids repeated logical delivery, but PTM measures actual transmission and reception. Section 6.21.3 requires the specified t1 Request-transmit, t2 Request-receive, t3 Response/ResponseD-transmit and t4 Response-receive timestamps to update even for the stated Replay/duplicate cases. A deduplicated Transaction list alone cannot recover those wire times.

This case supports ePTM. Replaying the Endpoint's PTM Request invalidates the Requester context. Under the ePTM rule the context remains invalid until two successive dialogs complete successfully without replays. Replaying Response/ResponseD or receiving a duplicate Request also requires the Responder to invalidate the associated history under §6.21.3.2, so a later Response may be needed to rebuild it.

Figure 6-24, PTM Requester Operation, connects Invalid Context, Request issuance, Response/ResponseD and Valid Context. Response takes the wait-at-least-1 μs path; ResponseD supplies timing data, subject to the text's ePTM invalidation requirements. After issuing a Request, do not issue another until a corresponding response, Reset, or 100 μs without a corresponding PTM Message. This is not Memory Read Completion Timeout.

The Responder must attempt to issue Response or ResponseD within 10 μs. Missing history requires Response. With history available but master time still being retrieved elsewhere, Response is also permitted when retrieval is expected to exceed 10 μs. The rule does not guarantee a data-bearing ResponseD on every Request.

Base 6.0 §§6.21.3–6.21.3.2, Figure 6-24, pp.800–803. Keep ePTM/MUST@FLIT qualifications separate from generic Non-Flit behavior; the example explicitly supports ePTM.

Attach the accuracy and validity conditions to the result

Equation 6-2 estimates one-way transit as half the round trip. Actual one-way delays of 300 ns and 100 ns still total 400 ns and yield an estimate of 200 ns. Subtraction from responder receipt time then overestimates the true transmit time by 100 ns. Effective Granularity=8 ns does not bound that asymmetry error.

Figure 6-25, PTM Timestamp Capture Example, places capture near the Physical Layer. Non-Flit timestamps refer to the first bit of the framing STP Symbol/Token at Port pins. Flit timestamps refer to the Flit_Marker Indicator bit identifying the contained PTM Message; a Flit may contain at most one PTM Message. Internal capture requires consideration of path compensation. The specification does not bound overall capture accuracy and consistency; verify the analyzer's reference point too.

Retimers may introduce asymmetric and variable delays; consult their manufacturer documentation. A non-Root Switch using a local context must invalidate it no more than 10 ms after the last upstream dialog and refresh before further downstream ResponseD transmission. Periodic refresh is optional when implementation-specific means guarantee phase lock with master time. This is not a universal 10 ms Endpoint-context lifetime.

Master time observed through PTM must be monotonic and strictly increasing. Keep the time domain and valid interval with each converted event. Different PTM Hierarchies may have independent master times; PTM time is not automatically UTC or an OS wall clock. Software access to context, internal Switch distribution and triggers for refreshing time have implementation-specific aspects. Enable=1 permits participation; actual dialogs and context validity still need evidence.

Base 6.0 §6.21.1, p.796; §6.21.2 and Implementation Notes, pp.798–799; §6.21.3, p.800; §6.21.3.3, p.804; Figure 6-25, p.805.

Turn an unknown Trace into a reading route

Identify the hierarchy, controlling Function, selected Root and adjacent Ports. Confirm mode and Message type, then pair Requests with Response/ResponseD using Table 2-35. Mark dialogs as in Figure 6-22, verify turnaround byte order and retained local timestamps, and check for context invalidation between dialogs. Apply Equation 6-2 only after those inputs match; retain granularity, capture reference and asymmetry limits alongside the result.

A Control snapshot alone cannot provide a time conversion. One ResponseD still lacks the preceding local round trip. If the clock relationship has changed, the old context is unsuitable for new events. Each step points to concrete missing evidence without assigning a unique faulty component.

Edition and source map

PCI Express Base Specification Revision 6.0 (6.0-1.0-PUB) supplies the technical rules. Printed and PDF-viewer pages match. All topology, registers, timing and arithmetic examples are author-created; no hardware programming or accuracy measurements were performed. No external website is used as technical evidence.