<h2 id="isPasted">September 28th 2026 Efinix announced the Sapphire RV64 soft SoC</h2>The Sapphire RV64's CPU cores, caches and peripherals are built from FPGA logic, with DRAM reached through the FPGA's hardened DDR interface. It uses one to four cores derived from VexiiRiscv, an MIT-licensed open-source RISC-V CPU. Each core has a seven-stage in-order pipeline implementing RV64IM with optional A, F, D, C, Zba, Zbb, Zbs and Zicbom extensions; Efinix lists Linux support via an optional Sv39 MMU.[1][2][3]Efinix aims it at designs that have "outgrown the performance, addressable memory, cache, and I/O limits of 32-bit embedded cores". Support covers all Efinix's Titanium and Topaz FPGAs (its 16 nm families) and Trion devices (its first-generation 40 nm family) from the T20 up.[1][4][5]<h2>Why it matters</h2>The step from the company's 32-bit Sapphire SoC is mostly about memory. The 32-bit version addresses up to 3.5 GB of DRAM and has L1 caches only. Sapphire RV64 addresses up to 8 GB of DDR3 or LPDDR4x and adds a shared 64 to 512 KB L2 cache.[2][6] With the L2 enabled, it also keeps two AXI DMA ports from user logic coherent, so accelerators in the fabric share cached memory without software flushes.[2]The 32-bit Sapphire already runs Linux; Efinix's br2-efinix Buildroot tree now builds Linux 6.6 for Sapphire RV64 too, so far only for the Titanium Ti375 C529 development board.[7][8] The gain is address reach: Sv39 gives software a 512 GB virtual address space, and the physical map places 8 GB of DRAM and a 64 GB cached AXI window above the 4 GB a 32-bit address spans.[2]Raw speed is modest. On the Ti375 board one Sapphire RV64 core scores 1.23 to 1.57 CoreMark/MHz, and fMAX is 250 to 278 MHz on the Ti375 and 65 to 77 MHz on a Trion T120. On that T120, the nearest published 32-bit Sapphire configuration reaches 115 MHz in 7,391 logic/adders, against 77 MHz and 10,741 for the most basic 64-bit build.[2][9] The Ti375 also carries a hardened quad-core 32-bit RISC-V block, which Efinix benchmarks at 2.345 CoreMark/MHz at 1 GHz.[10][11][12] Multiplying score by clock (our calculation, if per-MHz scores hold across clocks and compilers), the best soft configuration gives about 400 CoreMark per core, a hard core about 2,300.Where a hard CPU exists, Sapphire RV64's case rests on memory reach: up to 8 GB of DRAM against the hard block's 3.7 GB, and two cache-coherent DMA ports against its one AXI slave. It fits best on Trion, on Titanium and Topaz parts without the hardened block, and in 32-bit Sapphire designs that need more memory.[2][12][13]AMD's MicroBlaze V soft core already offers a 64-bit Sv39 implementation, with a Linux preset listed at 199 to 258 MHz on UltraScale+ devices; Lattice's RISC-V RX is 32-bit.[14][15][16]<h2>Technical specifications</h2><h3>Sapphire RV64 SoC: configurable range</h3><div><table><thead><tr><th>Spec</th><th>Value</th></tr></thead><tbody><tr><td>CPU</td><td>1 to 4 VexiiRiscv cores, 7-stage in-order pipeline, little-endian; machine and supervisor modes</td></tr><tr><td>ISA</td><td>RV64IM; optional A, F, D, C, Zba, Zbb, Zbs, Zicbom</td></tr><tr><td>System clock setting</td><td>20 to 400 MHz (achieved clock limited by device fMAX)</td></tr><tr><td>L1 cache</td><td>Instruction and data, 1, 2, 4 or 8 ways of 4 KB each; write-back data cache</td></tr><tr><td>L2 cache</td><td>Optional, shared, 64, 128, 256 or 512 KB, 8-way; coherency point for DMA</td></tr><tr><td>On-chip RAM</td><td>4 to 512 KB, with SPI flash boot loader</td></tr><tr><td>External memory</td><td>DDR3 at 800 Mbps, LPDDR4x at 3,200 Mbps, HyperRAM at 500 Mbps; 4 MB to 8 GB; DDR requires the FPGA's hardened DDR controller (Trion's supports DDR3, LPDDR3 and LPDDR2)</td></tr><tr><td>Memory bus</td><td>AXI4 full-duplex or AXI3 half-duplex, 32 to 512 bits</td></tr><tr><td>User-logic ports</td><td>Up to 2 coherent AXI4 slave (DMA) ports, 32 to 512 bits; up to 2 AXI4 master ports: A (AXI-Lite compatible, 256 MB uncached I/O region) and B (burst-capable, 64 GB cached region)</td></tr><tr><td>Memory management</td><td>Optional Sv39 MMU; optional PMP at 4 KB granularity</td></tr><tr><td>Interrupt handling</td><td>PLIC and CLINT; direct-mode trap vectors only (no vectored mode)</td></tr><tr><td>Other options</td><td>FPU (single or single plus double precision); BTB, RAS and gshare branch predictor; hardware and software prefetchers; custom-instruction interface with 1,024 IDs</td></tr><tr><td>Peripherals</td><td>Up to 32 GPIO, 5 I2C, 3 SPI, 3 UART, 3 timers, 8 user interrupts, 5 APB3 slave ports; watchdog</td></tr><tr><td>Debug</td><td>RISC-V debug specification through the FPGA's JTAG User TAP, up to 4 hardware breakpoints, co-debug with the FPGA debugger; no GPIO-based soft debug TAP</td></tr><tr><td>Linux support</td><td>br2-efinix Buildroot tree: Linux 6.6, U-Boot 2025.01, OpenSBI 1.6; RV64 build for the Titanium Ti375 C529 development board</td></tr><tr><td>Supported FPGAs</td><td>All Titanium and Topaz; Trion T20 and above</td></tr><tr><td>License terms and price</td><td>Not stated</td></tr></tbody></table></div><h3>Sapphire RV64 single-core benchmark configurations (Efinix's Efinity design software, version 2026.1)</h3><div><table><thead><tr><th>Spec</th><th>Basic L1</th><th>Basic L2</th><th>Advanced L1</th><th>Advanced L2</th></tr></thead><tbody><tr><td>CoreMark/MHz (Ti375 board)</td><td>1.23</td><td>1.25</td><td>1.56</td><td>1.57</td></tr><tr><td>Dhrystone/MHz (Ti375 board)</td><td>1.17</td><td>1.17</td><td>1.37</td><td>1.54</td></tr><tr><td>fMAX, Titanium Ti375 C529</td><td>271 MHz</td><td>278 MHz</td><td>250 MHz</td><td>252 MHz</td></tr><tr><td>fMAX, Topaz Tz170 J484</td><td>176 MHz</td><td>170 MHz</td><td>164 MHz</td><td>167 MHz</td></tr><tr><td>fMAX, Trion T120 F324</td><td>77 MHz</td><td>77 MHz</td><td>65 MHz</td><td>65 MHz</td></tr><tr><td>Logic/adders, Ti375</td><td>10,740</td><td>14,258</td><td>23,838</td><td>27,250</td></tr><tr><td>Memory blocks, Ti375</td><td>91</td><td>188</td><td>128</td><td>225</td></tr><tr><td>DSP48 blocks, all three devices</td><td>17</td><td>17</td><td>17</td><td>17</td></tr></tbody></table></div>Sources: [1][2][5][8][17]All four configurations use 1-way 4 KB L1 caches and a 256-bit AXI4 memory bus; the L2 variants add 64 KB of L2. Basic enables the I, M, A and C extensions; Advanced enables every extension except Zicbom plus all optional features.[2] All published figures are single-core. Advanced roughly doubles logic for about a quarter more CoreMark/MHz, and at each configuration's Ti375 fMAX the gain narrows to about 14% (our calculation: 27,250 against 14,258 logic/adders; 252 × 1.57 against 278 × 1.25). Efinix notes that enabling custom instructions, the FPU or the Linux MMU affects fMAX.[17]<h2> </h2>Recommended Reading:<a href="https://www.wevolver.com/article/risc-v-architecture"> RISC-V Architecture: A Comprehensive Guide to the Open-Source ISA</a>. Background on the RV32 and RV64 base ISAs, the standard extensions and the privilege modes that an Sv39 MMU relies on.<h2>References</h2><ol><li><a href="https://www.efinixinc.com/company-pr-efinix-brings-64-bit-riscv-performance-to-embeddded-fpga-designs-with-new-sapphire-rv64-soc.html">Efinix Brings 64-Bit RISC-V Performance to Embedded FPGA Designs With New Sapphire RV64 SoC</a>, Efinix, 28 September 2026. Company press release.</li><li><a href="https://www.efinixinc.com/docs/riscv-sapphire-rv64-ds-v1.0.pdf">Sapphire RV64 SoC Data Sheet, DS-SAPPHIRE-RV64 v1.0</a>, Efinix, May 2026.</li><li><a href="https://github.com/SpinalHDL/VexiiRiscv">VexiiRiscv</a>, SpinalHDL, accessed 30 September 2026. Open-source project repository.</li><li><a href="https://www.businesswire.com/news/home/20240711244170/en/Efinix-Releases-Topaz-Line-of-FPGAs-Delivering-High-Performance-and-Low-Power-to-Mass-Market-Applications">Efinix Releases Topaz Line of FPGAs, Delivering High Performance and Low Power to Mass Market Applications</a>, Business Wire, 11 July 2024. Company press release.</li><li><a href="https://www.efinixinc.com/docs/trion-overview-v3.3.pdf">Trion FPGA Overview v3.3</a>, Efinix, 2025.</li><li><a href="https://www.efinixinc.com/docs-html/rv32-sapphire-ds/topics/riscv-saxon-efx-features-sapphire.html">Sapphire RV32 SoC Data Sheet: Features</a>, Efinix, accessed 1 October 2026.</li><li><a href="https://efinixinc.com/products-linux-riscv.html">Linux + RISC-V Sapphire SoC</a>, Efinix, accessed 1 October 2026.</li><li><a href="https://github.com/Efinix-Inc/br2-efinix">BR2-Efinix: Buildroot external tree for building Linux for Efinix RISC-V Sapphire SoC</a>, Efinix, branch 2025.02, accessed 1 October 2026. Company board support package.</li><li><a href="https://www.efinixinc.com/support/ip/riscv-sapphire.php">Sapphire RISC-V SoC</a>, Efinix, accessed 1 October 2026. Product page for the 32-bit soft SoC, with resource and fMAX tables.</li><li><a href="https://www.businesswire.com/news/home/20240401675642/en/Efinix%E2%80%99s-Titanium-Ti375-Sampling-Unlocking-and-Delivering-Mainstream-Edge-Intelligence-Innovation">Efinix's Titanium Ti375 Sampling; Unlocking and Delivering Mainstream Edge Intelligence Innovation</a>, Business Wire, 1 April 2024. Company press release.</li><li><a href="https://www.efinixinc.com/docs-html/riscv-sapphire-hpb-ug/topics/riscv-performance-hpb.html">High-Performance Sapphire SoC User Guide: Performance</a>, Efinix, accessed 30 September 2026. Vendor benchmark results.</li><li><a href="https://www.efinixinc.com/docs-html/rv32-sapphire-hpb-ds/topics/riscv-saxon-efx-features-sapphire-hpb.html">High-Performance Sapphire RV32 SoC Data Sheet: Features</a>, Efinix, accessed 1 October 2026.</li><li><a href="https://www.efinixinc.com/support/ip/riscv-sapphire-hpb.php">High-Performance Sapphire RV32 SoC</a>, Efinix, accessed 1 October 2026. Product page for the hardened block.</li><li><a href="https://docs.amd.com/r/en-US/ug1629-microblaze-v-user-guide/Resource-Utilization">MicroBlaze V Processor Reference Guide (UG1629): Resource Utilization</a>, AMD, release 2026.1, 31 July 2026.</li><li><a href="https://docs.amd.com/r/en-US/ug1629-microblaze-v-user-guide/Memory-Architecture">MicroBlaze V Processor Reference Guide (UG1629): Memory Architecture</a>, AMD, release 2026.1, 31 July 2026.</li><li><a href="https://www.latticesemi.com/Products/DesignSoftwareAndIP/IntellectualProperty/IPCore/IPCores04/RISC-V-RX-CPU">RISC-V RX CPU IP Core</a>, Lattice Semiconductor, accessed 30 September 2026.</li><li><a href="https://www.efinixinc.com/docs/riscv-sapphire-rv64-ug-v1.0.pdf">Sapphire RV64 SoC User Guide, UG-SAPPHIRE-RV64 v1.0</a>, Efinix, May 2026.</li></ol>

Up to four 64-bit RISC-V cores, a coherent L2 cache and a Linux-capable Sv39 MMU built from FPGA logic.

New 64-bit RISC-V soft SoC for FPGAs with 8 GB DRAM reach

<h2 id="isPasted">When Interconnect Shapes the System</h2>Modern SoCs are no longer defined solely by their compute capabilities. Instead, they are shaped by the complexity of integrating diverse processing elements and ensuring efficient communication between them. The rise of heterogeneous architectures, combined with the increasing adoption of chiplet-based and multi-die systems, has significantly expanded the role of interconnect design.As these systems scale, the interconnect is no longer a secondary consideration—it becomes a determining factor in overall system viability. Ensuring that data can be delivered efficiently, predictably, and at scale is now central to achieving performance and power targets.This shift has been observed across multiple generations of SoC development, particularly among companies focused on on-chip connectivity, such as <a href="https://www.arteris.com/" target="_blank" rel="noopener noreferrer">Arteris</a>, where evolving system requirements have increasingly highlighted data movement as a system-level constraint [1].<h2>Why NoC Complexity Has Increased</h2>The growing importance of network-on-chip (NoC) design is closely tied to the demands of modern workloads, particularly in artificial intelligence (AI). AI systems require high bandwidth, low latency, and efficient data reuse across multiple compute units, placing significant pressure on interconnect infrastructure.As AI workloads scale, SoCs integrate more heterogeneous IP blocks, including CPUs, GPUs, NPUs, and specialized accelerators. This increases both the volume and complexity of data movement. At the same time, chiplet-based designs and advanced packaging approaches such as 2.5D and 3D integration multiply the number of communication paths within a system.These trends introduce additional challenges, including:<ul><li>Multiple clock domains and power islands </li><li>Increased need for isolation and security boundaries </li><li>Greater variability in traffic patterns </li></ul>Together, these factors make interconnect design a system-level challenge. In this context, the NoC becomes a primary enabler of AI system scalability, power efficiency, and deterministic behavior, ensuring that distributed compute resources can operate effectively [2] [3].<h2>Core NoC Design Trade-offs</h2>Designing an effective NoC requires balancing several competing constraints, each of which directly impacts system performance, power, and scalability.One key trade-off is bandwidth provisioning versus power and area efficiency. Over-provisioning bandwidth can reduce contention and improve performance, but increases area and energy consumption. Under-provisioning, on the other hand, can lead to congestion and reduced throughput.Another critical consideration is managing contention, latency, and quality of service (QoS). In heterogeneous systems, different components may have varying latency and bandwidth requirements. Ensuring predictable performance requires mechanisms for prioritization and arbitration.Energy-aware communication is also increasingly important. Techniques such as power gating and dynamic scaling help reduce energy consumption but must be carefully managed to avoid performance penalties [4].In addition, modern NoC design must be physically aware, considering placement, routing, and timing constraints early in the design process. As technology nodes shrink and system complexity increases, physical and logical considerations are becoming more tightly coupled.These trade-offs have been the focus of ongoing research and development across the industry, as interconnect design evolves to meet the demands of increasingly complex SoCs.<h2>Security, Safety, and Isolation</h2>As SoCs are deployed in safety-critical and security-sensitive applications, the role of the interconnect extends beyond performance and efficiency.In automotive and industrial systems, compliance with standards such as ISO 26262 requires robust support for functional safety, including predictable communication and fault isolation (ISO, 2018). The interconnect plays a key role in preventing faults from propagating across system boundaries [5].At the same time, increasing system complexity introduces new security challenges. The NoC, as the central communication fabric, becomes both a potential attack surface and a point of enforcement for system-level policies.This has led to growing emphasis on hardware assurance—ensuring that system behavior is secure, predictable, and verifiable across all operating conditions. Industry efforts, including those by Cycuity, highlight the importance of validating hardware security properties across complex SoC designs.Modern NoC architectures must therefore support isolation, monitoring, and policy enforcement at scale, enabling both safety and security requirements to be met.<h2>Build vs. Reuse: The Economics of NoC Design</h2>Historically, many companies developed custom interconnect solutions tailored to their specific SoC architectures. This approach was feasible when systems were less complex and workloads more predictable.However, the economics of NoC design have changed. Rising R&amp;D costs, long maintenance lifetimes, and the accumulation of verification debt—the increasing effort required to validate evolving systems over time—have made custom development more challenging.The shift toward AI workloads further increases complexity. Designing interconnects that can handle high bandwidth demands, dynamic traffic patterns, and strict performance requirements adds both cost and risk [6].As a result, data movement infrastructure is increasingly treated as reusable system IP rather than bespoke logic. Industry observations, including those from companies such as Arteris, indicate that this shift allows teams to manage complexity more effectively while reducing development risk [1].By relying on reusable interconnect solutions, engineering teams can focus their efforts on areas of differentiation—such as algorithms, software, and system-level innovation—rather than maintaining underlying communication infrastructure.<h2>Automation and the Future of NoC Development</h2>The scale and complexity of modern AI-driven systems are making manual NoC design increasingly impractical. Automation is emerging as a key enabler in addressing these challenges.AI workloads act as a forcing function, driving the need for more sophisticated design methodologies. At the same time, the industry faces a shortage of experienced NoC and system IP architects, further increasing reliance on automated approaches.Automation is now being applied across multiple stages of development, including architecture exploration and RTL generation. These approaches enable systematic evaluation of design trade-offs and help identify optimal configurations more efficiently.Another important trend is the convergence of physical and logical design considerations earlier in the development process. Incorporating placement, routing, and timing constraints at the architectural stage helps reduce downstream integration challenges.The benefits of automation include improved performance and power efficiency through systematic design exploration, reduced integration risk, faster time-to-tapeout, and shorter time-to-market for end products. These approaches also enable reusable architectures that can scale across AI generations and chiplet-based systems.<h2>NoC as Enabling Infrastructure</h2>In modern SoCs, the most effective interconnect designs are often the least visible. When designed correctly, they enable seamless communication between components, allowing the rest of the system to operate efficiently.Robust interconnect design enables innovation in higher-level system functions by abstracting the complexity of data movement. This has led to increased specialization in NoC design, with companies such as Arteris developing expertise across multiple markets and system architectures.This cross-market experience, accumulated over many generations of SoC development, provides insights into design trade-offs and scalability challenges—expertise that can be difficult for individual teams to build and sustain internally.As systems continue to grow in complexity, the <a href="https://explore.arteris.com/white-paper-flexgen" target="_blank" rel="noopener noreferrer">role of the NoC</a> will only become more central. Rather than being viewed as supporting infrastructure, it is increasingly recognized as a foundational element that enables performance, efficiency, and innovation across modern computing systems.<hr /><h2>References</h2><h2> </h2><ol><li>Arteris. Data Movement in SoCs: NoC Performance, Power &amp; Scalability. [Online]. Available: <a href="http://arteris.com/learn/data-movement/" target="_blank" rel="noopener noreferrer">http://arteris.com/learn/data-movement</a></li><li>Hennessy, J. L., &amp; Patterson, D. A. (2019). Computer Architecture: A Quantitative Approach (6th ed.). Morgan Kaufmann.</li><li> NVIDIA, “NVIDIA Hopper Architecture In-Depth,” NVIDIA, Mar. 22, 2022. [Online]. Available: <a href="https://resources.nvidia.com/en-us-hpc-ai/nvidia-hopper-architecture">https://resources.nvidia.com/en-us-hpc-ai/nvidia-hopper-architecture</a></li><li>Horowitz, M. (2014). Computing’s energy problem (and what we can do about it). IEEE ISSCC.</li><li>ISO 26262. (2018). Road vehicles – Functional safety. International Organization for Standardization.</li><li>EE Times Asia. The Data Dilemma: Cracking the Code of Data Movement for the Next Wave of Semiconductor Innovation.</li></ol>

Arteris shapes System-on-Chip (SoC) performance and power efficiency

Network-on-Chip (NoC) Design Architectural Trade-offs

Cellular connectivity is one of the most common failure points in IoT deployments. Devices that perform perfectly in controlled environments often behave very differently once installed in basements, vehicles, metal enclosures, or remote locations.Missed messages, delayed commands, and unexpected battery drain are rarely application problems. More often, they come down to how connectivity was selected, configured, and validated.This white paper gives you a practical framework to avoid those issues before they scale.<iframe id="JotFormIFrame-261244210544345" src="https://form.jotform.com/261244210544345" frameborder="0" style="min-width:100%;max-width:100%;height:800px;border:none" scrolling="yes" class="fr-draggable"> </iframe><h2>What this white paper covers</h2>This guide is written for engineers and technical teams building connected devices who need clear, field-ready guidance without getting lost in standards documentation.Inside, you will learn how to:<ul><li>Choose the right cellular technology for your specific use case</li><li>Understand real-world trade-offs between LTE-M, NB-IoT, Cat-1, and emerging 5G options</li><li>Evaluate performance based on field conditions, not datasheet claims</li><li>Design pilot tests that reveal issues before deployment</li><li>Plan for roaming, network changes, and long device lifecycles</li></ul><h2>Who should read it</h2>This white paper is for engineers and technical teams responsible for how connected devices perform in the real world. That includes hardware and embedded engineers building IoT products, connectivity specialists selecting cellular technologies, and product or engineering leads making deployment decisions. It is especially relevant for teams working across multiple regions or operating environments where reliability, coverage, and lifecycle planning directly impact product success.<h2>Why read this white paper</h2>Connectivity issues rarely show up in early testing. They tend to surface later, during pilots or after deployment, when fixing them is significantly more complex and costly. This guide helps shift that discovery earlier by focusing on how cellular technologies behave under real conditions rather than ideal scenarios.By reading it, you gain a clearer way to evaluate trade-offs, a practical approach to field testing, and a structured framework for making decisions that hold up over time. The aim is to reduce uncertainty, avoid common pitfalls, and ensure your connectivity design performs as expected once deployed.<h2>Download the white paper</h2>If you are designing or deploying cellular IoT devices, this guide will help you avoid common pitfalls and build systems that perform reliably in the real world.Get the full Engineer’s Field Guide to Cellular IoT and start designing with field conditions in mind.<iframe id="JotFormIFrame-261244210544345" src="https://form.jotform.com/261244210544345" frameborder="0" style="min-width:100%;max-width:100%;height:800px;border:none" scrolling="yes" class="fr-draggable">   </iframe>

Design connectivity that works beyond the lab

Engineer's Field Guide to Cellular IoT

<h2 id="isPasted">Compute Scaling Has Exposed a New Bottleneck</h2>For decades, system-on-chip (SoC) design has been driven by improvements in compute performance. Advances in transistor scaling enabled higher clock speeds, greater parallelism, and increasingly specialized processing units. As a result, architectural priorities focused on maximizing compute throughput.That paradigm is now shifting. As SoCs grow in complexity—driven by AI workloads, heterogeneous integration, and evolving system-level requirements—performance is no longer determined solely by compute capability. Instead, it is increasingly limited by the efficiency with which data moves across the system.This reflects a broader transition: modern SoCs are becoming data-movement-bound rather than compute-bound. Delivering data with the required bandwidth, latency, and energy efficiency has become a central design challenge. In many cases, adding more compute resources does not translate into higher performance if those resources cannot be fed with data efficiently.This shift has been observed across multiple generations of SoC design, particularly by companies focused on on-chip connectivity, such as <a href="https://www.arteris.com/" target="_blank" rel="noopener noreferrer">Arteris</a>, where evolving system requirements have increasingly exposed data movement as a limiting factor.<h2>What Changed Inside Modern SoCs</h2>Modern SoCs are highly heterogeneous systems, integrating CPUs, GPUs, NPUs, DSPs, and domain-specific accelerators. Each of these blocks has distinct compute characteristics and data access patterns, increasing coordination complexity across the chip.This complexity is further amplified by the adoption of chiplet-based and multi-die architectures. Instead of a single monolithic die, functionality is often distributed across multiple dies within a package. While this approach improves scalability, yield, and design flexibility, it also introduces additional communication layers—both on-chip and inter-die—making data movement more complex and resource-intensive.At the same time, memory is becoming more distributed and physically distant from compute. Data may traverse multiple interconnect layers, including on-chip networks, inter-die links, and off-chip memory interfaces, before reaching processing elements. Each step adds latency and energy overhead.As a result, workloads increasingly stall waiting for data rather than executing instructions. This trend is particularly evident in AI systems, where performance is strongly influenced by memory access patterns, bandwidth availability, and data reuse efficiency [1]. In such systems, the ability to move data efficiently can matter as much as compute capability itself.<h2>The Real Cost of Moving Data</h2>The cost of moving data is now a dominant factor in system design, both in terms of energy and performance.Accessing data from memory can consume significantly more energy than performing arithmetic operations on that data [2] [3]. As system complexity increases, this imbalance becomes more pronounced, making data movement a primary contributor to overall power consumption.This leads to several interconnected system-level challenges:<ul><li>Energy consumption: Data movement can account for a large share of total power usage, particularly in data-intensive workloads</li><li>Latency: Delays in data delivery reduce effective compute utilization and increase idle cycles</li><li>Throughput limitations: Bandwidth contention between multiple agents constrains overall system performance</li></ul>Traditional interconnect approaches, such as shared buses or simple point-to-point links, do not scale effectively under these conditions. As the number of components grows, these approaches introduce contention, congestion, and inefficiencies that limit performance gains.Industry discussions increasingly frame this as a “data movement problem,” where optimizing compute alone is insufficient. Instead, improving how data flows through the system becomes essential for achieving performance, efficiency, and scalability [4].<h1>Network-on-Chip as System Infrastructure</h1>To address these challenges, modern SoCs rely on network-on-chip (NoC) architectures. A NoC provides structured communication between components through routing, arbitration, and flow control mechanisms.Rather than serving as simple wiring, the NoC functions as core system infrastructure—much like a biological circulatory system distributes resources within an organism. It enables data to move efficiently between distributed compute and memory elements while managing contention and prioritization.The design of the NoC directly affects:<ul><li>End-to-end latency and quality of service</li><li>Achievable bandwidth and throughput</li><li>Power and energy efficiency of communication</li><li>Scalability as system complexity increases</li></ul>Because of this, NoC design is increasingly treated as an early architectural decision rather than a late-stage integration task. Early consideration allows designers to align compute placement, memory hierarchy, and communication topology more effectively.Companies specializing in interconnect IP, such as Arteris, have highlighted this shift across multiple SoC generations, emphasizing that NoC design is foundational to achieving performance, power, and scalability targets in complex systems [5]. <h2>Why This Matters Across Markets</h2>The constraints imposed by data movement are not theoretical—they translate directly into measurable system-level trade-offs across industries, affecting cost, performance, and efficiency:<ul><li>AI systems: Performance is frequently limited by memory bandwidth and data reuse efficiency. Even highly optimized accelerators can experience reduced utilization when data cannot be delivered efficiently, leading to underused compute resources [6].</li><li>Automotive systems: In addition to latency and isolation requirements, systems must comply with functional safety standards such as ISO 26262, including Automotive Safety Integrity Levels (ASIL). These requirements impose strict constraints on communication predictability, determinism, and fault isolation, making reliable data movement critical [7].</li><li>Edge and mobile devices: Tight power and thermal budgets mean inefficient data movement directly impacts battery life, thermal limits, and system responsiveness.</li><li>Data centres: Energy efficiency and total cost of ownership are increasingly influenced by how effectively data is moved and managed, rather than by raw compute scaling alone.</li></ul>Across these domains, inefficient communication infrastructure leads to higher costs, reduced throughput, and underutilized compute resources. Conversely, architectures that optimize data movement enable better system performance, improved energy efficiency, and more predictable behaviour. This is where specialized interconnect solutions, such as those developed by Arteris, help teams manage complexity, optimize data flow, and meet performance and efficiency targets.<h2>Takeaway: Data Movement Is Now an Architectural Concern</h2>The transition from compute-centric to data-movement-centric design represents a fundamental shift in SoC architecture.Data movement is no longer a secondary concern—it is a primary determinant of system performance, efficiency, and scalability. As compute resources continue to scale and diversify, the ability to deliver data efficiently has become just as important as the ability to process it.This makes interconnect design, and particularly network-on-chip architecture, a strategic decision that must be addressed early in the design process. Choices made at this stage influence not only performance and power, but also system flexibility, scalability, and long-term design viability.In this context, effective data movement becomes a key enabler and competitive differentiator for SoC teams, enabling them to better utilize compute resources, meet performance targets, and manage power and system complexity. Systems that can efficiently connect distributed compute and memory resources are better positioned to meet the demands of modern workloads across AI, automotive, edge, and data center applications.As SoCs continue to scale in complexity, the ability to design for <a href="https://explore.arteris.com/white-paper-flexgen" target="_blank" rel="noopener noreferrer">efficient data movement</a> will play a central role in defining next-generation system architectures.<hr /><h2>References</h2><ol><li>Hennessy, J. L., &amp; Patterson, D. A. (2019). Computer Architecture: A Quantitative Approach (6th ed.). Morgan Kaufmann.</li><li>Horowitz, M. (2014). Computing’s energy problem (and what we can do about it). IEEE ISSCC.</li><li>NVIDIA, “NVIDIA Hopper Architecture In-Depth,” NVIDIA, Mar. 22, 2022. [Online]. Available: <a href="https://resources.nvidia.com/en-us-hpc-ai/nvidia-hopper-architecture">https://resources.nvidia.com/en-us-hpc-ai/nvidia-hopper-architecture</a></li><li>EE Times Asia. The Data Dilemma: Cracking the Code of Data Movement for the Next Wave of Semiconductor Innovation.</li><li>Arteris. Data Movement in SoCs: NoC Performance, Power &amp; Scalability.</li><li>Jouppi, N. P., et al. (2017). In-Datacenter Performance Analysis of a Tensor Processing Unit. ISCA. <a href="https://doi.org/10.1145/3079856.3080246">https://doi.org/10.1145/3079856.3080246</a></li><li>ISO 26262. (2018). Road vehicles – Functional safety. International Organization for Standardization.</li></ol>

System on Chip Connectivity

ORGANIZATIONS. SHAPING THE INDUSTRY.

Latest Posts

New 64-bit RISC-V soft SoC for FPGAs with 8 GB DRAM reach

Network-on-Chip (NoC) Design Architectural Trade-offs

Engineer's Field Guide to Cellular IoT

Limiting Factor in Modern System-on-Chip (SoC) Design