NoC Experiences From The Trenches

Network-on-chip (NoC) interconnect as an alternative to traditional crossbars is already well-proven, but there are still plenty of design teams on the cusp of a transition or who maybe do not yet see a need for a change. As with a switch to any new technology, the first hurdles are often simply misconceptions. When new users first evaluate any new technology, they often make the mistake of attempting a 1-to-1 replacement of their old technology without considering all the new things the new capabilities bring to them. Here are some examples I have seen during my years at Arteris IP.

Replacing each crossbar with a NoC

In graduating from crossbars to NoCs, a too-obvious starting point is to replace each crossbar in an existing design with an equivalent NoC, replicating the cascaded network hierarchy, and evaluating the performance, area, and power differences. This approach is certainly not uncommon among design teams. Unfortunately, designing a NoC this way immediately throws away most of its advantages, possibly resulting in worse area and congestion.

Teams need to understand the right way to leverage a NoC. These interconnects are designed to fit into the nooks and crannies of a system-on-chip (SoC). With crossbars, engineers must design the SoC around the crossbar architecture – all that cascaded hierarchy. With a NoC, teams can design the interconnect around the chip architecture. They should think instead about the topology of the floorplan around intellectual properties (IPs) and design the NoC to fit into that topology. There is a bit of iteration to refine the floorplan to the NoC, but nothing like the overhead of the traditional approach. As soon as designers comprehend this concept, they can quickly reduce the area and congestion more than is possible with crossbars.

One customer was building a mid-sized design for an automotive application. There were about 600 different routes for the crossbar approach. Adding those up, it would cost about 10 millimeters of area to route that many wires, a ridiculous overhead. With a NoC implementation, they were able to whittle that down to 5% of the size. Why so impressive a reduction? By explaining the details of how to build out the data, control switches, distribute functions and manage the clock crossings within the network, the scaling becomes obvious.

My design is too small to need a NoC

If a design is very small, perhaps area and congestion are not a concern. Why would a design team want to change the flow? Maybe because they can reduce the power budget for the product. A NoC can be power gated internally, unlike a crossbar. In fact, NoCs can provide very fine-grained control over dynamic and static power, which explains why one smart toothbrush maker chose to use a NoC in their design. There cannot be many designs smaller than that.

This power management is completely configurable through the NoC generator with intelligent controls for clock gating as well as complex power, voltage, and clock domains. For a power-sipping IoT chip, the ability to wake up when needed or power down when dataflow is quiescent results in the system being effectively off 99% of the time and is a real competitive advantage over old technology crossbar on-chip interconnects.

My design is too complex for your NoC

At the other end of the scale are big hardware accelerator designers who build artificial intelligence (AI) training engines in datacenters, for example. These teams sometimes argue that their designs are so advanced and so specialized they have no choice but to build their own on-chip network. The designers feel the need to tune every switch, router and add special connectivity for broadcast and other functions, bypassing the switched network.

Although this is completely understandable, world-leading teams have been using NoC technology to build huge AI designs for many years. All of them have had similar needs. Solutions have been developed to meet objectives as teams have evolved their designs. Designers can now customize the NoCs to exact requirements without disconnecting from the generator infrastructure. There is no need to handcraft the register-transfer level (RTL) directly.

Time to ditch the myths

Arteris IP understands why some design teams might not want to try NoCs, but those reasons are widely disproven. Just check out our customer list, which includes the best-of-the-best in many domains implementing small to large designs. Learn more about our NoC solutions here.