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
May 7, 2021
In one of our Knowledge Booster Blogs a few months ago we introduced you to some tips and tricks for the optimal use of Virtuoso ADE Product Suite with our analog IC design videos . W e hope you... [[ Click on the title to access the full blog on the Cadence Community site. ...
May 7, 2021
Enough of the letter “P” already. Message recieved. In any case, modeling and simulating next-gen 224 Gbps signal channels poses many challenges. Design engineers must optimize the entire signal path, not just a specific component. The signal path includes transce...
May 6, 2021
Learn how correct-by-construction coding enables a more productive chip design process, as new code review tools address bugs early in the design process. The post Find Bugs Earlier Via On-the-Fly Code Checking for Productive Chip Design and Verification appeared first on Fr...
May 4, 2021
What a difference a year can make! Oh, we're not referring to that virus that… The post Realize Live + U2U: Side by Side appeared first on Design with Calibre....

featured video

The Verification World We Know is About to be Revolutionized

Sponsored by Cadence Design Systems

Designs and software are growing in complexity. With verification, you need the right tool at the right time. Cadence® Palladium® Z2 emulation and Protium™ X2 prototyping dynamic duo address challenges of advanced applications from mobile to consumer and hyperscale computing. With a seamlessly integrated flow, unified debug, common interfaces, and testbench content across the systems, the dynamic duo offers rapid design migration and testing from emulation to prototyping. See them in action.

Click here for more information

featured paper

From Chips to Ships, Solve Them All With HFSS

Sponsored by Ansys

There are virtually no limits to the design challenges that can be solved with Ansys HFSS and the new HFSS Mesh Fusion technology! Check out this blog to know what the latest innovation in HFSS 2021 can do for you.

Click here to read the blog post

featured chalk talk

Medical Device Security

Sponsored by Siemens Digital Industries Software

In the new era of connected medical devices, securing embedded systems has become more important than ever. But, there is a lot medical device designers can borrow from current best-practices for embedded security in general. In this episode of Chalk Talk, Amelia Dalton chats with Robert Bates from Mentor about strategies and challenges for securing modern medical devices and systems.

Click here to download a whitepaper called "Medical Device Security: Achieving Regulatory Approval"