hls4ml tutorial and the Vitis install it assumes

This is a Jupyter Book, not a pile of notebooks

The repository is structured as a book rather than a notebook dump, and the root is where that shows. A _config.yml and a _toc.yml sit at the top, which are the configuration and table of contents files a Jupyter Book uses to assemble a site, and the README ends with a tableofcontents directive that has nothing to fill in locally because it is filled in when the book is built. There is an images directory for the figures those notebooks produce, and the rendered result is published at fastmachinelearning.org/hls4ml-tutorial, which is also the repository homepage. That layout has a practical consequence for a reader: the numbered directories are chapters, the ordering is deliberate, and the published site is the same content you would build yourself. It also means the notebooks are meant to be read top to bottom in one sitting rather than cherry-picked, since each chapter is written assuming the ones before it ran.

The chapter numbers skip from four to six

Five chapter directories are visible in the root: 1_getting_started, 2_quantization, 3_advanced_config, 4_advanced_models and 6_more_models. There is no 5. The numbering is not a typo you should correct on sight, because a gap like that usually means a section was renumbered, merged or retired while the other directories kept their prefixes, and the book build follows the table of contents rather than the directory listing. An archived directory sits alongside them, which is where superseded material is parked rather than deleted, and a TODO.md at the root is the visible placeholder for work that has not happened yet. The practical read for a new user is that the sequence gets you from a first model through quantization and advanced configuration into more advanced and additional models, and that whatever sat at position five is either in archived or was folded into a neighbour.

A local run starts with a vendor toolchain, not a package

The requirement that shapes everything else is stated once and stated plainly: running the tutorials requires AMD Vitis HLS to be installed, with a link to the vendor's own download page given rather than a version list. Once it is installed, the environment variables the toolchain needs are set by sourcing its settings script:

source /path/to/your/installtion/Xilinx/Vitis_HLS/202X.X/settings64.(c)sh

Two things in that one line are worth pausing on. The year is written as a placeholder, 202X.X, so the tutorial does not pin a Vitis HLS release and you are expected to substitute the version you installed. And the script name carries a (c) in it, which is shorthand for choosing between the csh and sh variants depending on the shell you are in, not a filename you will find on disk. Everything after this step is ordinary Python work, but this step is a several-gigabyte vendor installation that has to happen first.

The Python side is one environment file and three commands

Once Vitis HLS is in place, the Python environment is specified in a single environment.yml at the root, and the documented setup is three commands:

conda env create -f environment.yml
conda activate hls4ml-tutorial
source /path/to/your/installtion/Xilinx/Vitis_HLS/202X.X/settings64.(c)sh

The order matters more than it looks. The third command repeats the settings sourcing from the previous step, and it comes after activating the environment, which tells you the toolchain's variables have to be present in the activated environment's shell session rather than only in your login shell. The environment name is fixed as hls4ml-tutorial, so anything that launches a subprocess, from an IDE or a scheduler, needs that name spelled correctly. That is the whole local setup: one file describing the Python side, one vendor install, and a sourced settings script.

Binder is the path that skips the vendor install

Two of the three documented routes avoid the local toolchain problem in different ways. Binder is the first, linked both as a badge and under a heading of its own, pointing at a launch URL for this repository at HEAD. Opening it builds an environment from the repository and hands you the notebooks in a browser, which is the cheapest way to read the exercises and see what the expected outputs look like before you commit several gigabytes to a vendor installation. Because the build targets HEAD rather than a tag, what you get is whatever the default branch currently holds, and this repository has no releases to pin against, so there is no stable version of the tutorial to bookmark. The third route is the conda path above, which is the only one that gives you a local environment you can edit and re-run.

Two Python modules and a formatter guard the notebooks

A notebook course usually accumulates helpers, and this one keeps them at the root rather than inside a chapter. models.py and plotting.py sit beside the chapter directories, which is where a shared model definition or a plotting helper would live if every exercise reused the same ones. The images directory holds figures, and the presence of a .pre-commit-config.yaml at the root, together with badges for pre-commit and for the black formatter, says the notebooks are formatted automatically rather than by hand. That is worth knowing before you open a pull request against this repository, since a reformat of a notebook you did not touch is the normal outcome rather than a sign that you broke something. The repository also configures CI in two places at once, with a .github directory and a .gitlab-ci.yml, so the same checks appear to run whether the change arrives through GitHub or through GitLab.

There is no license file, and the docs never mention one

One thing to settle before you build on these notebooks is licensing, because the repository does not answer it. There is no LICENSE file at the root, and the license field for this repository is reported as unknown rather than as a named license, so nothing in the checkout tells you what you are allowed to reuse. That is a real gap rather than a formality, since notebooks are exactly the kind of material people copy into their own courses. The rest of the project metadata is tidy by comparison. There are no GitHub releases to track, the last push landed on 2026-09-28 on the default branch main, and the repository is not archived, so the notebooks are current. The companion material is a slide deck hosted on Google Slides rather than in the repository, described as an introduction plus more detail on each exercise, which means it can change without leaving a trace here. One last detail about the published copy: the repository homepage is recorded as an http address for the tutorial site rather than https, while the README links the same site without the trailing slash, which is the kind of small inconsistency that survives in a project whose documentation is this short. The primary language is recorded as Jupyter Notebook, which fits a repository whose product is the notebooks rather than the two Python modules beside them.

Editorial conclusion

It fits someone who has already decided to take a model through an HLS flow and wants worked exercises in the order the maintainers chose, with a Binder path for reading them before committing to a vendor toolchain. It does not fit someone looking for a library, since the tool itself lives elsewhere and this repository only teaches it. Before you reuse a notebook or build on these exercises, settle the licensing question yourself, because there is no license file at the root, and pin a Vitis HLS version yourself, because the documented path is written with a year placeholder rather than a release.

Frequently asked questions

Official sources

1. fastmachinelearning/hls4ml-tutorial on GitHub
2. Issues
3. Project website
4. README