Module 00 · Free Preview

The FPGA Mindset

Core thesis of this course: AI can write the HDL. The engineer who understands what happens to that HDL inside programmable silicon — timing, placement, routing, clock domains — is the one who makes the design actually work in hardware.

What this module covers

Before writing a single line of VHDL or Verilog, you need to understand what you are actually doing. When you describe hardware in HDL, a chain of physical events follows — synthesis infers logic gates, placement maps them to LUT cells, routing connects them through a fixed copper fabric, and timing analysis checks whether signals propagate within the laws of physics that the flip-flops enforce.

This module builds the mental model you need for every module that follows. It is the difference between using Vivado as a text editor and using it as a physical design tool.

Duration

~2 hrs

Reading + simulation exercises

Prerequisites

Digital logic fundamentals. Flip-flops, combinational gates, basic timing concepts.

Tool needed

None for this module. Vivado introduced from Module 3 onward.

Sections in this module

1

The FPGA MindsetWhy FPGA is not a microcontroller. What you are really describing when you write HDL.

2

Worked Example — Simulation Passes, Hardware FailsA short diagnosis from symptom to ILA evidence, root cause, RTL/XDC correction, and verified result.

3

Inside the FabricLUTs, flip-flops, carry chains, BRAM, DSP48, and the routing fabric — the physical resources your HDL maps to.

4

The V-ModelHow this course is structured. Why verification mirrors design at every level.

5

Concept LadderThe ten ideas that connect every module in this course.

FPGA Architecture V-Model LUT · FF · BRAM · DSP Programmable Routing Timing Fundamentals

01

Section 1

The FPGA Mindset

The most common mistake: treating FPGA development like software development. You write code, compile, run, debug. On an FPGA, "compile" is a physical process that maps your description onto silicon. The physics is always present, even when you cannot see it.

What you are actually doing

When you write HDL, you are not writing a program that runs sequentially on a processor. You are describing a circuit — a network of logic gates, flip-flops, and wires — that will be physically instantiated inside a sea of programmable silicon cells.

The key word is physical. Every signal has a propagation delay. Every flip-flop has a setup time and a hold time that the laws of semiconductor physics enforce. Every routing path has resistance and capacitance. The tool does not hide this — it enforces it.

Three worlds an FPGA engineer works in simultaneously

1

Behavioural worldWhat the system should do. Written in VHDL or Verilog. Simulated with a testbench. Independent of any physical device.

2

Logical worldWhat synthesis infers from your HDL. A netlist of gates and flip-flops. Still abstract — not yet assigned to physical cells.

3

Physical worldWhat place-and-route commits to silicon. Specific LUTs, specific flip-flops, specific routing tracks. Timing is now a hard constraint governed by physics.

FPGA vs Microcontroller — the fundamental difference

Aspect	FPGA	Microcontroller
Execution model	Concurrent hardware — everything runs simultaneously	Sequential instructions — one at a time
Parallelism	Inherent — limited only by available logic resources	Simulated — interrupts, RTOS, DMA
Timing control	Physical — you define and constrain every path	Abstracted — compiler and hardware handle it
Design artefact	Bitstream — a map of physical cell configurations	Firmware — a sequence of opcodes
Failure mode	Timing violation → metastability → random failures in hardware	Logic error → wrong output, but deterministic

Where AI tools fit: AI-generated HDL can produce syntactically correct, synthesisable code quickly. What it cannot reliably do is reason about your timing budget, your clock domain crossings, your resource constraints, or whether a chosen architecture fits your FPGA's fabric efficiently. That is the engineer's job — and it requires understanding the physical layer.

The bitstream is not a program

When you program a microcontroller, you write instructions into flash memory. The processor fetches and executes them in sequence. There is one execution engine, and it works through your code linearly.

When you program an FPGA, you write a bitstream — a large binary file that configures hundreds of thousands of individual cells. Each configuration bit sets a LUT function, a flip-flop mode, a routing switch, or an I/O standard. After programming, the FPGA is your circuit. There is no interpreter. There is no fetch-decode-execute. Signal propagates from source to destination through gates and wires at the speed permitted by the physics of CMOS silicon.

Mental model to carry throughout this course

HDL is a description language, not a programming language. A synthesiser reads your description and infers a circuit. A place-and-route tool maps that circuit to physical resources. A timing analyser checks whether the physics permits your design to function at the intended frequency. You are always describing hardware — the text is just the medium.

CASE

Worked Example · Symptom to Fix

Simulation Passes. The FPGA Output Behaves Randomly.

