Unified Emulation and Prototyping: Pipedream or Reality?

Preamble
Hardware-assisted verification (HAV) platforms, including hardware emulators and FPGA-based prototyping systems, are the two dominant methodologies for validating long workloads on complex System-on-Chip (SoC) designs before tape-out. HAV sits within a broader continuum of verification engines: simulation and formal methods are applied earlier, at the block and sub-system level, while post-silicon validation comes later. Historically, emulation and prototyping have been distinct product categories, each requiring its own capital investment, hardware platform, and tool flow.

What if emulation and prototyping could be two sides of the same machine, like Janus, the Roman god who faced two worlds at once? For years, the industry’s honest answer was simple: they couldn’t be. Synopsys challenges that long-standing assumption with a fundamentally different approach: a unified architecture capable of serving both emulation and prototyping from the same hardware platform. Synopsys’ EP-Ready architecture, significantly enhanced in 2026 with software-defined dual-mode switching, overturns this decade-old separation. A single hardware platform can now transition between high-performance emulation and FPGA prototyping without physical reconfiguration. Think of Apple’s Boot Camp letting one Mac run both macOS and Windows. This article introduces the key technical aspects of the EP-Ready architecture and analyzes its advantages over a multi-platform strategy.

1. Introduction

The verification gap continues to expand. Gate counts in leading-edge designs for data-center compute and AI training have crossed the 100 billion gates, while mainstream SoC designs range from one to twenty billion gates. At the same time, time-to-market windows continue to compress. In this environment, hardware-assisted verification platforms have become even more indispensable given that simulation alone cannot provide the throughput required to validate a modern SoC in a commercially viable timeframe.

Customer requirements differ sharply across the application domains these tools serve. Leading-edge data-center designs are approaching one trillion transistors within this decade, roughly 250 billion gates, in a single multi-die package, requiring the highest capacity, scalability, performance, and reliability. The AI workloads for datacenter computing and training demand long runs to enable pre-silicon performance and power analysis. In contrast, Edge AI, Physical AI, Mobile, Automotive, and Consumer designs are up to two orders of magnitude smaller in complexity and require even higher performance and real-world modeling of interfaces.

Two distinct HAV methodologies have historically served different phases in the verification cycle:

• Emulation, such as Synopsys’s ZeBu, verifies hardware-accurate models at multiple MHz-range clock speeds, supporting full software bring-up, power analysis, and debug-rich pre-silicon validation.
• FPGA-based prototyping, such as Synopsys’ HAPS, achieves clock speeds of 10–300 MHz, enabling real-time interface speed, application-layer testing, and high-speed I/O characterization.

Until recently, a team requiring both capabilities had to procure, install, operate, and maintain two separate hardware platforms. The Synopsys’ EP-Ready dual-mode system eliminates this duplication by software-defining the operating mode of a single FPGA-based HW platform, focused on a sweet spot of up 23 BG designs, which includes – besides Edge AI designs – sub-systems for data-center designs. For the highest capacity designs requiring capacity scalability beyond 60 BG, Synopsys recommends ZeBu Server 5.

2. EP-Ready Architecture

2.1 Foundational Hardware Architecture

The EP-Ready system is built on a direct-connect FPGA-based architecture. Rather than routing inter-FPGA signals through a central switch fabric, approach taken by many traditional emulators, EP-Ready boards establish point-to-point high-speed connections between FPGA devices. This architectural choice delivers several important technical results:

• Reduced interconnect latency: Switch-based architectures introduce deterministic but non-trivial latency at each hop, which accumulates across large multi-FPGA designs. Synopsys’ introduction of direct point-to-point connections avoid the additional routing and switching delays introduced by a centralized interconnect fabric.
• Bandwidth concentration: Point-to-point connections dedicate full link bandwidth to the connected pair, avoiding arbitration overhead and blocking inherent in shared switch fabrics.
• Scalability ceiling: direct-connect topologies are constrained by cable length and direct-connect systems today typically reach up to 4 racks. The EP-Ready architecture trades a limited top capacity, up to 24 BG, with even higher performance than FPGA-based emulation already provides over processor-based emulation.

