What is FPGA design?

FPGA design is the process of describing digital hardware in a hardware description language (HDL), usually VHDL or Verilog, verifying that description in simulation, and turning it into a configuration that runs on a field-programmable gate array. Unlike software, the result is not a sequence of instructions. It is a circuit: thousands of operations happening in parallel on every clock cycle.

An FPGA is a chip full of configurable building blocks connected by programmable routing:

• Look-up tables (LUTs) implement small pieces of combinational logic.
• Flip-flops store state and define the clocked, pipelined structure of the design.
• Block RAM provides on-chip memory for buffers, FIFOs and line stores.
• DSP slices are hardened multiply-accumulate units for filtering, FFTs and image processing.
• I/O and clocking resources such as PLLs, high-speed transceivers and memory interfaces connect the design to the outside world.

FPGA design is about mapping your problem onto these resources efficiently: deciding what happens in parallel, where data is buffered, and how fast each part of the circuit must run.

FPGA vs ASIC vs processor: when to choose an FPGA

An FPGA is the right choice when you need hardware-level parallelism or precise timing, but a custom chip is not justified yet, or the design must be changeable after deployment.

Many ASICs start life on an FPGA: the RTL is proven on real hardware first, then taken to silicon once the design and the market are stable.

The FPGA design flow, step by step

Every FPGA project, from a single IP block to a full video pipeline, follows the same basic flow. The steps overlap and loop back on each other, but skipping one almost always costs time later.

1. Specification

Define what the design must do in measurable terms: interfaces, data rates, latency limits, throughput, target device and power budget. "Process 4K video" is not a specification; "accept 3840×2160 at 60 frames per second over a given interface with under one frame of latency" is.

2. Architecture

Break the system into blocks and decide how data moves between them. This is where you choose pipeline depth, clock domains, memory buffering and interfaces such as AXI4-Stream, and where you estimate LUT, block RAM and DSP usage against the target device. Architecture decisions are the most expensive to change later, so this step deserves the most experienced people on the team.

3. RTL design

Write the register-transfer level (RTL) description of each block in VHDL or Verilog. Good RTL is written for synthesis: clearly clocked processes, explicit registers, and structures the tools recognise and map to the right resources. A simple example in VHDL:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity counter is
  generic (WIDTH : positive := 8);
  port (
    clk   : in  std_logic;
    rst   : in  std_logic;  -- synchronous, active high
    en    : in  std_logic;
    count : out unsigned(WIDTH-1 downto 0)
  );
end entity counter;

architecture rtl of counter is
  signal count_r : unsigned(WIDTH-1 downto 0) := (others => '0');
begin
  process (clk)
  begin
    if rising_edge(clk) then
      if rst = '1' then
        count_r <= (others => '0');
      elsif en = '1' then
        count_r <= count_r + 1;
      end if;
    end if;
  end process;

  count <= count_r;
end architecture rtl;

4. Simulation and verification

Before anything touches hardware, prove the RTL works in simulation with testbenches that drive inputs and check outputs automatically. In simulation you can see every signal on every clock cycle; on hardware you can see very little. More on verification below.

5. Synthesis

The synthesis tool converts RTL into a netlist of the FPGA's primitives: LUTs, flip-flops, block RAM and DSP slices. Read the synthesis report. Unexpected latches, removed logic or memories inferred as flip-flops are early warnings that the RTL does not describe what you intended.

6. Place and route

Implementation places each primitive at a physical location on the device and routes the connections between them. Placement determines wire lengths, and wire lengths determine how fast the design can run.

7. Timing closure

Static timing analysis checks that every signal reaches its destination within the clock period set in your timing constraints. If any path fails, you go back to the RTL or architecture: add pipeline stages, restructure logic, or adjust constraints that were wrong. More on timing closure below.

8. Bring-up on hardware

Generate the bitstream, configure the FPGA and test against real interfaces and real data. Embedded logic analysers such as Vivado's ILA or Quartus's Signal Tap let you capture internal signals, but only a limited window of them. That is why bugs found here are far more expensive than bugs found in simulation.