Why this case matters: behavioural simulation validates the stimulus you modelled. It does not automatically model a mechanical switch bouncing, an asynchronous input arriving near a clock edge, or an incomplete constraint set. Hardware exposes all three.

DesignA push-button toggles an LED mode in a 100 MHz FPGA design.

SimulationEvery ideal button pulse toggles the mode exactly once.

HardwareOne press sometimes toggles twice, does nothing, or changes the mode after release.

1. Initial symptom

The RTL simulation is clean, synthesis succeeds, and the bitstream is generated. On the board, however, the LED mode changes unpredictably when the button is pressed. Re-running the same action does not always reproduce the same result.

2. Possible causes — do not guess too early

Inside the FPGA

Setup or hold violation on an internal path
Unsynchronised asynchronous input
Reset release crossing the clock domain incorrectly
Incorrect edge-detection logic

At the board boundary

Mechanical contact bounce
Wrong pin or I/O standard in the XDC
Floating input or weak pull-up/down
Clock frequency or board-clock assumption is wrong

3. Evidence from Vivado and ILA

Timing summary

Post-route timing is met: WNS is positive. That makes an ordinary synchronous setup failure less likely, but it does not prove the asynchronous input is safe.

Methodology / CDC review

The external button feeds sequential logic without a recognised synchroniser. The path enters the clock domain directly.

ILA capture

The raw button changes several times during one physical press. Some transitions occur close to active clock edges.

Testbench gap

The simulation drove one clean, clock-aligned pulse. It never represented contact bounce or asynchronous arrival.

Original VHDL — unsafe-- Raw board input is sampled directly and used for edge detection.
process(clk)
begin
  if rising_edge(clk) then
    btn_d <= btn_raw;
    if btn_raw = '1' and btn_d = '0' then
      led_mode <= not led_mode;
    end if;
  end if;
end process;

4. Actual root cause

Two effects were combined: the mechanical button bounced, and the raw signal entered the 100 MHz clock domain without synchronisation. The ideal testbench hid both behaviours. The random-looking output was therefore not an HDL syntax problem and not a place-and-route timing-closure failure.

5. RTL and XDC correction

The repair has three parts: synchronise the asynchronous input, accept a new state only after it remains stable for a defined debounce interval, and generate one clock-wide pulse from the debounced signal.

Corrected VHDL — essential structure-- Two-stage synchroniser. ASYNC_REG helps Vivado place the stages correctly.
attribute ASYNC_REG : string;
attribute ASYNC_REG of btn_meta, btn_sync : signal is "TRUE";

process(clk)
begin
  if rising_edge(clk) then
    btn_meta <= btn_raw;
    btn_sync <= btn_meta;

    -- Update btn_stable only after btn_sync remains unchanged
    -- for DB_MAX clock cycles. Then form a one-cycle rising pulse.
    btn_stable_d <= btn_stable;
    if btn_stable = '1' and btn_stable_d = '0' then
      led_mode <= not led_mode;
    end if;
  end if;
end process;

XDC — boundary and clock intent# Constrain the actual board clock.
create_clock -name sys_clk -period 10.000 [get_ports clk_100m]

# Match the board schematic: package pins and I/O standard.
set_property PACKAGE_PIN W5 [get_ports clk_100m]
set_property PACKAGE_PIN U18 [get_ports btn_raw]
set_property PACKAGE_PIN H17 [get_ports led_out]
set_property IOSTANDARD LVCMOS33 [get_ports {clk_100m btn_raw led_out}]

# The button is asynchronous. Exclude only the path into the first
# synchroniser stage; all downstream synchronous paths remain timed.
set_false_path -from [get_ports btn_raw] -to [get_pins -hier *btn_meta_reg/D]

Constraint discipline: a false path does not make an unsafe crossing safe. The synchroniser fixes the hardware architecture; the scoped timing exception only tells STA how to treat the asynchronous boundary. Never false-path the entire downstream logic cone.

6. Result after correction

1clean mode pulse per valid press

0unexplained changes in repeated board tests

PASSpost-route timing and CDC review

Reusable debugging sequence

Observe the symptom → list causes across RTL, constraints, clocks and board inputs → collect report/ILA evidence → identify the boundary condition the testbench omitted → correct the architecture first → constrain it accurately → repeat the hardware test.

02

Section 2

Inside the Fabric

An FPGA is not a blank slate. It is a fixed array of configurable resources connected by a programmable routing fabric. Understanding what those resources are — and what they cost — is the foundation of every architecture decision you will make.

Why this matters before you write HDL: When you write if rising_edge(clk), you are inferring a flip-flop. When you write a multiply-accumulate, you are (or should be) inferring a DSP48 block. If you do not know what physical resource your HDL maps to, you cannot reason about area, timing, or power.

