Question bank — FPGA-based acceleration

False. An FPGA becomes a circuit shaped like your algorithm; there is no instruction fetch/decode loop — data flows through fixed hardware, not through a reused ALU. See Dataflow architectures.

False. Throughput = (ops per cycle) × clock. A 250 MHz FPGA doing 1000 ops/cycle crushes a 4 GHz CPU doing ~10; frequency is only one factor.

False. Latency is how long the first result takes ($S$ cycles); throughput is the steady rate after fill (1 result/cycle). For large $M$ (many items) throughput dominates and latency is a one-time cost. See Pipelining and Throughput.

True. A $k$-input LUT stores $2^k$ output bits — a full truth table. Every boolean function of $k$ inputs is a truth table, so writing it in makes the LUT that gate. See Configurable Logic Blocks (LUTs & Flip-Flops).

False. Speedup is $\frac{MS}{S+M-1}$, which only approaches $S$ as $M\to \infty$. For small $M$ (few items) the fill cost $S-1$ eats much of the gain.

False. If you are memory-bound ($P\le B\cdot I$, performance capped by bandwidth × intensity), extra units sit idle waiting for data. You must raise arithmetic intensity $I$ (buffer in BRAM), not add compute. See Roofline Model & Arithmetic Intensity.

False. Naive C synthesizes to a slow state machine, often slower than the CPU. You must expose parallelism — unroll, pipeline, partition arrays — and think in dataflow. See High-Level Synthesis (HLS).

True. For custom/irregular/low-latency streaming, FPGAs deliver the best performance/Watt; GPUs shine on regular dense SIMD math but burn more power. See GPU vs FPGA vs ASIC trade-offs.

False. Only the FPGA is field-programmable; an ASIC's logic is etched permanently. The FPGA trades some efficiency for that post-fab flexibility.

False. DSP slices are hardwired multiply-accumulate units. Building multipliers from LUTs is large and slow, so hardening them saves area, power, and boosts clock. See Domain-Specific Accelerators.

The $K\times$ is an upper bound on compute parallelism; real speedup is capped by input bandwidth — if you can't feed a new sample each cycle, the multipliers starve.

No — timing closure checks that the longest combinational path $\le$ clock period. A syntactically valid design that fails timing produces wrong data because values aren't stable at the clock edge.

Synthesis only maps logic to primitives (LUTs, DSPs). Place & Route assigns physical locations and wires — and wire delay depends on distance, which sets the achievable clock. Skipping it means no real hardware.

FLOP count doesn't decide it — the ratio does. With $P$ = performance, $P_{peak}$ = compute roof, $B$ = bandwidth and $I$ = intensity, you're compute-bound only when $B\cdot I\ge P_{peak}$; a high-FLOP kernel with low intensity $I$ is still memory-bound. See Roofline Model & Arithmetic Intensity.

Pipelining usually raises latency (more register stages) while raising throughput. You trade a longer first-result delay for one result every cycle. See Pipelining and Throughput.

BRAM is fast on-chip SRAM whose whole purpose is to avoid slow DRAM trips — it raises data reuse and keeps you compute-bound, the opposite of a slow memory.

It monotonically approaches $S$ from below and never exceeds it — the ratio caps at the stage count $S$ (the gap $S-\text{speedup}=\frac{S(S-1)}{S+M-1}\ge 0$).

The CPU re-fetches and re-decodes instructions and reuses one ALU each cycle; the FPGA lays out one physical unit per operation, so there's no instruction overhead and many ops run every cycle.

Their edge is width and depth (spatial parallelism + deep pipelines), not clock. Thousands of ops/cycle at a modest clock outproduce a few ops/cycle at a high clock.

The extra $S-1$ is the fill cost — the first result needs all $S$ stages before the steady one-per-cycle stream begins. It's a fixed overhead amortized over the $M$ items.

To raise arithmetic intensity $I$ (ops per byte fetched) so you stay compute-bound; each cached value feeds many operations, avoiding repeated slow DRAM fetches.

It gives data reuse — each input sample naturally feeds all $K$ taps over successive cycles, so you never re-fetch it from memory.

It offers near-ASIC efficiency but stays reprogrammable after fabrication, avoiding the ASIC's huge fixed NRE cost while beating the GPU's efficiency on custom streaming work.

HLS synthesizes it into a serial state machine with a low clock and no parallelism, so it loses the CPU's high clock without gaining the FPGA's parallelism.

Speedup $=\frac{1\cdot S}{S+0}=1$ — no benefit at all. With one item you pay full fill cost and get nothing to amortize it over.

You get no steady-state benefit — it degenerates to unpipelined behavior. Pipelines only win when the input stream is dense (a new item each cycle).

The clock period is still set by that shared maximum $t_{max}$; ties don't change closure — the longest path (however many share it) governs $T$.

There's nothing to compute — no multipliers, no output. It's a degenerate design; the parallelism gain ($\approx K$) collapses to zero because there's no work to spread.

Speedup saturates at (bandwidth / bytes-per-result), regardless of how many compute units you add — you're on the memory roof of the Roofline Model & Arithmetic Intensity, not the compute roof.

In resource terms yes, but it's underperforming — idle logic waiting on data. "Full of logic" and "fast" are unrelated when the bottleneck is bandwidth.