Design the Right Chip: Why Prototyping Has to Be Easy

Design the right chip. Design the chip right.

Every verification methodology in mainstream use answers the second half of that sentence and assumes the first. Simulation, emulation, formal, constrained-random testbenches, coverage closure — all of them take a specification as given and ask whether the implementation matches it. The industry has become very good at that. Across three Wilson Research Group functional verification studies, “design error” as a root cause of ASIC functional flaws fell from 75% to 60% between 2016 and 2024, and “changes in specification” fell from 59% to 43%.

The industry has made no comparable progress on the first half. Over the same three studies, “incorrect or incomplete specification” went from 56% to 58% to 59% — essentially flat, and slightly in the wrong direction. (Each figure is the share of respondents citing that cause; multiple answers were allowed, so the numbers do not sum to 100%.)

A misunderstood requirement cannot be caught by anything that encodes the same misunderstanding. It is caught only when the design meets the software, the traffic and the interfaces it was actually meant to serve — and the people who asked for it. That is what FPGA prototyping is for, and it is why prototyping has moved from a late-stage software vehicle to the engine for the half of the problem the industry has been ignoring.

Shift left, further left than software

Shift-left is usually quantified in software: get the software team started six to nine months before first silicon. That is real, but it understates the case. The same prototype that boots the software stack can be put in front of a customer, a partner or a standards body while the specification is still soft — the only time “are we building the right chip?” is still answerable, and the only time the answer is cheap.

What changes is who asks the questions. In the lab, a testbench asks what the designer thought to ask, and the coverage model was written from the specification — the same specification that may be wrong. In front of a customer, the questions are the ones nobody thought to ask: their workload, their driver stack, their interop or compliance suite. That is where you learn that a buffer was sized from the wrong traffic model, that a latency budget cannot be met at the interface you specified, or that a mode the customer assumed was mandatory was never implemented. Those are specification errors, not implementation bugs — and specification errors are exactly what the Wilson data says is not improving.

The timing is different, too. Software shift-left starts when the RTL is stable enough to boot; the specification is soft much earlier, at architecture definition, which is where the expensive decisions get made. A prototype that can be stood up quickly is the only thing that can test an architectural choice while it is still a choice — and in the environments where those decisions actually get tested: a customer’s office, a partner’s integration lab, a plugfest, a show floor.

That reframes what matters in a prototyping platform. If the value lies in getting to a running system early, repeatedly and in someone else’s building, capacity is table stakes and ease of use becomes the gating factor:

• System Environment — how fast you can stand up the system around the silicon.
• Debugging — how fast you can see inside it when it misbehaves.
• Complex Design — how much of a hard partition is automated rather than hand-scripted.
• Ecosystem — how much is already proven before your RTL arrives.

S2C, which has spent more than 20 years on nothing but ASIC and SoC verification, builds the Prodigy platform and the PlayerPro toolchain around those four questions.

1. System Environment: Accelerate System Setup with Ready-to-Use Modules & Reference Designs

Most of the time lost on a prototype is not lost inside the FPGAs. It is lost building the system around them — the memory that matches the target, the PHY that speaks the right protocol, the processor adapter that lets real firmware boot. S2C reduces that setup work with 100+ Prototype Ready daughter cards and reference designs and 50+ Prototype Ready IP blocks, organized into the categories teams actually need: Arm processor adapters, DDR4/LPDDR4 memory modules, high-speed GT peripherals (QSFP28/QSFP-DD, Mini-SAS, PCIe root complex and endpoint), embedded and multimedia (HDMI 2.0, DisplayPort, MIPI D-PHY), eMMC and Flash, GPIO with Arm JTAG.

A standardized environment also makes the prototype portable. A Prodigy system can be crated, shipped and re-commissioned at a customer site, a partner lab or a trade-show booth, and run the real software stack when it gets there — not something an emulator bolted to a rack can offer.

2. Debugging Made Easy: Multi-FPGA Visibility Without a Cable