The LUT — Look-Up Table

What it is physically

A LUT is a small SRAM block with N address inputs and 1 output. In a Xilinx 7-series device, each LUT has 6 inputs (LUT6). The 64-bit SRAM content is loaded by the bitstream and defines the truth table of any 6-input Boolean function.

It is, physically, a 64-word × 1-bit memory. The combinational logic you describe in HDL is implemented by writing the right values into this memory.

What this means for you

Any 6-input combinational function costs exactly one LUT. A 7-input function costs two LUTs. Complex arithmetic that overflows LUT inputs will use carry chains — shared resources between adjacent LUTs that implement fast ripple-carry addition.

Synthesis reports tell you LUT count. When that number gro ws unexpectedly, a function became too wide or a priority encoder was inferred where you did not intend one.

VHDL inference-- This describes a 3-input mux — synthesises to one LUT6
process(sel, a, b, c)
begin
  case sel is
    when "00" => y <= a;
    when "01" => y <= b;
    when others => y <= c;
  end case;
end process;

The Flip-Flop

Physical reality

Each LUT6 in a Xilinx slice is paired with a D-type flip-flop. The FF samples its D input on the rising (or falling) edge of a clock signal and holds the value until the next edge. This is not an abstraction — it is a physical storage element with real setup and hold time requirements.

Setup time (tsu): The D input must be stable for this long before the clock edge arrives. Hold time (th): D must remain stable for this long after the clock edge. Violate either, and the FF enters a metastable state — its output is indeterminate for an unpredictable time. In hardware, this manifests as random, unrepeatable failures.

The timing constraint is not a software check — it is physics. A timing violation does not throw an error at runtime. The circuit operates, but occasionally produces wrong values. These failures are non-deterministic and extremely difficult to debug in the lab. Static timing analysis in Vivado exists to catch this before the bitstream is generated.

BRAM — Block RAM

What it is

Dedicated 36Kb dual-port SRAM blocks scattered across the FPGA fabric. They are not built from LUTs — they are hard macros with fixed timing characteristics. A Xilinx 7-series device has between 50 and 1000+ BRAM blocks depending on part size.

When to use it

Any time you need to store a data array — FIFOs, lookup tables, frame buffers, coefficient stores. Inference is automatic: write a synchronous RAM description in HDL and the synthesiser maps it to BRAM. Failing to infer BRAM (and using LUTs instead) wastes fabric and degrades timing.

DSP48 — Digital Signal Processing Block

The physics of arithmetic

A multiplier implemented in LUTs is slow and area-hungry. A DSP48E1 block (7-series) is a hard-macro 18×25-bit pre-adder + multiplier + post-adder cascade. It runs at over 500 MHz in a −1 speed grade device. Building the same function from fabric LUTs might achieve 150 MHz.

More importantly, DSP48 blocks have a fixed cascade input — they connect to adjacent DSP blocks through dedicated fast routing, enabling FIR filters, MAC units, and complex arithmetic without touching the general routing fabric.

In Module 2 (Architecture & Partitioning), you will learn to identify which parts of your design belong in BRAM and DSP before writing a line of RTL — because retrofitting these decisions later is expensive.

The Routing Fabric

Between every LUT, FF, BRAM, and DSP block runs a programmable routing fabric — a grid of wire segments and programmable switches. The bitstream configures which switches close, creating your signal paths. This routing has resistance and capacitance, which means it has delay. That delay is not fixed — it depends on which routing resources the tool selects.

Routing congestion is one of the most common causes of timing closure failure in real designs. When too many signals compete for the same routing tracks in one area of the die, the tool is forced to use longer, slower paths — and your timing budget collapses. Module 6 covers how to read the congestion map and use placement constraints to resolve it.

The hierarchy: what maps to what

1

Combinational logic → LUT6Any Boolean function of up to 6 variables. Wider functions cascade multiple LUTs.

2

Registered output → LUT6 + FF pairA synchronous flip-flop inference adds the paired FF. Clock enable and reset are built-in.

3

Memory arrays → BRAMSynchronous dual-port arrays inferred automatically. Asynchronous reads may use LUT RAM (distributed RAM) instead.

4

Multiply-accumulate → DSP48Inferred when the multiplier fits within DSP48 port widths. Check the synthesis report to confirm inference.

03

Section 3

The V-Model

This course is structured around the V-model of hardware development. The left side decomposes a system from specification down to physical implementation. The right side verifies each level of the decomposition — in the same order, from physical upward. The bottom of the V is the silicon itself.

Course Structure — V-Model

Design Implementation Verification