2.2 The Dual-Mode Innovation

The pivotal 2026 innovation is the shift from hardware-defined to software-defined mode selection. Prior EP-Ready systems switched between emulation and prototyping by physically re-cabling the interconnect and installing prototyping interface cards, a process that took several days and was therefore performed only at procurement or at the start of a new project, when a team committed to shifting its emphasis from emulation toward prototyping to give software developers a faster platform.  The new architecture removes that physical intervention entirely:

• Pre-configured cabling topology: Systems ship with an optimized, fixed interconnect already installed. A single, highly symmetrical cabling pattern satisfies both use cases without modification.
• Pre-installed interface cards: All I/O interface cards for prototyping the project will need over its lifetime are populated in the chassis at initial installation, so no cards are added or moved during a mode transition.
• Software-orchestrated switching: Switching between the ZeBu emulation stack and HAPS ProtoCompiler, namely, re-programming the FPGAs, re-routing I/O to transactors or interface cards, and initializing the appropriate debug infrastructure, completes in minutes and can be repeated several times within a single working day.
• Preserved characteristics of each mode: The architecture retains the defining strength of each mode. Emulation runs with a fully synchronous, deterministic clock, which is what enables cycle-accurate debug visibility and power analysis. Prototyping runs with an asynchronous, free-running clock that reaches far higher speeds (HAPS-200 targets ~50 MHz), which is what makes long software workloads and high-speed interface validation practical.
• Day-to-day flexibility: In practice, a team can run emulation on Monday, switch to prototyping for high-speed I/O validation on Tuesday, and revert for regression closure on Wednesday.

2.3 Performance Characteristics by Mode

The performance delta between EP-Ready prototyping mode and a dedicated prototyping system stems from cabling topology. In a true prototyping system, inter-FPGA cabling is routed to minimize latency paths for the specific design partition, reducing routing congestion and maximizing usable FPGA resources. The EP-Ready fixed cabling accepts a modest performance penalty in exchange for mode flexibility — a trade-off that is favorable for the vast majority of verification tasks.

3. Market View: EP-Ready vs. Dedicated Emulation and Prototyping Platforms

3.1 What else is out there

Each of the major HAV vendors takes a distinct approach to the market. Synopsys anchors the high-capacity end with the ZeBu Server architecture, while its EP-Ready hardware serves designs up to ~24 BG by running both the emulation (ZeBu) and prototyping (HAPS ProtoCompiler) software stacks on a single FPGA-based platform. See Figure 2.

Cadence pursues a two-platform strategy unified by a shared compiler and common virtual and physical interfaces. The processor-based Palladium Z3 delivers debug-rich emulation on Cadence’s custom emulation processor at comparatively low execution speed, while the FPGA-based Protium provides higher-speed, prototyping-class runs with lighter debug. Congruency between the two lets a design move quickly from one to the other: a bug first seen on the fast Protium system can be reproduced on Palladium, where lower speed and deeper visibility enable root-cause isolation. The pair scales to tens of billion gates but spans that range with two distinct hardware architectures rather than one reconfigurable platform, and therefore a larger overall footprint.

Siemens offers a three-tier portfolio unified by a common OS and compiler. Veloce Strato CS handles emulation on Siemens’ purpose-built emulator chip, not a commercial FPGA, which gives it predictable compile times and deep debug visibility. Veloce Primo CS handles enterprise prototyping on commercial FPGAs, trading some debug depth for higher execution speed, and Veloce proFPGA CS targets software prototyping on the same FPGAs. Emulation and enterprise prototyping each scales to tens of billion gates. Collectively these systems span much of the EP-Ready use-case range but split it across a custom-silicon emulator plus two FPGA-based prototyping platforms, again, considerably more distinct hardware than a single reconfigurable EP-Ready system.

3.2 Technical Advantages of EP-Ready

3.2.1 Infrastructure Consolidation

Running separate emulation and prototyping systems, the norm for both Cadence and Siemens, carries recurring operational overhead. Each additional platform brings its own:

