# Open Logic: a VHDL component library for FPGA work

> Open Logic is a VHDL-2008 library of reusable FPGA components, split into base, AXI, interface, fixed point and fault tolerant areas, intended to play the role a standard library plays for C. Its selling point is trust rather than novelty: every entity ships with a testbench, CI runs the simulations, and each piece of code carries a badge counting open issues.

**open-logic/open-logic** — Open Logic FPGA Standard Library

- Repository: https://github.com/open-logic/open-logic
- Stars: 1,033 · Forks: 122
- Language: VHDL
- License: NOASSERTION
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/open-logic-open-logic

## A stdlib for VHDL, with the standard spelled carefully

The README states the ambition in one line: Open Logic aims to be for HDL projects what stdlib is for C and C++ projects. That is the right analogy to hold on to, because it sets expectations. You are not getting a design flow, a project generator or an IP catalogue. You are getting a set of components you instantiate in your own design, with the same kind of expectation about quality that you attach to a standard library.

The name needs a caveat, and the project puts it in bold. The formulation Standard Library is used to depict the idea behind the project, and the README states plainly that it is not meant to imply any kind of standardisation committee is involved. There is no standards body here, no certification, and nobody obliged to keep the API stable. What you have is a maintained open source library that tries to deserve the name.

The code itself is VHDL-2008, and the README says it can also be used from System Verilog, with the limitations for cross-language instantiation documented separately and the README asking you to read that document before using Open Logic from Verilog. Releases come on a steady cadence: 4.7.0 on 2026-10-01, 4.6.0 on 2026-07-08 and 4.5.0 on 2026-04-27, with the last push on 2026-10-13.

## Five areas, and you take only the ones you need

The library is split into areas, and the README makes the point that you might use all of them or only some:

```
- [base](./doc/EntityList.md#base) - basic logic to be used for device internal logic
- [axi](./doc/EntityList.md#axi)  - any components related to AXI4/AXI4-Lite/AXI4-Stream interfaces
- [intf](./doc/EntityList.md#intf)  - any logic related to device external interfaces
- [fix](./doc/EntityList.md#FIX)  - fixed point mathematics incl. bit-true models and co-simulation support
- [ft](./doc/EntityList.md#ft)  - fault-tolerant components (ECC codecs, protected RAMs)
```

The dependency lines below each entry matter more than the descriptions. The axi and intf areas require base, the fix area requires base plus the en_cl_fix third-party library, and the fault tolerant area requires base. So the area you probably want first, base, is also the floor for everything else.

The README suggests compiling all files of the areas you need, plus their dependencies, into one VHDL library, and it is deliberately relaxed about naming: you choose the library name, and you are free to use that same single library for Open Logic files and for your own user code. That is a simple but consequential choice. Putting vendor or third-party code in the same namespace as yours means a name clash becomes a compile error you have to resolve, but it also means there is one library to configure in the tool, and the fixed point tutorial explicitly walks through building a fixed point implementation in HDL and then co-simulating it against a Python bit-true model.

## Submodules decide whether your checkout is complete

Getting the sources is a two step operation, and the second step is the one people get wrong. The repository carries a .gitmodules file and the README lists a single submodule, en_cl_fix from Enclustra under the MIT licence, which the fixed point area depends on. The clone command therefore needs the recursive switch:

```bash
git clone --recurse-submodules https://github.com/open-logic/open-logic.git
```

If you download from the release page instead, the README tells you to pick the archive named CompleteSources.zip and not one of the auto-generated archives, because in those the submodules are missing. That is not a subtle difference. A checkout without en_cl_fix simply does not compile the fixed point area, and the failure appears as missing files rather than as an obvious dependency message.

The third route avoids the problem entirely. When you use FuseSoC, the README states that all dependencies are resolved automatically and no special action is required, and the HowTo document is the reference for that workflow. For a team that already standardises on FuseSoC for core and third-party libraries, that is the path with the least friction.

## Trust is the product, and it is measured per entity

The README is unusually direct about why an open source hardware library has to argue for its own reliability. It notes that open source HDL projects exist but are far less popular than open source software projects, that one main problem is a general lack of trust in open source HDL code, and that in some cases the code quality is not great while RTL designers are probably less used to relying on other people's code.

What the project offers in response is a set of measures rather than a claim. Every entity comes with a testbench. A CI workflow regularly runs all simulations and synthesis tasks, and the badge in the README is the signal to watch: as long as it is green, all testbenches pass. Documentation for every piece of code carries a badge that shows the number of open issues related to that piece and whether there are potential bugs.