Abstraction ↓Confidence ↑

M1

Behavioural SpecificationWhat the system must do

verifies

M10

System ValidationSpec satisfied in silicon?

M2

Architecture & PartitioningBlocks, clock domains, BRAM/DSP

integrates

M9

CDC & IntegrationMetastability & synchronisers

M3·4

RTL — VHDL & VerilogType-safe hardware description

times

M8

Static Timing AnalysisSetup, hold, WNS, TNS, WHS

M5

Synthesis & OptimisationRTL → netlist · LUT/FF/BRAM/DSP

checks

M7

Post-Synthesis VerificationGate-level sim · equivalence checking

M6

Place & Route — bottom of the VBitstream · physical · routing · placement

Left descends: abstraction decreases — spec to silicon Right ascends: confidence accumulates — silicon back to spec

04

Section 4

Concept Ladder

Ten ideas that connect every module in this course. Each one builds on the previous. If you find yourself lost in any module, trace back to the rung where the thread broke.

1. HDL describes hardware, not behaviour VHDL and Verilog are hardware description languages. Every construct you write synthesises to a physical circuit. The mental model is always: what gate or flip-flop does this produce?

2. The FPGA fabric has fixed, finite resources LUTs, FFs, BRAM, and DSP48 blocks are real silicon structures. Your design competes for them. Resource estimation before RTL is the difference between a design that closes timing and one that does not.

3. Synthesis infers, it does not compile Synthesis reads your intent and infers the closest matching hardware. It does not execute your code. The synthesis report is feedback — read it, do not just check for errors.

4. Timing is physics, not a software check Setup and hold time are semiconductor physics. A timing violation is not a warning — it is a prediction of hardware failure. Static timing analysis is how you check physics before programming the device.

5. Clock domain is an architectural decision Every flip-flop belongs to a clock domain. Signals crossing domains without synchronisation will cause metastability. This decision must be made at architecture time — not fixed during implementation.

6. BRAM and DSP are the performance enablers General LUT-based arithmetic and memory are area-hungry and slow. BRAM and DSP48 are hard macros that run at 2–3× the clock rate of equivalent LUT logic. Plan your architecture around them.

7. Place-and-route determines actual timing Post-synthesis timing is estimated. Post-implementation timing is real — it reflects actual routing delays on actual die locations. The implementation report is the truth.

8. VHDL enforces type safety; Verilog does not VHDL's type system catches mistakes at compile time that Verilog will silently synthesise into hardware bugs. Understanding this difference is not academic — it changes how you debug.

9. Verification mirrors design at every level For every design decision, there is a corresponding verification step. Testbench validates RTL. STA validates timing. ILA validates hardware behaviour. They are not sequential — they are paired.

10. The bitstream is the design — not the HDL The HDL is your description. The bitstream is what runs. Between them: synthesis, P&R, timing closure. A design that simulates correctly but fails timing closure will fail in hardware — always.

05

Course Map

FPGA Design for Hardware Engineers

Ten modules. One design taken from behavioural specification to hardware validation. Click any module to see what it covers.

00 The FPGA Mindset CURRENT ›

LUT, FF, BRAM, DSP48, routing fabric. Why HDL is hardware description, not a program. The V-model structure of this course.

01 Behavioural Specification LEFT ↓ ›

Defining what the system must do before writing RTL. Timing budgets, interface contracts, throughput requirements.

02 Architecture & Partitioning LEFT ↓ ›

Decomposing the spec into blocks. Clock domain planning. BRAM and DSP48 pre-allocation. Resource budgeting before RTL.

03 RTL Design in VHDL LEFT ↓ ›

Entities, architectures, processes, signal vs variable. Type safety and process safety.

04 RTL Design in Verilog LEFT ↓ ›

Same design, Verilog. Blocking vs non-blocking. Where Verilog silently synthesises unintended hardware.

05 Synthesis & Resource Optimisation LEFT ↓ ›

What Vivado does to your RTL. LUT, FF, BRAM, DSP48 inference. Reading the synthesis report.

06 Place & Route + Physical Constraints BOTTOM ◆ ›

The bottom of the V. Placement constraints — Pblocks, LOC, BUFG. Routing congestion. Bitstream generation.

07 Post-Synthesis Verification RIGHT ↑ ›

Gate-level simulation + logic equivalence checking. Verify the synthesised netlist matches the RTL before P&R commits to silicon.

08 Static Timing Analysis RIGHT ↑ ›

Setup and hold — the semiconductor physics. Clock skew, jitter, uncertainty. Reading WNS, TNS, WHS in Vivado.

09 Clock Domain Crossing & BRAM/DSP Verification RIGHT ↑ ›

