XLS: Accelerated HW Synthesis

Recorded: Sept. 15, 2026, 11:08 p.m.

Original

Overview

Initializing search

GitHub

XLS: Accelerated HW Synthesis

GitHub

Overview

Table of contents

What is XLS?

State of the Project

Colab Notebooks

Install Latest Release

Building From Source

Docker Build

Adding Additional Build Caching

Getting Clangd completions

Stack Diagram and Project Layout

Community

Contributors

Talks

Tutorials

Overview

DSLX

Hello, XLS!

Basic logic

Intro to parameterics

For expressions

Enumerate and match

What is a Proc?

How to use Procs

Dataflow & Time

\[contrib\] XLS[cc]

Overview

Integers

Channels

Memory

State

Pipelined Loops

FAQ

Overview

Semantics

Optimizations

Overview

Passes

Dev Passes

Profiling

Scheduling

Overview

Delay Estimation

Ir Visualization

Web Visualizer

Cytoscape

Native JIT/AOT

Overview

Data Layout

Formal

Elaboration

IR Fuzzer

DSLX

Reference

Standard Library

Floating Point

Fuzzer

Interpreter

FFI

Language Server

Type System

Code Generation

Codegen Options

IR Lowering

VAST

Tools

Build System

Bazel Rules And Macros

Quick Start

Listing

Interpreters

Development

Contributing

Style Guide

Adding a new IR operation

Ideas and Projects

FPGA characterization (experimental)

Design Docs

Legalize Multiple Channel Ops Per Channel (v1)

Legalize Multiple Channel Ops Per Channel (v2)

Proc-scoped channels

Synchronous Procs

DSLX Pattern Exhaustiveness

Optimizations

Value Set Simplification

Division

XLS[cc] Activation Barriers

Releasing

NoC

Overview

Topologies

Overview

Dimension Order

Tree

k-ary n-fly Butterfly

Fully Connected

Star

Glossary

Table of contents

What is XLS?

State of the Project

Colab Notebooks

Install Latest Release

Building From Source

Docker Build

Adding Additional Build Caching

Getting Clangd completions

Stack Diagram and Project Layout

Community

Contributors

XLS: Accelerated HW Synthesis

What is XLS?
XLS implements a High Level Synthesis toolchain that produces synthesizable
designs (Verilog and SystemVerilog) from flexible, high-level descriptions of
functionality. It is Apache 2 licensed.
XLS (Accelerated HW Synthesis) aims to be the Software Development Kit (SDK) for
the End of Moore's Law (EoML) era. In this "age of specialization", software and
hardware engineers must do more co-design across their domain boundaries --
collaborate on shared artifacts, understand each other's cost models, and share
tooling/methodology. XLS attempts to leverage automation, software engineers,
and machine cycles to accelerate this overall process.
XLS enables the rapid development of hardware IP that also runs as efficient
host software via "software style" methodology. An XLS design runs at native
speeds for use in host software or a simulator, but that design can also
generate hardware block output -- the XLS tools' correctness ensures (and
provides tools to help formally verify) that they are functionally identical.
XLS supports both (optionally pipelined) functions with pure-wire I/O interfaces
and
concurrent processes
(or procs). Procs are stateful, allowing induction over time, and include more
general communication interfaces.
State of the Project
XLS is experimental, undergoing rapid development, and not an officially
supported Google product. Expect bugs and sharp edges. Please help by trying it
out, running through some tutorials,
reporting bugs.
We are early stage and this has some practical effects:

We welcome your issues and PRs.
- Please try to lead with an issue. Engage us in conversation if you wish
to upstream changes. Sending a PR without back and forth with us in an
issue may be a longer road to success. If you believe your PR is ready
and has not received a response within two business days, please ping
the issue with what you think are next steps.
At the current point in its evolution, we regularly improve DSLX without
considering backward compatibility.
- If you are building a corpus of hardware with XLS, please be thoughtful
about your process for bringing in new versions of the compiler.

Colab Notebooks
For a more setup-free and environment-independent way of trying out XLS, see our
colab notebooks:

bit.ly/learn-xls: a "learn XLS in Y minutes"
style walkthrough in DSLX, our Rust-inspired domain specific language (DSL).

