The FPGA Design Flow: How an FPGA Project Goes from Specification to Production

The FPGA design flow is the sequence that turns a set of requirements into a configured, tested device: architecture, device selection, RTL, simulation, synthesis, place and route, bitstream generation, on-target testing and hand-over. Every vendor documents a version of it, and every FPGA services page publishes the diagram. What the diagram leaves out is how the same flow changes between vendors, why a design that passed simulation can stop working on hardware, and how a regulated customer moves the finish line. This guide walks through each step of FPGA development with that judgement attached.

Key Takeaways

• The FPGA design flow consists of nine industry-standard steps, and the sequence is similar across AMD/Xilinx, Intel/Altera and Lattice devices.
• Names, tools and failure modes differ by vendor, which is why vendor-specific experience matters as much as HDL skill.
• Device selection belongs at the start: the target device has to meet the requirements, be reasonably priced, and leave headroom for the project to grow.
• A design that passes simulation can still fail on hardware, so bring-up and on-target testing are a phase with real effort, not a formality.
• The customer's regime sets the verification bar. Ask what evidence you will need at hand-over before anyone quotes.

The FPGA design flow, and what a flow diagram will not tell you

The industry-standard FPGA design flow consists of nine steps:

1. Requirements and architecture
2. Device selection
3. Design entry (RTL in VHDL or Verilog)
4. Simulation
5. Synthesis
6. Place and route, including timing closure
7. Bitstream generation
8. Bring-up and on-target testing
9. Documentation and hand-over

This is general engineering practice, not a proprietary method. Vendors document it, and their implementation tools and simulation tools are built around it. It is also the least informative part of the subject, because the order rarely changes. What changes is everything inside each step.

"The design flow actually looks similar, but at different vendors things are called different names, it looks slightly different, and you have different tools that work better or worse."

‍

Adam Szychulec, Head of Hardware / Embedded, InTechHouse

The map is public; the terrain is not. A team that has closed timing in one vendor's environment knows which reports to trust, which warnings matter, and which step carries a different name and a different trap. The design process below follows the standard sequence and stops at each step to show where FPGA projects actually lose time.

Step 1 and 2: requirements, architecture, and choosing the target FPGA device

Requirements and architecture, including the processor/fabric split

Requirements fix what the design must do: its interfaces, its performance requirements and its timing requirements. The FPGA architecture then decides how that work divides into blocks and clock domains.

On a SoC, such as the Zynq and Zynq UltraScale+ families, there is one more decision, and it happens before a line of RTL is written: which work goes to the processor and which goes into programmable logic. The operating system and control flow belong on the processor. Work that needs parallelization belongs in the fabric. Treat this as an explicit phase, because the split shapes the RTL, the software and every interface between them, and it is expensive to reverse later. The partitioning method itself is covered in the article.

Device selection, and the headroom you either buy now or pay for twice

Device selection is a designed step, not a procurement afterthought. It sits this early in the flow because the target FPGA device constrains everything downstream, including whether a feature requested next year costs a board respin. Adam Szychulec describes the choice as three constraints held at once: a device that is reasonably priced, that meets the requirements, and that leaves headroom for the project to grow.

"Meets the requirements" has a concrete meaning in a datasheet. It means enough logic elements for the design's resource usage (vendors count these differently, which is the vendor problem again), enough DSP blocks for the arithmetic (AMD/Xilinx calls them DSP slices), enough block memory, transceivers that match the interfaces, and the right dedicated blocks such as clock managers and hard memory controllers. Those physical resources are finite. A design that fills the device leaves no room for additional resources later, and headroom that costs little at selection time costs a new board once the hardware exists.

Choosing an FPGA vendor and family is covered in our article.

Step 3: design entry, or writing RTL in a hardware description language

Design entry is where the design is written, almost always in a hardware description language at register transfer level. The two languages in industrial use are VHDL and Verilog.