VHDL vs Verilog for FPGA design

Both languages describe the same hardware, both are IEEE standards, and every major FPGA toolchain supports both. The differences are in how they help or hinder the engineer:

• VHDL is strongly typed and explicit. It is more verbose, but the compiler rejects many mistakes, such as mixing widths or signed and unsigned values, that Verilog would accept silently. It is widely used in Europe and in aerospace, defence and safety-related work.
• Verilog is more concise and closer to C in syntax, which makes it quicker to write and easier to pick up. It is widely used in ASIC design and in much of the US industry.
• SystemVerilog extends Verilog with stronger typing and, above all, powerful verification features. It is the basis of the UVM verification methodology.

In practice the better language is the one your team, your customer or your existing codebase already uses. Mixed-language designs are common and fully supported. For VHDL in depth, with examples and a self-checking testbench, see our VHDL design guide. At LogikHaus our design work is primarily in VHDL, with verification in both VHDL (OSVVM) and SystemVerilog (UVM).

Verification: where FPGA projects succeed or fail

Verification typically takes as much effort as the design itself, and on complex designs more. The goal is to find bugs where they are cheapest to fix: in simulation.

• Self-checking testbenches compare outputs against expected results automatically, so regressions are caught every time the design changes.
• Transaction-level models let testbenches drive interfaces such as AXI or video streams as whole transactions rather than individual signal wiggles.
• Scoreboards track what went into the design and check that the right data came out, in the right order.
• Constrained-random stimulus and functional coverage explore corner cases nobody thought to write a directed test for, and show which scenarios have actually been exercised.

OSVVM brings these techniques to VHDL as a free, open-source library, while UVM is the standard methodology in SystemVerilog. Our own work on communications IP such as FFT, QPSK/QAM and MIPI C-PHY relies on both to catch protocol corner cases that directed tests alone would miss.

Timing closure and clock domain crossing

A design that simulates perfectly can still fail on hardware if it does not meet timing. Three habits prevent most timing problems:

• Constrain everything. Every clock, every I/O and every intentional exception must be described in the timing constraints (XDC for Vivado, SDC for most other tools). An unconstrained path is not checked, so it can fail silently.
• Pipeline deliberately. Long chains of logic between registers limit clock speed. Adding register stages trades a few cycles of latency for a much faster clock.
• Treat every clock domain crossing as a design problem. A single-bit signal crossing between unrelated clocks needs a synchroniser, typically two flip-flops. Multi-bit values need a handshake or an asynchronous FIFO. Getting this wrong produces intermittent, temperature-dependent failures that are notoriously hard to find.

Common FPGA design mistakes

1. Debugging on hardware instead of in simulation. It feels faster at first, but visibility on hardware is tiny and every iteration needs a full rebuild.
2. Missing or incomplete timing constraints. The tools can only check what you tell them about.
3. Unsynchronised clock domain crossings. The design works on the bench and fails in the field.
4. Unintended latches. In VHDL, a combinational process that does not assign a signal on every path infers a latch. Assign defaults at the top of the process, and use process (all) in VHDL-2008 to avoid incomplete sensitivity lists.
5. Gated or derived clocks built from logic. Use the FPGA's clocking resources and clock enables instead.
6. Fighting the architecture. Writing RTL that the tools cannot map to block RAM or DSP slices wastes the device's most efficient resources.
7. Treating reset as an afterthought. Decide early which registers need a reset, whether it is synchronous or asynchronous, and how it is released safely.

FPGA design tools

Each FPGA vendor provides its own toolchain for synthesis, implementation and bitstream generation:

• AMD Vivado for AMD (Xilinx) FPGAs
• Altera Quartus Prime for Altera FPGAs
• Microchip Libero SoC for Microchip FPGAs such as PolarFire
• Gowin EDA for Gowin FPGAs

For simulation, the vendors include their own simulators, commercial options such as Questa are common in larger teams, and GHDL is a capable open-source VHDL simulator. OSVVM runs on all of them. Our FPGA boards and SOM modules cover several of these vendors.