NEWS AND INFORMATION

AI-powered FPGAs? It’s already a reality!


Release date:

2026-09

Preface

Well-known early examples of AI applications include chatbots, self-driving cars, and strategy games such as chess and Go. Since the beginning of 2020, generative AI has been used to create images, audio, and video.

Two years ago, “artificial intelligence” was named the International Word of the Year in the 2024 Chinese Language Review. Last year, China’s user base for generative AI reached 515 million, with AI being deployed on a large scale across sectors such as medicine—where it is used for diagnosing various respiratory diseases—legal services—where it supports end-to-end case management—and the power industry, among others.

For a long time, FPGA development has been extremely challenging, typically requiring hardware engineers to manually write RTL code. Porting AI algorithm models to FPGAs is a complex and cumbersome process, which has hindered the large-scale, real-world deployment of AI technologies. This new approach—“AI‑driven FPGAs”—is reshaping the landscape: instead of relying entirely on manual hardware coding, an AI‑powered toolchain automates model pruning, operator mapping, search for the optimal hardware architecture, and comprehensive optimization. It seamlessly transforms a trained AI model into a hardware circuit that can be executed on an FPGA, bridging the gap between AI algorithms and FPGA‑based hardware deployment.

Installing a functional Linux distribution on a bare‑bones board typically requires an engineer to spend two days or longer, involving steps such as individually testing each peripheral, customizing the kernel, building the image, flashing the firmware, and debugging the boot process.

The board is running the program—from power-up to SSH remote login, the entire process is handled by AI.

(This article’s data source: the WeChat public account “AI-Driven PFPGA”)

1. What board are you using?

First, let me introduce the board card that Teacher Lei uses:

The piece that Teacher Lei is using is Xi’an Birui Electronics The “KCU115 High-Performance Signal Processing Platform” is provided. The board features one KCU115 FPGA and one RFSoC (ZCU67DR). The RFSoC includes a quad-core A53 processing system, on which Professor Lei ultimately ran Linux.

II. Don’t rush to install Linux—first climb one step at a time.

Before installing Linux, Teacher Lei first used AI to systematically check each grid of the board’s foundation. He didn’t proceed to the next grid until he had completed the inspection for the current one, leaving behind logs and measurement data. Starting with JTAG connectivity, we confirmed that both downloading and reading back data worked flawlessly. Next came the 4 GB of memory on the PS side—every one of over a dozen operating modes was thoroughly tested, with zero errors. Then we moved on to the Gigabit Ethernet interface, which delivered an actual throughput of 948 Mbps. Finally, we examined the three boot modes, the logic board’s memory, and the eight high-speed links between the two chips. Radio Frequency Front-End Each step has been completed; only the final step remains—installing Linux.       

The logic is simple: if a problem arises in the top tier, and the underlying foundation hasn’t been verified, you won’t be able to tell whether the newly installed component has failed or whether the issue was already present at the base. By testing one tier at a time, any problems that do occur will be confined to that specific tier. 。”

With a board that doesn’t come pre‑installed with an OS, the most common mistake is to jump straight to tuning for the final goal—then, when something goes wrong, you can’t even tell which layer is at fault. The key to wrapping up this kind of work in a day is to first verify each layer of the low‑level signal path one by one, documenting your findings along the way, and only then add higher‑level components. “This is why Teacher Lei didn’t start by coding Linux right away, and it also reflects my insights into using AI to drive FPGAs.”

III. How was Linux developed and installed?

Only after the groundwork was completed did we begin working on Linux.

Use petalinux-build to compile the entire system, which involves over six thousand build tasks and a kernel version of 6.6.40. After the build is complete, run pealinux-package to package the components, producing a boot image, a kernel image, and a root filesystem.

Copy these two partitions onto the SD card, set the switch to boot from the SD card, and power on. Upon startup, the bootloader loads the kernel and proceeds all the way to the login prompt:

Log in, bring the network interface up, assign it a static IP address, and you’ll be able to SSH into it from another machine. At this point, the board has become a networked device that can be accessed remotely.

IV. Achieving success in a single day is by no means due to good luck.

Teacher Lei believes that being able to use AI to install Linux on a development board provided by a partner within a single day hinges on: Of course, there were plenty of pitfalls along the way; the key was that we never relied on guesswork—every issue was pinned down by carefully reading the machine’s actual state.

First, there are the DIP switches. Just by looking at the switch settings, it’s hard to tell which boot mode has been selected. The AI simply reads the register in the chip that stores the boot mode—whatever value is stored is what gets returned.

There are two more minor issues. During the first boot, the system mounted a temporary root filesystem in memory, which obscured the actual root filesystem on the SD card—so it appeared to be working, but it wasn’t. Switching to mount from the SD card’s ext4 partition resolved the problem. Additionally, the network interface name in the kernel boot parameters didn’t match the real one, preventing network connectivity; changing it to the correct eth0 fixed the issue.

Throughout the entire process, Teacher Lei provided clear guidance on which peripherals to test, in what order, and what evidence to document for each. The AI’s tasks included: connecting the board, running tests, reading registers, traversing the kernel, flashing the card, reviewing boot logs, diagnosing issues, and modifying configurations. AI doesn’t rely on assumptions; it directly reads the actual state of the machine. This is precisely what matters most in hardware debugging: the machine’s real‑world behavior is far more reliable than any guesswork.

Keywords: