# LitePCIe gives FPGA designers a configurable PCIe core

> LitePCIe is an open source PCIe core written in Migen, part of the LiteX library family, that supports several Xilinx and Intel device families and can be used either as a LiteX library or as generated Verilog dropped into a standard flow. The core is developed and maintained by EnjoyDigital.

**enjoy-digital/litepcie** — Small footprint and configurable PCIe core

- Repository: https://github.com/enjoy-digital/litepcie
- Stars: 739 · Forks: 177
- Language: Python
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/enjoy-digital-litepcie

## A PCIe core written in Python

LitePCIe provides a small footprint and configurable PCIe core, and the mechanism that makes it configurable is Migen, the Python based HDL description library LiteX is built on.

Using Migen to describe the HDL allows the core to be highly and easily configurable, which is the point. A core written in Verilog is fixed when it is written, while a core described in Python is a program, so a parameter like the datapath width or the number of requester IDs becomes an argument rather than a recompile-and-poke exercise.

The second half of the design decision is where the core can be consumed. LitePCIe can be used as a LiteX library, or it can be integrated with a standard design flow by generating the verilog rtl that you will use as a standard core. The console script litepcie_gen=litepcie.gen:main is the entry point for that generation, and the example board files in the examples directory are named ac701.yml, acorn.yml and kcu105.yml, which are Xilinx board descriptions.

LitePCIe is one of a family. The README places it inside LiteX libraries whose aims are to lower the entry level of complex FPGA cores by providing straightforward implementations of components used in today's SoC such as Ethernet, SATA, PCIe and SDRAM controller.

## What the PHY and core layers cover

The feature list is organised by layer, which is the clearest way to see what you get and what you still have to build.

At the PHY level, the supported device families are Xilinx Ultrascale and Ultrascale+, up to PCIe Gen3 X16, Xilinx 7-Series, up to PCIe Gen2 X8, and Intel Cyclone5, up to PCIe Gen2 X4. The datapath is configurable at 64, 128, 256 or 512 bits, and clock domain crossing is handled.

The core layer covers the TLP layer, reordering, MSI in single and multi-vector form along with MSI-X, and a crossbar. Reordering and MSI-X are the two items that most hand rolled implementations get wrong, so having them already solved is the main reason to use this rather than write your own.

The frontend layer provides DMA with Scatter-Gather, and MMAP over AXI or Wishbone in slave and master roles. PTM is supported on Xilinx 7-Series, with experimental multi-lane support and UltraScale+ Gen2, Gen3 and Gen4 support documented separately in the PTM integration document.

On the software side there is a Linux driver covering MMAP and DMA. That is the piece that decides whether the whole thing is usable, since a DMA engine without a driver is a block of logic you have to reach through a custom testbench.

## Where the core has already shipped

The README lists designs that are described as commercial and open-source, and the list is the best available evidence about how the core behaves in a real system.

There is a 3G-SDI capture and playback board, an SDR MIMO 2x2 board from Amarisoft, an SDR MIMO 4x4 board, and an SDR CPRI board. All four are PCIe devices doing real streaming work, with data rates high enough that a broken DMA path or a missed reordering case shows up immediately.

That is a meaningful distinction for an FPGA core. Simulation and synthesis tell you the design builds; they do not tell you that the TLP handling is right for a sustained multi-gigabyte stream. A core that has been used for SDI and SDR in shipping boards has been through the failure modes that only appear under load.

The list is not exhaustive and the README says as much with and others commercial designs. There is no published board support list or compatibility matrix, so the right way to read this section is as evidence of the class of system the core was built for, not as a guarantee for a specific device.

## Getting set up, and running the unit tests

The Getting started section is three steps and they are deliberately vendor-agnostic.

Install Python 3.8+ and the FPGA vendor's development tools, then install LiteX and the cores by following the LiteX installation guide, and then find the integration examples in LiteX-Boards and in the examples directory of the repository. The setup.py declares python_requires as ~=3.8 and install_requires as pyyaml and litex, so the core pulls in LiteX itself rather than assuming it.

The unit tests live in ./test/ and can be run as a suite:

```sh
$ ./setup.py test
```

or one at a time:

```sh
$ python3 -m unittest test.test_name
```

The test_suite setting in setup.py points at test, and a pytest.ini is present in the repository root, so pytest works as well.

One detail in setup.py is worth knowing before you try to install the development extras. The extras_require develop list is written without separators between the entries, so the four names are concatenated into a single string rather than forming a list of four packages. The effect is that the develop extra does not install the tools it appears to name, and a developer who needs meson, pexpect or requests for a local build has to install them directly.

## The license permits closed-source designs

LitePCIe is released under the very permissive two-clause BSD license, and the README is explicit about what that means in practice: under the terms of this license, you are authorized to use LitePCIe for closed-source proprietary designs.

