What makes an FPGA project succeed (or fail)

The projects that succeed and the projects that struggle often use the same tools, the same programming languages, and the same engineering methods. The difference often lies in how well the people involved understand each other: their expectations, their communication, and a shared sense of what engineering involves.

We have seen both sides: projects that ran smoothly despite difficult technical challenges, and projects that stumbled because the working relationship didn’t support the process. This article describes what we learned from both.

Engineers talking to engineers

Our client contacts are almost always other engineers. Sometimes they are team leads or project managers, but predominantly they are people with technical backgrounds. That follows from the work itself. FPGA design is specialized work. The conversations that drive a project forward are mostly technical: interfaces, timing constraints, verification strategies, and trade-offs between performance and complexity.

This engineer-to-engineer dynamic works well when the client side mirrors it. The best projects are the ones where both teams can discuss technical details directly, without layers of translation in between. The client doesn’t need to understand FPGA design; that’s what they hire us for. It does help when they understand engineering as a discipline. Engineering is iterative, not everything can be predicted upfront, and the process needs investment alongside the product.

The planning problem

One of the problems with creating technology that doesn’t exist yet (as we do here daily) is that long-term planning is unreliable. Impossible, even. You don’t know how long it will take because you don’t yet fully grasp the problem you’re solving.

For a project that spans a year or more, this adds up. Experienced engineers will tell you that a year-long project estimate is, at best, an educated guess. The uncertainties compound over time, and the further out you plan, the less reliable the plan becomes.

The source of these uncertainties is often the environment the FPGA must operate in, more than the FPGA design itself. That means the existing systems, the interfaces it must connect to, and the legacy complexity on the client side. A piece of technology that wasn’t fully documented, a hardware interface that behaves differently than specified, a protocol implementation with undocumented quirks. These are the things that cause projects to run over. And they are, by definition, the things you cannot know about until you encounter them. How our design process handles this, from specification to sign-off, is described in The modern FPGA design process.

The difficult conversation

When a project does run into a problem, someone has to pick up the phone and tell the client. This is the conversation nobody enjoys. Not the engineer, not the project lead, not the client.

What makes this conversation bearable, and what separates a setback from a crisis, is the relationship. When both sides know that engineering involves unknowns, they trust that the delay comes from the complexity of the problem. Then the conversation is difficult but productive. You adjust the plan, recalibrate expectations, and move forward.

What successful projects have in common

After years of projects with different clients across different industries, a pattern has emerged. The projects that succeed tend to share two qualities, and both teams bring them.

1. The first is an engineering mentality: an understanding, on both sides, that engineering is a process of discovery as much as it is a process of construction. Things will go wrong. Obstacles will appear that nobody predicted. When both teams expect that, a delay or a sidetrack becomes something to work through together, and both keep their confidence in the other side.
2. The second is openness in communication. Technical compatibility matters, and so does the willingness to share information, ask questions and keep the dialogue going throughout the project. That applies to us as much as to the client. The best working relationships are the ones where either side feels comfortable raising a concern early, well before the formal review points.

What the FPGA projects that succeed have in common, and where schedule risk usually comes from.

The right tools for the context

We created Clash and still maintain it, but not every project uses Clash. Our tooling choices are guided by what makes sense for the specific engagement.

Some clients specify their preferred tools: a particular hardware description language, a specific vendor toolchain, a required verification framework. Others give us a free hand. We work across a broad stack: Clash and Haskell, VHDL, Verilog, FPGA vendor toolchains, ASIC tooling from Cadence and Synopsys, and open-source tools like GHDL, NVC, and CoCoTB for verification. The right tool depends on the project, the client’s ecosystem, and the specific engineering challenge at hand.

This flexibility is deliberate. We would rather use the tool that best fits the situation than insist on a single approach regardless of context. Engineering is about solving problems, and dogma about tooling gets in the way of that.

The pattern

Looking back across our project history, the pattern is clear, whatever the technical requirements. In the projects that succeed, both sides, we and the client, share a realistic understanding of what engineering involves. They communicate openly throughout the process and treat setbacks as problems to solve together.

That is not a guarantee against delays or difficulties, since complex projects will always have both. But it is the foundation of good engineering outcomes. It is also the most reliable predictor of whether a project will end with a handshake or a headache.