XLS designs run in host software and can generate hardware

The equivalence claim is the product

XLS implements a high level synthesis toolchain that produces synthesizable designs in Verilog and SystemVerilog from high-level descriptions. The description is short: accelerated hardware synthesis.

What is unusual is the second half of the story. An XLS design runs at native speeds for use in host software or a simulator, and that same design can generate a hardware block. The README states that the tools' correctness ensures, and provides tools to help formally verify, that the two are functionally identical.

That is a much stronger guarantee than simulation alone, and it is the reason to look at XLS rather than at a one-off HLS tool. If a function is written once and used in a testbench, in a software model and in a synthesized block, the expensive class of bug where the model and the hardware diverge is designed out rather than tested for.

The project frames itself as a Software Development Kit for the end of Moore's Law era, on the argument that specialised hardware forces software and hardware engineers into co-design. The concrete claim is narrower: write hardware IP once, use it as software until you need it in silicon.

Functions and procs cover two different shapes of hardware

XLS supports both optionally pipelined functions with pure-wire I/O interfaces, and what the documentation calls concurrent processes, or procs.

The distinction is the usual one about state. A function is combinational: inputs go in, outputs come out, and pipelining introduces registers between stages without changing the interface. That maps onto arithmetic, decoders and filters.

A proc is stateful. The README says procs allow induction over time and include more general communication interfaces. That maps onto anything with a memory, a counter that persists across cycles, or a handshake protocol, where the word-wire interface of a function is not expressive enough.

So the language choice is not stylistic. Deciding per component whether it is a function or a proc is part of the hardware design, and the documentation has a tutorial page dedicated to explaining what a proc is, which suggests it is the concept newcomers find least obvious.

DSLX itself is described as Rust-inspired, and the Colab walkthrough is a learn-it-in-Y-minutes tour of the language rather than of the toolchain.

Prebuilt binaries exist, and they are x64 Linux only

There is a release path, and it is worth using if you are evaluating the project rather than developing it. The README gives a shell sequence that queries the GitHub releases API with an Accept header and a pinned API version header, extracts the first tarball URL with grep, downloads it and unpacks it.

curl -O -L ${LATEST_XLS_RELEASE_TARBALL_URL}
tar -xzvvf xls-*.tar.gz
cd xls-*/
./interpreter_main --version

The tarball contains several separate tools, and the README tells you to observe the version numbers for each: interpreter_main, ir_converter_main, opt_main, codegen_main and proto_to_dslx_main.

That list is a compact map of the pipeline. The interpreter runs a DSLX program, ir_converter converts between representations, opt is the optimiser, codegen produces Verilog, and proto_to_dslx turns protocol buffer definitions into DSLX code.

The limitation is the platform: these binaries are for x64 Linux. Anything else is a source build.

Conda packages are also published, under the litex-hub channel rather than Google's own.

A source build is a two to six hour commitment

Everything except the Colab notebooks and the Linux binaries has to be built from source with Bazel. The instructions are for Ubuntu 22.04.

The timings are stated plainly and are the single most important fact for planning. On an average eight-core VM, a full initial build without the C++ front-end, described as DSLX only, may take about two hours. Including the C++ front-end may take up to six hours.

The distinction matters because the C++ front-end is xlscc, and it is not strictly needed if you only want the DSLX path. The two build commands reflect that.

bazel test -c opt -- //xls/... -//xls/contrib/xlscc/...
bazel test -c opt -- //xls/...

The first excludes the xlscc subtree; the second builds everything.

There is also a prerequisite step that looks incidental and is not: installing python3-dev, libtinfo6 and python-is-python3. The README explains that Ubuntu does not make /usr/bin/env python point at python3 by default on past releases, and that skipping this produces cryptic error messages.

Bazel 7 is the expected version, and .bazelversion is committed at the root so the right one is fetched.

Docker is the escape hatch for a broken dependency set

The Dockerfile route exists because the dependency list above is limited and awkward. The README recommends it if you have trouble setting those dependencies up in your own environment.