• Power distribution and dedicated circuits
• Cooling infrastructure, including liquid cooling on the larger systems
• Network and system-management interfaces
• Rack space in the lab or data-center environment

The EP-Ready architecture folds emulation and prototyping onto one physical platform, so this overhead is provisioned once rather than duplicated per use case. For organizations with constrained lab or data-center space, that consolidation is often the deciding factor.

3.2.2 Scheduling and Utilization

In a conventional two-platform environment, hardware utilization is tied to the verification phase. Emulation dominates during pre-silicon RTL closure; prototyping dominates during embedded software validation. Because the two functions live on physically distinct hardware — a custom-silicon emulator paired with a separate FPGA prototyping system, in both the Cadence and Siemens portfolios — neither box can absorb the other’s load. Teams routinely find one platform oversubscribed while the other sits idle, and that idle capacity cannot be repurposed.

EP-Ready removes that inefficiency. Because emulation and prototyping run on the same FPGA-based hardware, a single investment tracks the project’s evolving needs: a team can dedicate all its capacity to emulation during aggressive RTL closure, then reallocate that same hardware to prototyping for software validation with no additional purchase. And since a mode switch takes minutes rather than a procurement cycle, rebalancing isn’t a one-time, per-phase event — capacity can be re-split as often as daily as RTL-closure and software-validation demands rise and fall.

3.3 HAV Market re-segmentation

The EP-Ready innovations also re-segment the prototyping market. For the large majority of designs and use cases, the pre-installed dual-mode cabling delivers sufficient performance. A narrower class benefits from more: when the interface logic under test fits within one or two FPGAs, that’s on the order of 120 million gates, a set of optimized, direct point-to-point cable connections can raise the prototype clock above 100 MHz, well beyond the platform’s baseline. That headroom matters for bringing up high-speed interfaces at-speed rather than at a divided-down clock. For example, exercising a USB high-speed link (480 Mbps) or a comparable serial interface fast enough to validate real link-level behavior.

3.4 Financial Benefits

At the time of an HAV capacity purchase, the budget owner cannot know what split between emulation and prototyping will prove optimal over the system’s five-year depreciation life. In a two-platform world, that uncertainty carries a cost: unable to predict the split, buyers hedge by over-provisioning both platforms, and the excess capacity depreciates whether or not it is ever used. EP-Ready removes the guess. Because the same hardware can be reassigned between emulation and prototyping at any point in the verification and validation flow, the buyer sizes total capacity once and lets the mode split follow the project, rather than committing to a fixed ratio at purchase and paying for whichever half turns out underused.

Conclusions

The Synopsys EP-Ready dual-mode architecture represents a significant shift in both the economics and execution of HAV. By introducing software-defined switching between emulation and prototyping on a single FPGA platform, eliminating physical re-cabling and hardware reconfiguration, Synopsys’ EP-Ready resolves a structural inefficiency that has plagued the HAV market for decades.

This architectural unification delivers two pivotal advantages:

• Capital Flexibility: Budget owners no longer must guess the optimal split between emulation and prototyping capacity across a five-year depreciation cycle, eliminating the risk of costly over-provisioning..
• Operational Efficiency: Engineering teams shed the schedule drag of hardware conversion. Switching a system’s role takes only a software command, seamlessly adapting the infrastructure to immediate project demands on-the-fly.

The EP-Ready architecture does not make dedicated emulation and prototyping obsolete. It changes the purchasing decision for the up to 23 BG market of HAV by allowing organizations to trade some peak specialization for greater flexibility, utilization, and capital efficiency!

References

1 From Wooden Boards to White Gloves: How FPGA Prototyping and Emulation Became Two Worlds of Verification… and How the Convergence Is Unfolding by Lauro Rizzatti, SemiWiki 04-13-2026

Also Read:

From Detection to Safety: Reframing Fault Simulation for Functional Safety

When Software Outruns Silicon: Hardware-Assisted Test Generation to the Rescue

The Great Divide: A Tale of Three Hardware Emulation Architectures

Share this post via:

• 
• 
• 
•