The Difference Between a Dead FPGA and a Disconnected FPGA

One of the most uncomfortable moments during FPGA bring-up is not when something clearly fails.

It’s when nothing seems to happen at all.

No configuration. No I/O activity. No obvious response.

At that point, a dangerous assumption often creeps in:

“The FPGA might be dead.”

In practice, that conclusion is far more common — and far more wrong — than most teams would like to admit.

Why “Dead FPGA” Is Usually the Wrong First Diagnosis

FPGAs today are remarkably robust devices. Genuine silicon failures do happen, but they are relatively rare compared to the number of boards that initially appear non-functional.

Much more often, the problem lies somewhere else:

• A missing or incorrect connection
• A configuration pin not behaving as expected
• A power or reset condition that never quite reaches the device
• A signal that is assumed to be present, but isn’t

From the outside, all of these scenarios can look identical.

The FPGA doesn’t respond. The board appears lifeless. Progress stalls.

The Cost of Guessing Wrong

Treating a disconnected or inaccessible FPGA as “dead” has consequences.

Boards get swapped unnecessarily. Time is spent reworking designs that are logically correct. Confidence erodes, not just in the hardware, but in the process itself.

In teams working to tight schedules or limited prototype availability, this kind of misdiagnosis quickly turns into a delivery risk.

What Engineers Actually Need at This Point

At this stage, progress doesn’t come from more speculation. It comes from evidence.

The critical questions are simple:

• Can the FPGA be accessed at all?
• Are configuration and control paths intact?
• Is the device electrically connected the way we believe it is?

Until those questions are answered, behaviour-based debugging is premature.

Why Behaviour Alone Isn’t Enough

An FPGA that doesn’t configure, doesn’t toggle I/O, or doesn’t respond to software is not necessarily faulty.

It may simply be unreachable.

Without a way to distinguish between absence of behaviour and absence of connectivity, teams end up debugging symptoms rather than causes.

This is the point where experienced teams pause and change approach.

Instead of asking:

“Why isn’t it working?”

They ask:

“What can we prove about this board right now?”

Turning Uncertainty Into Direction

Once basic accessibility and connectivity are established, everything else becomes easier.

If the FPGA is provably reachable, attention can return to design, configuration, and timing with confidence.

If it isn’t, the problem is no longer abstract, it’s localised and actionable.

Either way, progress resumes.

Closing Thought

A dead FPGA and a disconnected FPGA can look identical from the outside.

The difference is not discovered by waiting for behaviour, it’s discovered by establishing proof.

The teams that move fastest through bring-up are usually the ones that make this distinction early, before guesswork sets the direction.

FPGA Board-Level Tip of the Week

Always provide a reliable way to prove FPGA accessibility before relying on behaviour.

Before assuming a configuration or design problem, ensure there is a clear, repeatable method to confirm that the FPGA can be accessed electrically and structurally.

Why it matters

• Connectivity issues often masquerade as device or design failures
• Early proof of access prevents unnecessary board swaps and redesigns
• Confidence in basic accessibility accelerates all subsequent debug

What to watch out for

• Configuration and JTAG pins that are assumed to be connected but aren’t
• Reset or mode pins that prevent access under certain conditions
• Designs that only allow access once the FPGA is fully configured

Being able to prove that an FPGA is reachable is often the single most important step in early bring-up.