Electronics Design AU
Digital

FPGA

FPGA design: HDL languages, synthesis, timing closure, IP cores, and FPGA platform selection.

FPGA design is a different discipline from firmware: it describes parallel hardware in HDL rather than writing sequential instructions, and it comes with its own selection, toolchain, and integration decisions once a team has decided an FPGA is the right platform. This subtopic covers FPGA design at the implementation level: choosing a device family, writing Verilog or VHDL, running the synthesis-to-bitstream toolchain, and integrating a hard processor when the application needs one.

What Is FPGA Design?

This subtopic covers what it takes to actually build with an FPGA once the platform decision is made: how to write HDL that synthesises to correct, efficient hardware; how the toolchain turns that HDL into a working bitstream; which device family fits a given application's resource, power, and toolchain requirements; and how to integrate a hard ARM processor when the application needs both custom hardware and a software stack. For the foundational concept (what an FPGA is and how its logic fabric works), see What Is an FPGA? in the parent Digital topic.

This subtopic is part of the Digital topic.

Why FPGA Design Matters

  • The platform decision is only the first choice — device family selection has real consequences. Choosing a family without adequate SERDES, LUT count, or toolchain maturity for the application means a costly mid-project respin, not a simple part swap.
  • HDL bugs that simulate correctly can still fail in hardware. Clock domain crossings, latch inference from incomplete conditional logic, and metastability are all invisible to a clean simulation and only surface as intermittent hardware failures — the kind of bug that's expensive to diagnose after the fact.
  • Timing closure is not optional polish — it's correctness. A design with negative slack in its timing report will fail intermittently at the target clock frequency in real hardware, even though synthesis and place-and-route complete without error.
  • A Zynq-class SoC-FPGA design is really two coordinated development flows, not one. Treating the processor software and the FPGA fabric hardware as a single combined build is a common source of confusing, hard-to-diagnose integration failures.

Key Concepts

  • LUT (Look-Up Table) — the fundamental FPGA logic element: a small RAM that stores the output of a Boolean function for every possible input combination, paired with a flip-flop to form a logic cell.
  • Synthesis vs implementation — synthesis maps HDL to a technology-independent netlist of FPGA primitives; implementation (place-and-route) assigns those primitives to physical device locations and routes the connections between them. See FPGA development flow.
  • Timing slack (WNS/TNS) — the margin between a timing path's budget and its actual delay; negative Worst Negative Slack (WNS) means the design will not meet its target clock frequency reliably in hardware, regardless of whether synthesis and implementation completed without error.
  • Blocking vs non-blocking assignment — the Verilog distinction (= vs <=) that determines whether sequential logic synthesises correctly; using the wrong one in a clocked always block is one of the most common sources of simulation-vs-hardware mismatches for newcomers to HDL.
  • PS-PL architecture — on a Zynq-class SoC-FPGA, the hard Processing System (ARM cores) and the Programmable Logic (FPGA fabric) are connected by an on-chip AXI interconnect and can be developed and brought up largely independently. See Zynq / SoC-FPGA devices.
  • Clock domain crossing (CDC) and metastability — any signal moving between two independently clocked parts of a design risks a flip-flop sampling it mid-transition and going metastable; a two-flop synchronizer, Gray-coded pointers, or an asynchronous FIFO are the standard fixes depending on whether the crossing signal is a single bit, a monotonic counter, or arbitrary data. See clock domain crossing and metastability.

Common Tools and Software

  • Vivado (AMD/Xilinx) — the primary toolchain for Xilinx 7-series, UltraScale, and Zynq devices: synthesis, implementation, timing analysis, IP Integrator for block-design-based Zynq PS-PL projects, and the Hardware Manager for JTAG programming and ILA-based debug.
  • Quartus Prime (Intel/Altera) — the equivalent toolchain for Intel Cyclone and Agilex devices.
  • Open-source toolchain (Yosys + nextpnr) — a fully open-source alternative for Lattice iCE40 and ECP5 devices, covering synthesis (Yosys) and place-and-route (nextpnr) without a vendor tool licence.
  • Simulators — Vivado's built-in XSIM, Icarus Verilog, Verilator, and ModelSim/Questa for pre-synthesis functional verification; simulating first is the standard discipline before trusting any HDL design in hardware.

Common Questions

Do I need to learn Verilog and VHDL, or can I pick just one?

Pick one to start. Most FPGA engineers develop a strong preference for either Verilog's C-like syntax or VHDL's strongly-typed, more verbose style, and either is fully capable of professional FPGA design. Verilog is more common in North American commercial FPGA work and has a larger base of freely available example code; VHDL is more common in European aerospace/defence and industrial contexts and its strict typing catches more mistakes at compile time. Reading the other language is a useful secondary skill once you're comfortable in your primary one, since vendor IP and reference designs appear in both. See Verilog and VHDL fundamentals for the practical syntax and synthesis-mapping differences.

How much FPGA fabric does a typical embedded product actually need?

Far less than the flagship parts in a vendor's lineup. Most embedded products doing a single custom protocol interface, a moderate amount of signal preprocessing, or a handful of parallel control loops fit comfortably in an entry-to-mid-range device (a few thousand to a few tens of thousands of LUTs). Reaching for a large, expensive part "for headroom" without profiling actual resource usage is a common and avoidable cost mistake. See How do you choose the right FPGA family? for a practical sizing and selection framework.

When does a design need a Zynq-class SoC-FPGA instead of a standalone FPGA?

When the application genuinely needs both a real-time or high-throughput hardware data path (the FPGA fabric's job) and a rich software environment (networking, a file system, complex application logic) that would be painful to implement in HDL alone (the processor's job). A standalone FPGA paired with a separate MCU over a board-level bus is often simpler and cheaper when the two sides don't need the PS-PL interconnect's bandwidth or tight coupling. See Zynq / SoC-FPGA devices for the PS-PL architecture itself, and FPGA vs Microcontroller vs ASIC for the platform decision this sits within. Zeus Design designs FPGA hardware and firmware, including Zynq/SoC-FPGA integration, for embedded products.

Knowledge Base

Platform Selection

HDL Implementation

Toolchain and Bitstream Generation

Device Family Selection

  • How Do You Choose the Right FPGA Family? — Artix-7 vs ECP5 vs iCE40 vs Cyclone 10: comparing LUT count, SERDES, DSP blocks, toolchain (Vivado, Quartus, open-source), power, cost, and decision framework for embedded product development

SoC-FPGA Integration

Forum Discussions

For clock domain crossing failures that pass simulation but fail intermittently in hardware, see this Digital-cluster thread in the parent Digital topic.

Forum Discussions

Related Topics