The Rise, Fall, and Rebirth of In-Circuit Emulation: Real-World Case Studies (Part 2 of 2)

Recently, I had the opportunity to speak with Synopsys’ distinguished experts in speed adapters and in-circuit emulation (ICE). Many who know my professional background see me as an advocate for virtual, transactor-based emulation, hence I was genuinely surprised to discover the impressive results achieved by today’s speed adapters critical to the validation of system in their actual use environment.

In this article, I share what I learned. While confidentiality prevents me from naming customers, all the examples come from leading semiconductor companies and major hyperscalers across the industry using ZeBu® emulation or HAPS® prototyping together with Synopsys speed adaptors. As you read through the article you can refer to the following diagram of the Synopsys Speed Adaptor Solution:

Figure 1: Deployment diagram of Synopsys’ Speed Adaptor Solution and System Validation Server (SVS)

Case Study #1: The Value of Combining Fidelity and Flexibility in System Validation

The Challenge

A major fabless semiconductor company adopted virtual platforms as well as Hardware-Assisted Verification (HAV) platforms to accelerate early software development and design verification.

The company’s operations were organized around three distinct business units, each responsible for designing its own silicon independently. Each unit selected a different major EDA vendor for its virtual host solution platform. At first glance, such a multi-vendor setup might seem fragmented, but because virtual platforms are generally built on similar architectural blueprints, the approach still resulted in a verification environment that was consistent and standardized across all three BUs.

Alongside these virtual setups, the engineering teams also adopted In-Circuit Emulation (ICE). Here again, they diversified their tools, sourcing speed adapters and emulation from two of the three major EDA vendors. This allowed them to carry out system-level testing, interfacing the emulated environments with real hardware components to validate behavior under realistic conditions.

During a critical design milestone, a senior VP overseeing design verification mandated a cross-platform validation initiative: swap designs and tools across BUs, validate that silicon from each BU worked on all vendors’ platforms, uncover hidden inconsistencies before tape-out.

The mandate required running each BU’s design on all three virtual host platforms and on both ICE setups to ensure environment independence.

That’s when the surprise hit! One design passed flawlessly on all three virtual host platforms. It passed on one of the ICE platforms, but it failed on the other ICE platform, halting system boot entirely. The immediate suspicion fell on the speed adapter. The design team escalated the issue to the EDA vendor’s ICE experts for root-cause analysis.

The Solution

The EDA vendor’s ICE team dug deep into the logs and waveform traces and found the real culprit. It wasn’t the adapter. It was a bug in the DUT’s RTL.

This RTL flaw had escaped all three virtual platforms because of missing low-level system behavior modeling. Escaped one of the ICE setups due to lower fidelity implementation and surfaced only on the higher-fidelity ICE platform, which accurately mirrored real server behavior.

In real-world server systems, three critical hardware/software layers interact simultaneously. From the bottom up, the layers are:

1. Motherboard chipsets, including PCIe switches, bridge chips, and other supporting silicon
2. BIOS, handling low-level system initialization and configuration
3. Operating System (OS), such as Linux or Windows, running on top

Virtual host platforms typically simulate only the OS layer using a virtual machine approach (typically QEMU based). The BIOS is minimally represented, and chipset behavior is completely abstracted out.

On the high-fidelity ICE platform, however, a real Intel server board was connected through the speed adapter. During boot, this Intel chipset correctly issued a Vendor Defined Message (VDM) over PCIe, a standard behavior in many production Intel servers, but not modeled at all in virtual platforms. Upon receiving this VDM, the DUT incorrectly dropped the packet instead of updating the PCIe flow control. This caused a deadlock during system boot. There was no software workaround, the only solution was to fix the RTL before tape-out.

Results

If undetected, the chip would have failed in every server deployment, resulting in a dead-on-arrival product. Detecting the bug pre-silicon saved the company a multi-million-dollar re-spin and months of schedule delay. The incident demonstrated why high accuracy virtual environments are critical to finding bugs early while high fidelity in-circuit setups are necessary to have final fidelity and confidence in the design.

—

Case Study #2: ICE Delivers Superior Throughput

The Challenge

When designing peripheral interface products, engineering teams often rely on virtual solutions for early verification. While virtual environments can model a protocol controller, they cannot accurately represent the physical (PHY) layer.

In these virtual models, the PHY is removed and replaced by a simplified “fake” model allowing to write software for basic register programming but does not support link training, equalization, or true electrical signaling. As a result, link training may appear to succeed because the model “assumes” compliance. Subtle issues like timing mismatches, equalization failures, and signal integrity problems remain hidden until late post-silicon testing. Testing real-world interoperability, especially with diverse third-party hardware and drivers, is not possible.

