How to Certify a Supercomputer

As the organizer of this year’s Hardware-Assisted Verification track at Synopsys Converge Silicon Valley 2026, I had the opportunity to see a wide range of advanced verification use cases. One presentation that particularly stood out was from Nobuyuki Matsui-san of Fujitsu, who shared how Fujitsu approached Arm SystemReady pre-silicon verification for the FUJITSU-MONAKA processor, that will be the heart of the FugakuNEXT supercomputer, using Synopsys ZeBu Server 5.

What intrigued me was not only the scale of the design — a highly parallel Arm server processor aimed at supercomputer-class performance — but also the strategic importance of the problem being solved. Matsui-san showed that certification and ecosystem readiness are no longer late-stage checklist items. For advanced Arm-based infrastructure, they are verification goals that must be addressed before silicon. Matsui-san went into great detail explaining how he did it and I you read through the end you will even find hints on what kind of bugs he found. While finding bugs is one goal for verification not many engineers do admit which bugs they found.

The next generation of supercomputers is defined by specialized silicon and the software stacks that run on top of it. Performance, power, throughput, latency, and cost all matter. But for Arm-based server systems, there is another requirement that is just as critical: the platform must be able to run the huge amount of available Arm software stacks customers expect, without custom workarounds, late-stage surprises, or post-silicon rework.

For a system as advanced as FUJITSU-MONAKA, waiting until silicon is available to validate Arm server compliance is too late. MONAKA targets a cutting-edge Armv9 server architecture with 144 cores per die, support for two dies per node, ultra-low-voltage operation, 3D chiplet architecture, DDR5 memory, and PCI Express 6.0 with CXL 3.0 features. 

The result is a highly parallel server system built for demanding performance, power, latency, throughput, and cost targets. But those advantages only matter if the hardware can reliably support the software environment that enables it. To help achieve that goal, Fujitsu used ZeBu Server 5 and an Arm SystemReady pre-silicon verification flow to validate key server architecture requirements before silicon. 

Arm SystemReady is a compliance program for new hardware. Its purpose is straightforward but powerful: software designed for Arm systems should run on Arm SystemReady-compliant hardware as expected. For users and software developers, that means software resources can be available as-is, without platform-specific changes simply to boot, install, or operate correctly.

For server-class Arm designs, this matters deeply. The Arm ecosystem depends on interoperability across hardware, firmware, operating systems, and software. The Base System Architecture, or BSA, and Server Base System Architecture, or SBSA, are key parts of that foundation. Their specifications help make Arm-based systems predictable and compatible across the ecosystem.

Matsui-san explained why this matters in practical terms. In previous Arm server developments, compliance violations have been reported at the post-silicon phase. That is exactly the wrong moment to discover that an operating system fails to boot, that a process crashes or hangs, or that the platform exposes non-standard PCIe behavior. Other problems, such as non-standard PCIe ECAM implementations or the absence of ECAM support, can create high-impact issues that must be prevented or identified early.

This is the core challenge: compliance is not a paperwork exercise. It is a system-level validation problem. It requires long execution, realistic software interaction, and enough debug visibility to trace failures back to their root cause. It also includes the verification of the critical PCIe interface. That makes it an ideal use case for pre-silicon hardware-assisted verification.

Matsui-san walked through Fujitsu’s approach: running the MONAKA design on Synopsys ZeBu Server 5 and using ACS. Arm ACS stands for Arm Architecture Compliance Suite. It is a collection of compliance tests provided by Arm to verify that a hardware platform correctly implements Arm architecture specifications. (see Figure 2)

In this setup, the device under test runs in ZeBu Server 5. An emulation host PC connects to the ZeBu environment. The ACS execution software includes firmware, the exerciser driver, and the BSA/SBSA test program. Results are output through UART, while PCIe XTOR and an exerciser are used to connect ACS PCIe devices into the environment.

Together, these components create a pre-silicon environment in which the compliance suite can exercise the design much earlier than would be possible with real silicon. That matters because the bugs being targeted are not always simple block-level errors. They are issues that emerge when architecture, firmware, operating system expectations, device behavior, and standards compliance all meet.

Matsui-san also highlighted the role of virtual system adapter technology. The emulation model connects virtual devices, including an exerciser and virtual NVMe, through PCIe Gen 6 XTOR. He explained that configurations can be selected at runtime without recompilation, reducing the effort required to switch between test configurations.

Before running the compliance workload on ZeBu Server 5, Fujitsu verified the execution software using its proprietary system-level architecture simulator. Matsui-san explained that this simulator can detect software defects as well as system specification issues, including BSA/SBSA non-compliance. This staged approach helps confirm system-level behavior earlier, while emulation executes the implementation with higher fidelity and enough performance to run long compliance workloads.

Matsui-san described two ACS execution environments. First, the team used a bare-metal environment with custom firmware and SBSA ACS. This environment supports part of the test scope, but some tests cannot be executed. Second, the team moved to a UEFI environment with firmware and BSA/SBSA ACS, enabling a broader test scope. He explained that migrating to the UEFI environment increased coverage and contributed to quality improvement, and that Synopsys and Fujitsu collaborated to realize UEFI support for the ACS solution.

