# LiteX: writing an FPGA system-on-chip in Python instead of wiring cores by hand

> A framework for building FPGA SoCs from reusable bus, memory and peripheral cores, where the board description, the interconnect and the CPU choice all live in Python. Useful if you are porting a design or assembling cores you did not write, less convincing if you want a finished board support package handed to you.

**enjoy-digital/litex** — Build your hardware, easily!

- Repository: https://github.com/enjoy-digital/litex
- Stars: 4,148 · Forks: 762
- Language: Python
- License: NOASSERTION
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/enjoy-digital-litex

## What the framework actually assembles

LiteX describes FPGA systems as a SoC rather than as a schematic. The README lists what that covers: buses and streams with their interconnect, among them Wishbone, AXI and Avalon-ST; simple cores such as RAM, ROM, timer, UART and JTAG; complex cores pulled from a surrounding ecosystem including LiteDRAM, LitePCIe, LiteEth and LiteSATA; and CPU softcores across RISC-V, OpenRISC, LM32, Zynq and X86 through PCIe.

The design flow in the README is worth reading closely, because it explains the shape of the whole tool. Your design, written against Migen, enters LiteX, the ecosystem cores enter from the side, and the result leaves as two artifacts: a board file describing the physical target and a target file describing the system. Those two files are what the FPGA toolchain consumes at the top of the diagram.

The listed softcore set is broader than the abstraction suggests: VexRiscv, Rocket, LM32, Mor1kx, PicoRV32 and BlackParrot all appear in a compatibility table. The README also shows a multi-core Linux-capable SoC built from VexRiscv-SMP, LiteDRAM and LiteSATA, running on a repurposed Acorn CLE 215+ mining board, which tells you the intended ceiling is well past blinking an LED.

## Migen underneath, with an escape hatch in both directions

The digital logic is described with Migen, and LiteX does not force you to stay there. The README makes two-way interoperation an explicit feature rather than a workaround: importing VHDL, Verilog, SystemVerilog, nMigen or Spinal-HDL into a LiteX project is described as common and easy, and so is generating the LiteX design as Verilog and dropping it into a traditional flow.

That second direction is the one that matters for a team with existing infrastructure. If your build system already runs Verilog through a vendor toolchain, you can keep it and use LiteX to generate the part it struggles with. If you have no HDL in your toolkit at all, the Python entry point is the reason to try it.

The cost is that you are choosing a description language rather than an implementation language, and the repository reflects that. There is no schematic capture and no constraint editor here; the `doc/` directory and the project wiki carry that load.

## Reading setup.py to see what you are actually installing

The README points new users at the wiki rather than giving a pip command, so the package manifest is the most reliable description of the install. From `setup.py`:

```python
setup(
    name                          = "litex",
    version = "2026.04",
    python_requires               = "~=3.7",
    install_requires              = [
        "migen",
        "packaging",
        "pyserial",
        "requests",
    ],
```

Four runtime dependencies, and Migen is the one that generates the logic. That is a light footprint for a hardware tool, and it is a fair signal of what the framework is: a Python layer that arranges cores, not a vendor toolchain in disguise.

Two details in the same file are worth flagging. The declared floor is `~=3.7`, which permits the whole 3.x line rather than pinning a modern interpreter, so nothing in the packaging stops you on an old Python. The `develop` extra is also written without commas:

```python
    extras_require                = {
        "develop": [
          "meson"
          "pexpect"
          "setuptools"
          "requests"
        ]
    },
```

Adjacent string literals in Python concatenate, so that block asks for one package named `mesonpexpectsetuptoolsrequests` rather than four. The runtime requirements are unaffected, but expect the development extra to fail to resolve as written.

## Calendar versioning and an alpha status that has not moved

Versions are dated rather than numbered: `2026.04`, then `2025.12`, then `2025.08`, with the 2026.04 tag published on 2026-05-26. That is a clean release cadence, roughly four months apart, and it matches the `version` string in `setup.py` exactly. The last push was on 2026-09-23.

