A network-on-chip (NoC) IP is a configurable interconnect block that lets the processors, accelerators, memory controllers and peripherals inside a system-on-chip (SoC) talk to each other by sending packets over a small on-chip network, rather than over shared buses or a single large crossbar. It scales better than buses as the number of IP blocks grows, and it makes timing, power and floorplanning easier to manage. Good NoC design balances performance, power, area, reliability, security and, above all, physical awareness of where blocks sit on the die.
Key takeaways
- A NoC packetises transactions at network interfaces (sockets), routes them through switches and buffers, and converts them back at the destination.
- It connects IP blocks that speak different protocols (AXI, AHB, APB, OCP and others), widths and clock frequencies.
- Pipeline registers on long paths make timing closure possible across a large die.
- The main design trade-offs are power, performance, area, reliability, fault tolerance and security.
- Physical awareness, designing the NoC with the floorplan in mind, is key to integration and overall system efficiency.
What is a NoC IP?
A NoC IP is a type of intellectual property used in SoC designs to provide communication between the different components of the chip. In other words, it is a communication architecture that lets many IP cores within an SoC exchange data over a network. It gives a scalable, high-performance interconnect fabric for moving data between processing elements, memory controllers and the other components of the SoC.
Commercial NoC IP is supplied by interconnect vendors such as Arteris, and by processor IP vendors such as Arm with its coherent mesh interconnects. Many large SoC teams also build their own.
Why not a bus or crossbar?
| Interconnect | Strength | Weakness as the SoC grows |
|---|---|---|
| Shared bus (for example AHB) | Simple, small | One transfer at a time; bandwidth does not scale |
| Crossbar | Many parallel transfers, low latency | Wiring and area grow roughly with initiators x targets; hard to route and close timing |
| Network-on-chip | Scales with distributed switches, narrow serialised links and pipelining | More latency per hop, more design and verification effort |
How a NoC is built
Network interfaces (sockets)
A NoC is formed from several elements. First, each IP block has its own interface characteristics, such as data width and clock frequency, and uses one of the standard protocols adopted by the SoC industry: OCP, APB, AHB, AXI, STBus and DTL. One or more sockets (network interfaces) are attached to each functional IP block. They packetise and serialise data from source IPs into a normalised form suitable for transport over the network. Conversely, sockets attached to destination IPs convert incoming packets back into whatever form the target expects.
Switches, buffers and links
Besides the wires linking everything together, the main transport of the NoC is made of switches and buffers. The switches act like multiplexers with associated arbiters, or demultiplexers with mapping logic, using the destination in each packet's header to route it from source to destination. Buffers are storage elements that hold data along a path. For example, a buffer might be loaded quickly by an IP block on a fast clock, which then turns to other tasks while another IP block on a slower clock drains it. Buffers are also where clock domain and width conversion usually happen.
Pipeline registers
Last, but certainly not least, pipeline registers are inserted into NoC paths to address timing. Long distances across the SoC mean wire delay can exceed one clock cycle, so registers break the path into segments that each fit in a cycle.
Packets, flits and flow control
A packet is split into flits (flow control units), each one link-width wide. Most NoCs use wormhole switching, where the head flit reserves a path and the body follows, with credit-based flow control so a sender only transmits when the receiver has a free buffer slot. Virtual channels let different traffic classes share a link without blocking each other, and they are one of the tools used to avoid deadlock.
Worked examples
The numbers in this section are illustrative.
Link bandwidth
A 128-bit NoC link at 1 GHz carries 128 Gb/s, or 16 GB/s in each direction. An LPDDR5 interface 64 bits wide at 6400 MT/s delivers 51.2 GB/s at peak, so the path into that memory controller needs about four such links, or a wider or faster link, to avoid becoming the bottleneck.
Hop latency in a mesh
In a 4 x 4 mesh with uniform random traffic, the average route is about 2.5 hops. If each router takes 2 cycles and each link 1 cycle, a request spends about 7.5 cycles in the network, plus a few cycles in the sockets at each end, around 10 to 12 ns at 1 GHz. A latency-critical CPU-to-cache path may justify a dedicated, shorter route.
Pipelining a long path
If a signal can travel about 1.5 mm in one 1 GHz cycle after allowing for setup and clock skew, a 6 mm path between two corners of a subsystem needs at least three pipeline stages. Each stage adds a cycle of latency, which is the price of closing timing.
Design recommendations
When designing an SoC with NoC IP, several factors must be considered.
Power
Power consumption is a critical consideration, especially for battery-powered devices. Clock gating, power gating and voltage scaling can be applied to NoC IP to minimise power consumption. Idle links and switches should be clock gated, and the NoC must handle power domains that switch off without leaving transactions hanging.
Performance
SoC performance is directly tied to the performance of its interconnect fabric. NoC IP must offer low latency and high bandwidth so components can communicate efficiently. Quality of service (QoS), such as priorities and bandwidth regulators, keeps real-time traffic like display or camera data from being starved by bulk transfers.
Area
The area occupied by NoC IP directly affects production cost. It should be designed with a small footprint to minimise overall SoC area. Buffer depth is the main lever: deep buffers help throughput but cost area and leakage.
Reliability
NoC reliability is the ability of the fabric to work correctly and consistently over time. NoC IP must handle the noise and interference that occur in a complex SoC. This includes error detection and correction such as parity or ECC (error correction code), to protect against transmission errors or data corruption.
Fault tolerance
Fault tolerance is the ability of an SoC to keep operating when a component fails. NoC IP must handle failures without disrupting the overall system. This can be done through redundancy, where several NoC components are implemented so that if one fails, others take over. Fault-tolerant NoCs may also use error correction, error detection and graceful degradation. In automotive SoCs these features support functional safety work under ISO 26262.
Security
Security is an important consideration in any SoC, and NoC IP is no exception. Measures can include authentication and encryption to protect against unauthorised access or data theft. They can be implemented at several levels of the NoC architecture: in hardware, in the NoC protocol or in software. A common hardware measure is a firewall at each target that checks the initiator ID and security attributes of every transaction.
Physical awareness: the key to integration
Physical awareness is a key aspect of integration and overall system efficiency. It means the NoC architecture takes the physical constraints and limits of the hardware into account during design: the position of the IP blocks, the routing resources available, the power delivery network and the signal integrity of the links.
A physically aware NoC can optimise placement of IP blocks and minimise the distance between them, reducing latency and power. It also allows efficient routing and avoids congestion, improving performance and reliability. Considering physical constraints during NoC design helps make the links robust, reducing the risk of errors and raising overall design quality. Examples:
Placement of IP blocks
Consider IP placement within the SoC from the start. If two IP blocks communicate often, place them close together and keep the links between them as short as possible. This reduces communication latency and power, improving performance.
Routing resources
Take account of the routing resources available, including the number of routing layers and vias. If routing is limited, avoid too many long-distance links, which cause congestion and lower performance. Optimising routing paths reduces the number of vias needed and the overall complexity of the routing structure.
Power delivery network
Consider the power delivery network of the SoC. The network can be designed to reduce the power of communication links, for example by using lower power signalling or by aligning NoC segments with the chip's power domains. This lowers overall system power, which matters most in battery-operated devices.
Signal integrity
Links between IP blocks must be robust and reliable. Considering signal integrity and avoiding interference from other signals or noise sources lets the NoC minimise distortion, improve reliability and reduce the risk of errors.
Common mistakes
- Designing the NoC topology before the floorplan is known, then discovering long wires and congestion late.
- Sizing links for average bandwidth and ignoring bursts from DMA, display or camera traffic.
- Leaving deadlock analysis to simulation alone; protocol and routing deadlocks need systematic checks.
- Forgetting that every pipeline stage and clock crossing adds latency for latency-sensitive CPUs.
FAQ
Is a NoC only for large SoCs?
Mostly. Small microcontrollers do well with buses. NoCs pay off once there are many initiators and targets, several clock domains or a large die.
What topology do NoCs use?
Meshes, rings, trees and custom irregular topologies are all common. Many commercial SoCs use a custom topology shaped to the floorplan and traffic pattern.
Does a NoC support cache coherency?
A NoC can carry coherency traffic. Coherent interconnects add snoop filters or directories on top of the transport to keep caches consistent.
Your comments will be moderated before it appears here.