This two-step approach balances confidence and complexity. Bare-metal testing can expose foundational issues earlier. UEFI-based execution can then validate broader system behavior under a richer and more realistic software environment. For a supercomputer-class design, compliance must be verified in a way that reflects both the architectural requirements and the real software expectations of the Arm server ecosystem.

Compliance testing is valuable precisely because compliance does not simply “run clean” the first time. The purpose is to uncover bugs, diagnose them, and fix them before they become silicon or market problems.

Matsui-san outlined several debug technologies used in the MONAKA compliance effort, including bus traces, PCIe XTOR trace, and waveform capture. He explained that instruction trace, proprietary bus trace, and AMBA bus trace were embedded in the emulation model and connected to the emulation host. He also showed how PCIe XTOR trace provided PCIe debug information, while ZeBu Server 5 Quick Waveform Capture enabled targeted waveform capture in a short time.

The challenge is the length of the test patterns. In the debug case study, trace acquisition covered approximately 100 million cycles or less, while waveform acquisition focused on approximately 100 thousand cycles or less. That creates a three-order-of-magnitude gap between the amount of execution that may need to be traced, and the smaller waveform window engineers actually need to inspect.

This is where save-and-restore capability becomes critical. By storing intermediate points in the emulation timeline, engineers can avoid rerunning everything from the beginning and instead focus on the relevant slice of execution. Matsui-san showed a fail message during SBSA ACS testing, creation of save data immediately before the failure point, acquisition of bus and PCIe XTOR traces, waveform capture around the identified issue location, fixes to both the test program and hardware implementation, and confirmation that the issue was resolved.

The scale of the Fujitsu compliance activity illustrates why pre-silicon emulation matters. Matsui-san reported that BSA ACS testing ran for 75 billion emulation cycles in 33 hours, while SBSA ACS testing ran for 45 billion emulation cycles in 25 hours. Together, the testing represented approximately 120 billion emulation cycles and about 58 hours of execution time based on the table he shared.

Those numbers show the complexity of compliance testing for a massively parallel server machine. They also show why software-only simulation alone is not enough for this class of validation. When workloads reach tens of billions of cycles, teams need a platform that can execute long scenarios fast enough to be useful while preserving the visibility required to debug what goes wrong.

The testing produced meaningful findings. Matsui-san explained that FUJITSU-MONAKA hardware bugs, including BSA/SBSA non-compliant specification issues, were detected and fixed. Issues in ACS itself were detected and corrected by providing feedback to Arm. Issues in the ACS solution were also detected and corrected by providing feedback to Synopsys.

That outcome is significant. Compliance for a system of this complexity is an ecosystem activity between the silicon developer, Arm, and Synopsys. Each part of this ecosystem matters: the design under test, the compliance specification and test suite, and the emulation infrastructure that makes pre-silicon execution and debug possible.

The broader lesson is that server compliance must move left. For advanced Arm-based infrastructure, certification readiness cannot wait until bring-up. By then, the cost of a compliance failure is too high. A boot failure, PCIe incompatibility, firmware issue, or operating system problem discovered after silicon can delay schedules, consume engineering resources, and weaken market positioning.

Pre-silicon compliance changes that equation. It allows teams to validate architecture and implementation earlier, run long system-level workloads before hardware is manufactured, and resolve interoperability issues while the design is still flexible. It also gives engineering leaders greater confidence that the system will work with the software ecosystem customers depend on.

For the FUJITSU-MONAKA processor development project, Matsui-san concluded that Arm SystemReady pre-silicon testing using ZeBu Server 5 and the ACS solution made it possible to complete tape-out successfully. He identified the keys as detecting, investigating, and resolving non-compliant specification issues and hardware bugs at the pre-silicon phase.

As supercomputers become more specialized, more parallel, and more tightly connected to software-defined workloads, this shift becomes increasingly important. The next generation of systems will not be judged only by peak compute metrics. They will also be judged by how quickly they can run real software reliably, how efficiently they can integrate into established ecosystems, and how confidently they can reach deployment.

In that environment, pre-silicon compliance is not just a verification milestone. It is a path to successful silicon. The teams that can certify earlier, debug deeper, and collaborate across the ecosystem will be better positioned to bring complex Arm-based supercomputing platforms to market with confidence.

What stayed with me after Matsui-san’s presentation was how clearly this customer story reflected the broader shift toward software-defined hardware-assisted verification. As systems become more software-defined and workloads grow longer and more complex, HAV has to do more than run designs faster; it has to help teams answer system-level readiness questions earlier, with the flexibility to expand use cases, improve debug productivity, and reuse infrastructure as requirements evolve. FUJITSU-MONAKA is a strong example of why these matters: pre-silicon execution, deep debug visibility, and adaptable verification infrastructure can reduce risk before silicon decisions become much harder to change.

Find the Fujitsu-Synopsys success story here.

Arm SystemReady Pre-Silicon Verification for Large-Scale Processor “FUJITSU-MONAKA” on ZeBu Server 5, Nobuyuki Matui, Advanced Technology Development Unit, Fujitsu Limited, Synopsys Converge Silicon Valley 2026

Software-Defined Hardware-Assisted Verification: A New Benchmark for AI-Era Chip Design, Frank Schirrmeister, Tom De Schutter