Question bank — FPGA-based acceleration

False. FPGA tumhare algorithm ki shape ka ek circuit ban jaata hai; koi instruction fetch/decode loop nahi hota — data fixed hardware se flow karta hai, na ki ek reused ALU se. Dekho Dataflow architectures.

False. Throughput = (ops per cycle) × clock. Ek 250 MHz FPGA jo 1000 ops/cycle karta hai, ek 4 GHz CPU jo ~10 ops/cycle karta hai use crush kar deta hai; frequency sirf ek factor hai.

False. Latency batata hai pehla result kitni der mein aayega ($S$ cycles); throughput fill hone ke baad ka steady rate hai (1 result/cycle). Bade $M$ (bahut saare items) ke liye throughput dominate karta hai aur latency ek one-time cost hai. Dekho Pipelining and Throughput.

True. Ek $k$-input LUT mein $2^k$ output bits store hote hain — ek full truth table. $k$ inputs ki har boolean function ek truth table hi hoti hai, to use LUT mein likh dene se LUT woh gate ban jaata hai. Dekho Configurable Logic Blocks (LUTs & Flip-Flops).

False. Speedup hai $\frac{MS}{S+M-1}$, jo sirf $M\to \infty$ par $S$ ke paas jaata hai. Chhote $M$ (kam items) ke liye fill cost $S-1$ zyada tar gain kha jaata hai.

False. Agar tum memory-bound ho ($P\le B\cdot I$, performance bandwidth × intensity se cap ho rahi hai), to extra units data ka intezaar karte hue idle baithte hain. Tumhe arithmetic intensity $I$ badhana hoga (BRAM mein buffer karo), compute nahi add karna. Dekho Roofline Model & Arithmetic Intensity.

False. Naive C synthesize hokar ek slow state machine banta hai, aksar CPU se bhi slow. Tumhe parallelism expose karni hogi — unroll karo, pipeline karo, arrays partition karo — aur dataflow mein sochna hoga. Dekho High-Level Synthesis (HLS).

True. Custom/irregular/low-latency streaming ke liye, FPGAs best performance/Watt dete hain; GPUs regular dense SIMD math mein shine karte hain lekin zyada power burn karte hain. Dekho GPU vs FPGA vs ASIC trade-offs.

False. Sirf FPGA field-programmable hota hai; ek ASIC ki logic permanently etched hoti hai. FPGA us post-fab flexibility ke liye kuch efficiency trade karta hai.

False. DSP slices hardwired multiply-accumulate units hote hain. LUTs se multipliers banana bada aur slow hota hai, isliye unhe harden karna area, power bachata hai aur clock boost karta hai. Dekho Domain-Specific Accelerators.

Woh $K\times$ compute parallelism ka sirf ek upper bound hai; real speedup input bandwidth se cap hota hai — agar tum har cycle mein ek naya sample feed nahi kar sakte, to multipliers bhookhe reh jaate hain.

Nahi — timing closure check karta hai ki sabse lamba combinational path $\le$ clock period ho. Ek syntactically valid design jo timing fail karta hai galat data produce karta hai kyunki values clock edge par stable nahi hoti.

Synthesis sirf logic ko primitives (LUTs, DSPs) par map karta hai. Place & Route physical locations aur wires assign karta hai — aur wire delay distance par depend karta hai, jo achievable clock set karta hai. Isse skip karne ka matlab koi real hardware nahi.

FLOP count decide nahi karta — ratio decide karta hai. $P$ = performance, $P_{peak}$ = compute roof, $B$ = bandwidth aur $I$ = intensity ke saath, tum compute-bound tab hote ho jab $B\cdot I\ge P_{peak}$; ek high-FLOP kernel jo low intensity $I$ wala ho woh phir bhi memory-bound hai. Dekho Roofline Model & Arithmetic Intensity.

Pipelining usually latency badhata hai (zyada register stages) jabki throughput badhata hai. Tum pehle result ki zyada delay trade karte ho har cycle mein ek result ke liye. Dekho Pipelining and Throughput.

BRAM fast on-chip SRAM hai jiska poora maksad slow DRAM trips se bachna hai — ye data reuse badhata hai aur tumhe compute-bound rakhta hai, ek slow memory se bilkul ulta.

Ye monotonically $S$ ke paas jaata hai neeche se aur kabhi exceed nahi karta — ratio stage count $S$ par cap hai (gap $S-\text{speedup}=\frac{S(S-1)}{S+M-1}\ge 0$).

CPU har cycle mein instructions re-fetch aur re-decode karta hai aur ek ALU reuse karta hai; FPGA har operation ke liye ek physical unit lay out karta hai, isliye koi instruction overhead nahi hota aur har cycle mein kai ops run hote hain.

Unka edge width aur depth mein hai (spatial parallelism + deep pipelines), clock mein nahi. Ek modest clock par hazaron ops/cycle ek high clock par kuch ops/cycle ko outproduce karta hai.

Extra $S-1$ fill cost hai — pehle result ko steady one-per-cycle stream shuru hone se pehle saare $S$ stages chahiye. Ye $M$ items par amortize hone wala ek fixed overhead hai.

Arithmetic intensity $I$ (fetch kiye gaye har byte par ops) badhane ke liye taaki tum compute-bound raho; har cached value kai operations ko feed karta hai, repeated slow DRAM fetches avoid karte hain.

Ye data reuse deta hai — har input sample naturally successive cycles mein saare $K$ taps ko feed karta hai, isliye tumhe use memory se kabhi re-fetch nahi karna padta.

Ye near-ASIC efficiency offer karta hai lekin fabrication ke baad reprogrammable rehta hai, ASIC ki huge fixed NRE cost se bachata hai jabki custom streaming work par GPU ki efficiency ko beat karta hai.

HLS use ek serial state machine mein synthesize karta hai jo low clock aur no parallelism wali hoti hai, isliye ye CPU ka high clock khoye bina FPGA ki parallelism gain kiye.

Speedup $=\frac{1\cdot S}{S+0}=1$ — bilkul koi benefit nahi. Ek item ke saath tum full fill cost pay karte ho aur use amortize karne ke liye kuch nahi hota.

Tumhe koi steady-state benefit nahi milta — ye unpipelined behavior pe degenerate ho jaata hai. Pipelines tab hi jeetti hain jab input stream dense ho (har cycle mein ek naya item).

Clock period phir bhi us shared maximum $t_{max}$ se set hoti hai; ties closure nahi badlate — sabse lamba path (chahe kitne bhi share karein) $T$ govern karta hai.

Compute karne ke liye kuch nahi hai — koi multipliers nahi, koi output nahi. Ye ek degenerate design hai; parallelism gain ($\approx K$) zero par collapse ho jaata hai kyunki spread karne ke liye koi kaam hi nahi hai.

Speedup saturate ho jaata hai (bandwidth / bytes-per-result) par, chahe tum kitne bhi compute units add karo — tum Roofline Model & Arithmetic Intensity ke memory roof par ho, compute roof par nahi.

Resource ke terms mein haan, lekin ye underperforming hai — idle logic data ka intezaar kar raha hai. "Logic se full" aur "fast" unrelated hain jab bottleneck bandwidth hai.