Embracing Change: The Impact of Technology Advancements

As I went around turning dials, pressing buttons, and occasionally grumbling aloud at the different sequences of buttons required to change various electronic devices’ clocks, I thought how nice it would be to have clocks which kept themselves in sync.  Now, I do have a number of clocks and watches which synchronize themselves to the atomic clock in Ft. Collins, but the majority of my timepieces do not.  (As an aside, my children will happily tell you that “Dad has too many watches!” – hey, I’m a techno-geek, and there are so many cool technologies in watches!  Which, as a second aside, reminds me to send a note to Pebble asking them why the heck their “Smartwatch” wasn’t smart enough to switch to DST when the phone it’s paired with did…)

ll these ruminations on time got me to thinking this might be the perfect day on which to discuss one of the lesser-known PCI Express functions – Precision Time Measurement (PTM) – which came out as an ECN to PCIe 3.0 early in 2013.  Unfortunately, you can’t (yet?) go out and buy a new oven (or mayor as far as I know) with PCI Express PTM in it and never have to touch the time setting again, but PTM provides some new functionality to PCI Express which helps in other ways. 

To understand why PTM is useful, we have to first think about where time is important in a system.  As a note, when PTM refers to the “clock” it means the “wall clock” or “system time” (as in X seconds have elapsed since January 1st, 1970, or some similar measurement) as opposed to the reference clock or any other “clock” which causes digital logic to change state at some regular interval. 

Consider one case where we have several instruments collecting data and sending it to a host for storage. PCI Express doesn’t make any guarantees about the order of arrival for packets from different agents, and depending on the topology, those packets could have very different delays from sender to the ultimate receiver.  This means that each packet needs a timestamp so the host can reassemble the data in order – and prior to PTM, it would be entirely device-specific how those timestamps were created.

Consider another case where there are two different video cameras capturing the same scene from different angles – and we’d like the frames to all arrive at the host at about the same time so they can be processed together (Think automotive collision avoidance systems, robotic vision, etc…). Here we not just want to be aware of the absolute timestamp, but the path delay for each component – so that we can adjust the buffering on our cameras to align not when the packets are transmitted, but when they will be received!

In order to achieve these things, PTM provides a new Extended Capability in PCI Configuration space which tells software that the device supports PTM, offers various enables for PTM operation, and includes information about the device’s internal clock (if any) frequency and granularity.  Three new PCIe Messages are part of PTM:

• PTM Request
• PTM Response
• PTM ResponseD

The PTM Request and PTM Response are Msg (no payload) types, and signal PTM devices to make note of their internal timestamps at the time of transmission/reception.  PTM devices then can calculate the time delay between components based on these timestamps.  The PTM ResponseD is a MsgD (message with data payload) that includes a 64-bit time value and a 32-bit time propagation delay. 

Full details of the PTM protocol can be found in the Precision Time Measurement (PTM) ECN on the PCI-SIG website.  In summary, PTM:

• Allows coordination of “wall time” between different PCIe devices
• Allows calculation of precise propagation delays between PCIe components
• Does NOT keep Richard from having to change his clocks between DST and non-DST times