feature article
Subscribe Now

Network Timing in Your Car

Of Oscillators and IEEE 1588

It’s a quaint tradition, born out of decades of action thrillers summoning teams of protagonists to execute some very precise (and unlikely) plan. As the caper commences, before they disperse, they execute the final ritual: synchronizing watches.

Seems silly these days; quartz and electronics have long ago given us watches that keep excellent time, with no need for constant resetting. What with cell phones doubling as watches, our timing is even better coordinated.

But that last step isn’t simply one of better electronics: for most of us, it represents the availability of a master clock. Anybody here remember dialing POP-CORN? Why back in my day, that was the master clock. Today, we can get the time from our cell phone network. All the adventure is gone…

As it turns out, however, we still have situations where different nodes in a network will operate mostly independently of each other, but will need to share a sense of what time it is. They may not lead a dramatic Mission Impossible life, and they darn sure won’t attract an audience to watch them operate, but a lot of what we take for granted depends on this ability to synchronize systems.

The high-level issue here is one of automata (for lack of a better hundred-dollar word) that work independently of each other, and yet need to coordinate time without the benefit of a precise central master clock. Or so it would seem until you ask a few questions and learn that it’s not quite as simple as all that. So let’s back up and set some context.

This all came up in a conversation with SiTime about new oscillator offerings addressing the rather demanding needs of automotive applications. The discussion touched on a network timing standard, IEEE 1588, and its potential appearance in automotive applications.

This standard, to oversimplify things, is what gets different points on a network to agree on what time it is. So, obviously, as a timing issue, it seems relevant to a discussion about oscillators and such. Except for this: the adjustments made on any node to synch up with the rest of the nodes are going to be large jumps as compared to the minute phase perturbations of an oscillator. So why in the heck would tight oscillator specs have anything to do with supporting 1588?

I posed the question to SiTime, and the response from their Jeff Gao took me far afield from cars. In fact, cellular folks will find this to be familiar territory, even if it is newer to automotive. The big-picture context would be this: each node’s local clock, on its own, will have a tendency to drift. In fact, more than a tendency: it will drift, guaranteed, when compared to any other independent clock, no matter how accurate. It’s just a question of how fast it will drift.

When drift takes the local clock too far afield, then IEEE 1588 lets you make a quick adjustment to get back into spec. So you can think of each node as noodling along, but, every now and then, needing to “slip a notch,” giving up or gaining an extra cycle to stay in synch.

For this to work, you need a reference of some sort so that you know if you’ve drifted. Ideally, every node should work on that same reference. In practice, it’s not quite so simple. Using the mobile network as an example, a given cell would look to GPS for very high accuracy – but poor reliability. So a second source could be a Synchronous Ethernet (SyncE) signal, which provides a backup reference that’s more reliable but less accurate.

Locally, you have an oscillator that provides good phase stability. And phase stability holds a prominent position in this whole timing scheme. So you can use that oscillator both as the local clock and to recover the GPS or SyncE clock. 

But there’s a second part to this: what if you lose the reference signals for some reason? Are you dead in the water? If you’ve played with PLLs before, you know that you treat them like a flywheel; an occasional nudge will keep the thing spinning merrily along. If you stop nudging, it will keep spinning – for a while, until it “loses lock.”

So here we have a higher-level flywheel – and the question is, if you lose the reference, how long can you keep going before you drift out of spec? Turns out this has a name: holdover. And there are specs that establish what grade of oscillator is required for a given level of holdover. We’re not talking milliseconds here; we’re talking human time – a half hour, an hour, even as long as a month.

Using quartz, the only way to get to the level of stability required for cellular timing is to take control of the temperature using oven-controlled oscillators. These guys are fussy and expensive and require a 24-hour temperature soak before they’re good to go. This is an area where SiTime says their 100 ppb MEMS oscillators can compete with the oven-controlled quartz units on select critical parameters, if not across the board.

