GOFER - A SYNTHESIS-AS-A-SERVICE PLATFORM FOR FPGA

GOFER A SYNTHESIS-AS-A-SERVICE PLATFORM FOR FPGA August 2025 AUTHOR(S): Anushka Bilandani IIIT Pune SUPERVISOR(S): Vladimir Loncar Dimitrios Danopoulos PROJECT SPECIFICATION This project focuses on enhancing the FPGA synthesis-as-a-service platform Gofer, addressing the challenges of tool installation, scalability, multi-user management, and reproducibility in FPGA High-Level Synthesis (HLS) workflows. The work was carried out during a nine-week research placement at CERN as part of the Next Generation Triggers activity, within the EPSFT (Experimental Physics – Software Frameworks and Tools) group. I worked under the supervision of Vladimir Loncar and Dimitrios Danopoulos, who guided the technical development and integration aspects of the project. The main objectives of the project were to abstract complex FPGA synthesis flows into a unified, cloud-based service layer, to implement robust scheduling and multi-user support for concurrent synthesis tasks, and to improve user accessibility through programmatic interfaces. The specific contributions include mapping tool-specific build features for vendor toolchains, developing a job scheduler with concurrency control to enable fair resource allocation, creating a Python client that communicates with Gofer’s REST API for streamlined job submission, monitoring, and result retrieval, and starting the development of a web-based user interface (UI) for Gofer to provide users with a graphical overview of job status, history, and results. By embedding this work within CERN’s broader efforts in scalable computing infrastructures, the project not only improves FPGA development workflows for individual users, but also contributes towards long-term goals of reproducibility, efficient resource usage, and integration into scientific computing pipelines. In this way, the project reflects the collaborative nature of CERN research, combining systems design with practical experimentation to support nextgeneration data processing and trigger applications. 1 ABSTRACT Field Programmable Gate Arrays (FPGAs) are a central technology in accelerating scientific computing, artificial intelligence, and real-time data processing. However, the tools required for FPGA development, such as Xilinx Vivado or Intel Quartus, are heavyweight, complex, and resource-intensive. Installing these tools on local machines requires significant technical expertise and large amounts of memory, making them inaccessible to many students, researchers, and developers. In shared remote environments, users face multi-tenancy issues, software version conflicts, and unstable toolchains that hinder reproducibility. This project enhances Gofer, a Python-based synthesis-as-a-service platform, which abstracts FPGA synthesis into a cloud-hosted backend. Gofer offers both interactive and asynchronous job execution, a REST API, and a Python client for workflow integration. Over nine weeks, the project delivered key components: mapping tool-specific features, designing a test scheduler to regulate concurrent builds, building a client to submit and track synthesis jobs, and initiating work on a web-based user interface that will allow users to monitor and manage jobs directly through a browser. The work improved the accessibility, scalability, and reliability of FPGA synthesis while providing insights into service design, job scheduling, client-server integration, and user interface development. 2 TABLE OF CONTENTS 1 Background 4 2 Motivation 5 3 Gofer - Synthesis as a Service Platform 5 4 Implementation Work 6 4.1 Tool-Specific Build Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2 JobSchedulerDesign................................. 6 4.3 PythonClientDevelopment ............................. 7 4.4 Web User Interface Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5 Challenges and Problem Solving 8 6 Outcomes and Learnings 9 7 Future Work 9 8 Conclusion 10 3 1 Background FPGAs are reconfigurable hardware devices that allow developers to implement custom circuits optimized for performance, latency, and energy efficiency [1]. They are particularly valuable in domains such as telecommunications, cryptography, scientific computing, and machine learning acceleration [10]. Traditionally, programming FPGAs required designing in Hardware Description Languages (HDLs) like VHDL or Verilog. High-Level Synthesis (HLS) tools simplified this process by allowing designs to be described in higher-level languages such as C, C++, or domain-specific languages. Figure 1: Visual summary of the key challenges in FPGA development addressed by Gofer: accessibility, reproducibility, and scalability. Despite these advances, the FPGA toolchain remains highly specialized. Vendor tools such as Xilinx Vivado HLS, Vitis HLS, and Intel Quartus HLS are closed-source, large in size, and require extensive system resources. They often demand more than 40 GB of memory during synthesis and optimization. Additionally, licensing models restrict usage, which complicates 4 collaborative research and teaching. As a result, there is a strong need for service platforms that abstract away the difficulties of tool installation and provide users with a reliable, scalable interface for FPGA synthesis. Cloud-based “synthesis-as-a-service” systems can democratize access to FPGA development by allowing users to focus on their algorithms while the platform handles infrastructure. 2 Motivation The motivation for developing Gofer arises from three persistent challenges in FPGA development: accessibility, reproducibility, and scalability. Vendor tools such as Xilinx Vivado, Vitis, and Intel Quartus are closed-source, large in size, and require extensive system resources [11,7,12]. Only well-resourced labs or companies can afford powerful workstations with sufficient memory to run these tools. For students or small research groups, this becomes a barrier that slows down experimentation [9,6]. By providing synthesis as a cloud service, Gofer eliminates the need for local installations, allowing anyone with internet access to submit jobs. Secondly, reproducibility in FPGA workflows is often fragile. Running the same design on two different systems can yield divergent results due to mismatched tool versions, inconsistent environment variables, or corrupted license setups [2,5]. In contrast, Gofer ensures that jobs always execute in a controlled, versioned, and containerized environment. This guarantees that synthesis outcomes are consistent, making experiments repeatable and reliable. Finally, scalability is a fundamental issue. Large design space explorations, where dozens of synthesis runs are required to evaluate different optimization parameters, are inefficient when done manually [3,8]. Users often need to queue jobs, track logs, and monitor results by hand. Gofer automates these processes by introducing a job scheduler, quotas, and multi-worker execution, enabling large-scale synthesis scans to run smoothly with minimal manual intervention. 3 Gofer - Synthesis as a Service Platform Gofer is designed to operate as a synthesis-as-a-service platform that hides the complexity of vendor tools behind a clean, programmatic interface. Users can submit jobs through a REST API, a dedicated Python client, or in the near future, a web interface. The Python client exposes simple methods such as .build(), which abstracts the submission of complex synthesis workflows into a single function call. For instance, a user experimenting with loop unrolling can trigger multiple builds programmatically and later retrieve the corresponding results, without dealing with tool installation or job scheduling. The platform provides both blocking and non-blocking modes of operation. In blocking mode, the client waits for synthesis results before proceeding, making it suitable for small jobs or interactive debugging. In non-blocking mode, the client submits the job and continues execution, allowing large experiments to proceed in parallel. This design offers flexibility to accommodate both casual users and power users running large-scale experiments. 5 Figure 2: Gofer Architecture Another important feature of Gofer is its fairness and resource management. By enforcing quotas and multi-worker scalability, Gofer ensures that multiple users can share the platform without interfering with each other’s results. Jobs are executed in isolated environments, which prevents environment mismatches and guarantees clean reproducibility. The architecture of Gofer is modular, allowing additional tools and interfaces to be integrated with minimal effort. While the initial implementation focused on Vivado, Vitis, and Quartus, the system was designed with extensibility in mind, making it possible to support specialized frameworks such as hls4ml and new user interfaces such as the web-based dashboard. 4 Implementation Work The implementation phase of this project focused on four major deliverables: tool-specific build mapping, job scheduler design, Python client development, and the web UI prototype. 4.1 Tool-Specific Build Mapping Each FPGA synthesis tool has its own unique set of commands, input requirements, and output artifacts. Vivado, for example, requires TCL scripts and produces reports on timing, resource utilization, and power consumption. Quartus follows a different structure, and Vitis introduces additional constraints for software integration. The project involved studying these workflows in detail and creating a unified interface within Gofer. The result is that Gofer can now accept user input in a standardized form and translate it into the correct commands for the chosen tool. This abstraction layer is critical for extending Gofer to additional tools in the future. 4.2 Job Scheduler Design The scheduler is the heart of Gofer’s multi-user capability. It was implemented using a thread pool model that enforces a maximum number of concurrent builds. For example, if the platform 6 Figure 3: Snapshot of testing via Swagger is configured with a pool of five workers, only five builds can execute simultaneously, while additional jobs are queued. Each job is tracked throughout its lifecycle, with logs capturing submission time, start time, and completion. To validate the scheduler, simulated jobs were executed using timed TCL scripts, allowing precise measurement of concurrency and queuing behavior. Tests confirmed that the scheduler correctly enforced limits, maintained order, and gracefully handled shutdowns. 4.3 Python Client Development The Python client provides an accessible interface for users to interact with Gofer’s REST API. The client exposes functions for submitting jobs, monitoring progress, and retrieving results. Behind the scenes, it manages authentication, constructs HTTP requests, and handles responses. The design goal was to make FPGA synthesis as simple as possible for end users, enabling them to focus on experiment design rather than infrastructure. The client also supports integration into larger pipelines, making it suitable for automated testing, research workflows, and teaching environments. 4.4 Web User Interface Prototype As a fourth component, work began on developing a web-based user interface for Gofer. The purpose of this UI is to provide users with a graphical dashboard to submit jobs, monitor their status, view build history, and download results directly through a browser. The prototype focused on laying the groundwork for a responsive frontend that communicates with Gofer’s backend via the REST API. This work opens Gofer to a wider audience, especially students and researchers who may be 7 Figure 4: Gofer Web Interface Figure 5: Gofer Web Interface less familiar with command-line tools or Python scripting. It also establishes the foundation for future visualizations of synthesis performance metrics and resource usage. 5 Challenges and Problem Solving The project encountered several challenges, particularly in creating a unified backend for multiple tools. Each vendor’s synthesis environment uses different configuration files, option sets, and output formats. Debugging these inconsistencies required extensive testing and iterative refinement. Another significant challenge was handling unexpected user input. In some cases, users submitted incomplete or malformed job descriptions, which caused synthesis failures. To address this, validation checks were added at the client and API levels to catch errors early. Maintaining synchronization between the web API, Python client, and the emerging web UI also proved non-trivial. As new features were added to the backend, both client interfaces 8