Read alongside the PyPI classifier, which declares Development Status 3 - Alpha, the picture is a mature project on a release rhythm that still labels itself pre-1.0 in status terms. The copyright line in the README spans 2012-2026, so the age is not in question; only the maturity label is.

For a framework that generates hardware, calendar versioning has a practical advantage: when a board fails to build, the date you can name in an issue is usually enough to locate the relevant state of the code. The trade is that tooling which expects semantic versions will not get one.

## Simulation, debug and the hardware you have to bring

Verification is addressed directly rather than promised. The README lists direct and fast simulation through Verilator, and debug infrastructure through bridges for host-driven control plus Litescope for inspecting a running SoC.

What the framework does not do is support your board. That is LiteX-Boards' job, a separate repository the README sends you to explicitly. The build backends are named as a category, open-source and vendor toolchains both, but the repository tree here carries no toolchain versions, no part files and no pin definitions of its own. The root contains `litex_setup.py`, `litex_repos.py` and `litex_release.py`, which reads as release and repository plumbing rather than board support.

So the realistic workflow is: confirm your board exists in LiteX-Boards, follow its instructions, and treat the toolchain choice as that board's concern. A board that is not listed means writing its pin definitions yourself before LiteX becomes useful at all.

## A test suite split by how long it takes

The repository has a `test/` directory, and `pyproject.toml` configures it with explicit markers that describe the project's own testing philosophy:

```toml
markers = [
    "integration: tests that build or exercise complete LiteX systems",
    "slow: tests that are expected to dominate local runtime",
]
```

The first marker says what an integration test means here: building or exercising a complete system, not exercising a Python function. The second exists because building hardware descriptions is slow enough that it needs its own label.

That is a small file, but it tells you something the README does not. The test suite is organised around building real systems, which means the slow path dominates and CI time is a genuine cost for anyone modifying the framework. The same file sets `testpaths` to `test` and matches `test_*.py`, and the build backend is plain setuptools with a wheel build, so nothing exotic is required to run them.

## Conclusion

LiteX is worth a look when the hard part is assembly: stitching a softcore, a memory controller and a board's pins into a working SoC without hand-writing every interconnect. It is a poor fit if you need a vendor-supported board package on day one, or if your Python and build environment are already at the edge of their limits, since the package itself asks for anything from Python 3.7 upward and declares an alpha development status on PyPI. The repository root is the honest place to start: read the dependency list in setup.py, then pick a board from LiteX-Boards and follow that board's wiki page, because the README deliberately stops before any of that.

## FAQ

### Do I need to know Verilog or VHDL to use LiteX?

No, though it helps. LiteX describes its logic with Migen, a Python description of digital hardware, so a Python-only team can build a SoC. The README also treats mixing VHDL, Verilog, SystemVerilog or Spinal-HDL into a LiteX project as routine, and generating the finished design as Verilog for a traditional toolchain.

### Which FPGA boards does LiteX support?

The framework repository does not list them. Board definitions live in a separate project, LiteX-Boards, which the README links to for exactly this purpose. If your board is absent from that repository, you would need to write its pin and peripheral definitions before LiteX became usable for you.

### What is the difference between LiteX and Migen?

Migen generates digital logic from Python and knows nothing about boards or processors. LiteX is the system-on-chip layer built on top of it, adding buses, memory controllers, CPU softcores, debug facilities and the split into a board file and a target file. LiteX depends on Migen; Migen does not depend on LiteX.

### What are LiteX's Python version requirements?

The packaging declares `python_requires = "~=3.7"`, which permits any 3.x interpreter from 3.7 upward rather than pinning a specific version. Runtime dependencies are migen, packaging, pyserial and requests.

## Sources

- [enjoy-digital/litex on GitHub](https://github.com/enjoy-digital/litex)
- [Issues](https://github.com/enjoy-digital/litex/issues)
- [README](https://github.com/enjoy-digital/litex/blob/master/README.md)
- [Releases](https://github.com/enjoy-digital/litex/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/enjoy-digital-litex