More Tales from the NoC Trenches

Science texts like to present the evolution of knowledge as step-function transitions, from ignorance to wisdom. We used to think the sun revolved around the earth. Then Galileo appeared, and we instantly realized that the earth revolves around the sun. But reality is always messier, as Galileo understood all too well. The transition from darkness to light is often bumpy. The same can be said for adopting new technologies. There may be mechanical challenges along the way, but the biggest barriers are often our own preconceptions. I talked to William Tseng (AE Manager) and Kurt Shuler (VP Marketing) at Arteris IP to share more tales from the trenches on this learning curve in NoC adoption.

Let’s go for the state-of-the-art solution!

You’re ready to make a major change in implementation architecture, so you might as well go the whole way, right? Read the latest papers, find out where all the excitement is and go for that. No compromises. According to William, this is an especially common viewpoint in research institutes. Those big organizations around the world bridge academia and industry, helping translate research ideas into something closer to real applications.

These outfits are stuffed with intellectual heavyweights, all PhDs and all well connected with counterparts in universities across the world. In their domains, they reign supreme. Not the kind of people with whom you want to get into a technical argument. Except that, like all of us, they sometimes can have a blinkered view of larger needs. Take NoCs as an example. The hot architecture is meshes because that’s what’s taking over new server and AI training SoCs. What an endorsement, right?

The bleeding edge isn’t always the right solution

This is a great direction to go if you’re building Gravitons or TPUs. Lots of uniform processors arrayed inside a mesh. But the great majority of us are building more heterogeneous systems. Containing video pipelines, roots of trust, a variety of IO peripherals, sensor fusion, inference engines, wireless connectivity. A kitchen sink of IP and connectivity needs. As an exercise, you could make that all fit inside a mesh. Distort the mesh here and there to fit larger IPs or make off-grid connections. It’s possible, but you start to wonder if it’s worth the effort. You still must meet PPA goals, and your previous design looks nothing like a mesh.

Which is where those research heavyweights start to come around. For most commercial applications, a more flexible NoC architecture is preferable. Something that can flow between IPs, as you’d expect from a NoC. That will support a mesh where an array solution is what you need but is equally at home and efficient in managing your kitchen sink of IPs and connectivity.

Use cases, architecture, and the interconnect

A challenge for any component vendor is that prospective buyers are happy to talk about the component but see no need to discuss their larger objectives. Why should software architects or product application engineers get involved in the discussion? They’ll reveal secrets the vendor shouldn’t know. Or perhaps sometimes that the integrators themselves don’t know.

William said that a common problem in helping small system teams transition to large systems is understanding how they want to manage traffic on the on-chip network. Designing effective traffic management requires some understanding of use cases. If the integrators are new to NoCs, they’ll have to turn to the NoC experts (here, Arteris IP) in a discussion together with the software and application experts. Which paths will be used most heavily? Do they know which paths must have low latency? Which can afford to be a little slower? System architects know how to answer these questions. Based on which the NoC experts can suggest an architecture for the interconnect. Architects may refine their answers over time, but once the integrators understand the NoC design concepts, they can adapt easily enough.

Coming to terms with safety

Teams with a background in small designs and now on a fast ramp are often inexperienced in all the complexities of meeting safety needs for automotive and other domains. This is another area where a component mindset can get in the way. William tells me what these kinds of integrators are looking for is an assurance that the component will be safe no matter how they use it.

Which, of course, no one can give. That’s why ISO 26262 details concepts like development interface agreements, system elements analyzed out of context and assumptions of use. Those define the boundaries around which the component vendor will provide assurances of safety.

Kurt has told me before that getting past this point takes a discussion (maybe a few). About Arteris IP experience in working with many customers in the field. About their long-standing involvement with the standard and commitment to the spirit and not just the letter of the standard. And about the practicalities of ensuring safety through the value chain, from IP to device, to module to car. Requiring not just good components but also experienced support throughout. Ultimately setting a higher bar for safety compliance than a simple checklist.

Different yes, but also better

Galileo had the harder sales job, but ultimately, he was right. People needed to change their perspectives to understand why his model was better. As they sometimes need to with NoCs. With a different perspective comes a better outcome. You can learn more about Arteris IP solutions HERE.

Also Read:

Smoothing the Path to NoC Adoption

The Zen of Auto Safety – a Path to Enlightenment

IP-XACT Resurgence, Design Enterprise Catching Up