FPGA interview questions, with worked answers, RTL and numericals

An FPGA is a chip of programmable resources: LUTs and flip-flops for logic, block RAM, DSP slices, clock managers, I/O and often transceivers and hard processors, connected by programmable routing. A bitstream configures them into your design.

• FPGA: no mask cost, weeks to market, can be updated in the field. Higher unit cost and power, lower clock speed than an equivalent ASIC.
• ASIC: high NRE and months of fabrication, but the lowest unit cost at volume, best power and performance, and fixed after tape-out.

FPGAs win for low-to-medium volume, evolving standards, prototyping and anything that must be reprogrammed. ASICs win at high volume or tight power and performance targets.

A k-input LUT is a tiny 2^k-bit memory. The inputs form the address and the stored bits are the truth table, so a LUT6 can implement any function of six inputs with the same delay. Wider functions are built from several LUTs in levels, which is why "logic levels" matter for timing.

Arithmetic would be slow in LUTs alone, because a carry has to ripple through general routing. The dedicated carry chain runs vertically through the logic blocks with fast, fixed connections, so adders, counters and comparators are much faster.

Many LUT6s can also be split into two smaller LUTs sharing inputs, or used as 64-bit distributed RAM or a 32-bit shift register (SRL).

A blocking assignment (=) updates immediately, so later statements in the same block see the new value. A non-blocking assignment (<=) schedules the update for the end of the time step, so every right-hand side uses the old value, just as flops all update together on the edge.

// Wrong: collapses to one stage in simulation
always_ff @(posedge clk) begin b = a; c = b; end

// Right: two real stages
always_ff @(posedge clk) begin b <= a; c <= b; end

The blocking version can also simulate differently from what synthesis builds, a simulation/synthesis mismatch.

In a combinational block, if a signal isn't assigned on every path (an if without else, a case without default), the tool must remember its old value, so it builds a latch.

always_comb begin
  y = '0;              // default first: no latch possible
  if (sel) y = a;
end

Latches are bad in FPGAs: they're built from LUT feedback or used as latch-mode registers, they make timing analysis harder, and they're almost always unintended. Use always_comb, assign defaults at the top, and read the synthesis log for latch warnings.

• Synchronous reset: sampled on the clock edge, fully timed, and the tool can merge it into logic. Needs the clock running.
• Asynchronous reset: acts immediately without a clock, useful at power-up, but de-asserting it near a clock edge can leave flops in different states (a recovery/removal problem).

The common rule is assert asynchronously, de-assert synchronously: pass the reset through a reset synchroniser in each clock domain so release is aligned to that domain's clock.

Equally important: don't reset what doesn't need it. Datapath registers that are overwritten anyway can skip reset, which cuts fanout, frees routing and lets the tool use SRLs and DSP pipeline registers.

A clock generated in logic (a flop toggling, a gate on the clock) doesn't use the dedicated low-skew global clock network. It adds skew, can glitch, and creates a new clock domain that needs its own constraints and CDC.

logic tick;
always_ff @(posedge clk) tick <= ~tick;        // every 2nd cycle
always_ff @(posedge clk) if (tick) q <= d;    // slow logic, same clock

The slow logic still runs on the main clock, so it's one domain and fully timed. If you need a real second frequency, make it with an MMCM/PLL or a clock-buffer divider so it sits on a global clock network and the tool knows its relationship to the source.

(* ASYNC_REG = "TRUE" *) logic s1, s2;
always_ff @(posedge clk_dst) begin
  s1 <= async_in;   // may go metastable
  s2 <= s1;         // has a full cycle to resolve
end

The first flop may go metastable, but it has almost a whole destination clock period to resolve before the second flop samples it, so the chance of a bad value reaching the logic becomes tiny.

