GHDL: a real compiler for VHDL, not an interpreter pretending to be one

Why the compiler framing matters more than the simulator framing

The README's opening paragraph makes a point that is unusual for a simulator to insist on: GHDL is not an interpreter. It allows you to analyse and elaborate sources for generating machine code from your design, and native program execution is the only way for high-speed simulation. That is a performance argument dressed as a clarification, and it is the reason the project bothers with multiple code generators at all.

The consequence is that GHDL behaves like a compiler in the ways that matter for a large design. Analysis and elaboration are separate steps from execution. Elaborating a design that references a large library such as leon3/grlib is real work that happens once, and the README cites that library as an example of the scale it can handle.

The repository tree supports this framing. There is a `src/` directory, a `configure` script, `Makefile.in`, a `build.rs` and a `ghdl.gpr.in` template, which is the shape of a project built from source on several platforms rather than a Python package with a native extension. The presence of `Cargo.toml` also reflects a Rust component, and the repository topics list `llvm` and `gcc` alongside `simulator`, `testbench` and `compiler`.

So the honest summary is that GHDL is a compiler that ships a simulator, rather than a simulator that happens to compile things. Everything else follows from which of those two it is.

Which VHDL revisions are actually covered

The support statement is precise and worth reading exactly. GHDL has full support for the 1987, 1993 and 2002 versions of the IEEE 1076 VHDL standard, and partial support for the 2008 and 2019 revisions.

That distribution is not arbitrary. VHDL-93 and VHDL-2000 are the revisions that ASIC and FPGA toolchains converged on, and a large body of existing IP is written against them. Full coverage there means legacy designs compile without modification. The 2008 revision added a substantial set of features, and partial coverage of 2019 on top of it means the newest language constructs are the ones you may have to work around.

Partial support of PSL, the Property Specification Language, sits alongside this. PSL matters for formal verification and assertion-based checking, so a team migrating from a commercial simulator with heavy PSL assertions may find the gap.

None of this is a criticism of the project. Full coverage of a language revision that keeps gaining features, across four backends and several architectures, is a large amount of work for a volunteer project. It is simply the constraint that determines whether a given design will compile on the first try, and the only way to find out for a specific design is to point the analyzer at it.

Four backends and seven kinds of release asset

Backend choice is a real decision here, and the release notes list four of them. `gcc` uses the GCC compiler framework. `mcode` generates code in memory. `llvm` uses the LLVM compiler framework. `llvm-jit` uses LLVM but keeps the generated code in memory rather than writing it out.

The README describes the generator set as LLVM, GCC, or an x86_64 and i386 built-in. The practical difference between `llvm` and `llvm-jit` is startup time against raw throughput: the JIT variant skips a separate compile step for each elaboration, which suits a flow where you elaborate many small testbenches in sequence. `mcode` is the same idea without LLVM. For long-running simulations of large designs, the ahead-of-time `llvm` build is the one the speed claim is about.

Prebuilt binaries cover a wide matrix, and the nightly release assets published on 2026-09-14 list them explicitly: macOS x86-64 and macOS aarch64 as TAR/GZ, Ubuntu 24.04 LTS and Ubuntu 26.04 LTS as TAR/GZ, Windows builds for standalone use without MSYS2 as ZIP, and MSYS2 packages for MinGW64 and UCRT64 as TAR/ZST. Container images are published separately to ghdl/ghdl on Docker Hub, with per-backend tags such as `ghdl:6.0.0-llvm-ubuntu-22.04`.

Architecturally the README claims GNU/Linux, Windows and macOS, across x86, x86_64, armv6, armv7, aarch32, aarch64 and ppc64. Getting GHDL is a matter of downloading a nightly asset, pulling an OCI image for Docker or Podman, or building from source. One inconsistency is worth flagging: the `Cargo.toml` in the repository root still declares version 5.0.0-dev, while the release line is at 6.0.0 and the nightly notes describe 7.0.0-dev. The crate manifest is not the authority on the current version.

Waveform output and the testbench libraries it plugs into

Simulation output is not the bottleneck for most VHDL work, and GHDL treats it that way. It writes waveforms to GHW, its own format, to VCD, or to FST. Paired with a GUI-based waveform viewer and a decent editor, the README calls this a very powerful setup for writing, testing and simulating code, which is an unusual amount of enthusiasm for a project description and probably reflects how much of the workflow really depends on it.

Co-simulation with foreign applications goes through the Verilog Procedural Interface, or VPI, and VHPIDIRECT, which GHDL describes as supporting either mechanism. That is the hook that lets a test written in another language, or a simulator from another vendor, drive a GHDL simulation. The README points to a separate ghdl-cosim documentation site for the details.

