You are currently viewing SemiWiki as a guest which gives you limited access to the site. To view blog comments and experience other SemiWiki features you must be a registered member. Registration is fast, simple, and absolutely free so please, join our community today!
The increasing complexity of advanced driver assistance systems (ADAS) and automated driving architectures has driven a transition from traditional bus-based interconnects to scalable Network-on-Chip (NoC) fabrics. Renesas’ next-generation R-Car automotive SoC platforms adopt Arteris FlexNoC interconnect intellectual property to meet stringent requirements for performance, power efficiency, and functional safety. This deployment represents a critical architectural shift toward heterogeneous computing and software-defined vehicle (SDV) architectures in modern automotive electronics.
Arteris is a leading semiconductor IP provider specializing in NoC interconnect technologies designed to optimize on-chip communication between heterogeneous processing blocks such as CPUs, GPUs, NPUs, and memory subsystems. Its FlexNoC architecture uses packetized communication and distributed interconnect elements to reduce routing congestion, improve timing closure, and lower power consumption compared with traditional crossbar or bus-based fabrics. This approach enables scalable SoC designs capable of supporting AI-centric workloads increasingly required in automotive applications.
Renesas has integrated Arteris FlexNoC into its latest R-Car Gen-5 automotive SoCs, which target advanced ADAS and automated driving solutions. The interconnect fabric links Arm CPU clusters, GPU engines, and dedicated neural-processing accelerators, enabling efficient data movement across compute domains. This heterogeneous integration is essential for sensor fusion workloads where camera, radar, and LiDAR streams must be processed concurrently with minimal latency.
One of the primary motivations for deploying Arteris NoC technology in the R-Car architecture is performance scalability. Automotive AI workloads require deterministic bandwidth between processing elements and memory. The FlexNoC fabric provides configurable topology, quality-of-service (QoS) controls, and traffic prioritization mechanisms that allow real-time workloads to coexist with high-throughput AI inference pipelines. Renesas has indicated that this interconnect enables the performance and power efficiency required for Level 2+, Level 3, and future Level 4 automated driving systems.
Power efficiency is another critical design constraint in automotive SoCs, especially for electric vehicles where thermal budgets directly impact system cost and driving range. The next-generation R-Car X5H platform, built on a 3-nm automotive process, achieves approximately 30–35% power reduction compared with previous generation nodes. This improvement is partially attributed to efficient data routing and reduced interconnect overhead enabled by the NoC architecture. Lower power consumption also reduces cooling requirements and supports higher compute density within automotive electronic control units.
Functional safety compliance is equally important in automotive applications. The R-Car Gen-5 SoC is designed to meet ISO 26262 ASIL-D system-level safety targets, and the Arteris FlexNoC fabric incorporates safety mechanisms such as error detection, redundancy support, and fault isolation. These capabilities allow system designers to implement safety partitioning across compute clusters and maintain deterministic behavior under fault conditions. Such safety-aware interconnect design is essential for centralized vehicle compute platforms supporting autonomous driving.
Another significant advantage of the Arteris NoC deployment is scalability for chiplet-based architectures. The R-Car platform is expected to evolve toward multi-die integration to support increasing AI compute requirements. The FlexNoC interconnect supports chiplet extensions and high-bandwidth interfaces, enabling Renesas to scale AI performance beyond monolithic die limits. Reports indicate that chiplet extensions can boost AI performance by up to four times, illustrating the importance of a flexible interconnect backbone in future automotive SoCs.
From a system architecture perspective, the NoC approach enables Renesas to implement centralized domain controllers for software-defined vehicles. Instead of multiple distributed ECUs, a single R-Car SoC can handle perception, planning, and control workloads. Efficient on-chip communication is essential for maintaining low latency between sensor processing pipelines and decision algorithms. The Arteris fabric provides deterministic communication paths, ensuring predictable real-time performance required for safety-critical automotive systems.
Bottom line: The deployment of Arteris FlexNoC IP within Renesas’ next-generation R-Car automotive technology represents a key enabler for high-performance, scalable, and safety-compliant automotive compute platforms. By providing efficient data movement between heterogeneous processing engines, reducing power consumption, and supporting chiplet scalability, the NoC architecture aligns with the evolving requirements of AI-driven automated driving systems. This integration underscores the growing importance of advanced interconnect IP in modern automotive SoC design and highlights how communication fabrics have become as critical as compute engines in enabling next-generation vehicle intelligence.
I was invited to listen in on an event hosted by Fujitsu and Quantum Insider on the reality of Quantum Computing (QC) in financial services today. This market is a good test for QC since multiple possible high value applications have been suggested. The panel was chaired by Brian Lenehan, (Founder and Chair, Quantum Strategy Institute), with panelists Franco Severini (CTO Financial Services, Fujitsu), Philip Intallura (Head of Quantum, HSBC), Spencer Izard (Research Director, at industry analyst firm PAC) and Ellen Devereux (Quantum Computing Consultant, Fujitsu). Great opportunity to get past the hype and panelists did not disappoint – sharing guarded enthusiasm mixed with realism.
Quantum and finance – a deliberate, cautious approach
Our simplistic view of new technologies tends to binary choices: full-throttle adoption or wait-and-see, production-ready tomorrow or years in the future. Panel participants were much more thoughtful in balancing upside and downside risks, as you would expect in a domain where opinions can swing hundreds of billions of dollars.
Everyone agreed that there is significant promise in using quantum computers in finance for modeling probabilistic systems, for optimization and for quantum machine learning, and an eye on quantum risks around encryption which I won’t touch on here. There was equal agreement that hardware isn’t ready yet for production applications. What I hadn’t appreciated is the degree of preparation necessary in financial services to get ready for production.
Identifying use-cases for quantum starts with business priorities, not a library of standard quantum algorithms. Figuring out how quantum will fit into existing financial pipelines requires thought and planning. Staffing for expertise is another challenge. Where do you start – with QC experts or with quants (financial experts with deep mathematical and programming expertise)? Both face a steep learning curve, but the panel felt quants may be the better choice given their deep grounding in applications.
On this point it is important to understand a central challenge in applying QC in virtually any domain. What QCs do very well is to solve exponentially hard math problems in sub-exponential time. For anything else, control, data transport, even regular arithmetic, you’re much better off using a classical computer. Think of quantum as a specialized coprocessor attached to a classical computer. Algorithm development must start by figuring out an effective partitioning between these two systems. This task is non-trivial, even for an experienced programmer. Shor’s algorithm is a good example of this hybrid computation: mostly running in classical with a small (but exponentially hard) number theory problem running in QC.
Building teams of expert program developers will take time, and faces significant competition from other financial institutions. All panelists see accelerating wage inflation for such experts, not unlike competition for AI talent. I also sensed wide agreement, if not phrased this way, that QC in financial services starts by design with bespoke partner support. Fujitsu for example offers such services to build momentum around QC while learning about and preparing for high value opportunities, while also remaining nimble as tech and market needs evolve.
The point of QC is algorithm acceleration, but the level of acceleration that will be interesting is highly dependent on the application. One panelist said that quantum Monte Carlo for high dimensional derivative pricing today only shows quadratic advantage, which for him is not interesting. He needs exponential advantage to keep up with exploding problem sizes. In contrast, for applications supporting high volume transactional processes such as fraud detection, almost any level of performance improvement is interesting.
Overall, the view was that it will take 5 years to prepare good understanding of best targets, to optimize (hybrid) algorithms to meet those targets, and to staff up with experts able to manage technical algorithm complexities. Enough time perhaps for physical QCs to become ready.
For hype enthusiasts claiming 2026 QC is the year of quantum, yes financial services are making “measured investments” to get ready and are working with partners like Fujitsu to help develop expertise. But production deployment is generally agreed to be 5 years out and still cautiously funded.
Fujitsu and QC
I haven’t covered Fujitsu so far in my quantum series, but I now know that they are a serious contender and have been for some time. Their production QC supports 256 physical qubits. A 1,000-qubit system is planned for later this year with QEC (quantum error correction) sounding somewhat like the IBM approach. Users can access the technology through a hybrid quantum platform, supported by libraries to simplify development, also through classical-hosted quantum simulators.
Fujitsu is also collaborating with a company building on diamond spin qubits and reporting fidelity levels (difference between a noisy quantum state and the ideal state) among the highest today. Good for Fujitsu in spreading their bets, given proliferation of QC technologies. They have also announced interesting joint development with Osaka university which should allow them to dramatically reduce the number of noisy qubits required in certain calculations, extending the value of QC in the NISQ (noisy intermediate scale quantum) era.
I’m adding Fujitsu Quantum to my list of Quantum enterprises to watch.
Modern SoC design for artificial intelligence workloads has fundamentally shifted the role of the network-on-chip (NoC) from a simple connectivity fabric to a primary architectural determinant of system performance, power, and scalability. As compute density increases and heterogeneous accelerators proliferate, data movement increasingly dominates overall system behavior. Consequently, NoC architecture must be treated as a first-order design decision rather than a late integration step. The white paper Considerations When Architecting Your Next SoC: NoCs with Arteris emphasizes that modern AI SoCs face bottlenecks not in computation but in arbitration, memory access, and interconnect bandwidth, making NoC topology, buffering, and quality-of-service policies critical for achieving target performance metrics.
AI-centric SoCs differ from traditional designs in both traffic characteristics and integration complexity. Contemporary systems integrate CPUs, GPUs, NPUs, DSPs, and domain-specific accelerators, generating bursty and highly concurrent traffic patterns that are sensitive to contention and tail latency. These characteristics challenge traditional bus-based architectures and demand scalable NoC topologies capable of balancing throughput and latency. Furthermore, advanced process nodes increase wire delays and routing congestion, making physical implementation constraints tightly coupled to architectural decisions. As a result, topology selection must account for both logical hop count and floorplan feasibility, since physically long interconnects may negate theoretical performance advantages.
One of the most consequential architectural decisions in AI SoCs is the coherency model. Hardware cache coherency simplifies programming but introduces coherence traffic and scalability challenges, particularly with snooping and directory mechanisms. Software-managed coherency, by contrast, reduces hardware complexity and allows deterministic accelerator behavior, though it increases compiler and runtime overhead. Dedicated AI accelerators often favor software-managed memory to minimize unpredictable latency, while heterogeneous SoCs typically adopt hybrid approaches to maintain compatibility with legacy CPU clusters. This coherency choice directly influences NoC traffic patterns, arbitration logic, and memory hierarchy organization, demonstrating that interconnect architecture cannot be separated from system-level memory decisions.
Beyond topology and coherency, specialized NoC hardware units are essential for handling mixed workloads. Link-width adapters enable burst absorption and clock domain crossing, reorder buffers preserve transaction ordering across multiple targets, and QoS arbitration logic ensures latency-sensitive traffic is prioritized over bulk transfers. These features help maintain predictable latency under heavy load, which is crucial in AI systems combining control traffic with large tensor data movement. Without carefully designed QoS policies, critical real-time transactions may suffer starvation, leading to performance variability and degraded system efficiency.
Physical floorplanning also plays a major role in NoC design. Centralized interconnects may minimize logical complexity but can create routing congestion and timing closure risks, whereas distributed NoC implementations align better with partitioned floorplans and reduce long wire lengths. Early architectural modeling should therefore incorporate physically plausible assumptions, including clock domains, power partitions, and IP placement. Ignoring these factors often results in late-stage redesigns that increase schedule risk and engineering cost.
A structured methodology for NoC development further reduces implementation risk. Effective design flows begin with traffic modeling and high-level performance analysis, followed by topology exploration, floorplan alignment, pipeline insertion for timing closure, and validation through physical synthesis constraints. Iterative feedback between architectural modeling and physical implementation allows designers to converge on viable solutions before RTL commitment. Automation frameworks such as topology generation tools can further improve productivity, reduce wire length, and enhance latency by embedding floorplan awareness into the exploration process.
As SoCs scale, physical partitioning becomes unavoidable due to power domains, clock islands, and organizational boundaries. Partitioned NoCs must maintain connectivity while supporting isolation, retention, and reset sequences during power transitions. Coordinating these behaviors across domains is complex and must be addressed early to avoid functional and verification issues. Proper planning ensures that the NoC remains operational across low-power states and wake-up sequences without introducing deadlocks or data corruption.
Bottom line: Architecting a NoC for modern AI SoCs requires holistic consideration of traffic patterns, coherency models, topology, QoS mechanisms, physical floorplanning, and power management. Treating the NoC as a system-level design problem rather than a connectivity afterthought enables scalable performance, efficient power usage, and predictable implementation schedules in increasingly complex heterogeneous silicon platforms.
Daniel is joined by Dr. Wally Rhines, CEO of Silvaco, to discuss the Electronic Design Market Data report that was just released. Wally is the industry coordinator for the EDA data collection program called EDMD. SEMI and the Electronic System Design Alliance collect data from almost all electronic design automation companies globally and compile it by product category and the region where sales occurred. It’s the most reliable data for the EDA industry, providing insight into which design tools and IP are in highest demand worldwide.
Wally explains that Q4 of 2025 was another good quarter for EDA, with 10.3% growth compared to last year. Total revenue was $5.5B, placing the industry solidly over the $20B annual run rate for EDA. He also mentions that the last four-quarter moving average shows 10.1% growth, reflecting the continuing demand for EDA software. Dan then explores several details from the current report with Wally. The split between EDA tools and IP is reviewed with significant data suggesting shifts in IP acquisition strategies. The growth rates of the various segments of EDA are dicussed, along with an exception for growth in a particular region. Substantial changes in resolution enhancement orders are also discussed. Worldwide EDA employment is reviewed, which grew 13.8% compared to last year, with total employment now around 71.5K employees.
The views, thoughts, and opinions expressed in these podcasts belong solely to the speaker, and not to the speaker’s employer, organization, committee or any other group or individual.
FPGA prototyping and hardware emulation originated from two independent demands that emerged at roughly the same time, namely, the necessity to implement digital designs in reconfigurable hardware. This was conceivable given the newly introduced field programmable gate array (FPGA) device.
Yet from the very beginning they were driven by different motivations.
Hardware emulation emerged from the need to tame complexity. As integrated circuits grew larger, engineers could no longer rely on simulation alone to validate designs with millions of transistors. Emulation promised to overcome the simulation limitations, still allowing for controlled execution and powerful debugging.
FPGA prototyping, by contrast, grew out of the drive for speed and real-world execution. Its purpose was not primarily to debug signals deep inside the design, but to run the design fast enough to enable meaningful software development, system validation, and application workloads, long before silicon existed.
For decades, these two approaches lived in largely separate universes, shaped not only by distinct technical goals, but also by different engineering mindsets and even cultural identities. Emulation’s mindset sits on the engineer desk, a world of computer-driven waveform analysis and controlled verification workflows. Prototyping, by contrast, belongs to the lab bench, defined by the sensory reality of cables, hardware peripherals, and real-time execution.
The boundary between them has always been somewhat nebulous and poorly defined. Over time, however, market forces, customer demands, and the growing dominance of software-defined systems steadily pushed these paths closer together. Today, emulation and prototyping are no longer isolated disciplines. They coexist under a shared hardware-assisted verification (HAV) umbrella, increasingly complementary in workflows that span functional correctness, performance analysis, power validation, and full software-stack system bring-up.
Understanding how these two worlds rose, diverged, and ultimately began to converge is essential to understanding where verification is headed next.
The Origins of Prototyping: Breadboarding with Wooden Boards
My earliest memories of hardware design verification take me back more than four decades, to an internship I completed at SIT-Siemens in Milan, Italy. At the time, I designed and built a digital clock using discrete TTL logic, a project that became the subject of my doctorate thesis and the culmination of my electronic engineering degree.
Looking back, what is striking is how radically different the landscape was. In those years, design verification was not an industry buzzword. In fact, there was no verification industry at all. There were no standardized methodologies, no dedicated verification engineers, and certainly no sophisticated platforms for pre-silicon validation. Hardware was tested the only way engineers knew how: by physically building it.
Picture: Lauro Rizzatti and his digital clock
The dominant practice was breadboarding—literally constructing prototypes on wooden boards. Nails served as connection nodes. Wires were routed, wrapped, soldered, and adjusted by hand. The process required equal creativity, patience, and perseverance. Later, wooden boards would be replaced by wire-wrap boards, allowing for higher density and more complex routing, still all manual.
Eventually designers would use printed circuit boards populated with sockets and discrete components. This was progress, but it was hardly “rapid.” Each iteration often required new boards, careful assembly, constant troubleshooting, and the reality that debugging meant chasing elusive errors with physical instrumentation rather than inspecting signals with software tools. Prototyping was essential, but it was slow, costly, and highly errorprone. And a fundamental ambiguity always lingered: was the failure caused by the design itself or by the prototype implementation?
Field-Programmable Gate Arrays (FPGAs) to the Rescue
Everything changed with the arrival of the field-programmable gate array.
FPGAs introduced a novel idea: instead of rebuilding hardware every time the design evolved, engineers could map the design-under-test (DUT) directly into programmable silicon. With that shift, testing moved from a dirty-hands discipline—wooden boards, nails, solder, and hammers—to something far closer to a white-glove workflow.
Prototyping became cleaner, faster, and dramatically more scalable.
In many ways, FPGA prototyping was born directly from the hardware designer’s bench. It remained a hands-on, roll-up-your-sleeves craft, but now empowered by re-programmability and speed. Engineers could run real workloads, connect real peripherals, and observe system behavior at near real-time performance.
For the first time, validation could extend beyond synthetic test vectors. Systems could boot operating systems. Software teams could begin development before tape-out. Hardware could be exercised not only for correctness, but for integration realism.
This was the beginning of a new era: one in which verification was no longer confined to signal-level inspection but expanded toward system-level execution.
FPGA prototyping became the bridge between the abstract world of RTL and the concrete world of deployed electronic systems.
Emulation’s Parallel Rise: Debugging Designs Too Big to Simulate
While FPGA prototyping was taking shape on the engineer’s bench as a practical path toward speed, system validation, and early software execution, a different pressure was building elsewhere in the industry.
Designs were exploding in size.
Between the mid-1980s and early 1990s, the semiconductor landscape underwent a structural disruption. Driven by the relentless shrinking of transistor size and dropping cost, integrated circuits (IC) exploded from thousands of transistors to millions. Logic was no longer a series of isolated blocks; it was the entire system, condensed onto a single sliver of silicon.”
Table I: Intel x86 evolution: 1978–1989
Simulation, which had been the workhorse of verification, began to buckle under the weight of this complexity. Not just gate-level simulators, even hardware-description-language (HDL) simulators introduced in the 1990s were becoming increasingly slow. Despite the remarkable progress in compute power, the gap between design size and simulation throughput widened year after year. Furthermore, as designs grew in size, the number of test cycles required to validate them expanded exponentially, stretching the verification schedule beyond tape-out. Comprehensive fault analysis became increasingly out of reach.
It was in this context that hardware emulation emerged—not from the desire to run software fast, but from the need to verify hardware deeply, systematically, and with control. Emulation was born as an answer to complexity.
Two Different Philosophies: Visibility Over Speed
From the beginning, FPGA prototyping and emulation embodied two fundamentally different philosophies. Where prototyping prioritized execution speed and system realism, emulation prioritized control, observability, and debugging.
FPGA prototypes could run rather fast, often at tens or even hundreds of megahertz, but they were notoriously opaque. Once a design was mapped into a sea of programmable logic, internal signals became difficult to access, waveform visibility was limited to compiled internal probes, and debugging required painful recompilation of new or additional sets of probes. Prototyping excelled at-speed execution and early system bring-up, but not necessarily at uncovering the root cause of elusive failures buried deep inside the design.
Hardware emulation, by contrast was conceived as a verification instrument: a specialized platform designed to execute hardware models orders of magnitude faster than simulation, while still preserving the introspection, controllability, and determinism mandatory to carry out debugging quickly and reliably. They were built from the ground up to support the verification workflow. They provided deep signal visibility, full-state capture and replay, non-intrusive tracing, controlled execution with breakpoints, and rapid debug iteration. Their primary purpose was to find and fix bugs, whether deep within complex RTL or at the hardware/software interface, making emulation the natural domain of verification engineers rather than system integrators.
These distinct philosophies were also reflected in operating modes and deployment.
Early emulators often ran in in-circuit emulation (ICE) mode, cabled directly to target systems and driven by real external stimulus. Over time, emulation evolved toward increasingly virtualized environments, integrated with software testbenches, transaction-level models, and hybrid simulation flows. Typical emulation speeds remained in the low single-digit megahertz range—fast enough to escape simulation’s limits but still optimized for observability rather than throughput.
FPGA prototyping, on the other hand, prioritized real-time performance and physical connectivity. It was most effective for designs and subsystems that could fit within a few single-digit FPGAs, enabling extensive software development and interoperability testing long before silicon availability. Prototypes were designed to operate directly with real-world interfaces such as PCIe, USB, Ethernet, and DDR memory, delivering near-system-speed execution.
Organizationally, emulation became a centralized, shared resource: a large platform managed by specialists and accessed by distributed teams of verification and software engineers worldwide for deep-dive debugging and pre-silicon software bring-up. Prototyping, conversely, often lived on the hardware designer’s bench as a hands-on, roll-up-your-sleeves discipline optimized for speed, connectivity, and early system validation.
Separate Markets and Vendor Ecosystems
For many years, these two worlds were served by different vendor ecosystems.
The emulation market was dominated by the large EDA companies, whose platforms were tightly integrated into enterprise verification flows. FPGA prototyping, meanwhile, thrived in a vibrant “cottage industry” of smaller, specialized firms. These companies provided high-performance FPGA boards, mostly used industry standard FPGA compilers, and practical tools aimed squarely at hardware engineers and system developers.
The separation was not only technical, but it was also commercial, cultural, and organizational.
The Commercial Convergence of Emulation and Prototyping
Around 2010, a significant market convergence began to take place. Recognizing the strategic importance of owning the entire HAV continuum, major EDA vendors began acquiring the smaller prototyping players. As a result, the “cottage industry” largely disappeared, and today prototyping solutions are offered primarily by the same three major EDA vendors that dominate emulation.
This consolidation fueled a long-held industry ambition: a single unified hardware platform that could serve both purposes. An ideal “one machine that does both” that could be configured as a high-visibility emulator or a high-performance prototype “with the push of a button.”
Vendors have made real progress toward this vision, with offerings such as Synopsys’s EP-Ready (Emulation and Prototyping) systems, originally announced in 2025. In the spring of 2026 Synopsys then doubled down on this strategy by making all of their hardware systems now ‘Software-defined’.
Even unified platforms still require significant manual effort to transition between emulation-style instrumentation and prototyping-style performance. This highlights a crucial truth: the convergence has been primarily economic and commercial, not yet fully technical.
The fundamental engineering tension persists. The deep, intrusive instrumentation required for effective emulation is often at odds with the non-intrusive, high-speed, real-world operation demanded by prototyping. The “push-button” dream remains elusive because it requires solving this core conflict through advanced automation, smarter compilers, and more seamless workflow integration, challenges the industry continues to confront.
Conclusion: From Wooden Boards to Full-Stack Verification
The journey from wooden breadboards to white-glove verification platforms is more than a technological progression. It reflects how the semiconductor industry itself has evolved, from manual construction to programmable prototyping, through industrial-scale emulation, and now into full-stack system validation.
FPGA prototyping and emulation began as two separate worlds, shaped by different user goals, cultures, and constraints. Over time, driven by the unstoppable rise of software-defined systems and the unprecedented demands of AI-era computing, HAV has outgrown its original purpose.
Verification teams will continue to push the envelope across all software-driven use cases. What was once an elusive goal of performing them on a common HAV platform is steadily becoming reality, one software release at a time. If you are a user of these new software-defined platforms, I am curious how are they working out for you?
Everyone has been treating Intel as a turnaround story. What if it’s not a scheduled airline — but a charter, and Musk is the one filing the flight plan? Not just Tesla. Companies like Microsoft, Google, Meta, and Oracle are all designing their own silicon now, and their AI infrastructure depends on it. And yet they remain dependent on TSMC for leading-edge supply — one choke point, and it’s tightening. They need a second source. They just haven’t had a credible one.
Then comes the Intel–Musk signal, a short statement with volumes left unsaid. But the direction it points is interesting. It doesn’t look like a supplier building capacity and then going out to find customers. It looks like a customer moving to shape his own supply.
It’s something more like Jensen Huang and NVIDIA committing to capacity at TSMC ahead of availability, aligning their roadmap to future supply rather than waiting for it. TSMC built to that demand, and NVIDIA’s access to leading-edge capacity became a competitive moat. The brilliance people celebrate today is work someone else perfected earlier — and better.
Around 2010, Apple began quietly shifting its foundry strategy away from Samsung and toward TSMC, committing volume and roadmap alignment in exchange for process priority. By most accounts, Apple pushed for more aggressive node transitions and committed to significant volume, giving TSMC the confidence to invest heavily in new capacity and process technology. Apple was securing priority.
From that point forward, Apple consistently had first access to new nodes and, at times, the ability to ramp at scale ahead of other customers. Its volume and cadence helped shape TSMC’s roadmap, influencing both process transitions and advanced packaging technologies. Apple’s relationship with TSMC evolved into a partnership rather than a traditional supplier arrangement. They helped shape the factory.
Intel had its own opportunity in that moment. Under Paul Otellini, Intel chose not to pursue the foundry relationship on Apple’s terms. While TSMC built foundry and roadmap for customer demand, Intel did not. Intel’s decline began when it drifted away from the manufacturing-centric leadership that once defined it. Under Andy Grove and Craig Barrett, Intel’s fabs were the company’s identity. When that lineage ended, leadership shifted toward sales, finance, and product thinking.
Manufacturing moved off center and investments lagged. The 10nm collapse epitomized both. The culture that treated process technology as sacred began to erode. TSMC’s ascent wasn’t a symptom of Intel’s leadership drift, but its consequence. By the time Intel acknowledged it had fallen behind, the damage was deep. The broader ecosystem had aligned around TSMC’s design flows and packaging standards. Intel became increasingly isolated.
When Lip-Bu Tan arrived, the definition of the problem changed. Tan isn’t a fab operator, but he understands the semiconductor ecosystem in a way Intel hadn’t seen in decades. His experience spans EDA, IP, venture investment, and deep relationships across TSMC, Samsung, and the fabless world. Under him, the foundry effort shifted to manufacturing execution.
That made Kevin O’Buckley’s exit inevitable. The role he was hired for, making foundry a customer-facing business, no longer matched the one that emerged. When he moved on, Tan used the transition to reset the foundation — elevating Naga Chandrasekaran, a manufacturing veteran, and beginning the work of rebuilding credibility.
The focus now is making Intel’s fabs relevant. Tan is trying to rebuild the manufacturing discipline Intel walked away from. Musk is offering him a reason to move faster: a committed domestic customer whose roadmap depends on execution and has no patience for excuses — exactly when geopolitical pressure is making U.S. foundry capacity a strategic imperative.
Like Apple before him, Musk isn’t just buying chips. He’s filing the flight plan. Intel has lived with the consequences of saying no once before. If Musk moves first, he likely won’t be alone for long. Any hyperscaler watching a credible U.S.-based foundry being pulled forward by a major customer will want exposure to that model. Each can commit independently — through capacity agreements, co-development, or direct investment — and align it with broader strategic and political priorities.
None of this works if Intel can’t execute. A bilateral deal is not a subsidy, and signaling does not fix a process node. The deal would force execution into the open, accountable to customers whose roadmaps depend on results. It forces execution into the open market to customers whose roadmaps depend on results. TSMC thrived under that pressure because it was built for it. Intel is being asked to become something it has historically resisted being, a foundry for hire.
If AI demand continues to outpace supply — and if control over silicon becomes as strategic as control over data centers — the question becomes who moves first to shape what semiconductor manufacturing becomes. Intel put out a single tweet. But did it get the business?
Hardik Kabaria is the founder and CEO of Vinci, a frontier lab building systems that make physical reality continuously computable.
While software has become programmable, physics has remained episodic—accessed through discrete simulations and approximations. Vinci is changing that. Under Kabaria’s leadership, the company is building the first system in what is emerging as continuous physics infrastructure, where physics is no longer simulated but continuously computed.
At its core is a deterministic, solver-grounded physics foundation model that operates directly on manufacturing geometry without reliance on customer data. The system is already embedded inside semiconductor engineering workflows, continuously computing thermal and mechanical behavior as designs evolve.
This eliminates simulation as a gating event in engineering workflows—shifting physics from a bottleneck to an always-on constraint, and enabling companies to reach manufacturable, high-yield designs in fewer cycles.
Tell us about your company.
At Vinci we have created what we believe is the first production-deployed physics foundation model for engineering workflows.
Our platform performs deterministic, solver-accurate physics simulation directly on native design and manufacturing geometry, enabling engineers to evaluate real semiconductor and electronics designs without the manual setup and simplifications that traditionally limit simulation workflows. In practice this allows teams to evaluate orders of magnitude more design scenarios — often up to 1,000× more simulations within the same engineering time window.
Today the platform is deployed at more than a dozen semiconductor and electronics organizations and is being used on real development programs.
The broader goal is not simply to make simulation faster. It is to make high-fidelity physics operational inside everyday engineering decisions.
In most organizations today, physics simulation remains episodic. It occurs at specific validation checkpoints, typically executed by highly skilled and scarce specialists, and often after major architectural or design choices have already been made. As systems become more complex, that model becomes increasingly difficult to scale.
Our view is that engineering is entering a new architectural phase where physics foundation models become a core layer of engineering infrastructure, much the way numerical solvers became foundational during the previous generation of CAE. In that world, engineers are no longer limited to isolated simulation runs — they can continuously query physical behavior across designs, materials, and operating conditions, making physics reasoning a far more accessible part of everyday engineering decisions.
What problems are you solving?
The fundamental constraint today is not whether physics simulation works. It does.
The constraint is who can use it, how often, and at what point in the workflow.
Across roughly $4 trillion of global hardware development, physical decisions are still gated by about one million specialists worldwide who know how to run complex simulation workflows. That creates a structural bottleneck.
Design teams are moving faster, even as the systems they build become dramatically more complex: single-digit nanometer features on centimeter-scale substrates, heterogeneous material stacks, and tightly coupled designs assembled from components supplied by multiple vendors. Yet the physics validation process remains largely manual, specialist-driven, and reliant on legacy simulation tools that were never designed to scale with the pace and complexity of modern hardware development.
The result is that teams explore less of the design space than they ideally should, and critical physical insights often arrive later than they need to. In practice this means engineers cannot evaluate as many package and die configurations as they would like, test boundary conditions and power envelopes systematically, or identify thermal sensitivities early in the design cycle. Reliability risks that could have been caught earlier instead propagate downstream into later validation stages, where they are much more expensive to diagnose and fix.
Our goal is to change the economics of physics reasoning.
On real semiconductor workflows, engineers using Vinci have been able to evaluate hundreds to thousands of design scenarios in the time traditional processes might support a single run. When that happens, physics stops being a bottleneck and starts becoming something teams can use continuously during design exploration.
That shift is ultimately much more important than raw simulation speed.
What application areas are your strongest?
Our strongest initial applications are in semiconductor and advanced electronics, particularly thermal and thermo-mechanical behavior. These are some of the hardest physics environments in engineering: extremely dense geometries, complex materials, tight tolerances, and direct consequences for performance and reliability. Thermal behavior, warpage, and mechanical stress are not secondary concerns in modern systems. They affect packaging, yield, reliability, and long-term performance.
We chose this domain intentionally because it is one of the most demanding proving grounds for physics computation. If you can run deterministic, solver-accurate physics on real semiconductor designs at manufacturing resolution, you are solving a problem class that sits near the frontier of engineering simulation. From there, the platform can expand across additional physics domains and into other hardware industries where similar bottlenecks exist.
What keeps your customers up at night?
Physical validation is non-negotiable in hardware development, but the workflows around it do not scale well with the pace and complexity of modern design. Each design change can trigger a chain of setup work, coordination between teams, and delays before engineers receive a trustworthy physics answer. As systems become more complex, those delays become more costly and limit how often teams can explore the design space. Engineers usually know the physics questions they want to ask, but they cannot ask them frequently enough or early enough in the design cycle. What they ultimately want is not just faster simulation, but physics that is reliable, repeatable, and available early enough to shape design decisions rather than simply validate them afterward. That is the gap Vinci is focused on closing.
What does the competitive landscape look like and how do you differentiate?
There are three broad approaches emerging in this space.
First are the traditional CAE and EDA simulation platforms that have powered engineering analysis for decades. These systems are extremely capable, but they were architected for workflows where simulations are run intermittently by specialists rather than continuously across the development process.
Second are research efforts and startups applying machine learning techniques to physics problems, often by training surrogate models on large datasets generated from simulations or experiments. These approaches can work well in narrow problem domains, but they typically require significant training data and retraining as conditions change. That can be challenging in semiconductor environments where design data is highly sensitive and design spaces evolve rapidly.
The third category now emerging is physics foundation models designed to operate as engineering infrastructure, and that is the direction we are focused on. The idea is not to build a separate model for every domain or dataset, but a single physics model capable of deterministic reasoning across many designs and operating conditions. Our platform runs directly on native design and manufacturing geometry, produces solver-grade deterministic results, and can be deployed securely behind the customer’s firewall without requiring training on proprietary design data.
That distinction is critical. Engineering organizations cannot rely on tools that behave probabilistically or require retraining on sensitive design data to produce credible results. For physics to become operational inside real development workflows, the system must maintain the determinism, traceability, and validation standards engineers expect from established solvers, while also delivering the advantages AI makes possible: dramatically greater simulation throughput, the ability to explore much larger design spaces, and physics reasoning that can be applied continuously across many scenarios rather than only during isolated analysis runs. That is the challenge we have focused on solving.
You mention Physical AI. Can you explain the difference between that and what you provide with Physics AI?
The terms sound similar, but they refer to two very different parts of the technology stack.
Physical AI generally refers to AI systems that perceive and act in the physical world — robotics, autonomous vehicles, drones, and other embodied systems. The focus there is decision-making and control in real environments.
Physics AI, by contrast, is about computing how physical systems behave. It applies machine learning and advanced numerical methods to predict thermal behavior, structural stress, fluid dynamics, electromagnetics, and other physical phenomena inside engineering designs.
In practice, physics AI sits earlier in the lifecycle. Before a robot moves, a vehicle drives, or a chip is manufactured, engineers need to understand how the system will behave physically under real operating conditions. Physics AI helps compute those outcomes before hardware is built.
Our focus at Vinci is on that second category — enabling engineers to reason about physical behavior directly on their designs with deterministic, solver-grade accuracy.
What new features or technologies are you working on?
Our roadmap is centered on three areas: scale, physics coverage, and operational integration.
First is scale. We want engineers to be able to evaluate far more scenarios than has historically been possible. When teams can run orders of magnitude more simulations, they can explore the design space much more thoroughly.
Second is expanding the physics domains we support while maintaining solver-grade fidelity.
Third is reducing the operational friction between design inputs and validated outputs so the platform can be used naturally inside real engineering workflows.
The long-term direction is straightforward: physics that is continuous, composable, and operational across the development lifecycle, rather than an isolated analysis activity.
How do customers normally engage with your company?
Most engagements begin with a specific workflow bottleneck.
A team will identify an area where physical validation is too slow or difficult to scale — often in thermal or thermo-mechanical analysis.
We then run Vinci directly on their real designs and compare the outputs against the baselines they already trust. That step is important because engineers want to verify that the results are deterministic and consistent with established methods.
Once that trust is established, the conversation usually shifts.
Instead of asking whether a single simulation can run faster, teams begin asking how much more physics they could evaluate if the bottleneck disappeared.
That is typically when the broader implications of the platform become clear.
Marc Evans, Director of Business Development & Marketing, Andes Technology USA
I work at a RISC-V IP company, and I genuinely root for Arm — probably more than most people in my position would admit. Not because I’m confused about who competes with whom, but because Arm’s best move for their shareholders is also RISC-V’s biggest tailwind yet.
This isn’t really an Arm vs. RISC-V story. It’s a classic platform economics story: what happens when a neutral platform provider begins competing with the customers it enables.
The Value Chain Climb — and Why It Makes Sense
Throughout its history, Arm has steadily moved up the value chain — from CPU IP to system and GPU IP to full Compute Subsystems — capturing more silicon value at each step. More license fees, more royalties, more of the margin their customers were earning. Smart business. Logical business.
The economics are straightforward: IP licensing captures a thin but highly profitable slice of system value. Moving into silicon means competing for a much larger share of that system value — potentially orders of magnitude more revenue, at lower margin but far greater scale. For a public company under growth pressure, that math is compelling.
Now they’ve announced their AGI CPU with Meta as a lead customer, targeting a $100B TAM in datacenter CPUs. This is a smart move — and largely aligned with where the market was already going.
The hyperscalers were already moving off x86: AWS Graviton, Google Axion, Microsoft Azure Cobalt, Oracle on Ampere. Arm is formalizing that shift and taking direct aim at Intel and AMD.
This doesn’t meaningfully threaten Arm’s existing customer base. Hyperscalers at tier-1 scale have the volume and leverage to manage that relationship. Tier-2 players generally can’t justify the custom silicon investment regardless of who supplies the IP. Good for Arm shareholders. Good for the ecosystem. Cheer for it.
The Statement Worth Paying Attention To
But then came this, from Rene Haas at Arm Everywhere:
“There will be some tomorrows,” he said at Arm Everywhere, “And we think this opportunity to take the work we’ve done across all of the markets — as you’ve heard in the videos from edge to cloud, from milliwatts to gigawatts — we think we have an opportunity to address greater than a $1T TAM by the end of the decade.”
That’s the statement worth paying attention to.
Because that $1T TAM isn’t new market creation. It’s not x86 territory. It maps directly to Arm’s existing customer base: smartphones, automotive, industrial, AI acceleration, storage and networking, communications infrastructure.
The Structural Tension
Arm’s IP business was built on a model where they capture value because their customers succeed. Licensing revenue scales with their customers’ volume. The incentive alignment was clean — Arm wins when its customers win.
Moving into silicon in their customers’ end markets changes that alignment.
At sufficient scale, Arm’s silicon revenue competes directly with the revenue of the same companies paying their licensing fees. When silicon becomes the larger profit pool, which business gets the roadmap investment? Which gets the favorable terms?
That shift inevitably influences where engineering investment and long-term roadmap priority go.
That’s not a criticism. It’s just what the business model evolution implies.
When Switzerland Picks a Side
Arm’s entire IP business was built on being Switzerland. You could build on Arm and trust that your foundational CPU supplier wasn’t going to show up as a competitor in your end market. That neutrality had real value. Customers paid for it, designed around it, built long-term product roadmaps on top of it.
That Switzerland just picked a side. And that changes the relationship.
If you’re an automotive OEM trying to differentiate on processing, or an industrial company with a specific long-cycle compute roadmap, you now have to factor something into your planning you never had before: your strategic IP vendor is also a competitor with de facto first-mover advantage in your market, while simultaneously setting your license fees and royalty rates.
Those are design cycles measured in years and product investments measured in hundreds of millions. The risk doesn’t have to be immediate to be real. By the end of the decade — which is exactly the timeframe Haas cited — this becomes existential for some.
The New Switzerland
RISC-V is the new Switzerland — and it’s not entirely ironic that RISC-V International is incorporated in Switzerland.
Open standard, no license fees, no single entity controlling the architecture, no vendor who can pivot to compete with you. You can license a proven commercial implementation and differentiate however you need to — with full confidence that your IP supplier’s business model depends on your success, not on displacing you.
The risk profile is structurally different. That matters in a design decision with a five-to-ten year horizon.
What About the Software Ecosystem?
It’s a fair challenge, and I won’t oversell it. But the framing matters.
What made Arm ubiquitous was underwriting the full transition of the software world from x86 to a RISC architecture — operating systems, compilers, middleware, application stacks. That was a decade-long, industry-wide investment.
Moving between RISC architectures is a fundamentally different problem. The architectural model is established, tooling and abstraction layers exist, and the transition cost is a fraction of the original lift.
The RISC-V software base reflects that — Linux, Android, real-time OSs, and expanding AI and HPC frameworks are already in place for a broad set of real products shipping today.
More importantly: ecosystem maturity follows economic incentive. It always has.
If you’re starting a design today with a two-year horizon to production, the question isn’t where the RISC-V software ecosystem is right now. It’s where it will be when your product ships.
Arm’s move just poured accelerant on that timeline.
The Bottom Line
This isn’t about ideology. It’s about structural incentives — and those incentives are shifting in a way that is both predictable and significant.
So yes — go Arm. Build the chips. Capture that silicon TAM. It’s the right move for your shareholders and it’s genuinely good for the industry: competition at the silicon level raises the bar for everyone, and customers ultimately win with real choice.
But for the companies now rethinking their silicon roadmap — the ones doing the math on long-cycle design risk, differentiation strategy, and supplier alignment — this shift is no longer abstract. It’s something to plan around now, before the next design cycle commits you to a path.
Where This Discussion Is Happening
These questions are already being worked through in real silicon programs. RISC-V Now! by Andes is focused on exactly this transition — real deployments, real tradeoffs, and lessons from teams who have already made the move to production. Not standards. Not theory. What’s actually shipping, what worked, and what didn’t. If you’re doing serious roadmap evaluation, this is the room to be in. The next event is April 21 in Silicon Valley.
Daniel is joined by Dr. Sakya Dasgupta, CEO and founder of EdgeCortix. He is a seasoned technologist who has been at the forefront of artificial intelligence systems for the past two decades. His experience spans public research institutes such as The Max Planck Society and RIKEN, as well as leading corporations like Microsoft and IBM Research.
Sakya explains that EdgeCortix’s fundamental goal is to build the software and AI silicon together from the ground up. He explains that this strategy created the EdgeCortix SAKURA-II, the world’s most flexible and energy-efficient AI accelerator. Dan explores the history and application of this technology with Sakya. He explains that this compact, energy-efficient technology is well suited for AI applications at the edge. Sakya explains that the technology has also been proven in space, opening a new option for using commercial off-the-shelf technology in space exploration applications.
Dan also explores future work at EdgeCortix with Sakya, who describes chiplet-based technology for future products. You can learn more about this unique company here.
I’m Steve Kim, the CEO of Chips&Media. I’ve been immersed in the multimedia imaging industry for approximately two decades. Prior to joining Chips&Media, I spent over five years working within handset manufacturing companies. Following more than ten years here at Chips&Media in roles spanning Marketing, Sales, and Procurement, I was appointed CEO. I hold a Bachelor of Science in Electrical Engineering from the US, obtained in 1995, and subsequently completed my MBA studies in the US in 1997.
Tell us about your company.
‘Powering 3 Billion Devices Across 150+ Global Top-Tiers’
Chips&Media, headquartered in Seoul, Korea, is a Premium Multimedia IP company, including video codec, image processing NPU, frame buffer compression IP, and more. With over two decades of industry expertise and strong international collaborations, we are recognized for delivering dedicated, high-performance architectures optimized for memory bandwidth, power consumption, gate size, and reliability across various consumer applications.
Building on our proven success in diverse multimedia applications, we are expanding our footprint into overwhelming, including Automotive (IVI, ADAS, and Autonomous Driving), Cloud Data Centers, Robotics and AI accelerators. What sets us apart is our highly configurable and modular IP architecture, which empowers SoC designers to seamlessly select the optimal configuration for performance, power, and area (PPA) to best fit their target applications.
What problems are you solving?
‘High Performance, Low Power, Small Footprint’
We solve the core challenges of processing high-resolution video on resource-constrained edge devices. Our solutions compress high-quality video into the smallest possible size without loss and ensure smooth playback with minimal power consumption.
Ultimately, we satisfy our partners by delivering the “Triple Crown” of hardware design: High Performance, Low Power, and Optimized Area (PPA).
What application areas are your strongest?
‘Beyond Video Codecs: Leading the Future of Multimedia with AI-Powered NPU and FBC Innovation’
Building on over 20 years of proven expertise in the global video codec market, Chips&Media is solidifying its position in the multimedia IP industry.
Aligned with the latest trends in image processing, we offer real-time AI-driven video enhancement through our high-performance NPU IP. Furthermore, our FBC (Frame Buffer Compression) technology provides peak system optimization by effectively resolving DRAM bandwidth bottlenecks and eliminating the need for line buffers (SRAM) during data conversion. These innovations are the core drivers enabling us to deliver differentiated value as a comprehensive global multimedia IP provider.
What does the competitive landscape look like and how do you differentiate?
‘Powered by Technology, Proven by Performance, Trusted by 3 Billion Devices’
Currently, the multimedia IP market is structured around a competition between the general-purpose solutions of global EDA giants and the presence of region-based providers. However, as demand for AI and high-resolution video surges, the market is shifting.
Rather than a broad portfolio that simply lists features, there is now a stronger-than-ever demand for Deep-Tech specialized IP that delivers superior efficiency in specific domains. In response, Chips&Media is establishing a differentiated market position through three core strategic pillars.
1) Superior Tech Efficiency
– We provide industry-leading 8K60fps multi-standard video codecs that deliver superior image quality with minimal power consumption, offloading the host CPU to maximize overall system efficiency.
– Chips&Media has released the latest video standard IPs faster than anyone else in the market. We were the first codec IP provider for H.264/AVC, H.265/HEVC, AV1, APV and others; now, we are about to release our AV2 IP.
– Our FBC technologies minimize chip area by eliminating unnecessary line buffers (SRAM) and ensure real-time processing with ultra-low latency through its high-speed on-the-fly architecture.
– Our specialized image processing NPU maximizes MAC utilization through its efficient architecture. Its proprietary line-by-line processing technology drastically reduces DRAM bandwidth, enabling high-performance real-time video processing.
2) Committed to Functional Safety: On track to achieve ISO 26262 (ASIL-B) certification by 2026
3) Market-Proven Reliability:
We have secured over 150 global top-tier customers with a track record of more than 3 billion units delivered, while offering a wide range of customization options to meet specific customer requirements.
What new features/technology are you working on?
‘Driving the Future: AI Evolution and Ultra-High-Resolution Optimization’
We are focusing on three core innovations to lead the shift toward ultra-high-resolution data and AI evolution:
1. Next-Gen FBC (Memory Optimization):
Our latest FBC algorithms maximize compression ratios with minimal quality loss, drastically reducing system costs and power consumption by solving memory bottlenecks.
2. Image-Specific NPU (AI Efficiency):
Unlike general-purpose NPUs, our NPU IP (WAVE-N) architecture is optimized specifically for image processing, delivering exceptional performance with near-zero bandwidth consumption.
3. Versatile Portfolio & Customization (Multimedia IP Provider):
We offer high-performance video codec IPs adaptable to various industries, including Mobile, Automotive, and HPC. By providing flexible configuration to each client’s unique requirements, we continue to diversify our global portfolio.
How do customers normally engage with your company?
‘Business Model: License Fee + Royalty’
Our business model is built on a synergistic structure of license fees and royalties. Customers reduce development time through upfront licensing and subsequently share revenue with us through royalties as their products enter the market. This close collaboration has created a virtuous cycle, where over 90% of our clients consistently choose Chips&Media for their subsequent projects.
