FPGAs In Trading Systems

A normal computer program is a list of instructions a processor works through one at a time — fetch this byte, compare it, branch, fetch the next byte. Even at billions of operations per second, that's still a queue: step 2 has to wait for step 1. An FPGA (field-programmable gate array) is different — instead of a program, you design an actual electronic circuit, shaped exactly for your task, where many parts of the work happen simultaneously in parallel wires and logic gates rather than sequentially in a queue. For a task like "read this market data packet, check if the price crossed my threshold, and if so emit an order," an FPGA does the whole thing in one pass through purpose-built circuitry rather than thousands of general-purpose instruction cycles.

Why this matters for tick-to-trade

Recall the pipeline from Tick-To-Trade Latency: wire → parse → decide → construct order → wire. On a CPU, each stage is software, and each stage waits its turn — even highly optimized code still pays for instruction fetch, branch prediction, and memory access on a chip built to be generally useful, not built for this task. On an FPGA, "parse the packet" and "check the price condition" can be two circuits sitting side by side, with the second one starting to evaluate bits of the packet as they arrive, before parsing has even technically "finished." The result is a pipeline measured in tens to low hundreds of nanoseconds rather than tens of microseconds — commonly a 20-50x speedup on the parse-and-decide stages specifically.

Worked example: the arithmetic of a race

A CPU-based system takes 30 microseconds tick-to-trade: 8μs to parse, 12μs for strategy logic, 6μs to build the order, 4μs of network stack overhead. An FPGA-based system replaces the parse and strategy-logic stages with dedicated circuits: parsing drops to 0.3μs (happening as bits stream in) and the price-threshold check drops to 0.1μs (a single comparator circuit, evaluated the instant the relevant field is available), while order construction and network stack — often still partly software-driven or a simpler hardware path — drop to about 2μs combined.

$\text{CPU total} = 8 + 12 + 6 + 4 = 30\mu s \qquad \text{FPGA total} = 0.3 + 0.1 + 2 = 2.4\mu s$

A roughly 12x reduction. In the race described in Tick-To-Trade Latency, that's the difference between cancelling a stale quote before or after the market has already traded through it thousands of times over a trading day.

The trade-off: speed for flexibility

FPGA logic is written in hardware description languages (VHDL, Verilog), compiled into a circuit layout, and "flashed" onto the chip — a change to the strategy means re-synthesizing and re-deploying a circuit, a process that can take hours, versus editing and redeploying software in minutes. In practice, firms keep FPGAs for the narrow, latency-critical, rarely-changing parts of the pipeline — packet parsing, simple threshold checks, basic risk gates — and leave anything that needs frequent tuning (model parameters, more complex decision logic) in software running alongside, so only the genuinely time-critical path pays the hardware tax.

In interviews

If asked why HFT firms use FPGAs instead of just buying faster CPUs, the answer is parallelism versus serial execution, not "FPGAs are faster chips" — a modern CPU can run at a higher clock speed than an FPGA, but it's paying overhead per instruction that an FPGA's dedicated circuit never incurs. Tie it back to Tick-To-Trade Latency: the FPGA shrinks specific stages of that pipeline, it doesn't change the physics of the wire.