Systems-on-chips (SoCs) are increasingly becoming networks to which you attach separate blocks of intellectual property (IP). SoC IP blocks include processors, memory controllers, specialized subsystems, and I/Os — and the blocks can be segregated from the interconnect IP to partition increasingly complex SoCs. Increasingly complex SoCs are required for a near future when electronics systems are allowed to make decisions.

An interconnect handles various types of traffic inside an SoC and is a mechanism for effective IP block integration. The interconnect is the most configurable IP in the SoC — typically changing many times during a project and nearly always changing between projects. It also plays a vital role in security and functional safety because it carries most of the SoC data and contains nearly all the SoC’s long wires and system-level services, including quality of service (QoS), visibility, physical awareness, and power management. The interconnect enables cache coherency in multiprocessor SoCs, high-performance and bandwidth levels in advanced driver assistance systems (ADAS) automotive chips and networking SoCs, and ultra-low power in long-running consumer devices.

Interconnect IP must constantly evolve to support innovative SoCs for use in new sectors, such as the emerging artificial intelligence (AI) and machine learning (ML) applications that are driving innovation in data center automation and autonomous driving.

 

 

 

 

Figure 1. On-chip interconnects are the logical and physical instantiation of an SoC's architecture. (Source: Arteris IP)

As process geometries continue to shrink, the SoC interconnect becomes more critical. Dividing the chip into functional circuit blocks of reusable IP, or “chiplets,” increases the die yield and, at today’s process geometries of 16 nm and below, allows more functionality to be included. A chiplet approach enables developers to assemble dice from multiple companies or with specific functions (such as memory and I/O) in a single package.

What makes for a “good” interconnect?
The interconnect typically makes up about 10% of a finished SoC, yet significantly affects its quality, performance, and delivery schedules. The initial license cost for interconnect IP is relatively small compared to the overall SoC budget, but a “bad” interconnect can cause scheduling, cost, and specification problems. For example, if the interconnect does not allow closing of the timing at the targeted performance, the SoC will not meet frequency specifications — which can cause loss of a design win.

A performant interconnect IP that will be used on multiple SoC projects needs to satisfy a variety of criteria, including: 

Architectural flexibility — The interconnect has to accommodate a variety of architectural topologies to achieve necessary flexibility. For example, the interconnect fabric needs to allow tree structures (which are best for heterogeneous SoCs) as well as regular topologies, including meshes, rings, and toroids (which are required for AI and networking SoCs). The interconnect IP must also be able to “scale down” to meet lower-end interconnect requirements for projects such as IP subsystems and SoC service interconnects.

For example, an interconnect that has only corner router switches may be appropriate for high-end networking but not for a mobility SoC, in which minimization of power, area, and latency are essential. On the other hand, lack of corner router switches is a disadvantage for delivering on high-end server designs or AI/machine learning accelerators. Equally, an interconnect that handles non-coherent traffic but cannot support cache coherency limits the choice of cache-coherent SoC architectures. Protocol-conversion capability — where the interconnect can support a variety of IP-block communication protocols — maximizes the choice of IP blocks that can be used in a design.

Performance — Performance can be divided into three subcategories:

• Frequency —If the interconnect cannot achieve targeted frequencies, it limits the SoC’s performance. For example, if a processor runs at 4 GHz and the cache-coherent interconnect cannot run at 2 GHz, performance will be limited. However, not all paths in an SoC are equal. It is vital to have a variety of frequency domains and a rate-adaption capability so that individual paths can run at different frequencies. After all, why pay for a high-performance path for the entire interconnect when only some paths need to run at the highest frequencies specified? 

• Latency — Latency is determined by the number of cycles it takes for a packet to go from the initiator to the target IP block. It relies on the efficiency of the interconnect IPs, the length of the wires traveled to reach its destination, and the physical placement of the interconnect IP functions. Interconnect physical awareness is critical at 16 nm and below because timing closure must be estimated as early as possible in the RTL (register transfer level) stage to avoid problems during place and route.

  Latency and frequency present a tradeoff: if frequency is high, more pipelines are needed, which increases latency. Minimizing latency is particularly important for the latency-sensitive processor-to-memory paths. The good news is that relatively few paths in the SoC are as latency critical, but bear in mind that additional latency cycles along these paths are often the constraint on system-level SoC performance. The longer the paths and the more wires used to make them, the more pipelines must be added to meet the timing constraints. Network-on-chip (NoC) interconnects have distributed switching and typically offer lower latencies than hybrid buses with centralized crossbars. Distributed arbitration further shortens paths between switching elements. Not all networks are latency-critical, so the interconnect should provide flexibility for high-latency paths, for example, I/O IP blocks that are used only during the SoC’s initial operation. Having high-latency path capability conserves wires in the SoC design.

