FPGA MCP Bridge

Inspiration

FPGAs are really cool because you can re-wire the actual hardware logic for extremely high throughput, parallel computations where CPUs often-times fall short due to their sequential logic. FPGAs are notoriously tricky to program though because of timing closures and re-thinking hardware in a parallel fashion instead of sequential, so allowing AI to analyze the output data allows for a whole new world of testing and making.

How we built it

• The shell: a fixed hardware base built with LiteX. It makes the FPGA show up as a USB network card and handles networking, registers, counters and safety. Any data sent to UDP ports 7700–7707 flows through the AI's app in the chip's logic and back.
• One shell, seven boards: the same 48 MHz shell runs on boards from three FPGA vendors (Lattice ECP5, Gowin and Xilinx Artix-7), so an app written once runs on all of them.
• Manifest to hardware: an app declares its data channels and registers in a short TOML file. A generator produces all the glue logic and the exact port list the AI must implement.
• Closed-loop verification: every test case runs three ways: the Python model, a Verilator simulation that randomly stalls inputs and outputs, and the physical board. Any mismatch comes back to the AI with decoded records so it can fix itself.
• MCP server with guardrails: about 25 tools cover describe, create, simulate, build, load, test, benchmark and run live. Loading requires a passing simulation of the exact source files, and flashing requires passing hardware tests. API keys never pass through the AI, and a physical button on the board is a kill switch for all output.

Challenges we ran into

• Timing on a small chip: our FPGA only closes timing at about 52–60 MHz for a 48 MHz design, so long math chains fail. The signals app splits each trade's computation into 7 pipelined stages and met timing at 62.8 MHz.
• Backpressure: outputs can stall for hundreds of cycles, so the logic must stop accepting input instead of overwriting a result. The randomized stalls in simulation exist to catch exactly this.
• The real bottleneck wasn't the chip: the first hardware test run failed even though simulation passed. The test harness was pushing data faster than USB carries (about 1 MB/s), and a burst of signals filled the board's 4 KB input buffer. The logic was correct; the tests had to respect the physical link. Only real hardware could have told us that.
• Ordering across channels: each input channel is parsed separately, so settings and the data sent after them can arrive out of order. Apps either track which came first or latch settings when a run starts.

Accomplishments that we're proud of

• One sentence to live signals: a plain-English prompt became verified hardware trading on live market data within a single session, and every line of logic was tested on the real chip.
• Tested on real hardware: 20 of 20 tests passed on the physical FPGA, including 4,988 real Coinbase trades. No trades were dropped in the live run.
• Headroom: the logic handles about 5 million trades/second and the USB link about 90,000. Live Coinbase traffic is tens per second, so the chip has room to spare.
• 40× faster than Python at backtesting, on a small low-cost board.
• Safe to hand over: the guardrails let us give the AI full access, including live runs, flashing and network setup.

What we learned

• The model is the spec. A bit-exact Python reference model checked against both simulation and silicon is what makes AI-written hardware trustworthy.
• Simulation isn't enough. Simulation passed on the first try; only the physical board exposed the link-rate limits.
• Know your data. On a quiet morning, trades across 256 coins arrive at tens per second, while order book updates arrive at thousands. What you feed the chip matters as much as the chip.
• AI is a good hardware engineer when it can test. Given fast, honest feedback (simulation, timing reports, hardware results), it iterates the way a good engineer does.

What's next for FPGA MCP Bridge

• Order book feeds: stream every bid and ask change, thousands a second, so the chip can trade on order book imbalance, not just trades.
• Paper-trading gateway: turn signals into simulated orders with realistic fills.
• Inline network bridging: use the board's second USB port to pass whole Ethernet frames through the AI's logic, making it a true in-line firewall or filter.
• More hardware: gigabit Ethernet, Windows support, HDMI and GPIO as data channels, and hardware testing on the Xilinx and Gowin boards (only one board has been tested on hardware so far).

Built With

• ai
• fpga
• hardware
• mcp