Why FPGA Simulation Success Doesn’t Guarantee Hardware Success

If you’ve worked with FPGAs for any length of time, this scenario will feel familiar.

The design simulates cleanly. Timing closes. The bitstream builds without complaint.

And yet, when the board powers up, something doesn’t behave as expected.

This isn’t a failure of FPGA tools or methodology. Today’s FPGA design flows are extremely mature. The issue lies elsewhere, in the often-underestimated gap between a correct FPGA design and a working piece of hardware.

Where Simulation Stops Helping

Simulation answers an important question:

Is the FPGA design logically correct?

What it does not answer is a different, equally important question:

Is the FPGA correctly connected, powered, and behaving as part of a real system?

Once a design leaves simulation and meets a physical PCB, it becomes subject to realities no simulator can see:

• Connectivity errors
• Assembly defects
• Power sequencing issues
• Incorrect pull-ups or terminations
• Subtle opens, shorts, or pin swaps

None of these appear in a waveform.

When a “Dead FPGA” Isn’t Dead

One of the most time-consuming moments in FPGA bring-up is uncertainty.

An FPGA that doesn’t configure, doesn’t toggle I/O, or doesn’t respond as expected is often labelled as “dead”. In practice, the silicon is frequently fine. The problem lives somewhere between:

• FPGA pins
• PCB traces
• Surrounding components

At this point, engineers often reach for probes but modern FPGA boards make physical access increasingly difficult. High-density packages, fine-pitch routing, and sensitive high-speed signals turn probing into a slow and sometimes risky exercise.

The Blind Spot in FPGA Workflows

This isn’t a criticism of FPGA vendors. FPGA tools are rightly focused on:

• RTL correctness
• Timing closure
• Resource utilisation
• Functional behaviour

What they intentionally do not focus on is board-level visibility. That responsibility sits with the system designer and it’s often where FPGA projects lose time and confidence.

There’s a point in every FPGA project where the question is no longer:

Is my design correct?

but instead:

What can I prove about this hardware?

That transition is rarely explicit and often underestimated.

Closing Thought

Simulation remains essential. It’s the foundation of reliable FPGA design.

But the moment an FPGA design touches a PCB, a new class of problems appears problems that require different forms of visibility and evidence.

Knowing where simulation ends and where board-level reality begins, is one of the most valuable skills an FPGA engineer develops.

Next week:

We’ll look at the silent failures that occur between FPGA pins and the PCB, and why they can be so hard to detect.