Framework Desktop unexpected usecase: FPGA Development

This article is about the small Framework Desktop computer and our unconventional experiment to use the Framework Desktop Computer to develop FPGA (Field Programmable Gate Array) applications.

Background​

Digital Integrated Circuits (IC) are designed by describing their logic using a Hardware Description Language (HDL). The most common HDL is Verilog, it is designed to model the logic of the IC. Field Programmable Gate Arrays (FPGAs) are used to simulate the logic described in Verilog. The logic designed with the Verilog model is synthesized into a bitfile which can be flashed onto the FPGA. The FPGA consists of a huge amount of lookup tables, which values are contained in the bitfile. The synthesis from Verilog to the bitfile is very computational demanding because there are a lot of optimisations for plac and route to be done. Thats why we investigate the capabilities of the Framework Desktop to perform these synthesis.

Cooperation​

This Blog article is a cooperation between the RiKuWe GmbH and TU Graz ISEC doctoral students who donated the FPGA board and the Vivado know-how.
Florian Hirner provided the knowledge for the Vivado Software Setup and benchmarking.
Selim Kirbiyik provided a reference setup and the FPGA, a Varium C1100 from AMD/Xilinx.

The Framework Desktop​

The Framework Desktop is a small desktop PC manufactured by the manufactured by Framework Computer, Inc. Framework aims to have reliable and repairable computers with first-level Linux support. The Framework Desktop features a Strix Halo Ryzen™ AI Max+ 395 with 128 GB onboard memory. The RAM operates at 8000 MT/s, which is faster than conventional pluggable memory. Despite the impressive specs of the CPU and the RAM, the combination is what makes the Framework Desktop special, because Strix Halo is able to allocate large chunks of the system memory to the GPU. A GPU with a lot of fast VRAM enables us to host Large Language Models (LLMs) with many parameters. Hosting large LLMs is otherwise only possible by leveraging expensive GPUs. The Framework Desktop enables the self-hosting of large LLMs cheaply.

RiKuWe Framework in day to day operation​

In a world where AI and LLMs gain more and more popularity, we cannot simply ignore their advantages and need to harness their power. As mentioned above, local inference with GPUs is quite expensive, and because we do not directly make money from it we did not invest. The Framework Desktop offers a cost-effective alternative for local inference. We use the llama.cpp-based inference server ollama hosted with Docker. Ollama on the Framework runs great with flash-based large language models; gpt-oss:120b runs with about 50 tokens per second. The roughly 100 GB of available shared VRAM also provides us with a large context window, which is important for coding tasks. We primarily use Ollama to automatically analyze all kinds of workflows, error-logs, support tickets, SBOMs, Helm charts, deployment manifests, and more text-based content. Local LLM inference using the Framework Desktop with Ollama primarily uses the GPU, so the 16 CPU cores are unused most of the time. To put the 16 AMD cores to good use, we also have a KVM virtual machine on the Framework Desktop running the Woodpecker CI build agent.

Our goals​

With the following setup we wanted to see if the Framework Desktop with its Strix Halo platform is suitable for FPGA development. FPGA development requires a fast computer with a lot of speedy memory. Usually a remote server, which is large, loud, and produces a lot of heat, is used. Development on a remote server is unpleasant because of the latency of remote desktop applications and the constant data transfer back and forth to/from the server. The Framework Desktop combines power, speed, silence, and efficiency in one single small package. It would be an awesome setup to have a computer like this for FPGA development; we only need to overcome some challenges.

Challenges​

The Case​

The main challenge is the small form factor of the Framework Desktop; the case and motherboard are Mini-ITX. The case is not usable for most of the larger FPGA boards, which are too long and too thick for the small Framework case. To use the Framework Desktop with an FPGA we need to work around the case, either by removing it or by using a PCIe riser cable to connect the FPGA on the outside of the case. For our experiment we used a PCIe riser cable, but for a more permanent deployment I would recommend only buying the Framework Desktop motherboard and using it with an off-the-shelf PC case or opening it as a workbench-style setup.

PCIe​

Another challenge to overcome was the PCIe x4 connector of the Framework Desktop, because the FPGA only fits in a PCIe x16 slot. PCIe is structured into lanes; each lane has the same amount of bandwidth. The more PCIe lanes the device is connected to on the motherboard, the more bandwidth is available for communication. Even though the FPGA has a physical PCIe x16 connector, it is possible to operate with much lower bandwidth, e.g., with a PCIe x4 connection. Operating only with PCIe x4 is totally fine for our use case because we simply did not need a higher bandwidth. So the only problem is that the physical connector of the FPGA (x16) does not fit into the Framework's PCIe slot (x4); to circumvent this issue we used an x16-to-x4 PCIe adapter.

The Power Supply​

The FPGA requires an 8-pin PCIe power connector, but the power supply of the Framework Desktop does not have one. We use another PC power supply to power the FPGA. A PC power supply can be turned on by connecting the PS-ON pin of the ATX 24-pin connector to ground. If the power supply is turned on, we connect it to the FPGA. It is important to connect the FPGA to the powered-down Framework first to establish a common ground connection. After that the FPGA is powered by the second power supply.

The Setup​

Hardware​

A large chunk of the setup details is described in the Challenges sections. The final hardware consists of a Framework Desktop with open side panel. The FPGA is connected via PCIe riser cable using a PCIe x16-to-x4 adapter. A second power supply is used to power the FPGA; it is turned on via a connection from PS-ON to GND. The FPGA is powered via the 8-pin PCIe connector from the external power supply. The FPGA features a USB-to-UART converter which can be used to debug the FPGA; it was connected via USB-C to USB-A to the Framework Desktop.

Software​

We used Xubuntu Linux 25.10 with Vivado 2022.2. We used Xubuntu because Ubuntu is the distribution supported by Vivado, and Xfce is more resource-friendly and works very well with Vivado (for any other application I would never use any Ubuntu-based distributions). We also needed to make sure to use a Linux kernel new enough to support Strix Halo and old enough to work with Vivado and the Xilinx PCIe drivers.
We used Xilinx DMA drivers to communicate to the FPGA via PCIe. The Xilinx DMA drivers include a set of testing scripts to test the PCIe FPGA communication.

Key Takeaways​

All in all it was a smooth experience; we had luck with the version of Xubuntu so everything worked pretty much out of the box. We will not describe the performance numbers in detail because the Verilog project used for synthesis was not a standard benchmark. The Framework Desktop achieved similar synthesis and implementation speeds compared to a similarly priced Ryzen 9950X3D, while being quieter and less power-demanding. For a permanent setup I would recommend only the mainboard without the Framework case and a generic ATX power supply so it is possible to power the mainboard and the FPGA with one power supply.