bit.ly/xls-playground: an XLS evaluation
environment that can run the following interactively:- XLS tests
- XLS→IR conversion
- IR→Verilog codegen
- Verilog synthesis via Yosys (using open PDKs ASAP7 and SKY130)
- Place-and-Route (P&R) via OpenROAD
- Power/Performance/Area (PPA) metric collection

Install Latest Release
The following downloads the latest github repo release binaries for an x64 Linux
machine:
# Determine the url of the latest release tarball.
LATEST_XLS_RELEASE_TARBALL_URL=$(curl -s -L \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/repos/google/xls/releases | \
grep -m 1 -o 'https://.*/releases/download/.*\.tar\.gz')

# Download the tarball and unpack it, observe the version numbers for each of the included tools.
curl -O -L ${LATEST_XLS_RELEASE_TARBALL_URL}
tar -xzvvf xls-*.tar.gz
cd xls-*/
./interpreter_main --version
./ir_converter_main --version
./opt_main --version
./codegen_main --version
./proto_to_dslx_main --version

Building From Source
Aside from the binary releases (available for x64 Linux as described above), and
the available colab notebooks, XLS must be built from source using the Bazel
build system.
The following instructions are for the Ubuntu 22.04 (Jammy Jellyfish) Linux
distribution.
On an average 8-core VM:

A full initial build without the C++ front-end (e.g., "DSLX only") may take
about 2 hours,
Including the C++ front-end may take up to 6 hours.

Please see the two corresponding command lines below -- we start by assuming
Bazel has been installed:
~$ git clone https://github.com/google/xls.git
~$ cd xls

~/xls$ # Follow the bazel install instructions to install bazel 7
~/xls$ # https://bazel.build/install/ubuntu

~/xls$ # Note we're going to tell Ubuntu that `/usr/bin/env python` is actually python3
~/xls$ # here, since that has not been the case by default on past Ubuntus.
~/xls$ # This is important. Without this step, you may experience cryptic error messages:
~/xls$ sudo apt install python3-dev libtinfo6 python-is-python3

~/xls$ # Now build/test in optimized build mode.
~/xls$ # If you don't plan on using the C++ front-end, which is not strictly
~/xls$ # needed (i.e. DSLX front-end only), use this command line:
~/xls$ bazel test -c opt -- //xls/... -//xls/contrib/xlscc/...

~/xls$ # To build everything, including the C++ front-end:
~/xls$ bazel test -c opt -- //xls/...

Docker Build
Reference build/test environment setups are also provided via Dockerfiles, if
you have difficulty setting up the (limited set of) dependencies shown above in
your environment:
~$ git clone https://github.com/google/xls.git
~$ cd xls
~/xls$ # Build and run xls tests.
~/xls$ docker build . -f Dockerfile-ubuntu-22.04
~/xls$ # Setup the xls build environment and allow for manual testing/building
~/xls$ docker build . -f Dockerfile-ubuntu-22.04 \
-t xls-build-docker \
--build-arg SKIP_TESTS=1
...
~/xls$ docker run -it --rm xls-build-docker /bin/bash
...
xls-developer@de12154edf52:~/xls$ bazel build --verbose_failures -c opt //xls/jit:jit_channel_queue_test
...

Adding Additional Build Caching
Many programmers are used to using programs like ccache to improve caching for
a build, but Bazel actually ships with very-high quality caching layers. In
particular, incremental builds are more safe.
However, there are circumstances where Bazel might decide to recompile files
where the results could have been cached locally - or where it might be safe to
reuse certain intermediate results, even after a bazel clean. To improve this,
you can tell Bazel to use a shared "disk cache", storing files persistently
elsewhere on disk; just create a directory somewhere (e.g.,
~/.bazel_disk_cache/), and then run:
echo "build --disk_cache=$(realpath ~/.bazel_disk_cache)" >> ~/.bazelrc
echo "test --disk_cache=$(realpath ~/.bazel_disk_cache)" >> ~/.bazelrc

Warning
Bazel does not automate garbage collection of this directory, so it
will grow over time without bounds. You will need to clean it up periodically,
either manually or with an automated script.