Writing RTL looks like programming, but it is building hardware. An HDL design creates logic gates, flip flops and registers, and attaches clocks to them through code, rather than giving a processor instructions to execute one after another. Everything described runs in parallel. That is why the flow needs synthesis and place and route at all, and it is the part a software-trained reader does not intuit. FPGA design mistakes are described in the article.

Sequential behavior is normally expressed through state machines; data paths through registers and arithmetic. A minimal example in Verilog:

module counter (
   input  wire       clk,
   input  wire       rst,
   output reg  [7:0] count
);
   always @(posedge clk)
       if (rst) count <= 8'd0;
       else     count <= count + 8'd1;
endmodule


This HDL code describes an 8-bit register and an adder. On every rising clock edge (posedge clk), the register either resets to zero or loads its own value plus one. Nothing "runs" in the software sense: the hardware description becomes a circuit built from look up tables and flip flops, the same building blocks behind all digital circuits in an FPGA.

High level synthesis tools are a market option that generates RTL from C-like code. High level synthesis can be useful for algorithmic blocks, but its output still has to be simulated and closed for timing like hand-written HDL.

Step 4: simulation, and how you verify functionality before hardware exists

Simulation runs the design against a testbench to check that the design functions correctly before any hardware exists. The testbench drives inputs, observes outputs and compares them with the expected behavior. This is where design errors are cheapest to find: a bug caught in simulation costs an edit and a rerun, while the same bug found on a board costs debugging on real hardware.

It helps to be precise about what simulation proves. Simulation tools verify functionality, meaning that the logic does what was intended for the scenarios the testbench exercises. They cannot, on their own, prove timing behavior on silicon. A functional simulation treats timing as ideal unless the testbench models otherwise, and it only covers the cases someone thought to write.

That leaves a failure mode every experienced FPGA team recognizes: a design can pass simulation and still not work in hardware. This is not an argument against simulation. It is the reason on-target testing (step 8) is a phase with its own effort rather than a formality at the end.

Step 5 and 6: synthesis, place and route, and closing timing

Synthesis: from HDL code to a gate level netlist

During synthesis, the synthesis tool generates a synthesized netlist of device primitives (look up tables, flip flops, DSP blocks and memory blocks) out of the HDL. For an FPGA, this gate level netlist maps onto the primitives of the chosen family, which is one reason the same RTL produces different results on different vendors' parts.

Two outputs deserve a careful read at this point: resource usage against the device, and the first timing estimate. Both tell you early whether the device choice and the architecture will hold.

The tools are vendor-specific. AMD/Xilinx devices go through Xilinx Vivado, with Vitis for the software side on SoCs. Intel/Altera devices use Intel Quartus. Lattice devices use Lattice Radiant or Lattice Diamond. InTechHouse engineers work in all of these environments. Synopsys Design Compiler is the equivalent synthesis step in an ASIC flow; it marks the boundary of this article rather than a part of it.

Place and route, and static timing analysis

Place and route maps the netlist onto the physical resources of the device. It decides where each element sits and how signals travel between placed elements. Static timing analysis then checks every path against the timing constraints: does each signal arrive before the next clock edge with margin, and does the design meet its timing requirements across operating conditions.

Closing timing is work, not a button. The causes surface here: timing constraints that were never written, so paths were never checked; a clock domain crossed without synchronization; too much logic between registers; or a device chosen with no headroom, which leaves the placer nowhere to go. Looping back to RTL is normal. A design that needs several passes between implementation and code is not failing. It is being closed.

This is also where vendor differences bite hardest. The same step has different names, different reports and different failure modes in each toolchain, and knowing which warnings matter in a given environment is much of what vendor experience buys.

Step 7: bitstream generation and programming the device

Bitstream generation turns the routed design into configuration data: a binary file the FPGA loads to become the circuit you described. It is the final step of implementation, and on a development board, programming the device with it is routine.

