May 8, 2006 -- Networking has been proven in the computer systems arena to be an extremely effective means of managing communications among any collection of distributed systems that need some level of inter-communications. As more different types of functions, in the form of intellectual property (IP) blocks, are integrated into a single system on chip (SOC), a similar need for managing communications among the potentially very different needs of these functions becomes critical.

Approaches used to date have relied on some form of shared resource, typically derived from the shared bus architectures that are common to all processors, regardless of their specific processing characteristics. Due to limitations on the number of resources that can effectively share such a "bus," the difficulties of implementing these shared resources in deep sub-micron process technologies, the disparate nature of communications traffic imposed by the integration of different functions, and other issues, a new approach to managing the communications on chip must be found.

Fortunately, new approaches have emerged, among them Network on Chip (NoC) to allow efficient and high-performance on-chip communications for complex SOC design. The NoC advances traditional bus-based techniques to manage the increasingly on-chip communications requirements of SOCs containing tens or even hundreds of IP blocks.

NoC addresses some of the most significant obstacles to lower SOC design and unit costs:

NoC uses a relatively small number of global wires that can cause clock skew and signal integrity problems in complex SoCs NoC can solving the timing convergence problem by supporting the Globally Asynchronous, Locally Synchronous (GALS) design style which supports "islands of synchronicity" linked by asynchronous global connections. GALS help partition the timing problem without the methodology and design risk problems of a fully asynchronous approach NoC isolates the communication requirements of the IP from the packet transport requirements offering a scalable methodology for SOC design. NoC can support multiple IP communications formats such as OCP, AHB, AXI or even proprietary formats to facilitate IP reuse. NoC improves SOC performance and bandwidth with low average latency to improve SOC performance NoC can use fewer gates, in many cases, compared to a bus lowering SOC unit costs

As opposed to blindly adopting the networking implementations used at the macro system level, providers of NoC solutions have borrowed the most applicable concepts and applied them in a manner consistent with the constraints of semiconductor design. The following key networking concepts are part of an NOC approach applied to the needs of SOC design:

Separation of the communication protocol and its hardware implementation into well-defined layers to facilitate independent optimization of each layer Packetization of transactions entering the NoC Use of standardized packets for all information flow (data, control) . Switch and link style fabric(s) with intelligent packet routing Flexible NoC topologies to match the performance needs of the total system

Arteris SA has developed a methodology and toolset to support the development of an NoC. To create an Arteris NoC instance, Arteris NoCexplorer is used to capture the dataflow requirements of the IP blocks to be serviced by the NoC. Various topology options can then be readily explored to determine those that best meet the system objectives. Analysis of the alternative topologies is throughput-accurate, but not cycle-accurate as a means of accelerating the exploration process. The objective of this step is to quickly explore a set of NoC topology configurations that match the required overall SOC connectivity and worst-case traffic patterns, by quickly identifying and removing the potential bottlenecks created by shared resources such as network links, or tuning the arbitration scheme of the system to match specific system requirements.

In the case of systems built from IP blocks that have configurable communications behavior (for example, burst lengths, communication FIFO sizes, etc.) the exploration phase will also help to understand the optimal settings of these parameters. Conversely, this exploration phase can also reduce the over-design that architects put into traditional systems. For example, many systems perform more data reads than writes into memory, testing diverse topologies for request and response networks and finding the leanest topology adapted to each side can end up in significant area savings of the whole design.

Once a topology has been established, NoCcompiler is used to create the NoC instance. First the packet format options are chosen based on global system requirements (such as number of masters and slaves), IP block communications characteristics (burst types, endianness management, special transactions or information to transport between IP blocks) and the results of the NoCexplorer investigations (for example maximum packet payload length to be supported). The designer then configures the various units of the NoC in the chosen topology, choosing, for example, network port configurations and number of ports for the switches, clock ratios between IP blocks and their associated network links, etc. Each unit in the NoC will inherit the chosen packet format and configure itself accordingly. The Network Interface Units, for example, will configure themselves according to the maximum packet payload length in order to perform burst conversion, all units and links will configure themselves according to the presence of the optional byte enable packet fields, minimizing the required hardware if the feature is not needed at the system level.

A cycle-accurate simulation model can then be generated to verify the NoC in the context of the balance of the system, either in SystemC or with RTL simulation. Based on the results, as well as the results of pre-synthesis area estimates, additional tuning of the NoC unit configurations may be done to arrive at an optimum system. HDL synthesizable RTL and synthesis scripts are then generated for integration into the chosen SOC design. RTL to GDSII flows are then used to turn the resulting NoC Instance into silicon.

NoC unit parameters cover a wide range of settings: structural parameters (such as number of inputs and outputs for a switch), functional behavior (arbitration schemes, route tables, pipelining) or implementation details (configuration register settings, runtime reprogrammability). To ease parametrization, all user-defined parameter values are entered in NoCcompiler through a set of consistent menus that check assigned values and provide default settings when possible.

Arteris has introduced the first commercial implementation of a NoC delivered as a flexible subsystem allowing the SOC architect and/or designer to optimize for the communication requirements of a specific system on chip.

What does all of this technology add up to? Lower SOC unit costs, lower SOC design project costs and faster time to market.

By K. Charles Janac. Janac is president and CEO of Arteris, SA. He has more than 20 years experience in the EDA indsustry.