More NoC Wisdom

A common experience for anyone promoting a disruptive technology is that prospective customers understand that what is being offered is different. Still, without a familiar reference to compare, they extrapolate expectations unreliably. Sometimes expectations are extrapolated to infinity: “My existing solution has limitations, but the new technology should have no limitations.” Sometimes expectations are extrapolated to what they know as bleeding edge: “All the latest academic publications are on X, so this must be like X.” This is human nature, which is not always a good guide. Thinking of a switch to network-on-chip (NoC)? Here is wisdom for review.

Unbounded performance

It would be nice if there were no limits to bandwidth or latencies in any way for an on-chip interconnect. Put that way, the expectation is obviously unreasonable. But change the way the requirement is defined and relax the definition of “unbounded,” and then the disconnect becomes less obvious, especially to teams new to big designs.

Here is a real example from a team well-versed in small designs with a couple of initiators and targets (2×2) on the interconnect. Such a design presented no challenges to achieving bandwidth requirements. With a larger design built around cascading crossbars, they realized intuitively that traffic congestion is likely to become a real problem. They asked us if we could fix this problem with NoCs for 64 initiators and 32 targets with no other constraints on their product. An architecture discussion followed. If traffic at the endpoints is unconstrained, you can add contention FIFOs to improve general throughput (see the table above); however, this comes at the cost of an increase in area. But then further analysis indicated that the system software would not exercise all the endpoints at the same time. Understanding this requirement allowed the NoC to be designed without the area hit.

This is a problem in product design teams with a classical hardware/software split and who may be new to big systems-on-chip (SoCs). The hardware team wants to design to a generic “best performance” target, but that is not meaningful without understanding the system use models. Some paths must support higher traffic throughput, but not all, and certainly not simultaneously.

The research institute viewpoint

This is a different type of challenge. These are not universities. Rather, they are the kind of labs that sit between universities and industry, charged with helping move pure research closer to commercial applications. A government may fund these research institutes, or they may be small companies receiving government grants at a local or national level. They are often staffed by PhDs well connected to academia, who have been in the same company for 20-30 years. Their views of what is hot tend to be colored strongly by the people they talk to most often and the papers they read.

In the world of NoCs, meshes are prominent because meshes are state of the art in advanced servers and AI training architectures. They are not so common in the much larger commercial world of heterogeneous SoCs because those designs are not served well by a mesh structure. Also, such designs do not generate many NoC papers because these more general commercial applications are not necessarily research-rich targets. (“I made a bigger mesh” is a common Ph.D. thesis topic!)

It is often unavoidable to start with a discussion on mesh networks simply because that is the known “high-end” configuration. In these discussions, we acknowledge that, for specialized applications, a mesh is a good fit. The Arteris IP Ncore product provides a competitive solution in the area of the SoC where that structure is needed. But how well would the rest of the SoC fit into a mesh? Perhaps the integrator could leave holes to fit large or irregular pieces of the design, with some non-mesh offshoots to connect intellectual property (IP) inside those holes? As a discussion like this progresses, it often becomes obvious that a mesh is an unnecessary over-constraint for most of the design that may actually create a serious problem for performance/power/area (PPA) objectives.

Finding a checkmark for safety

For design teams just starting in automotive-class designs, safety looks like a messy, complex requirement. What some less safety-experienced teams are hoping for is a stamp of approval. They want to see a certificate of safety, so they do not have to worry about that IP when they are working on proving safety for their design. But that is not how safety works. A design team should be very suspicious of any IP vendor who claims they can offer that assurance.

That starts another conversation. What can an IP vendor prove about the safety of their IP, and what will the integrator need to prove? What documentation and support can the IP vendor offer to the integrator, and what experience do they have in supporting other customers who needed the same help? Once customers understand that safety is as much about partnership and support as it is about the product, they quickly start to realize the risks in looking for a simple stamp of approval.

Time to ditch the myths

Switching from familiar on-chip interconnect solutions to state-of-the-art NoCs comes with understandable anxiety and misconceptions, generally resolved with in-depth discussions. Arteris IP has extensive experience partnering with SoC design teams, not only around our IP but also about the overall SoC/software architecture to provide optimized and economically successful solutions that ship on time. Learn more about our NoC IP products here.