That per-entity badge is the most useful thing here for an engineer making a decision. Trust in a library is not a global property, and Open Logic is honest enough to expose the weak spots at the level of the individual component. The repository layout supports the same idea: separate src/, test/, sim/, lint/, tools/ and doc/ directories, a compile_order.txt for the VHDL build, a Changelog.md, and a Licensing section that points at License.txt and LGPL2_1.txt.

## Vendor tutorials for seven toolchains, and one documented how to

The documentation section is the practical entry point for a new user, and its structure tells you the project expects you to be in a specific toolchain. There are tutorials for Vivado, Quartus, Efinity, Questa, Libero and Gowin, each covering VHDL and System Verilog, plus a Cologne Chip tutorial for VHDL only, and a fixed point mathematics tutorial that covers bit-true modelling in Python, an Open Logic based fixed point implementation in HDL, and co-simulation between the two.

The HowTo document is described as the FAQ for all users, and the README goes further, calling it strongly suggested that every user quickly reads through it. Between that, the Entity List, which the README asks you to browse to see what is available, and the Coding Conventions document, which the README says is interesting for the ones who contribute, you have a documentation set that assumes you will both use and possibly extend the library.

The Code of Conduct, Contributing instructions, a markdownlint configuration and a .vscode directory with editor settings round out a project that is organised like a maintained tool rather than a research dump. One practical note for anyone automating a build: the CI workflows are named hdl_check and synthesis, and their documentation lives in doc/CI-Workflows.md, so the same jobs that verify the library are available as a reference for your own pipeline.

## LGPL with FPGA exceptions, and what that buys you

The licence is described in the README as a permissive open source license, LGPL with exceptions for FPGA usage, and the point of that exception is stated in plain terms: the code can be used in commercial projects. The repository carries both LGPL2_1.txt and License.txt, and the licence field is listed as a custom licence that GitHub cannot classify, which is a signal to read the files rather than to rely on a label.

The practical reading, without giving legal advice, is that Open Logic is intended to be dropped into a product, including a commercial one, without the friction that a copyleft licence tied to hardware distribution might create. The LGPL base and the FPGA exception together are what make that possible, and they are the reason the project can say what it says about commercial use.

Compare that with the alternative of writing the components yourself. A FIFO, an AXI4-Stream bridge, a fixed point multiplier with a bit-true model, an ECC protected memory wrapper: each is a day or two of work and a week of verification if you are careful, and every one of them has to be re-verified when the toolchain or the clock target changes. Open Logic is a way of buying that verification back, at the price of depending on code you did not write. The per-entity issue badge is what makes that trade legible, and it is the first thing to look at when you pick which components to depend on.

## Conclusion

Open Logic fits FPGA engineers who need standard building blocks such as AXI bridges, fixed point maths or protected memories without writing and verifying them from scratch, especially those working across more than one vendor toolchain. It does not fit projects that need a full SoC generator, a vendor IP catalogue, or a hard real time safety case, because the library ships components and evidence, not certification. Before you adopt it, read the HowTo document as the README insists, confirm the LGPL terms with the FPGA exceptions in License.txt match your distribution model, and check the open issue badge on each entity you plan to instantiate before you rely on it in a design.

## FAQ

### What is Open Logic and what is it written in?

Open Logic is a library of reusable FPGA components written in VHDL-2008, intended to be for HDL projects what stdlib is for C and C++ projects. It is written to be vendor and tool independent.

### Which licence applies to Open Logic?

The README describes it as LGPL with exceptions for FPGA usage, so the code can be used in commercial projects. The repository ships both LGPL2_1.txt and License.txt, and GitHub cannot classify the licence automatically.

### How do I clone Open Logic with all its sources?

Use git clone --recurse-submodules on the repository URL, because the fixed point area depends on the en_cl_fix submodule. When downloading from the release page, take the archive named CompleteSources.zip rather than the auto-generated ones, where the submodules are missing.

### What areas does the Open Logic library contain?

Five areas: base for device internal logic, axi for AXI4, AXI4-Lite and AXI4-Stream related components, intf for device external interfaces, fix for fixed point mathematics with bit-true models and co-simulation support, and ft for fault-tolerant components such as ECC codecs and protected RAMs.

### How can I judge whether a specific Open Logic component is reliable?

Every entity ships with a testbench, the CI workflow runs all simulations and synthesis tasks, and the documentation of each piece of code carries a badge showing the number of open issues and whether there are potential bugs. The README also points to a separate HowTo document that it strongly suggests every user reads.

## Sources

- [Issues](https://github.com/open-logic/open-logic/issues)
- [open-logic/open-logic on GitHub](https://github.com/open-logic/open-logic)
- [README](https://github.com/open-logic/open-logic/blob/main/README.md)
- [Releases](https://github.com/open-logic/open-logic/releases)

---

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