feature article
Subscribe Now

More Efficient Time-Sensitive Ethernet

Excelfore Provides a Traffic Shaper

Ah, Ethernet… our good, reliable, trusty friend from way back. So trusty, in fact, that our cars may soon be running a version of Ethernet for all of the electrification stuff. Leveraging something tried and true should certainly go without a hitch, right?

Well, certainly as compared to coming up with something entirely new, perhaps. But what’s this Ethernet going to do in our cars?

Well, for one, it will help with the infotainment stuff. Lots of data coming in through a wireless portal, to be beamed back to screens stared at raptly by restless children in an attempt to quell the hail of spitballs that otherwise might provide the divertimento during a long road trip. Important stuff, no doubt, but not mission-critical. After all, you didn’t see the Walton kids getting all butt-hurt when they couldn’t watch the depression-era version of Spongebob, so life is possible without a screen.

But then there’s the other part: beaming time-sensitive control messages around between the various functional parts of the car. Yeah, the Waltons survived just fine without those messages too, but this isn’t simply an ADD issue: it’s how cars are evolving. This isn’t your ancestors’ Buick. So, if that’s the case, that messaging has got to be right. Messages need to get to the intended target in time to be useful. “Turn left, we’re veering off a cliff to the right!!!” doesn’t help if it arrives at the steering assembly right about the time when the hood latch is greeting the rocks below.

And that gets to an issue with legacy Ethernet, love it though we do: it’s a “best-effort” kind of system. It can’t guarantee that your message will arrive when you need it to. Amazon Prime does you no good here, sorry.

So… how do we send messages with deadlines on a network that doesn’t know deadlines from deadheads? This has been an ongoing effort, creating what’s referred to as a time-sensitive network, or TSN. Not sure if this is a good name, since what you really have is a hybrid network with some time-sensitive messages (“Turn left!!!”) and with time-insensitive messages (“This is gonna be the BEST DAY EVER!”*).

So how do you blend those together? The approach taken is to reserve certain time slots for messages that absolutely, positively have to get there on time. Identification of those messages is by priority. So, during that time slot, messages of that priority will be sent. After the slot, other messages are sent according to their various priorities.

But the thing is, after those other messages start, then another time slot will approach. What if you start sending a low-priority packet in the unreserved time right before the designated slot, and it’s too long to finish sending by the time the priority slot arrives? It would be as if you reserved a time at the grocery-store checkout stand so that you could get in and get out quickly – except that the guy before you, who didn’t start during your time, ended up having 35 coupons, each of which needed to be verified and signed, and your time came and went with you standing there looking silly and knowing you’re going to be late back to work.

In order to avoid that, a guardband was added ahead of the reserved slot in order to block out some time where no new low-priority packet could be started. So you have a reserved slot, then open season for anything, then a time that might go empty, and then the next reserved slot.

If that guardband is long enough, you can pretty much guarantee that no packet that starts before the guardband will end after the guardband. That’s great – except for one thing: it’s a waste of bandwidth.

Now, for systems using a store-and-forward approach, where an entire message is received and stored before being sent on to the next destination, you can measure the length of the message to decide whether or not there’s time to send it before the critical time slot arrives. Got time to send 500 bits before the reserved slot? Then, if the stored message has less than 500 bits, go ahead and send it. If not, then wait. (Or find another message that does, but don’t take too long looking…) In this case, you no longer need the guardband, since you’re being deterministic about which packets will and won’t depart prior to the time slot.

But if your system is cut-through – that is to say, you receive a few bytes of a message and immediately start forwarding them on before you see the end of the packet – then you don’t know how long that packet is going to be. So you can’t tell whether or not to start sending it, and you no longer know whether or not it will encroach on the reserved slot. So you’ve still got a problem that might require a bandwidth-wasting guardband.

In order to address this, one final new critical feature has been added: the ability to interrupt a packet that’s in the middle of being sent in order to send some higher-priority packet at its duly appointed hour. The pre-empted packet continues being sent when the urgent stuff is complete. So now you can use the entire available bandwidth without having to throw some away “just in case.”

But some software has to perform this operation. It’s a matter of “shaping” the traffic as it’s being sent. Which is a product that Excelfore recently announced. It will be needed by sources of traffic as well as routers and switches to ensure that packets don’t bunch up at some bottleneck in the network.

Now… just because some company happens to be the first to send a press release about some new product doesn’t mean that they were the first to offer the product. So I asked Excelfore whether their traffic time-aware shaper (TAS) was new not only to them, but also to the industry.

According to Mark Singer, Director of Marketing at Excelfore, “Excelfore is aware that some TAS experiments have been shown, however we believe ours is the first commercially available.” So there you have it.


*For those of you without kids in a certain era, this is a Spongebob thing.


More info:


4 thoughts on “More Efficient Time-Sensitive Ethernet”

  1. In an automotive land where real-time events are tens of milliseconds, and $2 ethernet interfaces are 1 gigabit per second (possibly 10gbps) , it really seems somebody here is trying to sell a long unpopular bridge to nowhere.

    1. And I’m really including that state of the art vision system (several channels of stereo vision, plus LIDAR and RADAR) back to the AI front end. When interfaces are dead cheap, you DO NOT design bandwidth critical, congestion managed links into the system. Both copper and fiber ethernet links are point-to-point, and congestion free by design. Don’t get stupid and design congestion points into an already clean design.

  2. A big part of what fueled my first response was WTF, why are people thinking about designing unnecessary complexity into a mission critical high reliability application? IF these folks are thinking about replacing CAN Bus with Ethernet and using it as a primary navigation sensor bus, these folks are making a huge critical mistake. Ethernet switches, routers, bandwidth managers just become single points of failure that will take out the entire system, along with critical single point of failure cables, connectors, and the like for this botched system design.

    Using a star design, with dedicated cables and ports for each sensor, gets rid of single points of failure critical to mission success. You can easily add interface redundancy at the system controller connectors, if you are building a redundant 3 way system controller, … or not, if that’s not important to the designer.

    Given lives are at stake here, I’m not sure why anybody would purposefully design a system with single points of failure, or without a fair degree of redundancy.

Leave a Reply

featured blogs
Apr 24, 2019
In this week's Whiteboard Wednesdays video, Industry expert Rohit Kapur introduces the basic concepts of digital IC scan compression. Topics explained include the impacts of test application time... [[ Click on the title to access the full blog on the Cadence Community ...
Apr 23, 2019
Samtec Bulls Eye® test point systems are ideal for high-performance test applications because of their compression interfaces, small footprint, and high cycle count capabilities. Bulls Eye is now available in 50 GHz and 20 GHz designs, with a system up to 70 GHz in developme...
Apr 23, 2019
Move over, Information Age'€”the Autonomous Age is on its way. In the autonomous age, information is not just copious and accessible, it is integrated into our daily lives to automatically augment human capabilities. In the autonomous age, we expect technology to comprehend...
Jan 25, 2019
Let'€™s face it: We'€™re addicted to SRAM. It'€™s big, it'€™s power-hungry, but it'€™s fast. And no matter how much we complain about it, we still use it. Because we don'€™t have anything better in the mainstream yet. We'€™ve looked at attempts to improve conven...