In a product, the picture changes. On an SRAM-based FPGA, the configuration is lost when power drops, so the bitstream is loaded onto the FPGA at every power-up from external non-volatile memory, or by the processor during boot on a SoC. The configuration path is therefore a design decision with consequences for the board and the boot sequence, not an afterthought.

The workflow also splits into two layers that a buyer should ask about separately: the logic itself, and how software is loaded onto the device and with which tools. This is the part that most often surprises a customer whose experience is software-only. The FPGA design can be correct while the boot chain and the tooling that delivers software to the processor are still undefined.

Step 8: bring-up, on-target testing and debugging

Bring-up is the first power-on of the design on real hardware, and it is where the simulation gap from step 4 comes due. Something works in simulation and then does not work in hardware. Adam Szychulec names this as a recurring event in FPGA work, not an anomaly, and it is the honest reason bring-up carries real development time.

Adam points to clock domain crossings as one of the causes he meets: a signal passed between two clocks without proper synchronization can pass every simulation run and fail intermittently on silicon. Other common causes are general engineering knowledge: testbenches that never modeled real timing, and missing or wrong timing constraints that left critical paths unchecked.

Debugging on target means instrumenting the design with an on-chip logic analyzer, capturing internal signals at clock speed, and reproducing the failing condition rather than guessing at it. Intermittent faults need a trigger that catches them, which often means adding instrumentation, rebuilding and waiting for the event again. The goal is not a design that works in simulation, but proof that the design works on the board. That gap does not disappear; experienced teams make it visible early. The failure modes themselves are covered in FPGA design mistakes.

Step 9: verification evidence, documentation and hand-over

Who decides when an FPGA design is finished? The customer's regime, not the supplier's habit. For some customers, a design that works is the finish line. For a regulated customer, working is the minimum: the design must also be testable, repeatably tested with evidence, and written to the customer's code standard.

The contrast is wide in practice. On one aerospace project InTechHouse delivered, the customer required none of this beyond a design that met its functional requirements. A rail customer required all of it. The flow was the same; the evidence expected at the end, and the scope of work needed to produce it, were not.

So the instruction for a buyer is simple to act on: before anyone quotes, ask what evidence you will need at the end of the project and who has to accept it. An evidence regime discovered late needs additional resources at the worst possible moment, and a supplier who quotes without asking is quoting a different job.

The hand-over package should then cover two layers. The first is the logic: RTL, documentation and test evidence showing the design meets the agreed requirements. The second is the software side: what runs on the processor, how it is loaded onto the device, and the tools needed to rebuild and reload it. A hand-over that covers only the first layer leaves the customer unable to maintain the product. What to ask a supplier about this is covered in How to choose an FPGA design company.

When the flow starts earlier: a mid-life upgrade begins with reverse engineering

Not every FPGA project starts with a specification. For a mid-life upgrade (MLU), the design process starts earlier, with reverse engineering of the existing design, because the original documentation may not exist. This is the variant of the flow a buyer in rail, defence or energy is most likely to need, and the one almost nobody describes.

The sequence adds steps at the front: understand what the existing device actually does, select a supported target platform, port the logic, then verify the new implementation against the behavior of the old one. InTechHouse has done this FPGA work on a legacy Spartan-3 safety design (see the case study below).

The commercial consequence matters as much as the technical one. A mid-life upgrade cannot be quoted like a greenfield project, because the discovery phase is unbounded until the existing design is understood. Treat discovery as its own stage before committing to an implementation estimate. More on the obsolescence side in FPGA obsolescence and mid-life upgrade, and on the cost side in FPGA development cost.

InTechHouse case study: migrating a legacy Spartan-3 safety design to a supported platform

A UK rail supplier needed a legacy FPGA safety design, built on the Spartan-3 family, moved to a platform that is still supported. The work started with reverse engineering of the existing design, the step that replaces specification in a mid-life upgrade. InTechHouse then selected the target platform and ported the logic to it. The new implementation was verified across two hardware variants of the product. The outcome was the existing safety function moved onto a supported platform, with the new implementation checked against both hardware variants.

‍