An AI-generated Wi-Fi receiver, verified bit for bit

AlgoSilicon engineering · 2026

MATLAB ships a reference design called "Image Transmission and Reception Using 802.11 Waveform and SDR". It gives a full 802.11a transmit and receive chain: cut an image into packets, modulate them into a Wi-Fi waveform, and on the receive side synchronize, error-correct, and reassemble the original image exactly.

Re-implementing that receiver on an FPGA by hand, translating the MATLAB line by line into RTL or HLS C, is tedious enough that the project sits on the shelf for years. Instead, we pointed our algorithm-to-silicon flow at the reference design and let it generate the receiver directly. In a few days the whole 802.11a receive chain went from a mathematical model to synthesizable Verilog, targeting the small Zynq-7010 FPGA on an ADALM-Pluto software-defined radio.

That raises a fair question. If no engineer wrote the hardware by hand, why should anyone trust that it is correct? This is the part worth explaining.

Generated in layers, checked at every layer

The flow does not write hardware in one leap. It builds the receiver in three layers and has a machine check each layer against the one above it:

A golden mathematical model: a floating-point reference whose waveforms match the MATLAB standard toolbox exactly. This pins down "the algorithm is the standard".
A cycle-accurate model: the reference reduced to low-bit-width fixed point with cycle-by-cycle hardware timing, checked bit-for-bit against the mathematical model.
The Verilog RTL: translated from the cycle-accurate model and checked, bit-for-bit, against it.

What matters is that every adjacent pair of layers is reconciled automatically, bit by bit, rather than by assertion. That the code was generated is almost beside the point. Fixed-point hardware cannot match floating point in the last decimal place, and it does not need to. Its one hard target is to recover the transmitted bits exactly.

Three-layer generation and checking: mathematical model, cycle-accurate model, Verilog RTL, each cross-checked — Generated in three layers, each cross-checked by machine: the float model matches the MATLAB waveform, the cycle-accurate model is bit-identical to it, and the RTL is bit-identical to that.

What the receiver does

The input is the stream of baseband I/Q samples the RF front end (the AD9363 on the Pluto) produces after down-conversion, not the antenna signal. The receiver turns that stream into clean data bits, mirroring the 802.11a standard step for step: it detects each packet and corrects the carrier frequency offset, runs a 64-point FFT to demodulate each OFDM symbol and equalizes every subcarrier, soft-demaps the symbols to likelihoods and deinterleaves them, then Viterbi-decodes the convolutional code and descrambles to recover the payload.

Receiver block diagram: synchronize, OFDM demodulate and equalize, soft demap, decode and descramble across two clock domains — The receiver signal chain, from baseband I/Q samples to data bits. The Viterbi decoder runs in its own slower clock domain, bridged by an asynchronous FIFO.

Received constellations for BPSK, QPSK, 16-QAM and 64-QAM, tight clusters at the ideal points — Received constellations across all four modulations. Tight clusters at the ideal points are the visual signature of correct synchronization, equalization, and demapping.

What the signal looks like

Two measurements describe the link itself. The transmit spectrum shows the OFDM signature: 64 subcarriers filling roughly 16.6 MHz inside the 20 MHz channel. The bit-error-rate curves show how each modulation behaves as the channel degrades: denser constellations carry more bits but need a higher signal-to-noise ratio to stay clean.

Transmit power spectral density of the generated 802.11a waveform, about 16.6 MHz occupied inside a 20 MHz channel — Transmit spectrum of the generated 802.11a waveform: 64 subcarriers form the OFDM signal, occupying about 16.6 MHz of the 20 MHz channel.

Bit error rate versus SNR for BPSK, QPSK, 16-QAM and 64-QAM through the full receive chain — Bit error rate versus signal-to-noise ratio through the full receive chain. Open markers sit at the measurement floor: no errors seen in 1,600 bits at that point.

The proof: a picture in, the same picture out

The most convincing test is end to end. We take waveforms generated by the MATLAB WLAN Toolbox, pass them through a 12-bit ADC model, and decode them in the fixed-point hardware. Across 24 packets and 38,400 bits, the receiver returns the transmitted bits with no errors. The transmitted image is reassembled exactly.

0 errors / 38,400 bits

MATLAB-generated 802.11a waveform, recovered by the fixed-point receiver

Original transmitted image and the image recovered by the FPGA receiver, identical — Transmitted image (left) and the image recovered by the receiver (right). Bit-exact recovery means the two are identical, pixel for pixel.

See it run on real captured signals

The same picture-in, picture-out test was run over the air on two antennas, and the captured samples were saved straight off the radio. The link analyzer below replays that real on-silicon capture in the browser, with no hardware attached. As the data rate climbs from BPSK to 64-QAM, the constellation sharpens, the channel response and spectrum update, and the image rebuilds as each packet is decoded.

Live link analyzer replaying real captured 802.11a data: constellation, channel response, spectrum, and recovered image across every data rate — The link analyzer replaying real captured over-the-air data across every data rate. The constellation, channel response, spectrum, and recovered image all come from the saved on-silicon samples.

Launch the interactive demo

Deployed across three tiers to fit the Pluto

The receiver PHY is small and portable. As a full place-and-route on a Zynq-7010 it closes a 162.7 MHz receive clock and uses 8,514 LUTs, 8,233 flip-flops, 5.5 block RAMs, and 43 DSP slices; characterized on a Zynq UltraScale+ RFSoC the same design reaches 309.6 MHz, showing clock headroom for faster standards.

But the ADALM-Pluto's chip is tiny. The full receiver (about 8,500 logic cells) plus the radio's own interface logic (about another 8,500) do not both fit the 17,600 cells on the device. So the deployment is split across three tiers: the rate-critical synchronization front-end and FFT stay in the FPGA fabric (the programmable logic, PL); the embedded ARM processor (the processing system, PS) moves the data with its DMA engine, radio driver, and USB bridge; and the heavier back end (channel estimation, equalization, soft demapping, and Viterbi decoding) runs on the host. The FPGA hands the processor frequency-domain symbols over DMA, the processor streams them to the host over USB, and both ends run the same reference model, so the split stays bit-exact end to end.

Three tiers: the sync front-end and FFT in the FPGA, data movement on the embedded processor, the receiver back end on the host — The deployment split across three tiers: only the sync front-end fits the FPGA, the rest runs on the host, bridged by DMA then USB.

The Vivado block design of the Pluto with the synchronization core spliced in, beside the radio interface, the DMA, and the Zynq processor — The actual Vivado project: our synchronization core (PL) spliced into the vendor Pluto FPGA design, beside the radio interface, the DMA, and the Zynq processor (PS).

Run that way over the air on two antennas, the delivered image comes back bit-exact on every data rate. Over a cable a continuous 90-second run decoded every packet (1,390 of 1,390); over the air the raw per-packet rate was 99.88% (831 of 832), the single miss a real wireless channel hit rather than a host drop, which the protocol retransmits so the image stays perfect.

Why this is repeatable

Nothing here is specific to one image or one packet. The same flow takes a signal processing reference (a different standard, a transmit chain, a custom OFDM link) and generates a verified receiver or transmitter the same way, with the same bit-exact checks at every layer. The receiver is available as the Wireless PHY IP core; the method behind it is available as a design service.