The verification integrations are where a modern team spends most of its time. OSVVM, UVVM and VUnit are named as supported frameworks, and the README attributes to them constrained random verification, functional coverage and automated regression testing. cocotb gets its own paragraph: it is a coroutine-based co-simulation framework that allows Python-driven testing of VHDL designs, which is the route most teams take when they want to write assertions and scoreboards in Python rather than VHDL.

For Python integration inside the project itself there is `pyGHDL/`, and the `pyproject.toml` shows how seriously it is taken. It builds with setuptools and pyTooling, runs mypy in strict mode against a Python 3.14 target, formats with black at a 120-character line length, and treats any DeprecationWarning as an error in the pytest configuration. The `setup.py` header carries the GPL notice and an SPDX identifier of GPL-2.0-or-later.

From simulation to synthesis, and where it stops

The README describes GHDL as an analyzer, compiler, simulator and experimental synthesizer. That word experimental is load-bearing and should be read literally.

What synthesis does exist is specific. GHDL can synthesize arbitrarily complex VHDL designs into a VHDL 1993 netlist, which can then be used implicitly or explicitly in open-source or vendor synthesis frameworks. So GHDL is a front end that produces a netlist, not a place-mapping or timing tool. The output language being VHDL 1993 rather than something like Verilog tells you how conservative that path is.

The realistic way to use synthesis is through Yosys. The ghdl-yosys-plugin lets GHDL act as a front-end for Yosys, which the README describes as the key integration, enabling VHDL designs to be synthesized directly and letting you move from simulation to synthesis without leaving the GHDL environment. In practice that means GHDL does the elaboration and Yosys does the technology mapping, and the boundary is where you would expect it to be.

For mixed-signal work the README notes that ngspice supports device models with behaviour defined by VHDL code, using GHDL. That is a narrower integration than the Yosys one, but it is the one you need if your design has analog behaviour in it.

The honest evaluation of the synthesis story is that it exists and is used, but simulation is what this project is good at. Treat synthesis as a path that requires the Yosys plugin and a real integration effort, not as a feature you switch on.

Licensing, governance signals and what the project does not claim

GHDL's licence is GPL-2.0, stated in the repository description and covered by `COPYING.md` at the root. The documentation is separately licensed under Creative Commons Attribution-ShareAlike, and the README adds that some of the runtime libraries carry different terms, so the licence file of an individual source file is what governs if you are shipping a binary. GPL obligations on a tool you use to produce hardware designs are a different question from GPL obligations on software you distribute, and the README does not attempt to answer that, so nobody should take this paragraph as legal advice.

The repository carries badges worth noticing. There is a CII Best Practices badge linking to the Linux Foundation's project entry, which is a third-party assessment rather than a self-assessment. There is a Test workflow on GitHub Actions and a separate AppVeyor project for the Windows builds, which means the platform matrix is tested in CI rather than asserted. The last push was on 2026-09-20, days after the nightly release on 2026-09-14, so development is current.

The 337 open issues are the number most likely to make a newcomer hesitate, and for a project of this age and scope it is unremarkable. The more useful signal is the release pattern: version 6.0.0 shipped on 2026-03-07, with a release candidate earlier the same day, and nightly builds continue past that towards 7.0.0-dev. A project shipping regular versioned releases plus nightly artifacts is doing version management deliberately.

What the README does not do is claim support for synthesis signoff, for formal verification properties, or for complete VHDL 2019. It also does not present itself as a replacement for a commercial simulator on a project with existing vendor IP, and the partial PSL support means assertion-heavy verification flows are worth scoping carefully before you commit.

Editorial conclusion

GHDL earns its position because it treats VHDL as a compiled language. Full coverage of the 1987, 1993 and 2002 IEEE 1076 revisions, partial coverage of 2008 and 2019, native machine code through LLVM, GCC or mcode, and a waveform path that emits GHW, VCD or FST cover the needs of most FPGA and ASIC work today. Two limits are worth pricing in before you commit. VHDL 2008 and 2019 features are partial, so a design written against the newest revision may need trimming, and synthesis is labelled experimental in the README itself, with output limited to a VHDL 1993 netlist for downstream tools. For Python-driven testbenches start with cocotb or pyGHDL, for synthesis start with the ghdl-yosys-plugin, and for the language questions the README leaves open, ghdl.github.io/ghdl is where the reference lives.

Frequently asked questions

Official sources

1. ghdl/ghdl on GitHub
2. Issues
3. License: GPL-2.0
4. README
5. Releases