The algorithm works in MATLAB. What comes next is a long stretch of engineering: pick a board, assign the pins, bring up each interface, port Linux, build a datapath between the processor and the fabric, write drivers, turn the algorithm into an accelerator core, integrate the system, and write the application on top. Five or six trades, and every handoff re-aligns an interface and buries a fault that only surfaces at the end. This is the stretch the toolchain automates.
Two inputs, one product
You hand in two things. An algorithm reference, written in MATLAB or Python, which defines what correct means. And a board schematic, a vendor board or your own, which defines what the hardware is. The toolchain does the rest: interface bring-up, embedded Linux, the processor-to-fabric datapath, the drivers, the generated accelerator core, system integration, and the application. The bar it holds itself to is simple: the result has to run for the long term and be ready to hand to a customer.
One flow, four board families
Edge computing is not one board. Vision boxes reach for Kria modules, industrial control uses MPSoC, radio and radar need RFSoC, and cost-sensitive or teaching projects go back to Zynq 7000. Most toolchains serve one family and start over for the next. Our board catalog spans all four: 21 boards, 20 supported today and one more declared, covering the boards the open PYNQ framework supports plus several AMD evaluation boards. MEASURED
A new board is a new description file. The traits a whole silicon family shares live in a device-adaptation layer, the facts specific to one board live in that board's description, and the core carries no part number, no pin, no address. So attaching a new board adds a description; the core does not move.
The catalog is the toolchain's reach, not a claim that every board is silicon-proven. Each board is derived from its own board file, and the link in this article was measured on one of them.
Delivered in five layers
The deliverable is five packages, one per layer: board bring-up, embedded Linux, on-chip interconnect, function modules, and the application. A higher layer that needs a lower one declares its prerequisite and references it by content hash rather than copying its files in. The benefit is direct: a customer who needs only bring-up and the operating system takes those two packages and nothing else. Each package carries its own self-check and runs from a clean export, with no dependency on leftovers from a development machine.
One run, end to end
The clearest proof that the flow runs from top to bottom is a complete system built entirely by it. On an AMD RFSoC board with two antennas, a USB webcam points at the desk, and a live dashboard shows the link. The camera image goes into the host, into Linux on the ARM, into an 802.11 transmitter in the FPGA, out through the converter, around a cable, back into the receiver on the same chip, then demodulation, error correction, a byte-by-byte check, and reassembly into the browser. Board bring-up, Linux, the datapath, the drivers, the physical-layer logic, the application and the dashboard were all produced by the toolchain.
Over the two real antennas, running HT at MCS2 with LDPC coding and raw 320x240 video, the live dashboard read 11.73 Mb/s of byte-verified goodput, 95.7% of the geometry ceiling, at a 0.0% packet-error rate, with 27,612 of 27,617 frames byte-exact. MEASURED Swapped onto a cable at the highest modulation-and-coding scheme, the same link sustained about 34 Mb/s, 94.5% of the computed ceiling for that configuration, every one of 1,367 received frames byte-exact, zero errors and zero re-arms across a continuous run. MEASURED The transceiver covers three physical-layer frame formats, non-HT, HT and VHT at 20 MHz single stream, all verified on this board across three separate power cycles, each paired with a deliberately corrupted control to confirm the check can fail. MEASURED
The error correction, in simulation
The link's error-correcting code is easier to characterise in simulation than on a near-error-free cable, so this one number is stated as a simulation result, kept separate from the on-hardware figures above. On an additive-noise channel, the rate-one-half code takes a raw bit-error rate of about 8 in 100 down to roughly 5 in a million after decoding, about four orders of magnitude of correction. MEASURED IN SIMULATION
What it means for you
If you have an algorithm prototype that is already verified, a target board chosen, and you need a complete edge system that runs on hardware, keeps running, and ships to a customer, this toolchain covers the large middle: all the engineering between the schematic and the product. Two things get the flow started: an algorithm reference that can produce a bit-comparable output, and a complete board schematic.
The decoders and physical-layer blocks this flow generates are described on the product pages.