• Bandwidth/throughput —Bandwidth is the maximum rate of data transfer across a given path. Throughput is how much data travels along the interconnect path successfully. Throughput can be limited by interconnect architecture, implementation topology, and packet protocol. An effective interconnect supports performance as close to the theoretical bandwidth as possible; a poor interconnect creates bottlenecks. An interconnect that is able to support 8-bit low-bandwidth connections to 1024-bit high bandwidth — and interconnect widths in between — provides designers with maximum architectural flexibility.

Area — Silicon is a cost factor in any SoC design. A useful metric is that 1 square mm of silicon generally costs 10 cents per SoC in a standard 16-nm process. Savings can be realized by using fewer wires and gates and more efficient interconnect topologies. If the difference in area is more than 5 mm square, yield will improve, providing additional savings. Since an area-efficient interconnect typically makes up about 10% of the SoC’s area, an interconnect that is 30–50% smaller will save several square millimeters of silicon at the chip level. As a rough guideline, an area-efficient interconnect will save about 3‒5 square mm on a 100 mm square SoC, or 30‒50 cents per SoC depending on production volumes.

Power — In stand-alone consumer or Internet of things (IoT) devices, power consumption is essential. In active power modes, the interconnect IP uses less power than the CPU and GPU, but these can be shut down quickly when a task is completed. In fact, for most battery-powered systems, idle power is the determinant of battery life. Properly managing interconnect power consumption is essential for idle (or standby power) when there is no data traffic but the clocks are on.

For a battery-powered system that spends much of its time in an idle power mode, a low-power interconnect is needed. The interconnect IP must implement power control policies through three levels of clock gating, enable easy creation of multiple power domains, have one cycle power domain bring up, and low-power domain crossings. A sound metric for interconnect power at 16 nm is < 0.5 mW of idle power per million gates of interconnect logic.

Functional safety — Mission critical applications have to meet stringent safety standards, such as the ISO 26262 standard in the automotive market. Interconnect IP implementation to meet ASIL (Automotive Safety Integrity Level) B, C, and D requirements of ISO 26262 demands resilience features that compensate for systematic and random errors in order to achieve required fault detection and protection levels. To meet the highest level of ASIL D, interconnect IP requires network interface unit logic duplication, ECC (error code correction) and/or parity bit data path protection, and packet integrity checking. The interconnect IP supplier must also be able to provide a functional safety manual and accompanying analyses and work products that demonstrate that the interconnect IP is suitable for use in an ISO 26262-compliant system. Without such documentation and work product, it is difficult to qualify a semiconductor component in the final electronic system.

Security — While resilience protects SoCs from manufacturing and environmental errors, security protects mission-critical silicon from human attacks. An effective interconnect must be able to implement firewalls, which are typically configured by the design team. Section-isolation capability must be available to provide security when data traverses from one section of the SoC to another. These interconnect hardware features should seamlessly integrate with and strengthen the overall system-level security scheme.

Productivity — Productive interconnect tools accelerate deployment and make SoC design schedules more predictable. Interconnect IP software tools should include:

• SoC requirements and objectives input for capturing customer, marketing, and design intent.
• Design exploration for architectural optimization.
• Multi-level modeling capability for early SoC and interconnect analysis.
• Interconnect RTL generation for a variety of SoC topologies.
• Physical awareness for early timing closure estimation.
• Automated functional verification for timely NoC verification.
• On-chip observability and debugging for SoC visibility.
• Automated FMEDA output for ISO 26262 compliance for accelerated functional safety analysis.

 

Figure 2. An on-chip interconnect must satisfy different requirements for different kinds of chips. (Source: Arteris IP)

An ecosystem of IP and electronic design automation (EDA) products means support for multiple IP protocols from companies such as Arm, Synopsys, and Cadence. It also means integration with the simulation, emulation, verification, functional safety, modeling, and place and route tools of both leading and startup EDA vendors. World-class interconnect productivity software and production-level integration with other IPs and EDA tools reduce the R&D cost and schedule time of an SoC project.

Counting the cost of IP
Although interconnect IP makes up only 10% of an SoC, it can be responsible for delays or even missed system design windows. At best, a sub-optimal SoC can lead to timing issues, deadlocks that keep the SoC from functioning, data starvation at SoC subsystems, bandwidth bottlenecks, and missing features that force unforeseen workarounds adding R&D expense and delays. Therefore, a performant and proven interconnect plays a key role in SoC design project success.

Conclusion
Effective interconnect IP development requires years of effort and can cost $70–100 million. Shortcuts lead to disappointment and incur significant business costs. Designing an interconnect for a single chip is one challenge, but delivering a broad interconnect solution suitable for multiple SoC designs takes funding, scale, and commitment. IP teams can be challenging to assemble and retain — they must be interdisciplinary (architects, hardware engineers, software developers, and verification engineers) and remain together for years during the development project.

An effective interconnect makes delivering a complex SoC easier, more predictable, and less costly. SoC project directors just have to choose the right interconnect.