S2C EDA's June 2026 paper pushes FPGA prototypes to be judged on the evidence they produce, not their capacity. Here is an independent framework for testing that claim against any vendor.
"Useful pre-silicon evidence" reads like a neutral engineering term. It is not. S2C EDA, an FPGA prototyping vendor that self-claims the number-two global market share, introduced the phrase in a June 11, 2026 technical paper surfaced through SemiWiki to reposition its Prodigy platform from a capacity-and-throughput product into an evidence-generation platform. The framing is not wrong, but it is load-bearing: when a vendor defines what counts as "useful" evidence, the yardstick tilts before the test begins. The honest read is to take S2C's argument seriously, label what is methodology versus marketing, and give engineers a portable framework for judging any FPGA prototyping claim.
S2C's June 11, 2026 paper makes four engineering points that survive contact with practitioner reality. First, ASIC RTL rarely ports cleanly to FPGA. SRAM macros, gated clocks, scan chains, custom register files, and technology wrappers all need remapping before the prototype reflects real silicon behavior. Second, memory and clock architectures must be re-planned: BRAM, URAM, and distributed RAM each behave differently, and gated clocks collapse into clock-enable logic. Third, multi-FPGA partitioning is architecture, not rescue. Fourth, debug observability has to be designed in pre-implementation, not bolted on. Buses, state machines, clock domains, and software-visible registers need probe points before RTL is frozen.
The controversial part of the paper is the call to retire compile time and Fmax as the primary metrics for prototype value, and replace them with "Time-To-Waveform" (TTW), which S2C defines as the wall-clock span from design intent to first meaningful, debuggable system output. The idea has merit. Compile time is a vendor implementation detail. Fmax is a toolchain artifact. TTW at least measures something the program cares about: when can firmware, drivers, and real workloads actually run on hardware that behaves close enough to the ASIC to inform a sign-off decision?
A working definition of "useful pre-silicon evidence" that any vendor claim can be tested against needs five properties. Coverage: does the prototype exercise the bug classes the team is actually trying to catch, including clock-domain crossings, reset behavior, memory coherency, and peripheral hand-off, or only the easy paths? Fidelity: do timing margins, I/O protocols, and on-die interconnect behave within the tolerance the design needs, or is the prototype a "close enough" approximation that engineers caveat every read? Software boot: can firmware bring up the prototype into an OS or hypervisor and run a real workload end-to-end, not just a Hello World on a UART? Regression delta: does running an IP block or subsystem on the prototype produce numbers, like latency, throughput, or a power proxy, that meaningfully differ from simulation, and is the delta traceable to a known cause? Reproducibility: can another engineer, on a different day, with a different commit, get the same waveform and the same numbers, or does the prototype depend on tribal setup knowledge?
S2C's Prodigy platform pitch maps some of these properties cleanly. The company's self-description covers host-to-DUT connectivity, reusable I/O IP, memory models, and runtime control, which together support software boot and regression work. The 100M-ASIC-gate-per-FPGA capacity claim and the 2.5x I/O bandwidth framing are capacity arguments, not evidence arguments, and should be read as such. The "second-largest" market-share claim is self-reported on the company's own site and is not an independent benchmark. Treat it as company positioning, not industry fact.
Where S2C's framing is strongest, and where the broader industry has been converging, is the treatment of debug as an upfront design activity. The paper is right that buses, state machines, clock domains, and software-visible registers need probe points and transaction-level interfaces added during RTL, not retrofitted after a board is built. That piece is not vendor coinage. It is consistent with how RISC-V SoC programs have been planning pre-silicon work for at least two years, and it lines up with S2C's recent SemiWiki cadence on RISC-V IP sandboxes, a 2026 outlook with S2C's Ying J Chen, and a December 2025 S2C, MachineWare, and Andes RISC-V co-emulation announcement.
Where the framing is weakest is the implicit claim that FPGA prototyping is a single coherent step in the verification flow. In practice, decision-grade evidence comes from three engines used in combination. RTL simulation catches the long-tail of corner cases and architectural micro-bugs at speed, but does not run real software at real speed. Emulation, with full debug visibility and design-wide state, is where most regression and bring-up work happens for large SoCs, with cost and per-second runtime as the main downside. FPGA prototyping runs real firmware, drivers, and workloads at near-silicon speed with realistic I/O, but the prototype is always a model of the ASIC, not the ASIC, and the model breaks down at timing corners, custom analog blocks, and any block that lacks a clean FPGA equivalent. Treating FPGA prototyping as the place where "useful evidence" lives ignores that the three engines are complementary, and the choice of which one to invest in for a given decision is a program-level call.
A RISC-V vector workload on a chiplet-based SoC is a good stress test for the framework. The IP regressions, the boot sequence, the cache-coherency behavior across die boundaries, and the software-visible performance counters all need to be measured before tape-out. RTL simulation handles micro-architectural corner cases. Emulation handles design-wide bring-up. The FPGA prototype is where the team can run a Linux bring-up, exercise a real ML workload, measure wall-clock latency, and find firmware-driver interface bugs that do not show up until software touches silicon-realistic hardware. The prototype is most valuable when it is planned with probe points, transaction-level interfaces, and SW-visible registers from day one, which is the part of S2C's paper that is genuinely engineering and not branding.
A practitioner's checklist for evaluating any FPGA prototyping claim, S2C or otherwise, can ride on five questions. Does the vendor define TTW or a similar end-to-end metric, and can they show their own numbers on a reference design? Are probe points, state visibility, and SW-visible registers part of the platform's standard offering, or an add-on? Can the platform run a real OS and a real workload at useful speed, and is there a public demonstration of that? Does the platform's I/O and memory modeling match the I/O and memory of the target SoC closely enough to be decision-grade, or only directionally correct? Is the market-share or capacity number the vendor quotes independently corroborated, or is it self-reported?
S2C's recent content cadence, including a RISC-V IP sandbox post in May 2026, a January 2026 outlook with Ying J Chen, and the December 2025 S2C, MachineWare, and Andes co-emulation announcement, all point in the same direction: the company is building a story that puts FPGA prototyping at the center of RISC-V and SoC pre-silicon work. That story is worth taking seriously, but the engineer evaluating the platform should not accept the definition of "useful" that comes with the pitch. The useful definition is the one the program's risk register, regression suite, and tape-out criteria already use. If a prototyping platform's evidence lines up with those, the platform is doing its job. If it only lines up with the vendor's own metric, the engineer is doing the vendor's marketing a favor.