Traditionally, NoCs didn\u2019t care what was going on outside the chip, because that was a link across a standard protocol such as PCIe. \u201cNow that it\u2019s die-to-die, you really want that network-on-chip to extend transparently across the die, and you\u2019ve got a whole new area of innovation to address that,\u201d said Posner. \u201cFor example, in the space of Nvidia GPUs, Arm wants to be the CPU next to it. How do you solve that? They\u2019re looking at die-to-die interfaces utilizing AMBA CHI C2C (chiplet-to-chiplet), and that is a cache-coherent interface which solves their problem.\u201d<\/p>\n
Verifying coherency
The mix of coherent and non-coherent traffic is particularly challenging.<\/p>\n
\u201cA coherent request reordered behind a non-coherent stream, or a credit returned on the wrong virtual channel, is not going to show up as a functional failure in simulation,\u201d said Ashish Darbari, CEO of Axiomise<\/a>. \u201cIt will show up as a deadlock at bring-up, months later, when the cost of finding it is enormous. NoC architects understand this on-die. The difficulty now is that with chiplets, the NoC boundary has moved to the package edge, where timing, retry semantics, and error handling are fundamentally different.\u201d<\/p>\n Compared to I\/O coherency, cache coherency is more difficult to implement. \u201cIt\u2019s also heavier to verify, because you have many more issues that are hard to find,\u201d said Frank Schirrmeister, executive director of strategic programs for system solutions at Synopsys<\/a>. \u201cDefining all the cases is completely non-trivial. You must be really careful about how you build the environment around that.\u201d<\/p>\n Massive multi-physics simulations, enabled by almost unlimited compute power, have made this more tenable over the past few years, but with some caveats. \u201cThe NoC tool has all the inputs, masses, initiators, and targets,\u201d explained Schirrmeister. \u201cThese are the connections. You look at it functionally, you simulate it, and then verification tools help figure out what the actual timing is. That\u2019s the physically aware bit that comes from the NoC provider, and it is where we see one of the significant challenges \u2014 the functional verification of coherency aspects. If you look at the differences between cache coherency and I\/O coherency, it took the smartest brains, from an architecture perspective, to articulate the test cases.\u201d<\/p>\n Much of this has pushed farther left in the design flow in recent years. \u201cInstead of having the user go in and say, \u2018Here\u2019s a test case,\u2019 which is hard to create manually, you say, \u2018Write something into this memory, figure out how much is in the cache, move it over to the other side, and now have an access coming from the software running on the second core to the same memory region,’\u201d Schirrmeister said. \u201c\u2018Then, determine whether the representation within the NoC knows where the last cache element is, and who has the last cache element.\u2019 It\u2019s a very intricate process.\u201d<\/p>\n This system for integrating different processors and automatically generating tests based on constraints is roughly in the same vein as Portable Stimulus, although it\u2019s not based on the PSS standard and focuses on cache coherency.<\/p>\n AI forces I\/O considerations Fig. 1: Example of a setup for Arm cache coherency validation. Source: Arteris<\/p>\n The problem space that needs to be addressed is huge. It involves huge numbers of lines, or physical wires, all of which need to be captured and characterized in simulations of NoCs and I\/Os.<\/p>\n \u201cIn the grand scheme of things, interconnects are not grossly difficult designs, but they\u2019re big,\u201d said Matt Commens, senior director of product management at Synopsys. \u201cThe computer-aided design is not really difficult, as it is typically on the larger catch meter mark and larger node size, but the number of lines is off the charts. What we\u2019re seeing is capacity, capacity, capacity. People want to simulate the entire interconnect of chiplets to study as many lines as possible, if not all. We\u2019re hearing directives from companies where every line has to be simulated. It can be done, but they tend to be pretty big simulations.\u201d<\/p>\n A single die or NoC can be simulated with one power map and clean boundary conditions. But that has to be set in the context of what else is happening in a chip or system.<\/p>\n \u201cA system of multiple dies and chiplets has superimposed, spatially-distributed power maps that thermally couple,\u201d said Satish Radhakrishnan, head of GTM for semiconductor and electronics at Vinci<\/a>. \u201cThermal activity in one chip raises its neighbors\u2019 baseline, and the global hotspot may not coincide with any single chip\u2019s local maximum. You cannot simply add up independent single-chip results. Therefore, capturing crosstalk and the effects of neighboring chips and stacks is essential. The boundary condition and cooling solution must also be evaluated as a whole system to capture the full heat transfer path.\u201d<\/p>\n This is where traditional simulations run out of steam. \u201cThe number of scenarios that matter at the system level \u2014 across different power states, stack configurations, and boundary conditions \u2014 makes sequential, specialist-run solves impractical as a design workflow,\u201d Radhakrishnan explained. \u201cThe ability to run physics continuously across the full chip-to-system stack, with deterministic and reproducible results, changes what is actually feasible to evaluate before architecture is locked.\u201d<\/p>\n Simulating NoCs is a multi-physics challenge \u201cYou cannot isolate one node and expect the result to hold,\u201d Radhakrishnan said. \u201cWarpage, low-K dielectric cracking, and delamination are also concerns driven by the system\u2019s transient thermal loading. The deeper challenge is that an accurate but slow solver can answer one physics question, but the NoC problem involves a large, uncertain design space of transient, coupled, multi-scale scenarios. Running enough of those cases to understand the design space \u2014 before committing to an architecture \u2014 requires a fundamentally different throughput model.\u201d<\/p>\n And since simulation is done at both the transaction level (SystemC) and RTL, it affects the ability to measure exact cycle-accurate bottlenecks. \u201cSystemC or transaction-level models (TLMs) are useful for early architectural exploration and high-level performance tradeoffs,\u201d said Axiomise\u2019s Darbari. \u201cBut RTL-level formal verification is required to prove cycle-accurate microarchitectural properties, such as exact credit behavior, arbitration delays, CDC (clock-domain crossing) safety, and packet progress. Simulation-side VIP is used for performance and directed testing, while formal must be used to handle exhaustive corner-case closure. This matters because many real NoC bugs arise from single-cycle races and implementation details that are invisible in transaction-level models. A balanced methodology uses TLM for architecture studies and RTL formal plus RTL simulation for implementation signoff and bottleneck diagnosis.\u201d<\/p>\n Formal verification Advanced packaging options also bring challenges. \u201cEMIB (Intel\u2019s embedded multi-die interconnect bridge, CoWoS (TSMC\u2019s chip-on-wafer-on-substrate), and hybrid bonding impose real constraints on bump pitch, redistribution, and thermal envelope,\u201d said Darbari. \u201cTeams used to treat packaging as something you handed off downstream. That doesn\u2019t work anymore. The choice between 2.5D and 3D affects the floorplan, the power delivery network, and this has serious implications for validation and verification. It has to be in the conversation from day one.\u201d<\/p>\n Further, when verifying NoCs, designers must ensure the chosen topology correctly connects all nodes and that packets follow the intended shortest or adaptive paths.<\/p>\n \u201cFormal verification can be used to prove structural connectivity and reachability for every legal source-destination pair in a mesh, torus, or custom topology, rather than sampling selected routes in simulation,\u201d said Darbari. \u201cIt can be done easily via the connectivity checking app exhaustively. For deterministic shortest-path routing, SystemVerilog assertions, properties, and models can be written so that each hop reduces the routing metric defined by the specification, such as Manhattan distance in a 2D mesh, while still preserving legal progress toward the destination. For adaptive routing, the routing logic can be constrained and proven to choose only among the architecturally permitted minimal or escape paths, ensuring that adaptive choices never become illegal or inconsistent with the routing policy. Symmetry-based reduction and induction on hop count are the practical techniques that make these proofs scale beyond toy topologies.\u201d<\/p>\n Flow control mechanisms, such as credit-based flow control, must also be verified to ensure that buffers do not overflow under saturation. \u201cCredit-based flow control can be verified by proving that the number of in-flight flits targeting a downstream buffer never exceeds the credit budget or physical FIFO depth,\u201d he said. \u201cProperties should ensure that credits are returned exactly when storage is freed, never early, never lost, and never double-counted, because misalignment in credit accounting is a common source of latent NoC bugs. These proofs can be run under saturation-focused assumptions so that even maximal legal traffic cannot cause overflow, underflow, or silent packet loss through backpressure failures.\u201d<\/p>\n Network behavior must also be simulated and verified during a fault, such as a buffer error or a dead router node. \u201cFault scenarios such as a dead router, stuck link, or buffer error can be modeled formally as non-deterministic fault injections within a specified fault model, allowing the verification environment to explore all placements and timings of the fault within scope,\u201d Darbari noted. \u201cFormal is great for fault modeling, as inherently it runs unconstrained and the non-determinism comes naturally to formal \u2014 something needed for fault injection, propagation and detection.\u201d<\/p>\n Testing and emulating NoCs \u201cThis includes assessing and fine-tuning your AI fabric to ensure that you\u2019re minimizing GPU idle times,\u201d said Razvan Arhip, product manager for AI and network test solutions at Keysight Technologies<\/a>. \u201cAnother factor is to observe the impact of scaling traffic to hundreds of ports on your AI fabric and on your protocol deployment.\u201d<\/p>\n Fig. 2: Challenges and tasks to test AI fabrics. Source: Keysight\/Collective Communication Library (CCL), ECN (Explicit Congestion Notification), PFC (Priority-based Flow Control), RoCEv2 (RDMA over Converged Ethernet version 2)<\/p>\n Impairment testing is a vital part of the process, particularly at the data plane. \u201cWe can delay, lose, or drop packets,\u201d said Arhip. \u201cWe can add jitter to the packets with the various combinations of patterns into the actual traffic to see how the actual protocols on top behave.\u201d<\/p>\n One of the main differences between the pre-AI era and the AI-era type of traffic is the frequency of incast network bottlenecks, which occur during many-to-one communication.<\/p>\n \u201cThere\u2019s a lot of incast inside the AI fabric in data centers, because after the GPUs take the data and perform operations on the data, they exchange traffic in various patterns, such as all-to-all, or reduce ring, and so on,\u201d said Arhip. \u201cWhen they start, there is a trigger that starts the traffic movement across the network, and there\u2019s a very high probability of seeing incast, of seeing congestion at the particular entry point inside the device that\u2019s being generated by that. We specifically want to emulate these particular moments in the network. First, we deploy the GPU clusters. Then we fire traffic at a specific moment in time. But we do not perfectly synchronize it, because there\u2019s no such thing in the real world. We randomize things between the endpoints, so although the traffic is synchronized between them, it\u2019s not at the nanosecond level. We have options to do that, but by default the traffic is not nanosecond-synchronized between endpoints.\u201d<\/p>\n NoC reliability: data center vs. auto \u201cTo become automotive-certified and to play in the automotive space, the methodology behind the design and verification, and your support of things like redundancy of error detection, of data protection, all of that goes much higher in automotive,\u201d said Kent Orthner, principal solutions architect at Baya Systems<\/a>. \u201cWith a lot of the big data centers that are doing AI, they anticipate that eventually, over time, chips are going to wear out. But you can\u2019t have that in your car. If you\u2019re doing self-driving cars, it really needs to recognize a pedestrian. You can\u2019t have any possible failures there. A lot of the challenge when it comes to automotive is making sure that the design of the NoC has extra bits on every data path to be able to detect errors and to notify the control plane immediately. Or, in some cases, there\u2019s redundant logic, so that you\u2019re running the same thing multiple times in parallel and comparing it. Then, if anything ever goes wrong, you can recover within nanoseconds. As we see more self-driving and driver-assist features, you\u2019ll see the inference engines running in cars pretty regularly.\u201d<\/p>\n Overall, many automotive data flows are similar to those in data centers. \u201cThis may not be quite on the scale that you see in data centers, which are huge refrigerator-sized boxes \u2014 but from the chips\u2019 point of view, they\u2019re still very capable chips,\u201d said Orthner. \u201cIt\u2019s just that safety now becomes front and center.\u201d<\/p>\n Fig. 3: Integrating various NoCs into a unified fabric that functions like an intelligent global NoC in multi-die systems. Source: Baya Systems<\/p>\n Conclusion Designers are developing a range of new solutions to verify, validate, simulate, and test network-on-chip designs to ensure that data traffic movement is not the reason a system fails. But the challenge of ensuring unhindered traffic movement in the context of a multi-die assembly and constant routing and rerouting of different types of data looms big in increasingly complex devices, particularly under varying workloads and in mission- and safety-critical markets.<\/p>\n Related Articles<\/p>\n Verifying Networks On Chip<\/a> I\/O Design Challenges Grow In AI Data Centers And HPC Clusters<\/a>
Regardless of whether a NoC is cache-coherent CPU-to-CPU, or non-coherent I\/O only, it must be considered in tandem with I\/Os. \u201cThe more AI you pack in, the more you\u2019re forced to treat the I\/O perimeter as a first-class system resource. Bandwidth density, latency determinism, congestion control, quality of service, and error containment become architectural constraints, not post-layout problems,\u201d said Andy Nightingale, vice president of product management and marketing at Arteris<\/a>. \u201cThat\u2019s where a scalable on-chip fabric and a system-level interconnect approach earn their keep. They make connectivity predictable across many endpoints, while giving engineers knobs for topology, buffering, ordering, and isolation so more I\/O doesn\u2019t automatically mean more chaos.\u201d<\/p>\n![\"\"](\"https:\/\/www.newsbeep.com\/ie\/wp-content\/uploads\/2026\/07\/NoC-1.png\")
<\/p>\n
NoCs typically have distributed heat sources, and that heat is transient in nature, dependent on workloads, chip and system architectures for dissipating that heat, and whether various cooling options are deployed. But it also is dependent on neighboring dies in a package, or chips in a rack, which can cause crosstalk, thermal or substrate noise, and electromagnetic interference, as well as mechanical stress that can result in warpage or turn latent defects into real defects.<\/p>\n
Formal verification also can play a key role in finding bugs in the state space for cross-protocol corner cases. \u201cFor example, UCIe link states, combined with CHI snoop transactions, combined with NoC arbitration is not something you can simulate your way through,\u201d said Axiomise\u2019s Darbari. \u201cFormal verification can prove credit conservation, deadlock freedom, ordering properties, protocol compliance at every interface. We\u2019ve been shifting formal left of simulation for exactly this reason. By the time a multi-die system is in emulation, a coherence or deadlock bug costs you a tape-out slip.\u201d<\/p>\n
Chips are becoming so complex that previously discrete steps in the flow are now overlapping. Test is already complex for AI chips, but achieving full coverage is becoming more challenging because the whole ecosystem is undergoing continuous change.<\/p>\n![\"\"](\"https:\/\/www.newsbeep.com\/ie\/wp-content\/uploads\/2026\/07\/NoC-2.png\")
<\/p>\n
Network-on-chips must operate optimally in data centers to support high-speed data movement and reduce heat generation. But in automotive applications, lives may be at stake.<\/p>\n![\"\"](\"https:\/\/www.newsbeep.com\/ie\/wp-content\/uploads\/2026\/07\/NoC-3.png\")
<\/p>\n
AI training and inference are only as fast as the networks transporting the data between dedicated processors and memory. Likewise, a software-defined vehicle is only as reliable as the networks that support communication between the zonal architecture.<\/p>\n
Challenges increase significantly with chiplets and coherency.<\/p>\n
Physical I\/Os can be a chokepoint for high-performance chips and high-speed interconnect protocols, requiring design tradeoffs and extra reliability measures.<\/p>\n