So what happens if we end up with 1588 running the timing on our in-car network? This is a newer application – especially car-to-car – so it’s an active area of work. Are we going to need precision at the level of the cellular network? I sure hope not, because I don’t want to have to do a 24-hour soak before I can drive. And we don’t need ECUs to keep running independently for a month. Looking at the stability specs for the oscillators that SiTime has offered up for automotive shows stability in the 10s of ppm rather than ppb levels, so that’s encouraging.

As it turns out, I received a last-minute (or later-than-last-minute) clarification that, our discussion notwithstanding, the announced automotive devices can’t, in fact, manage 1588 – because they don’t have that elevated level of precision. Automotive versions of the Elite family would be needed, which haven’t been announced. So… yeah, that was unexpected. The just-announced devices are intended only for the more mundane tasks of ADAS, ECUs, and infotainment.

High precision or not, what distinguishes an automotive oscillator, of course, is the need to withstand the rigors of the road. Depending on where a unit is located, temperatures could be high, and they may change quickly. Same goes for vibrations and shock.

And the package? If it has leads, your mechanic can see and probe the connections. With a leadless package, you need an X-ray unit to check the connections. You can guess which one your mechanic is going to prefer.

So yes, the same standard that helps keep the cell system humming along may well keep the engine humming as well [edit: sometime in the future]. Minus the dropped calls, presumably.

 

More info:

SiTime Automotive Oscillators

 

Leave a Reply

featured blogs
Sep 21, 2023
Wireless communication in workplace wearables protects and boosts the occupational safety and productivity of industrial workers and front-line teams....
Sep 21, 2023
Labforge is a Waterloo, Ontario-based company that designs, builds, and manufactures smart cameras used in industrial automation and defense applications. By bringing artificial intelligence (AI) into their vision systems with Cadence , they can automate tasks that are diffic...
Sep 21, 2023
At Qualcomm AI Research, we are working on applications of generative modelling to embodied AI and robotics, in order to enable more capabilities in robotics....
Sep 21, 2023
Not knowing all the stuff I don't know didn't come easy. I've had to read a lot of books to get where I am....
Sep 21, 2023
See how we're accelerating the multi-die system chip design flow with partner Samsung Foundry, making it easier to meet PPA and time-to-market goals.The post Samsung Foundry and Synopsys Accelerate Multi-Die System Design appeared first on Chip Design....

Featured Video

Chiplet Architecture Accelerates Delivery of Industry-Leading Intel® FPGA Features and Capabilities

Sponsored by Intel

With each generation, packing millions of transistors onto shrinking dies gets more challenging. But we are continuing to change the game with advanced, targeted FPGAs for your needs. In this video, you’ll discover how Intel®’s chiplet-based approach to FPGAs delivers the latest capabilities faster than ever. Find out how we deliver on the promise of Moore’s law and push the boundaries with future innovations such as pathfinding options for chip-to-chip optical communication, exploring new ways to deliver better AI, and adopting UCIe standards in our next-generation FPGAs.

To learn more about chiplet architecture in Intel FPGA devices visit https://intel.ly/45B65Ij

featured paper

Intel's Chiplet Leadership Delivers Industry-Leading Capabilities at an Accelerated Pace

Sponsored by Intel

We're proud of our long history of rapid innovation in #FPGA development. With the help of Intel's Embedded Multi-Die Interconnect Bridge (EMIB), we’ve been able to advance our FPGAs at breakneck speed. In this blog, Intel’s Deepali Trehan charts the incredible history of our chiplet technology advancement from 2011 to today, and the many advantages of Intel's programmable logic devices, including the flexibility to combine a variety of IP from different process nodes and foundries, quicker time-to-market for new technologies and the ability to build higher-capacity semiconductors

To learn more about chiplet architecture in Intel FPGA devices visit: https://intel.ly/47JKL5h

featured chalk talk

Nexperia Energy Harvesting Solutions
Sponsored by Mouser Electronics and Nexperia
Energy harvesting is a great way to ensure a sustainable future of electronics by eliminating batteries and e-waste. In this episode of Chalk Talk, Amelia Dalton and Rodrigo Mesquita from Nexperia explore the process of designing in energy harvesting and why Nexperia’s inductor-less PMICs are an energy harvesting game changer for wearable technology, sensor-based applications, and more!
May 9, 2023
18,022 views