Alternatively, you can add a remote cache
that takes care of garbage collection for you. This can be hosted on a personal
server or even on the local machine. We've personally had good results with
localhost instances of bazel-remote.
Getting Clangd completions
There are two ways of getting clangd completions and related features.
A compile_flags.txt file compatible with clangd and similar
tools can be created by running xls/dev_tools/make-compilation-db.sh.
This approach is faster but does not account for differences in the way
individual targets are built.
Alternatively,
hedronvision/bazel-compile-commands-extractor
can be used to generate a compile_commands.json file that
clangd can consume. This approach is slower to setup but the
compiler flags are tailored for each target. The
compile_commands.json file can be built by running:
bazel build -c opt //xls/... -k
bazel run //:refresh_compile_commands

See the comments in the top-level
BUILD file for more details.
Stack Diagram and Project Layout
Navigating a new code base can be daunting; the following description provides a
high-level view of the important directories and their intended organization /
purpose, and correspond to the components in this XLS stack diagram:

dependency_support:
Configuration files that load, build, and expose Bazel targets for
external dependencies of XLS.
docs_src: Markdown
file sources, rendered to docs via
mkdocs.
xls: Project-named
subdirectory within the repository, in common Bazel-project style.
- build: Build
macros that create XLS artifacts; e.g., convert DSL to IR, create test
targets for DSL code, etc.
- codegen:
Verilog AST (VAST) support to generate Verilog/SystemVerilog operations
and FSMs. VAST is built up by components we call generators (e.g.,
PipelineGenerator, SequentialGenerator for FSMs) in the translation from
XLS IR.
- common: "base"
functionality that layers on top of standard library usage. Generally we
use Abseil versions of base constructs wherever
possible.
- contrib/xlscc:
Experimental C++ syntax support that targets XLS IR (alternative path to
DSLX) developed by a sister team at Google, sharing the same open source
/ testing flow as the rest of the XLS project. May be of particular
interest for teams with existing C++ HLS code bases.
- data_structures:
Generic data structures used in XLS that augment standard libraries;
e.g., BDDs, union find, min cut, etc.
- delay_model:
Functionality to characterize, describe, and interpolate data delay for
XLS IR operations on a target backend process. Already-characterized
descriptions are placed in xls/estimators/delay_model/models and can
be referred to via command line flags.
- dslx: A DSL
(called "DSLX") that mimics Rust, while being an immutable
expression-language dataflow DSL with hardware-oriented features; e.g.,
arbitrary bitwidths, entirely fixed size objects, fully analyzeable call
graph. XLS team has found dataflow DSLs are a good fit to describe
hardware as compared to languages designed assume von Neumann style
computation.
- fuzzer: A
whole-stack multiprocess fuzzer that generates programs at the DSL level
and cross-compares different execution engines (DSL interpreter, IR
interpreter, IR JIT, code-generated-Verilog simulator). Designed so that
it can easily be run on different nodes in a cluster simultaneously and
accumulate shared findings.
- examples:
Example computations that are tested and executable through the XLS
stack.
- experimental:
Artifacts captured from experimental explorations.
- interpreter:
Interpreter for XLS IR - useful for debugging and exploration. For cases
needing throughput, consider using the JIT (below).
- ir: XLS IR
definition, text parser/formatter, and facilities for abstract
evaluation.
- jit: LLVM-based JIT
for XLS IR. Enables native-speed execution of DSLX and XLS IR programs.
- modules:
Hardware building block DSLX "libraries" (outside the DSLX standard
library) that may be easily reused or instantiated in a broader design.
- netlist:
Libraries that parse/analyze/interpret netlist-level descriptions, as
are generally given in simple structural Verilog with an associated cell
library.
- passes: Passes
that run on the XLS IR as part of optimization, before scheduling / code
generation.
- scheduling:
Scheduling algorithms, determine when operations execute (e.g., which
pipeline stage) in a clocked design.
- simulation:
Code that wraps Verilog simulators and generates Verilog testbenches for
XLS computations. iverilog is
currently used to simulate as it supports non-synthesizable testbench
constructs.
- solvers:
Converters from XLS IR into SMT solver input, such that formal proofs
can be run on XLS computations; e.g., Logical Equalence Checks between
XLS IR and a netlist description. Z3
is used as the solver engine.
- synthesis:
Interface that wraps backend synthesis flows, such that tools can be
retargeted e.g., between ASIC and FPGA flows.
- tests:
Integration tests that span various top-level components of the XLS
project.
- tools:
Many tools that work with the XLS
system and its libraries in a decomposed way via command line
interfaces.
- visualization:
Visualization tools to inspect the XLS compiler/system interactively.
See IR visualization.