Metastability physics. Synchroniser design. BRAM read/write timing. DSP48 pipeline latency.

10 System Validation & Capstone RIGHT ↑ ›

Does the implementation satisfy the original specification? ILA for in-hardware debug. The complete worked design.

06

Glossary

Terms & Definitions

LUT (Look-Up Table)Fabric

A 6-input, 1-output SRAM block that implements any Boolean function of up to 6 variables. The fundamental combinational logic element in a Xilinx 7-series device. 64 bits of configuration memory define the truth table.

Flip-Flop (FF)Fabric

A D-type storage element paired with each LUT in a Xilinx slice. Samples D on a clock edge and holds the value. Has real setup time (tsu) and hold time (th) requirements enforced by semiconductor physics.

BRAM (Block RAM)Fabric

Dedicated 36Kb dual-port SRAM hard macros embedded in the FPGA fabric. Faster and more area-efficient than distributed RAM built from LUTs. Inferred by the synthesiser when a synchronous array description is detected.

DSP48Fabric

A hard-macro arithmetic block in Xilinx devices containing a pre-adder, 18×25-bit multiplier, and post-adder cascade. Runs at 500+ MHz versus ~150 MHz for equivalent LUT-based arithmetic. Used for multiply-accumulate, FIR filters, and similar patterns.

BitstreamImplementation

The binary configuration file that programs an FPGA. Each bit configures a LUT function, routing switch, FF mode, or I/O standard. The bitstream is the design — not the HDL.

SynthesisImplementation

The process of converting HDL to a gate-level netlist. The synthesiser infers logical components (gates, FFs, BRAM, DSP) from the intent of your HDL description. The synthesis report shows what was inferred.

Place & Route (P&R)Implementation

Maps the synthesised netlist to physical FPGA resources. Placement assigns each logical element to a specific cell. Routing connects them through the programmable switching fabric. Post-P&R timing is the true timing of the design.

Setup Time (tsu)Timing

The minimum time a D input must be stable before the clock edge arrives for the flip-flop to reliably capture the value. A setup violation means combinational logic is too slow to settle before the clock samples it.

Hold Time (th)Timing

The minimum time the D input must remain stable after the clock edge. A hold violation means a new value arrives too quickly after the clock edge — the FF captured neither the old nor the new value reliably.

MetastabilityTiming

The condition where a flip-flop enters an indeterminate state between logic 0 and 1. Caused by setup or hold time violations. The FF will eventually resolve, but the resolution time is unbounded — leading to random, unrepeatable failures in hardware.

Static Timing Analysis (STA)Timing

A verification method that checks all timing paths in a design without simulation. Computes worst-case propagation delays, compares against clock period constraints, and reports slack (WNS, TNS, WHS). STA is pre-silicon physics checking.

WNS (Worst Negative Slack)Timing

The most negative timing slack in a design — the largest amount by which setup time is violated. Negative WNS means the design will not function correctly at the target frequency. The primary metric of timing closure.

Clock Domain Crossing (CDC)Architecture

The condition where a signal originates in one clock domain and is captured by a flip-flop in a different clock domain. Without a synchroniser, metastability is guaranteed. CDC must be planned at architecture time — it cannot be fixed by the tools.

Routing CongestionImplementation

A condition where too many signal routes compete for the same routing tracks in a localised area of the die. Forces the tool to use longer, slower paths — degrading timing. Resolved through placement constraints or architectural changes.

ILA (Integrated Logic Analyser)Verification

A Vivado debug core that samples internal FPGA signals at runtime and stores them in BRAM for inspection via JTAG. Used when simulation passes but hardware fails — the lab equivalent of a logic analyser without needing probe access to internal nodes.

VHDLLanguage

VHSIC Hardware Description Language. A strongly-typed, concurrent HDL with strict process semantics. Signal assignments take effect at end-of-process, preventing race conditions. Type mismatches are caught at compile time.

VerilogLanguage

A hardware description language with C-like syntax. Uses blocking (=) and non-blocking (<=) assignments in always blocks. Blocking assignments inside sequential logic are a common source of hardware bugs that simulate correctly but behave incorrectly in silicon.

V-ModelMethodology

A systems engineering development model where each design phase on the left side has a corresponding verification phase on the right. Used in this course to structure the relationship between specification, RTL, synthesis, implementation, and hardware validation.

07

Module Quiz

Test Your Understanding

8 questions. Each tests a physical concept, not a syntax fact. If you get one wrong, the explanation will tell you which section to revisit.

Question 1 of 8

When you write HDL and the synthesiser processes it, what physical result is produced?