That sentence is the one to read if you are evaluating this for commercial work, because a core you cannot ship is a core you cannot use. The setup.py classifiers agree, listing the license as BSD and the OSI approved BSD License classifier.

The repository metadata on GitHub lists the license as a custom licence that GitHub cannot classify, which is a labelling quirk rather than a contradiction of the BSD text in the LICENSE file and the README.

The README then adds a request rather than an obligation. It says that even though we do not require you to do so, those things are awesome, so please do them if possible: tell the authors you are using LitePCIe, cite it in publications related to research it has helped, send feedback and bug reports, and send back the modifications and improvements you have made. Note the last one carefully, since it is a request to share derived work even though the licence does not require it.

## The gap between the core and a product

The Possible improvements section is unusually candid about what is missing, and reading it before committing saves a lot of time.

The first item is standardized interfaces, specifically AXI and Avalon-ST. The core's MMAP layer speaks AXI and Wishbone, but the README lists adding AXI and Avalon-ST as work still to do, which suggests the coverage of the common FPGA interface standards is partial rather than complete.

The second and third are device families: Intel Stratix support and Lattice support are both listed as future work, alongside more documentation. That means the supported set is Xilinx Ultrascale and 7-Series plus Intel Cyclone5, and nothing else.

This is the sharpest limitation of the project. A Stratix or Lattice design cannot use the core as it stands, and there is no indication in the README of when that would change or who would do it.

Support is offered commercially. The README states that LitePCIe is developed and maintained by EnjoyDigital, that they can provide standard commercial support as well as consulting services, and invites contact. So the missing device families and the missing documentation are in principle purchasable work rather than abandoned features, which is the practical question to ask.

## How the project is packaged and released

The packaging is straightforward Python and gives a clue about the intended audience.

The build system requires setuptools>=61 and wheel with the setuptools.build_meta backend, and the pyproject.toml contains nothing beyond that build-system block. Everything else lives in setup.py: the name litepcie, the version 2026.08, the description Small footprint and configurable PCIe core, the author Florent Kermarrec, and the entry point for the litepcie_gen console script. Packages are found with find_packages excluding test, sim, doc and examples directories, and include_package_data is enabled.

The classifier that matters most for an adopter is Development Status :: 3 - Alpha. The project classifies itself as alpha in its own metadata, which is a reasonable signal to weigh against the list of shipping boards, and it means you should expect to be an early user of new device support.

There are no GitHub releases, so there is no tagged artefact to pin. The version string in setup.py is a date, 2026.08, which is a LiteX family convention rather than semantic versioning. The last push was on 2026-10-12, and the repository is not archived, so work is ongoing even though there are no published releases to install from.

The repository also carries a bench directory, which is where performance characterisation work for the DMA paths would live, and a CONTRIBUTORS file.

## Conclusion

LitePCIe suits an FPGA engineer who needs PCIe without writing the TLP layer, the reordering logic and the DMA frontend themselves, since the core covers those and the LiteX integration path means the surrounding SoC can stay in the same Python design flow. It is the wrong tool if you need Intel Stratix or Lattice support, since both are listed as possible improvements, and it is the wrong tool if you need a maintained Verilog release, since the repository has no GitHub releases and the README asks users to send back their modifications. Before starting, read the PTM integration document in doc/ for the 7-Series and Ultrascale+ paths, run ./setup.py test to confirm the unit tests pass in your environment, and check the PHY support list against your exact device family.

## FAQ

### Which FPGA families does LitePCIe support?

The PHY layer supports Xilinx Ultrascale and Ultrascale+ up to PCIe Gen3 X16, Xilinx 7-Series up to PCIe Gen2 X8, and Intel Cyclone5 up to PCIe Gen2 X4, with 64, 128, 256 or 512 bit datapaths and clock domain crossing. Intel Stratix and Lattice support are listed as possible improvements rather than existing features.

### Can LitePCIe be used in a Verilog design flow?

Yes. The README states that LitePCIe can be used as a LiteX library or can be integrated with your standard design flow by generating the verilog rtl that you will use as a standard core. The litepcie_gen console script, mapped to litepcie.gen:main, is the generator entry point.

### How do I run the LitePCIe unit tests?

The unit tests are in the ./test/ directory. Run the whole suite with ./setup.py test, or a single test with python3 -m unittest test.test_name. A pytest.ini is present in the repository root, so pytest works as well.

### Can LitePCIe be used in a closed-source commercial design?

Yes. The README states that LitePCIe is released under the very permissive two-clause BSD license and that under the terms of this license you are authorized to use it for closed-source proprietary designs. The project separately asks, without requiring it, that you tell them you are using it and share back modifications you have made.

## Sources

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

---

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