The modern FPGA design process: from idea to hardware

How to run a successful FPGA design project

Every FPGA project starts with a question. Sometimes that question is quite precise, like a detailed specification with exact timing requirements and interface definitions. Sometimes it’s broad, like a client who knows what their product should do but isn’t sure what it takes to get there. Both are valid starting points, and both lead to good outcomes when the right process is followed.

At QBayLogic, we use a structured design process rooted in standard ISO procedures. But within that structure, there is room for the kind of engineering judgement that only comes from experience. Here’s how a typical project unfolds, from idea to hardware.

A typical FPGA fpga design process at QBayLogic

Understanding what the client needs

The first step is always a conversation. We sit down with the client to understand what they’re trying to achieve. And, just as importantly, how precisely they already know what they need.

Some clients come to us with detailed specifications. They’re deep into product engineering, they’ve defined their interfaces, and they need us to design a specific FPGA component that fits into a larger system. In those cases, the requirements phase is relatively straightforward. We enjoy working with fellow engineers who speak the same technical language and know exactly what they’re after.

Other clients have a functional requirement: they know what their product should do, but they need help figuring out the right technical approach. That’s a different kind of conversation, where we help translate a business need into a concrete technical specification. We enjoy these projects just as much. There’s real satisfaction in understanding someone’s challenge and working out a solution that fits.

Regardless of the starting point, the goal of this phase is the same: to arrive at a clear set of requirements expressed in natural language, and an interface definition in a standard hardware description language (Verilog or VHDL) that specifies how the FPGA component will communicate with the rest of the system. This is the go/no-go point. The offer is signed, and the real work begins.

The mathematical specification

Once a project gets the green light, we start by developing a mathematical specification of the desired behaviour. This is a compact, precise description of what the system should do. The relationship between inputs and outputs, stripped of any implementation detail.

Such mathematical specifications are elegant and powerful, but they come with an important caveat: they assume infinite resources. In the world of mathematics, memory is unlimited and calculations happen instantly. That’s useful for defining what the answer should be, but it tells you nothing about how to compute it within the constraints of real hardware.

Still, this step earns its place early: in a recent project, developing the mathematical specification and implementing it as a testable software model took roughly two weeks. The result was a piece of software that the client could run, test with their own data, and formally approve before any hardware design work began. This is a fast way of removing a category of risk from the project.

The functional model: sign-off before hardware

That first functional model becomes the reference point for the entire project. The client signs off on it, confirming that the behaviour it describes is exactly what they need. This happens before a single line of hardware-specific code is written.

This early sign-off resolves disagreements about what the system should do, early enough that fixing them costs a conversation rather than a redesign. It’s what stops a team from spending months building hardware, only to discover that they built the wrong thing.

From model to hardware: the real work

Translating a functional model into a working hardware design is where most of the project time goes. In the same project mentioned above, this phase took close to six months.

The functional model is the starting point. We take it apart, subsystem by subsystem, and rewrite each piece so that it can be synthesised into actual hardware. At every step, we test the evolving design against the original reference model to verify that it still produces the same results.

This is where our compiler, Clash, shows its strength. Because Clash is based on Haskell, the functional model and the hardware implementation live in the same language: the reference model is code, running alongside the implementation, rather than a separate document or a specification written in a different tool. There is no room for ambiguity, and no translation errors between a specification document and the actual design.

The refinement process can be done gradually. You might rewrite one subsystem to be hardware-ready while keeping the rest at the high-level model stage. This incremental approach makes it possible to verify each piece as you go, rather than waiting until the entire design is complete to discover that something doesn’t work.

When things get complicated

Not every project follows the ideal path. The mathematical model works beautifully when the problem is fundamentally computational and you’re transforming data according to well-defined rules. But some challenges don’t have a neat mathematical starting point.

Hardware interfaces with strict timing requirements, for example, are difficult to model at a high level. Ethernet communication, to name one common case, involves constraints that are artefacts of the physical world (cable lengths, signal propagation, timing tolerances), not mathematical problems. In these situations, you cannot start with an idealised software model and gradually refine it. You must work closer to the hardware from the beginning.

These cases require a different approach but the same underlying discipline: clear specifications, rigorous testing, and close collaboration with the client.

Preventing errors, not fixing them

Everything above comes down to one idea: get things right early. The mathematical specification catches misunderstood requirements before they cost anything, the functional model gives the client a testable reference before hardware design begins, and because model and implementation share a language, there’s no translation error between them. Because refinement happens incrementally, design issues surface as they’re introduced, not after the whole system is assembled.

This is deliberate, because testing hardware is expensive but fixing what testing finds is more expensive, and finding out late in a project that you built the wrong thing is the most expensive outcome of all. We build the process so that a design passing its first checks has already been verified against a reference the client approved months earlier. That’s where the confidence in the outcome comes from, for us and for the client.

Contact us to learn more about our FPGA design process.

Frequently asked questions

How does an FPGA design project start?

An FPGA design project always starts with a conversation about what the client is trying to achieve and how precisely they already know what they need. Some clients arrive with detailed specifications and defined interfaces, others have a functional requirement and need help finding the right technical approach. Either way the first phase of the project ends with a clear set of requirements in natural language and an interface definition in VHDL or Verilog. That is the go/no-go point.

What is a mathematical specification in FPGA design?

A mathematical specification in FPGA design is a compact, precise description of the relationship between inputs and outputs, stripped of any implementation detail. It assumes infinite resources, so it says nothing about how to compute the result within the constraints of real hardware, but it can be implemented as a testable software model. In a recent project that took roughly two weeks and produced software the client could run with their own data and formally approve before any hardware design began.

When does the mathematical model approach not work?

When the problem is not fundamentally computational. Hardware interfaces with strict timing requirements are difficult to model at a high level: Ethernet communication, for example, involves constraints that are artefacts of the physical world such as cable lengths, signal propagation and timing tolerances. In those cases, you cannot start from an idealised software model and refine it, and you must work closer to the hardware from the beginning.