hls4ml: four synthesis backends, three CI systems, and releases named after flowers

A model converter with four synthesis backends

What the package does is narrow: it takes a model trained in a mainstream framework and produces high level synthesis code, plus the configuration needed to compile that code, so you end up with firmware rather than a checkpoint. The walkthrough builds with the Xilinx toolchain, but that is a choice rather than a constraint. The file also names Vitis HLS, Intel's HLS tool, Catapult HLS, and experimental support for Intel oneAPI, with the target selected by passing a backend argument when building. That last word matters: experimental support is a different promise from the other three, and a team that picks it should expect to read compiler output. The build step itself is where the time goes, and the file says plainly that it might take several minutes, which is the normal cost of synthesis rather than a defect.

The first call downloads a model and writes your configuration

Getting started is three calls. The first fetches an example model from the project's example repository, which downloads the model file into your working directory and returns an example configuration file describing the conversion:

config = hls4ml.utils.fetch_example_model('KERAS_3layer.json')
print(config)
hls_model = hls4ml.converters.keras_v2_to_hls(config)

You can print that configuration to see the default parameters before changing anything, which is the part worth doing, because every later decision inherits from it. The model in the walkthrough is a small multi-layer file, which tells you the intended starting point is something you can convert in a minute and then read, rather than a production network you would be staring at compile logs for. A fourth call prints the full list of example models if you want to explore other architectures.

Release tags are named after flowers

The version scheme is the first thing a newcomer notices and the thing most likely to confuse a release script. The three most recent releases are 1.3.0, 1.2.0 and 1.1.0, and each carries a codename alongside the number: iris, hyacinth and gladiolus respectively. There is no fourth word to infer a pattern from, and no note in the file explaining the convention, so the safest approach is to treat the semantic version as authoritative and read the codename as decoration. The dating is reassuring, though: 1.1.0 landed in March 2025, 1.2.0 in November 2025 and 1.3.0 in March 2026, which is a release roughly every four to eight months for a tool whose output is firmware and therefore expensive to change.

Two archive identifiers appear in the same file

The citation instructions and the header badge disagree about the archive record. The badge near the top links to one Zenodo concept identifier, while the citation block below asks you to use a different, older Zenodo identifier for the software, along with a version field naming the current release and a year of 2026. Both are plausible: concept identifiers are minted once per record and get updated, while a fixed identifier points at a specific deposit. The problem is that the file does not say which is which, so a reader copying the citation block gets the older one and a reader copying the badge gets the newer one, and neither is told about the other. If you are citing this in a paper, use the block the file labels as the citation and check that the identifier resolves to the version you actually used.

Six feature papers, and an acknowledgement template

The citation section is longer than any other part of the file, and its structure is the point: cite the software, then cite the first publication, then cite the most recent overview paper, and then cite a further paper for each feature you actually used. The feature list covers convolutional networks, semantic segmentation for autonomous vehicles, distributed arithmetic, compression to binary and ternary precision, and spiking neural networks, each with its own record. That is a reasonable request from a project whose value is a body of methods rather than one algorithm, and it tells you which capabilities are considered substantial enough to have a paper behind them. The acknowledgements section asks for something specific as well: a sentence acknowledging the collective as an open community of contributors, with the individuals named, offered as a template to copy.

Three CI configurations and a C++ formatter in a Python package

The top-level listing explains a project that has been through more than one host. There is a GitHub Actions directory, a separate GitLab CI configuration, and a Jenkinsfile, all three at once, which is unusual and usually means one of them is the historical survivor nobody has removed. Submodules are present too, and the example models that the first tutorial command downloads also live in the repository as a directory, which explains why the fetch call works offline once cloned. Two other entries belong to a language the package is not written in: a C++ formatting configuration and a packaging include file, both of which exist because the generated firmware and the vendor overlays around it are C++ rather than Python. The manifest reinforces the mix by declaring a C++ classifier on a package that also declares itself Python-only.

One framework is capped at an old release

The dependency manifest is mostly ordinary, with an array library, a numeric library, a YAML parser, a quantizer package and one helper pinned to an exact version. The interesting entries are in the optional groups, and they exist per frontend: separate extras for the ONNX path, for Keras 3, for two different quantization toolkits, for a third-party distributed arithmetic library, for profiling, for documentation, and for optimisation with hyperparameter search. Two of those pin exact versions of the search and constraint libraries, which is sensible for reproducibility. The one to look at is the quantization group, which caps a machine learning framework at an old upper bound. If you want that path, the cap decides your framework version for you, and it will be the constraint you hit first on an otherwise unconstrained install.

Editorial conclusion

This suits a team with a latency budget that a GPU cannot meet and a hardware engineer who already knows which synthesis toolchain they have, because the abstraction is thin by design and the backend choice is a single argument. Two things to check before you commit. One optional dependency group caps a machine learning framework at an old upper bound, so the quantization path you most likely want may be the one that pins you to an older release. And the project asks you to cite feature-specific papers and to acknowledge a named collective in publications, which is a small amount of paperwork that is easier to satisfy at the start than to retrofit. Roots in trigger systems, with use cases now spanning fusion, quantum control, satellites and biomedical signals. Apache 2.0, release 1.3.0, last commit 2026-10-02.

Frequently asked questions

Official sources

1. fastmachinelearning/hls4ml on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases