Practical Chip Design

As SoCs become more complex, the concept of using a network to replace the bus or crossbar switch as the interconnect backbone on the chip has become more popular. From thesis material a few years ago, the NoC is now actually shipping, carefully buried in some consumer products.

The underlying concept of a NoC, such as those from Arteris, Silistix, or Sonics, is simple enough. It begins with the idea that all traffic between the major functional blocks in an SoC should be packetized. Packetization, in turn, allows great freedom to optimize the physical interconnect between the blocks. Ordinarily, for example, a backbone bus or central crossbar switch must be as wide as the width of the widest port on any of the IP blocks it serves. But if the traffic is packetized, the sender can chop the packet up into little pieces or spread it out into ultrawide words, fitting the format to whatever interconnect is, there with full confidence that there is enough information in every packet to allow the receiver to reconstruct the original message.
With this confidence, the interconnect designer can select each physical connection—the width, header location, speed, and choice of synchronous or asynchronous transmission, for example—based on the specific latency and bandwidth requirements of that particular link. This freedom can save as much as half the metal and gate-count in an interconnect implementation, according to Arteris president and CEO Charlie Janac. Further, packetization allows the network to deal with varying quality-of-service (QoS) requirements of different messages on the same general path.

That's the good news, and the reason companies such as Arteris are increasingly showing up in complex SoC designs where schedules are tight, interconnect timing is critical, and dataflow patterns are intricate. But in lean times the tip of the market is not the wisest place to dwell if you are trying to grow. So all of the NoC vendors are trying to make their technology more widely attractive. The trend kicked off earlier this year with Sonics's announcement of a simplified design kit for AMBA AHB users, and continued mid-year with Silistix's release of a toolkit for fully-synchronous interconnect designs. Now Arteris has joined the hunt.

There are two aspects to scaling such a product to less ambitious designs. One is to produce a subset of the architecture that is both sufficient for a meaningful set of designs and still powerful enough to be useful. The other is to create a user interface for generating the network that has the correct scale and uses the right metaphors for the problems the designers of smaller chips are actually trying to solve.

Arteris has addressed these issues with the introduction of three interlocking products. The first is FlexArtist: a design console for creating smaller-scale NoCs within conventional SoC design flows.

We should probably pause here to quantify that word "smaller." Janac suggests that a complex design these days will have a dozen or more major IP blocks. A moderate design will have perhaps eight to 15 blocks, while a small design will comprise less than eight blocks. "But it's not just a question of counting blocks," Janac said. ""there are other dimensions to complexity that you have to examine as well. For example, does the interconnect span multiple clock regions, or voltage domains? Do you want a modest bandwidth, or are you trying to move mountains of data all the way across a die at 700 MHz? Is your arbitration simple, or do you have to deliver different QoS to different data flows? All these are dimensions of complexity too."

That said, FlexArtist is an environment for creating interconnect on moderate or simple designs. In the tool, you create a description of the interconnect topology, and then you define your communications objectives on that topology with a script. When you are ready, a synthesis engine reads your requirements and pulls in an Arteris library, and then generates an instance of a network at RTL. In addition, FlexArtist creates a functional-level view of the network for its own internal verification tool, wherein you can examine the behavior of the network using, for instance, standard Synopsys verification IP.

"Our network verification engine is pretty unique," Janac said. "There are a few others out there that can handle one or two switches. But ours is designed to handle very large numbers of switches efficiently." This capability is apparently necessary because of the way Arteris's architecture uses switches.

Along with FlexArtist, Aretris is announcing two synthesis libraries: FlexNoC and FlexWay. FlexNoC provides the components necessary to construct a network for a moderate design. It is limited to a single domain and a synchronous network—while the full Arteris suite usually generates globally-asynchronous, locally-synchronous structures--but provides considerable flexibility in link latency, width, and timing. FlexNoC is also suitable for creating interconnect within subsystem-level blocks, such as the super-IP blocks now being discussed for such functions as video processing and GPS location services.

FlexWay is a simpler library still, intended to replace a traditional shared bus in a CPU-centric small SoC, or even to create a drop-in replacement for a low-speed peripheral bus such as AMBA APB. The primary idea here is that by moving from a multiplexer-based bus structure to a synthesized network you can get significant layout and power savings—even after the packetizing overhead—and be confident that you are making your performance and timing targets.