Posted by Richard Solomon on March 9, 2014
Unless you are Rob Ford of course, if you live in North America, you probably spent your Sunday morning much like I did – going around to every clock in the house and setting it an hour forward. If not, or if you ARE Rob Ford, then I’m sorry I didn’t post this blog entry on Saturday…
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…)
All 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:
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:
Thanks for reading ExpressYourself, please leave a comment below with your thoughts on places PTM could be useful, or what Toronto should do with their mayor, or really any other non-SPAM topic. As always, if you haven’t already done so, please click here to subscribe to this blog – and don’t forget to set your clocks!
I’ve been involved in the development of PCI chips dating back to the NCR 53C810 and pre-1.0 versions of the PCI spec so have definitely lived the evolution of PCI Express and PCI since the very beginning! Over the years I have worked on variations of PCI, eventually moving on to architecting and leading the development of the PCI Express and PCI-X interface cores used in LSI’s line of storage RAID controller chips. For the last ten plus years I've also had the honor of serving on the PCI-SIG Board of Directors and holding a variety of officer positions. I am still involved in PCI-SIG workgroups and I present at many PCI-SIG events around the world. Back before the dawn of PCI, I received my B.S.E.E. from Rice University, and hold over two dozen U.S. Patents, many of which relate to PCI technology.