A leading hyperscaler faced significant challenges because of this drawback. Early in their design cycles, they faced months-long delays just to program and train PHYs, pushing crucial bug discovery into expensive post-silicon stages.

The Solution

To overcome these challenges, they adopted Synopsys Speed Adapters to bring PHYs into the emulation environment.

With this approach, PHYs are physically connected to the emulator through the speed adaptation. These boards support full programming, training, and link initialization just as they would on silicon.

This integration effectively turns the emulation environment into a true In-Circuit Emulation (ICE) platform, combining the speed and visibility of pre-silicon emulation with the physical accuracy and interoperability of real-world hardware

Examples of Impact

PCIe Gen5 Interface

• In a virtual setup, a Gen5 device’s link training sequences seemed successful.
• When tested via a speed adapter and a PHY, the customer uncovered critical timing mismatches and equalization failures that would have escaped virtual verification.
• Catching these issues pre-silicon avoided a potential costly silicon re-spin and ensured full compliance with Gen5 specs.

UFS Storage Interface

• A UFS host controller passed functional tests in a virtual model.
• When connected to a real UFS PHY through a speed adapter, engineers discovered clock misalignments, burst mode instabilities, and data corruption under stress conditions—problems rooted in real signaling, invisible in virtual models.
• Early detection improved system reliability and ensured compliance with JEDEC standards.

Driver Interoperability Testing

• In root complex mode, different GPUs (NVIDIA, AMD, Intel) each use different drivers and optimizations.
• Virtual environments cannot test these real drivers because they require a physical interface.
• Speed adapters allowed full driver stacks against real devices, exposing errata and interoperability bugs that virtual models could never catch.

Results

Previous four months to program the PHY plus up to six months to train it in post-silicon were executed in pre-silicon in a couple of weeks. This was possible because speed adapters ran workloads , enabling rapid design iterations and faster bring-up cycles. Another benefit was improved debug and reuse since the same PHY configuration trained in pre-silicon could be directly reused in post-silicon, accelerating bring-up.

—

Case Study #3: Ethernet Product Validation

Challenge

When developing advanced Ethernet products—such as ultra-Ethernet, smart NICs, or intelligent switches—engineers face a recurring challenge: how to bring real software traffic into the Ethernet validation environment.

Virtual environments offer partial solutions. Virtual tester generators (VTG) offer low-level packet traffic (Layer 2, Layer 3) but do not exercise the application software stack. Virtual Hosts (VHS) allow software interaction but lacks flow-control capabilities. Without flow control, packets are dropped, an unacceptable limitation for validation environments where fidelity and determinism are critical.

As a result, traditional virtual environments are either incomplete (VTG) or not fully-reliable from a traffic control perspective (VHS). This gap left design teams without a way to fully validate Ethernet products across all protocol layers—especially the higher layers (L4–L7) that depend on real drivers, operating systems, and diagnostic software.

Solution

Ethernet speed adapters provide the missing link by bridging virtual test environments with real software execution over Ethernet.

Unlike VHS, speed adapters guarantee zero packet drops, delivering deterministic performance even under high traffic. Virtual testers (e.g., from Ixia or Spirent) remain useful for low-level (layer 2/3) functional validation. Speed adapters enable execution of real drivers and Linux-based diagnostic tools that testers cannot emulate. Together, virtual testers and speed adaptors form a complete solution spanning all Ethernet layers.

For startups or budget-constrained customers, speed adapters complement more expensive virtual tester licenses.  Speed adapters can provide equivalent packet generation and analysis at lower cost. Also, free and open-source test generators can be layered on top of a speed adapter to replicate tester functions at much lower cost.

Results

In practice, this hybrid approach has enabled customers to validate real software stacks against hardware under development without packet loss. Catch design bugs that only appear in higher protocol layers, issues that purely virtual test environments cannot expose. Scale affordably, combining limited VTG licenses with speed adapters to achieve full test coverage.

—

Case Study #4: Real-World Sensor Interoperability with MIPI Speed Adapters

The Challenge

The Display and Test Framework (DTF) team of a major fabless enterprise faced a recurring and costly problem. They needed to validate their chip design against real MIPI-based image sensors and cameras. However, in a virtual emulation environment, this was impossible because virtual models can mimic protocol behavior but cannot replicate real sensor electrical signaling or timing. Vendor-specific cameras and sensors each have unique initialization sequences, timing quirks, and signal integrity characteristics that no generic virtual model can capture. When first silicon returned from the fab, it frequently failed to interface with the intended cameras and sensors, leading to long bring-up efforts or even full silicon re-spins.

