FPGA Builds Without Local Toolchains: An Intro to CaaS - Post #17
- Angelo Jacobo
- 1 day ago
- 6 min read
What if you could build an FPGA design with open-source tools without installing anything locally?
Getting started with FPGA development often means wrestling with toolchains, dependencies, and long build times before you even write HDL. Open-source tools like OpenXC7 are powerful, but setup can still be a barrier.
Compilation as a Service (CaaS) removes that friction. You write your design, submit it for remote compilation, and get back a bitstream with no local toolchain required.
If this sounds like something you would want to try, read on. This post shows how CaaS works in practice, starting with browser-based builds and moving to API-driven workflows.
Table of Contents
I. What is CaaS?
At a high level, Compilation as a Service (CaaS) means you don’t do the heavy FPGA compilation work on your own machine.
Instead of installing synthesis, place-and-route, and bitstream tools locally, the idea is simple:
You write your HDL code
You send it to a remote compilation service
You get back the results: bitstreams, logs, and reports
That’s it!
No worrying about tool versions, broken installs, missing dependencies, or whether your laptop can handle long builds. The compilation happens in a managed environment that’s already set up for you.
II. Browser-based Compilation as a Service (CaaS)
Symbiotic EDA provides a browser-based CaaS platform that you can try immediately, straight from your browser:
To see it in action, I tried one of the provided example projects: a simple blinky design targeting the QMTech Kintex-7 board.
The flow is refreshingly simple: select the project template, click submit, wait for the remote build to finish, and download the generated bitstream. That bitstream can then be loaded to the FPGA board.
The browser interface is intuitive and beginner-friendly, with many ready-to-use example projects. It’s especially useful if your goal is to explore open-source FPGA tools or learn the basics of the FPGA build flow without worrying about toolchain installation.
There’s also a clear user guide if you want more detail.
II.I When a Browser Isn’t Enough
That said, a browser-based workflow isn’t always ideal. If you already have a design on your local machine, prefer script-driven flows, or want to integrate compilation into automation or CI, uploading files through a web interface can start to feel limiting.
This is where the API-based CaaS flow comes in. It lets you keep your local development setup while offloading synthesis, implementation, and bitstream generation to the remote CaaS backend.
Of course, Symbiotic EDA CaaS platform also provides this API-based access.
III. CaaS Wizard API Access Demo
The API access guide for caas-wizard is already well documented, and I recommend skimming through the official guide first if you want a deeper reference.
That said, let’s skip the theory for now and go straight to the hands-on part!
III.I Installing caas-wizard
We only need to do this setup once. First clone the caas-wizard repository:
The main script we’ll be using is caasw.py. Since this script will be called every time we interact with the CaaS API, it would be desirable if we can make it accessible from anywhere.
In my case, I simply added the caas-wizard/ directory to my PATH in ~/.bashrc:
Finally, install the required Python dependency:
With that done, we’re ready to use the API.
III.II Preparing the Design
Unlike the browser-based CaaS which provides ready-made template projects, it is now up to us to prepare the design on our own. For this demo, I will be using the example demo projects from UberDDR3.
If you’ve been following this blog, you already know I’ve been working on UberDDR3, the open-source DDR3 controller, over the years. And if you’ve really been following along, here’s a small spoiler: UberDDR4 is coming soon :)
Back to the demo. Clone the UberDDR3 repository:
Inside the example_demo/ directory, you will find demo projects targeting multiple FPGA boards. You can choose whichever fits your setup.
In my case, I’ll be using the alinx_ax7325b project.
III.III Prepare the CaaS Configuration File
Inside the alinx_ax7325b/ directory, you’ll find a CaaS configuration file named caas.conf. This file tells the CaaS backend how to build your FPGA design:
The [project] section is required and describes the FPGA design itself: which toolchain to use, which device to target, and which files are part of the build. While this is already covered in detail in the API access guide, it’s worth briefly walking through it here.
For the alinx_ax7325b/ project:
Backend is OpenXC7, the open-source FPGA toolchain for AMD/Xilinx 7-series devices
Part specifies the exact FPGA device
Top is the name of the top-level HDL module (ax7325b_ddr3)
Constraint points to the XDC file for pin constraints (ax7325b_ddr3.xdc)
Sources includes all Verilog source files in the directory
Nothing fancy, just the essentials needed to describe the design.
The [caas] section specifies where the compilation will run. In this case, it points to the Symbiotic EDA CaaS server.
And that’s it. With this configuration file in place, everything needed for a remote FPGA build is ready to go.
III.IV Submitting the Design to CaaS
With everything in place, submitting the design to CaaS is straightforward. From inside alinx_ax7325b/, simply run:
That’s all it takes to kick off a remote FPGA build. :)
Below is the output from my run:
The tool archives the entire project including the configuration, constraints, and all source files before submitting it to the server. Once the compilation finishes successfully, the results are automatically downloaded, including both the build log and the generated bitstream.
Looking once again inside alinx_ax7325b/, you will see a new build/ directory. This directory contains the compilation log (top.log) and the generated bitstream (top.bit):
The downloaded bitstream can now be loaded to the FPGA board using openFPGALoader: (here is the install guide if you don't have it yet installed)
For the alinx_ax7325b/ demo project, KEY1 acts as reset. After releasing reset and waiting a few seconds, you should see all four LEDs light up indicating that UberDDR3 has initialized successfully and the built-in self-test (BIST) has completed.
At this point, your design is now up and running on real hardware, built entirely through CaaS. Congratulations!
IV. Submitting a GitHub Repo Directly to CaaS
So far, we’ve been submitting designs that already exist on the local machine. But what if your design already lives on GitHub and you’d like to send it straight to CaaS?
Of course, you could clone the repository and follow the same steps as before. However, caas-wizard supports a more convenient option: submitting a GitHub repository directly to the CaaS platform.
IV.I Prepare the CaaS Configuration File
From any directory you like, create a caas.conf file with the following contents:
Compared to the earlier caas.conf, there are only two differences.
The Giturl field tells CaaS which GitHub repository to fetch. In this example, we’re pointing directly to the UberDDR3 repository.
Since the repository is fetched starting from its root, the Constraint and Sources fields now include the full relative path (example_demo/alinx_ax7325b/).
Other than that, everything remains the same.
IV.II Submitting the Design to CaaS
With the configuration file in place, submit the job as usual:
Below is my terminal output:
Just like before, a build/ directory is created containing the log file (top.log) and bitstream (top.bit).
With this setup, we have successfully submitted an FPGA design directly from a GitHub repository to the CaaS platform. Again, congratulations!
IV. Conclusion
Compilation as a Service (CaaS) takes away one of the most painful parts of FPGA development: setting up and maintaining local toolchains. Instead of worrying about installs, dependencies, or long build times, you can focus on writing and testing your design while the heavy lifting happens elsewhere.
Whether you’re using the browser-based interface, a script-driven workflow, or even submitting a design straight from GitHub, the idea is the same: make FPGA builds easier and more accessible, especially when using open-source tools like OpenXC7.
If you’ve been curious about open-source FPGA flows but felt blocked by setup complexity, CaaS is a really good place to start. It keeps things simple without hiding the actual FPGA flow, and that makes it useful for learning as well as real projects.
That wraps up this post. Catch you in the next blog post!
Comments