MTBF = e^t_r/τ / (T₀ · f_clk · f_data). Resolution time is in the exponent, so it matters most: keep the two flops close together with no logic between them (that's what ASYNC_REG asks the tool to do), and add a third stage for very fast clocks.

• A dual-port RAM is written in the write domain and read in the read domain.
• Each side keeps a binary pointer with one extra MSB, converts it to Gray code, and passes it through a two-flop synchroniser into the other domain. Gray code changes one bit per increment, so a pointer sampled mid-change is either the old or the new value, never garbage.
• Empty is computed in the read domain: synchronised write pointer equals read pointer.
• Full is computed in the write domain: pointers equal except the top two Gray bits inverted.

Because the synchronised pointers are a few cycles late, the flags are pessimistic (full and empty may stay asserted a little long) but never wrong. Constrain the pointer crossings with set_max_delay -datapath_only rather than a plain false path.

create_clock -name sys_clk -period 8.000 [get_ports sys_clk_p]
# MMCM outputs are derived automatically from the input clock
set_clock_groups -asynchronous \
  -group [get_clocks -include_generated_clocks sys_clk] \
  -group [get_clocks -include_generated_clocks eth_rxclk]
set_input_delay  -clock eth_rxclk -max 2.0 [get_ports {rxd[*]}]
set_input_delay  -clock eth_rxclk -min 0.5 [get_ports {rxd[*]}]
set_max_delay -datapath_only 4.0 -from [get_cells wr_gray_reg*] -to [get_cells rd_sync1_reg*]

• Primary clocks on every clock input; MMCM/PLL outputs are usually derived automatically.
• Clock groups for truly asynchronous clocks (with proper CDC in the RTL).
• I/O delays, min and max, from the external device and board.
• Exceptions only with design intent: multicycle paths with clock enables, bounded max-delays for CDC buses.

Then check the report for unconstrained paths and clock-interaction warnings.

1. Check constraints: right periods, clock groups, I/O delays, missing exceptions. Many violations aren't real.
2. Read the failing paths: logic vs routing split, logic levels, fanout, which clock pair, whether they share a source.
3. RTL fixes: pipeline long paths, cut logic levels, remove unnecessary resets, register block RAM and DSP outputs, avoid wide muxes.
4. Fanout fixes: replicate high-fanout registers (max_fanout or physical optimisation).
5. Tool settings: implementation strategies, physical optimisation, retiming.
6. Floorplanning as a last step, for critical blocks or SLR crossings.

• Block RAM: kilobits each, synchronous read, true dual-port. Best for FIFOs, buffers and anything larger than a few hundred bits.
• Distributed (LUT) RAM: small, asynchronous read, uses LUTs. Best for small register files and shallow FIFOs.
• SRL: a LUT as a 16–32-bit shift register. Best for fixed delay lines; no reset.

logic [31:0] mem [0:4095];
always_ff @(posedge clk) begin
  if (we) mem[waddr] <= wdata;
  rdata <= mem[raddr];       // registered read → block RAM
end

A registered (synchronous) read is what lets the tool map to BRAM. An asynchronous read, or a reset on the memory array, forces LUT RAM or flops.

Every AXI channel transfers on the clock edge where both VALID (from the source) and READY (from the destination) are high.

• A source must not wait for READY before asserting VALID; otherwise two blocks can deadlock waiting for each other.
• Once VALID is high, the source must hold it and the data stable until the transfer happens.
• READY may depend on VALID, but VALID must not depend combinationally on READY.

AXI4 has five independent channels (write address, write data, write response, read address, read data). AXI4-Lite drops bursts for simple register access; AXI4-Stream has no addresses, just a data stream with TVALID/TREADY and TLAST.

In long pipelines a combinational READY becomes a timing problem; a skid buffer registers READY and holds the in-flight word in a second register.

Routing-dominated paths with huge fanout aren't a logic-depth problem. One register drives cells spread across the die, so the net is long and slow.

• Is the net a reset or enable? Remove resets from datapath registers that don't need them, and use a per-region pipelined reset tree.
• Replicate the driver: max_fanout on the register, or let physical optimisation duplicate it near its loads.
• Pipeline the control signal: register it once or twice before it fans out, if the logic tolerates the latency.
• Check that the loads aren't spread out unnecessarily; a pblock may help a tightly coupled block.

See the timing report walkthrough below for exactly this path.

1. Is the right bitstream loaded? Read a build-ID or version register.
2. Are clocks running and MMCMs/PLLs locked? Route lock signals to LEDs or an ILA.
3. Is reset released, with the right polarity?
4. Are the pins assigned correctly, with the right I/O standards?
5. Did synthesis remove logic? Check warnings for removed or unconnected cells; an unconnected output can trim a whole block.
6. Are enables or configuration registers written by software?
7. Did timing actually pass, with no unconstrained clocks?

Same bitstream, different result means the design has no margin somewhere, and part-to-part or board-to-board variation pushes one unit over the edge:

• Timing: paths that only just meet timing, or that are unconstrained (especially I/O and CDC).
• CDC: unsynchronised crossings that fail depending on the phase between clocks at power-up.
• Reset and initialisation: reset released before clocks are stable, or a race between configuration and power supplies.
• Board: different oscillator tolerance, power-supply noise, signal integrity on fast interfaces, a marginal solder joint.

Swap parts between boards, vary temperature and voltage, and check timing and CDC reports for unconstrained paths.

Adding the ILA changed placement and routing, and the bug went away. That points to timing or CDC sensitivity, not a logic error: a path or crossing that works or fails depending on where things land.

• Check timing with every clock constrained; look for unconstrained paths and marginal slack near the failing logic.
• Run a CDC report: unsynchronised crossings and multi-bit buses synchronised bit by bit are classic causes.
• Check asynchronous resets and their release.
• For debugging, use incremental compile or keep debug cores in the design permanently so placement stops shifting.

At that utilization, routing congestion makes almost every path slow. Free up resources before fighting individual paths:

• Move logic into hard blocks: memories in LUTs into BRAM, multipliers into DSPs, delay lines into SRLs.
• Remove unnecessary resets and reduce wide muxes and over-wide counters.
• Share resources for operations that aren't needed every cycle.
• Check the utilization report by hierarchy: debug cores or one oversized block often dominate.
• Reduce clock domains and control sets so packing gets more efficient.
• If it still doesn't fit, a larger device or a functional split is a valid engineering answer.

1. Reference clock: present, correct frequency, on the right quad's dedicated pins.
2. PLL lock and reset done for each channel.
3. Settings on both ends: line rate, encoding, protocol options, lane mapping and polarity.
4. Loopback to split the problem: near-end PCS, then PMA, then far-end. If internal loopback works, the issue is the channel or the partner.
5. PRBS tests and eye scans to measure signal integrity and adjust equalisation.