Google's Coral chip team just deleted several test runners. Its replacement, CoralFlow, lets one Python workload test run against a fast software model, two chip simulators, or a field-programmable gate array (FPGA), a prototype board whose logic can be rewritten. The test asks each target to load a program, write memory, run, and return a result through the same interface.
That cleanup points to a larger change in hardware development. Tests are becoming portable assets that can follow a product from an early model to a physical prototype and eventually into the field. The engineering team writes the expected behavior once, then swaps the equipment underneath it. We think this will matter more than faster individual simulators because it shortens the time spent rebuilding evidence whenever the product moves to a new stage.
CoralFlow makes the hardware replaceable
The CoralNPU change covered 96 files. Google moved vector instructions, Gemma model kernels, LiteRT Micro workloads, and fault tests onto CoralFlow. It removed two standalone FPGA runners and older regression scripts built around the Universal Verification Methodology (UVM), a standard framework for testing chip designs in simulators.
CoralFlow gives every execution target the same basic fixture. A test can run locally with Verilator, an open-source chip simulator, then run on Synopsys Verilog Compiled Simulator (VCS), a commercial simulator used by large chip teams. The same workload can also run on Google's software model or an FPGA. Tests can be filtered and divided across build workers without each target inventing its own command line. Google says sharing compiled models cuts VCS compilations in half and reduces memory pressure in continuous integration (CI), the automated system that checks every code change.
Before this, a team often carried parallel suites. A simulator test drove internal signals that didn't exist on the board. A board script loaded firmware through another interface and parsed serial output. A software model had its own runner. Those suites drifted because every product change had to be translated three times. When the board disagreed with simulation, engineers first had to ask whether the hardware was wrong or the tests were asking different questions.
With CoralFlow, the disagreement becomes useful. A workload that fails everywhere points to the design or the test. One that passes in the software model and fails on the FPGA points toward implementation, timing, or the board interface. The test gives the team a common question, so the target supplies the new evidence.
The same behavior is surviving each build stage
Other projects are making the same move at different boundaries. openPIO, a small input and output coprocessor headed for a Tiny Tapeout manufacturing run, uses cocotb, a Python framework that drives chip simulations. Its CI runs one protocol suite on the register-transfer level (RTL) source that designers edit. After the design is converted into a netlist of physical logic cells, the manufacturing workflow runs those tests again. Waveforms and test results stay attached to both runs.
That second run matters because synthesis and physical implementation can preserve the design's broad shape while introducing a reset, timing, or connection mistake. Gate-level simulation is slower, so teams historically wrote a narrow signoff script or skipped behavioral tests at that stage. openPIO instead makes the manufacturing output answer the same protocol questions as the source.
The idea extends beyond one chip repository. The draft RISC-V Certification Test Plan, published by the RISC-V Certification Steering Committee, connects human-readable processor requirements to machine-readable coverage points, reference models, and self-checking assembly tests. Its stated goal is software compatibility across implementations. A processor vendor and an operating-system team can run the same certification material instead of comparing private reports.
The Aerospace Corporation's spacecraft autonomy framework, published in October, carries behavior through simulation, a real flight processor, hardware connected to the simulation, robotic emulation, and flight. Each stage adds a new piece of physical reality while keeping earlier safety claims visible. The team can see the first stage where a result changes, which narrows whether the fault sits in software, timing, sensors, actuators, or the vehicle itself.
The older approach treated each environment as a destination. Simulator engineers owned one test bench, lab engineers owned another, manufacturing test engineers translated patterns for factory equipment, and field diagnostics started again from logs. Portable tests treat those environments as adapters around one behavioral question.
Python, open interfaces, and cheap prototypes changed the economics
Three years ago, this was possible but expensive. Commercial simulators exposed different controls. Prototype boards needed custom loaders. Factory testers used specialized pattern formats. CI systems could start software containers easily but had trouble reserving a physical board and returning its measurements to the build.
The pieces are now ordinary enough to combine. Python test frameworks such as cocotb can drive multiple simulators. FPGA boards are large enough to host realistic chip designs and fast enough to run workloads that take hours in detailed simulation. One recent processor-design study found that compiling for an FPGA and running 8,000 CoreMark iterations took one tenth the time of a cycle-by-cycle simulation. Standard links such as Universal Serial Bus (USB) and Peripheral Component Interconnect Express (PCIe) give lab and production systems software-controlled paths into the device. Hosted CI can preserve waveforms, logs, and measured output with the exact source revision that produced them.
Commercial vendors see the same opening. Siemens' Tessent System Test Edition packages chip test sequences so they can run on automatic test equipment (ATE), the machines that screen chips in a factory, then run through USB or PCIe on a system bench or deployed product. A field failure can be checked with a manufacturing pattern instead of a lab engineer approximating it from a support log.
Test ownership moves toward the product team
Open chip projects and small hardware teams gain first. They rarely have separate groups to maintain simulator, board, and production suites. One behavioral test lets the same engineer move from a laptop model to a prototype without rewriting the question. Firmware teams also gain because they can start against a model and keep the workload when the first board arrives.
Synopsys benefits when CoralFlow makes VCS one useful target in a broader flow, but it loses some environment lock-in because the test no longer belongs to VCS. Teradyne and Advantest still sell the factory hardware required to handle and measure thousands of chips. Their exposed revenue is the custom translation work and proprietary pattern flow around that hardware. When a customer owns portable tests, it can compare equipment by execution speed, measurement quality, and device coverage without moving its whole test library.
The strongest defense for those vendors is better adapters. A simulator, board farm, or factory tester that can run a customer's existing behavioral suite and return structured evidence will be easier to adopt. A product that requires a second test language and a separate result database creates work the customer can now see and avoid.
This argument fails if the common layer becomes too shallow. A functional workload cannot replace analog measurements, scan diagnostics, timing checks, radio tests, or safety analysis. An adapter can also hide target-specific setup until a test passes in simulation and fails for a mundane reason on the board. If teams flatten every environment into a lowest-common-denominator interface, they will get portable tests that miss the faults each instrument is best at finding.
Hardware leaders should start with one behavior that already exists in two suites. Define the inputs, expected outputs, timeout, and evidence once, then write thin adapters for the fastest simulator and one physical target. Keep target-specific measurements beside that shared core. By the end of 2027, we expect serious chip and embedded projects to require every major workload test to name at least two execution targets, with one of them providing physical evidence from a prototype, factory system, or deployed device.