Speaker
Description
Configuring hls4ml(High-Level Synthesis for Machine Learning) for a new scientific task is a manual loop. The user sets precision, reuse factor, strategy, IO type, and backend, runs HLS synthesis, and reads back latency and resource usage. A single synthesis pass takes minutes to hours, and the search space grows quickly when settings are tuned per layer. Domain experts in particle physics, gravitational-wave astronomy, and accelerator control often lack hls4ml-specific intuition for these parameters, so they default to safe choices that overuse resources or miss latency targets.
Existing work address parts of the loop problem. AutoQKeras and MetaML-Pro apply Bayesian optimization to co-tune per-layer bit-widths and other hls4ml parameters. SNAC-Pack (Weitz et al., 2025) runs multi-objective NSGA-II search guided by the rule4ml surrogate and exposes its YAML-driven pipeline to external agents through a Model Context Protocol layer. The wa-hls4ml benchmark and surrogate (Hawks et al., 2025) predict LUT, FF, DSP, BRAM, latency, and initiation interval directly from a network description, removing the need for full synthesis on every step. Existing tools focus their search on precision and reuse factors. Choices such as backend (Vivado, Vitis, Quartus, Catapult) or IO topology (io_parallel, io_stream) are usually fixed by the user. An agent that reads the task description and reasons across all these parameters together can close this gap.
We propose HACE, the hls4ml Agent for Configuration Exploration that fills this gap. HACE takes a trained model from Keras, QKeras, or QONNX, a budget given as target FPGA, clock period, latency, and per-resource utilization, and a short description of the scientific task. It then uses four tools through function calls: the hls4ml Python configuration API, the wa-hls4ml resource and latency predictor, a quantization-aware accuracy checks on a held-out set, and HLS synthesis as the final verifier. Candidate configurations are scored against the predictor before any synthesis is run. Predicted Pareto-front candidates pass to HLS; a verifier agent accepts those that meet the budget and re-prompts the rest. Two design choices distinguish HACE from existing search tools.
HACE reasons about cross-cutting parameters that gradient-free search treats as fixed, including backend choice and IO topology, by drawing on hls4ml documentation provided in context. HACE also emits a written rationale for each chosen configuration, which supports review by physicists who must sign off on trigger or detector firmware. HACE can be evaluated using openly available resources. The wa-hls4ml dataset includes scientific exemplar models already synthesized for Xilinx FPGAs, the hls4ml Python API is open source, and current LLM APIs support the function-calling interfaces HACE requires. Useful indicators for this class of system include the number of syntheses runs avoided through pre-screening, the gap to default and Bayesian-optimized configurations on a Pareto front of latency and resource use, and the accuracy retained after the final configuration is applied. Both the wa-hls4ml paper (Hawks et al., 2025) and the hls4ml platform paper (Schulte et al., 2025) name this kind of integration as an open direction for the ecosystem.
| Do you plan to submit a 4-page extended abstract on OpenReview (only for Presentations/Posters)? | Yes |
|---|