This limitation created a significant time-to-market bottleneck. By the time hardware compatibility issues can be found the design has already gone through costly fabrication, delaying product launches.

The Solution

To eliminate this bottleneck, the company adopted MIPI speed adapters to enable ICE with real sensor hardware. Using this approach, the chip design running inside the emulator could be directly connected to real, vendor-specific MIPI cameras and image sensors. Engineers could exercise full initialization, configuration, and data streaming paths just as they would on physical silicon. The setup supported easy swapping of different sensors and camera models, enabling rapid interoperability testing across vendors.

This capability gave the DTF team the real-world coverage they needed in pre-silicon, without waiting for chips to return from the fab.

Results

The design was successfully tested with the exact vendor-specific camera and sensor models planned for production. By catching integration issues pre-silicon, the enterprise avoided costly design re-spins caused by post-silicon bring-up failures. Removing the post-silicon camera/sensor debug cycle accelerated overall product schedules. Finally, the team could sign off knowing the design was already proven with real-world peripherals.

—

Case Study #5: How Synopsys’ System Validation Server (SVS) Caught Critical Bugs Missed by other solutions

The Challenge

Pre-silicon validation using ICE has historically faced a critical obstacle. Standard off-the-shelf host servers are not designed to tolerate the slow or intermittent response times of an emulator. When the emulator clock stalls or slows the host often times out, aborting the test run.

This customer’s silicon validation team encountered this limitation firsthand. While they used a commercial emulation host server for ICE, this system wasn’t enforcing strict real-world timing AND protocol checks. This risked letting flawed designs pass pre-silicon signoff, only to fail later in production.

The Solution

To overcome these limitations, the customer’s validation team adopted Synopsys’ System Validation Server (SVS) as their host system for ICE validation. SVS is a specialized, pre-validated host machine designed specifically to work with speed adapters and emulators. It offers two major advantages over generic hosts or legacy commercial host server setups. The SVS ships with a custom BIOS, engineered to tolerate the slow response times of emulators to eliminate timeouts that can otherwise terminate validation runs prematurely. SVS faithfully mimics the DUT that will eventually plug into, including enforcing strict specification compliance, especially for complex subsystems like PCIe. See figure 1 at the top of the article.

The validation team tested their design on both 3^rd party emulation hardware and Synopsys’ SVS. Using the 3^rd party emulation, the system booted successfully, but on SVS, the boot failed completely. Initially, the engineers suspected a hardware fault in SVS. As they put it: “Your SVS is broken while the other guys work fine.”

However, after a detailed debug session, it emerged that their DUT contained configuration errors in PCIe space registers. The 3^rd party emulation solution and host server masked these errors because it used an outdated BIOS that failed to enforce PCIe register constraints. By contrast, SVS strictly enforced PCIe specifications and correctly rejected the illegal register values. The bug was non-fixable by firmware (no software patch could correct it).

Results

SVS exposed an RTL-level configuration bug that virtual flows and another emulation solution missed. It eliminated timeout instability in virtue of the SVS’s modified BIOS that allowed stable, long-duration tests.

SVS ensured that only spec-compliant designs advanced to tape-out, eliminating false positives from legacy flows.

Had the design been taped out based on 3^rd party emulation “pass,” the silicon would have been DOA, requiring a full, costly respin.

Conclusion

Back in 2015, I wrote “The Melting of the ICE Age” for Electronic Design, where I predicted the demise of in-circuit emulation (ICE). Its numerous drawbacks (see Part 1 of this series) seemed to doom it to history, replaced by transaction-based emulation and, later, hybrid approaches that drove the shift-left verification methodology. In hindsight, I must admit I underestimated the ingenuity and resourcefulness of the engineering community.

Today, the third generation of speed adapters has propelled ICE again into the limelight of system-level validation. Bugs once detectable only in post-silicon labs can now be identified pre-silicon. This capability not only reduces the risk of re-spins but also accelerates time-to-tapeout and saves enormous expense. Far from melting away, ICE has re-emerged as a cornerstone of system-level verification.

The Rise, Fall, and Rebirth of In-Circuit Emulation (Part 1 of 2)

Also Read:

Statically Verifying RTL Connectivity with Synopsys

Why Choose PCIe 5.0 for Power, Performance and Bandwidth at the Edge?

Synopsys and TSMC Unite to Power the Future of AI and Multi-Die Innovation

Share this post via:

• 
• 
• 
•