There are two variants of the same invocation. Building without extra arguments runs the XLS tests, which is the check you want in CI.

docker build . -f Dockerfile-ubuntu-22.04

The other sets SKIP_TESTS as a build argument and tags the image, giving you a shell to work in interactively.

docker build . -f Dockerfile-ubuntu-22.04 \
  --build-arg SKIP_TESTS=1 \
  -t xls-build-docker
docker run -it --rm xls-build-docker /bin/bash

Given the six-hour build, a prebuilt container is the difference between a usable evaluation loop and a lost afternoon. The image name and the host user in the resulting shell (xls-developer) are both visible in the README's transcript.

The repository also carries Dockerfile support beyond this one file, plus third_party/ and dependency_support/ directories that describe where the external dependencies come from.

The Colab playground covers the whole flow including place and route

Two Colab notebooks are linked and they do different jobs. The first, at bit.ly/learn-xls, is a walkthrough of DSLX in the learn-it-in-Y-minutes style, aimed at learning the language.

The second, bit.ly/xls-playground, is an evaluation environment, and the list of what it can run interactively is the most concrete statement of scope in the README: XLS tests, XLS to IR conversion, IR to Verilog codegen, Verilog synthesis via Yosys using the open PDKs ASAP7 and SKY130, place and route via OpenROAD, and power, performance and area metric collection.

That list is the toolchain end to end. A browser session can take a function through to a PPA report on an open process node without a local build.

Two things follow. The open PDK names tell you which process technology you are looking at when you read the numbers, and the fact that synthesis and place and route come from Yosys and OpenROAD tells you that XLS stops at Verilog and delegates everything downstream.

The project explicitly does not preserve DSLX compatibility

The State of the Project section is unusually blunt and should be read before any evaluation concludes. XLS is described as experimental, undergoing rapid development, and not an officially supported Google product. Expect bugs and sharp edges, the README says.

The consequence that matters for planning is stated next. At the current point in its evolution, the maintainers regularly improve DSLX without considering backward compatibility. If you are building a corpus of hardware with XLS, you are told to be thoughtful about your process for bringing in new versions of the compiler.

That is a warning about your release engineering, not about the code. A design written today may not compile against a release from six months from now, and the mitigation is a process rather than a feature flag.

The contribution guidance has the same character. Pull requests are welcome, but the README asks you to lead with an issue and engage in conversation before sending code, and notes that a PR sent without prior discussion may take a longer road to success. It even tells you what to do if you believe a PR is ready and has had no response within two business days: ping the issue with your proposed next steps.

The repository carries AGENTS.md and GEMINI.md at the root, and the existence of both suggests the same guidance is maintained for automated agents.

Releases are nightly, not semver

The version numbers explain why the README points at Colab rather than at version pinning. The three most recent tags are v0.0.0-10836-gaa1b96cba on 2026-10-15, v0.0.0-10828-g406a74f76 on 2026-10-14 and v0.0.0-10815-g70a9d174b on 2026-10-13.

Those are pseudoversions derived from a commit count and a hash, produced on consecutive days. There is no semver line to depend on and no stability promise between tags.

The last push was on 2026-10-16 and the repository is not archived. CI runs on Ubuntu 22.04 with both a continuous integration workflow and a nightly workflow, which is consistent with a project where every commit is expected to work and nothing is expected to be pinned.

The licence is Apache 2, stated in the README and in the LICENSE file at the root. For a hardware toolchain that is the right choice, since generated Verilog output does not inherit restrictions and downstream adopters are not forced to open-source their design.

Editorial conclusion

Use XLS if you are writing hardware IP that also has to run in host software, because that dual use is the design's reason to exist and the tooling is built around keeping the two functionally identical. Do not adopt it for a production tapeout or a long-lived hardware corpus without reading the warning, since the README states the project is experimental, not an officially supported Google product, and that DSLX is changed regularly without backward compatibility. Verify first how long your first Bazel build takes, budgeted at about two hours without the C++ front-end and up to six hours with it on an eight-core VM, and decide early whether you need xlscc at all.

Frequently asked questions

Official sources

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