A prototype is only useful early if it is observable early. Virtual JTAG replaces the physical FPGA cable, so standard Vivado download and debug flows still work — even remotely. VIO and AXI backdoor access run over Ethernet or USB, and the debug IP is multi-FPGA aware rather than per-device, so instrumenting FPGA_3 does not mean re-instrumenting FPGA_1. An AXI transactor over PCIe — the basis of ProtoBridge — gives host software high-bandwidth access into the running prototype for genuine HW/SW co-development. A debug loop measured in days can become one measured in minutes.

3. Complex Design Made Easy: Automated RTL-to-Bitstream, With the Headroom to Hold It

The hardest part of prototyping often comes first: getting a large design partitioned across multiple FPGAs and running. PlayerPro-CompileTime takes RTL to bitstream — gated clock conversion, memory mapping, debug IP insertion, RTL partitioning, then per-FPGA synthesis and place-and-route — under Time Division Multiplexing (TDM)-driven, multi-strategy scheduling. Two pieces matter most, because they are where in-house flows break: speed bridges for PCIe and 10G/40G/100G/200G/400G Ethernet, allowing logic designed for high-speed interfaces to run even when the FPGA implementation cannot natively sustain the target interface rate; and memory models with backdoor access that bridge DDR5, LPDDR5 and HBM3 controllers to the DDR4 physically mounted on the board. This is the difference between “the design fits” and “the design runs.”

The hardware has to hold the result. Prodigy Logic System S8-100, built on the AMD Versal Premium VP1902, carries roughly 100 million ASIC gates per core module — 18.5 million system logic cells, 858Mb of internal memory, 6,864 DSPs — two modules scale to roughly 200 million ASIC gates, and four to roughly 400 million. The number that matters more is I/O: 2,212 XPIOs at up to 56Gbps, GTM/GTYP transceivers, selectable 1.0V–1.5V. In large multi-FPGA designs, partitioning can hit a pin wall before logic capacity is exhausted. TDM eases pin constraints but can reduce effective  bandwidth and add latency, potentially affecting the timing behavior being evaluated.

4. Ecosystem: Built With the IP and Processor Vendors Your Chip Already Depends On

A prototype has to talk to the same processors, IP and software stacks the silicon will. S2C has already done that work with the vendors behind those components: Arm on Smart IoT and a next-generation automotive E/E architecture with Xylon and ZC; Andes on the AX46MPV and AX66 RISC-V cores; BOSC on a 16-core RISC-V processor with NoC; Sirius on Wi-Fi 6/Bluetooth RF IP; and XuanTie on the C925. In practice, many of the subsystems a prototype must bring up have already been exercised on Prodigy before your RTL arrives.

Why S2C

Prototyping is not a side business for S2C. The company has spent more than 20 years on ASIC and SoC verification, has more than 300 employees, serves 700+ customers, and supports them through seven branches and offices worldwide. Since 2020, S2C has served 12 of the world’s top 25 semiconductor companies.

Two things follow from that focus. The tools ship with the hardware, so a purchase is never a bare board plus a scripting project — the platform arrives as a working system, not as a kit to be assembled. And the economics differ: S2C estimates that the total cost of ownership runs 30–50% below the legacy EDA suppliers, which changes the calculus from one shared box per site to a prototype wherever one is needed, including at the customer’s facility.

Together, these four capabilities help teams bring up and validate prototypes more efficiently. For teams trying to validate a specification before its assumptions become expensive to change, that is the combination that matters. Design the right chip. Design the chip right.

Source: Verification data: 2024 Wilson Research Group FPGA Functional Verification Trend Report.

Also Read:

S2C Prodigy Complete Prototyping Solutions—and Why They Matter

Shift Left with S2C Prodigy: From RTL Verification to Real-World Software Validation

ASIC-to-FPGA Turnkey Prototyping Bundle: A Practical Path to Earlier Hardware Validation

Share this post via: