Design Complexity In The Golden Age Of Semiconductors

Increasing complexity isn’t just about processors.


While writing last month’s blog that used some of the trend charts we have seen, I noticed that a lot of the data ends in 2020 or earlier, but I was too close to the deadline to sit down and make orderly updates to some of the charts. Working day-to-day in the area of SoC integration and networks-on-chips (NoCs), the classic chart based on Karl Rupp’s now 50 years of processor data that overlays the Moore’s law transistors with single-thread performance, processor frequency, typical power, and the number of processor cores is relevant, but not quite perfect. Yes, processor cores are essential, but there are many other types of silicon IP blocks (SIP) to be connected using NoCs and integrated using what we at Arteris call “SoC Integration Automation.”

So, I looked for the relevant source data and developed some new visualizations.

NoC protocol complexity

First, let’s look at NoCs in the context of complexity. The chart below shows the evolution of transistor complexity as outlined on the Transistor Wikipedia page. I separated CPUs and GPUs; the latter is kicking in in the mid-1990s in earnest. Unsurprisingly, this part of the chart shows Moore’s law without considering transistor cost, which I plan to overlay in a future version.

The red data points are the number of SIP blocks, with permission from Richard Wawrzyniak at The SHD Group. We are arriving at about 400 SIP blocks for Advanced Multicore SoCs in 2023. Note that this is on a logarithmic scale, so in the early 2000s, the industry was in the lower two digits for the number of SIP blocks, and the number was growing fast.

Fig. 1: Transistor and network-on-chip (NoC) complexity over time.

All these SIP blocks need to talk to each other, which spawned the development of protocols for NoCs. The most prominent protocol is the  Advanced Microcontroller Bus Architecture (AMBA). It is a freely available, open standard to connect and manage functional blocks and charted with its complexity as measured in the number of pages. The first version of AMBA, released in 1996, included two buses, the Advanced System Bus (ASB) and Advanced Peripheral Bus (APB), and had 106 pages. The second version, released in 1999, added the AMBA High-performance Bus (AHB), a single clock-edge protocol. The spec had 204 pages.

The third version of AMBA was released in 2003 and introduced the AMBA Advanced eXtensible Interface (AXI), a high-performance, multi-channel protocol. The total number of pages grew to 260 pages in 2006. AMBA 4 was released in 2010 and added the AMBA AXI Coherency Extensions (ACE) and AMBA Low-power Interface (LPI) protocols, which enable cache coherency and power management. The specs grew to a total of 534 pages in 2012.

AMBA 5, the latest version, released in 2013, introduced the AMBA Coherent Hub Interface (CHI) architecture, which defines the interfaces to connect fully coherent processors and high-performance interconnects. It also extended the prior protocols to support new features such as quality of service and atomic operations. By 2023, the total page count of AMBA 5 related specs has grown to 1398, with various versions of CHI and specification of Adaptive Traffic Profiles (marked at ATP), a Generic Flash Bus Protocol (GFP), a Distributed Translation Interface (DTI) and a Local Translation Interface (LTI), defining the point-to-point protocol between an I/O device and the Translation Lookaside Buffer Unit (TLBU) of an Arm System Memory Management Unit (SMMU).

By the way, thanks to Arm’s Francisco Socal for his input on this project. He warned me that the AMBA complexity would drop slightly in 2023 due to the recent introduction of AXI-J. It significantly simplifies the document by removing legacy content and AXI5 now has a generic interface that can be configured as ACE5-Lite, ACE5-LiteDVM, and AXI5-Lite. He recently published Arm’s thoughts on, “Moving AMBA forward with multi-chip and CHI C2C.”

If you have, at this point, like me, the “TLA and FLA Blues” (three and four-letter acronyms), then it becomes clear that NoCs for AMBA require particular expertise. That’s where we at Arteris are coming in with our FlexNoC and NCore IP for non-coherent and coherent protocols.

But wait, there is more.

The bottom right of the chart above shows the timeline of the introduction of four other related protocols:

  • The Open Core Protocol (OCP) is a standard for on-chip interconnects. It was first introduced in 2007 by the SPIRIT Consortium. The latest version, OCP 3.0, was released in 2022.
  • The TileLink NoC protocol is a standard for on-chip interconnects focused on RISC-V. It was first introduced in 2016 by the RISC-V Foundation. Verification IP support exists for version 1.8.0 (SiFive, 111 pages) and version 1.8.1 (StarFive, 93 pages). Version 1.7 in 2017 had 106 pages, so roughly about as many pages as the original AMBA spec in 1996.
  • The Cache Coherent Interconnect for Accelerators (CCIX) is a high-speed interconnect standard for connecting processors, memory, and accelerators, first introduced in 2016.
  • The Compute Express Link (CXL) is a high-speed interconnect standard for connecting processors, memory, and accelerators, first introduced in 2019.

The chart only shows the complexity of these protocols as the number of pages, only the timelines, hence they are called out in a different block.

Bottom line: It’s a complex world of NoCs, and they are critical to enabling complex SoCs and, more and more, chiplet-based designs.

SoC integration complexity

Well, now you have many commercial SIP blocks and all your differentiating blocks. Where to go from here? SoC integration automation is the answer. The chart below shows how the industry has and still is reacting to the growing complexity and number of SIP blocks over time:

Fig. 2: Transistor and SoC integration complexity over time.

This chart repeats the transistor complexity and number of SIP blocks described above. But now it overlays the attempts and standards that deal with the SoC assembly, i.e., the management of the sea of RTL blocks, both commercially acquired and developed internally. IP-XACT is the critical term to remember here.

As charted, the VSI Alliance was an organization founded in 1996 to enhance the productivity of the SoC design community by providing standards and solutions for IP reuse. The SPIRIT Consortium was another organization founded in 2003 to develop and specify the IP-XACT standard, an XML format for describing IP components and designs. In 2008, the VSI Alliance and the SPIRIT Consortium merged into Accellera, an industry association dedicated to creating design and verification standards. Accellera maintains and updates the IP-XACT standard.

2004 marked the release of IP-XACT 1.0 as the first version of IP-XACT. It focused on describing SIP blocks’ register-transfer level (RTL) behavior. Then, in 2005, version 1.1 added support for defining SIP block transaction-level modeling (TLM) behavior; in 2006, version 1.2 added support for describing the physical implementation of IP blocks. Version 1.4 added support for defining the verification of IP blocks in 2008. After the merger, IEEE Std. 1685-2009 was the first version of IP-XACT approved by the IEEE in 2009. IEEE Std. 1685-2014 added support for describing the security of IP blocks. Today, the latest version of IP-XACT, IEEE Std. 1685-2022, supports the definition of vendor extensions of SIP blocks.


While the charts illustrate the trends leading up to today, 2023, both SoC designs and chiplet-based designs are only getting more complex from here. NoC protocols will become more complex, and the sea of RTL blocks to be connected is only getting more profound and extensive. Do you want to refactor the RTL manually when redefining power regions? No, you don’t! That’s where IP-XACT-based SoC integration automation comes in.

NoC SIP reuse and IP-XACT-based SoC integration automation are critical to keeping design costs in check and increasing productivity for the Golden Age of Semiconductors!

Leave a Reply

(Note: This name will be displayed publicly)