Community
Discussions about XLS - development, debugging, usage, etc.:

Ideally happen in
XLS repo GitHub discussions
But, if you feel email is a better venue for the discussion, there is also
an xls-dev mailing list -- please
prefer GitHub discussions if possible as they are searchable and can be
easily cross-referenced and converted to an issue in the issue tracker

Contributors
The following are
contributors to the XLS
project; see our
contributing documentation and
good first issues
if you're interested in contributing, or reach out via
GitHub discussions!

Aidan Kirk
Albert Magyar
Alex Light
Amin Kalantar
Angelo Matni
Balint Christian
Blaok
Brandon Jiang
Brian Searls
Chen-hao Chang
Chris Drake
Chris Leary
Conor McCullough
David Plass
Dan Killebrew
Derek Lockhart
Eric Astor
Ethan Mahintorabi
Felix Zhu
Georges Rotival
Hanchen Ye
Hans Montero
Henner Zeller
Iliyan Malchev
Johan Euphrosine
Jonathan Bailey
Josh Varga
Julian Viera
Kevin Harlley
Leonardo Romor
Manav Kohli
Mark Heffernan
Paul Rigge
Per Grön
Philipp Schilk
Ravi Nanavati
Rebecca Chen (Pytype)
Remy Goldschmidt
Robert Hundt
Rob Springer
Sameer Agarwal
Sean Purser-Haskell
Simone Campanoni
Ted Hong
Ted Xie
Tim Callahan
Vincent Mirian

Made with

Material for MkDocs

XLS, or Accelerated Hardware Synthesis, implements a toolchain designed to produce synthesizable designs in Verilog and SystemVerilog from flexible, high-level descriptions of functionality. The project aims to serve as the Software Development Kit for the End of Moore's Law era, addressing the need for greater co-design between software and hardware engineers by leveraging automation, software engineers, and machine cycles to accelerate the overall process. XLS facilitates the rapid development of hardware intellectual property that concurrently functions as efficient host software through a software style methodology. An XLS design can execute at native speeds for host software or simulators, while simultaneously generating hardware block outputs, with the tools ensuring and providing means for formal verification that the results are functionally identical. The system supports both pipelined functions with pure-wire I/O interfaces and concurrent processes, referred to as procs, which are stateful and enable induction over time with generalized communication interfaces.

The project is in an experimental stage and is undergoing rapid development, meaning users should anticipate bugs and evolving features. The developers encourage community involvement by soliciting bug reports and pull requests, advocating for engagement through issue tracking rather than direct pull requests to facilitate necessary discussions upstream. For practical exploration, the project provides Colab Notebooks, including an interactive walkthrough of the domain-specific language DSLX and an evaluation playground allowing interactive testing of the entire flow, from XLS input to IR conversion, Verilog codegen, and power, performance, and area metric collection.

The implementation relies on a complex internal stack, which includes a Domain Specific Language (DSLX), which is presented as an immutable expression-language dataflow DSL mimicking Rust, characterized by hardware-oriented features such as arbitrary bitwidths and fully analyzable call graphs. The core of the system involves an Intermediate Representation (IR) for XLS and DSLX, along with several passes for optimization, scheduling algorithms to determine execution timing in a clocked design, and synthesis interfaces to allow retargeting between different flows, such as ASIC and FPGA. Further key components include a Just-In-Time (JIT) compiler based on LLVM for executing DSLX and XLS IR programs at native speeds, formal solvers like Z3 for logical equivalence checks, and visualization tools to inspect the compiler and system interactively. The architecture organizes its components into modules such as data_structures, delay_model, ir, scheduling, and synthesis, demonstrating a structured approach to hardware synthesis.

The project provides comprehensive pathways for implementation, including the option to download binary releases, or to build from source using the Bazel build system, which is mandated for full development. Building from source involves setting up dependencies, ensuring proper environment configurations, and utilizing Bazel commands for testing and full compilation. Dockerfiles are also provided to facilitate reproducible build and testing environments. Further development support is offered through mechanisms to integrate with development tools, such as generating compile commands for tools like clangd, and through community contributions managed via GitHub discussions. The project structure organizes code into directories like build, codegen (handling Verilog Abstract Syntax Tree support), common, and contrib/xlscc for experimental C++ syntax features targeting the XLS IR.