# Veryl: a hardware description language that emits readable SystemVerilog

> Veryl is a Rust-implemented hardware description language based on SystemVerilog, with simplified syntax for logic design and a compiler that transpiles to SystemVerilog you can still read and modify at the flip-flop level. It suits an ASIC or FPGA engineer who wants Verilog-like ergonomics without the language complexity, and it is still in the exploration phase of language design.

**veryl-lang/veryl** — Veryl: A Modern Hardware Description Language

- Repository: https://github.com/veryl-lang/veryl
- Stars: 1,048 · Forks: 78
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/veryl-lang-veryl

## What the language is, and what phase it is in

Veryl is a modern hardware description language, and it is based on SystemVerilog. The primary language of the implementation is Rust, the licence is MIT or Apache-2.0, the last push was on 2026-10-15, and the releases are v0.22.0 on 2026-10-02, v0.21.0 on 2026-09-02 and v0.20.3 on 2026-08-03. The status line in the README matters for an evaluation, because the project says it is under the exploration phase of language design and calls for suggestions or contributions in three areas, language design, tool implementation and standard library implementation. So the syntax you read today may still change, and the fact that the project asks for input on language design is an invitation to shape it rather than a sign of instability. The name comes from the first letter of Verilog and Beryl, it is pronounced the same as beryl, and the theme colour is emerald, which is a type of beryl.

## The syntax example, and what it removes

The README puts a Veryl module next to the SystemVerilog it generates, and the differences are the argument for the language. The Veryl version uses a documentation comment in markdown format, with a list inside it, uses visibility control by the `pub` keyword, allows a trailing comma in the parameter list, and the port list has the type after the name. The SystemVerilog version needs three separate comment lines for the same documentation, uses `parameter int WIDTH = 1` without a trailing comma, and puts the type before the name with an explicit width range. The reset handling is the clearest simplification. Veryl uses an `if_reset` abstraction that covers the reset polarity and synchronicity, while the SystemVerilog needs an explicit sensitivity list of `@ (posedge i_clk or negedge i_rst)` and a nested `if (!i_rst)`. The clock and reset signals can be omitted entirely in Veryl because the tool infers them.

## Why the language exists, in the project's own terms

The FAQ answers the question that matters for an adopter, and the answer is about tooling rather than taste. SystemVerilog is a very complicated language and it causes difficulty in implementing EDA tools for it. As a consequence, major EDA tools only support a SystemVerilog subset which is different for each tool, and users must explore which usable language features are covered by the tools that happen to be adopted. The difficulty also prevents productivity improvement by developing support tools. That is the reason a new language with simplified and sophisticated syntax is required, rather than SystemVerilog. The alternative-HDL answer is just as direct. Many existing alternative HDLs, Chisel for example, are an inner DSL of a programming language, which has advantages like rapid development and a reusable tooling ecosystem, but the syntax cannot be fitted to hardware description completely, and enormous Verilog code is generated from short code in those languages, which prevents general ASIC workflows like timing improvement and pre and post-mask ECO, because those workflows require flip-flop level modification in Verilog.

## What is deliberately left out, and why

Two FAQ entries explain the limits, and both are the kind of thing you discover after you have adopted a language. Some language features, auto pipelining for example, are not adopted because Veryl focuses on equivalency with SystemVerilog at the level of language semantics, which makes it easier to predict how the generated SystemVerilog changes when the Veryl source changes, and because Veryl can then be applied to ASIC workflows such as timing improvement and pre and post-mask ECO. Features that generate flip-flops are not adopted because they prevent that predictability. Other syntax features, the off-side rule and semicolon-less syntax, are not adopted because Veryl focuses syntax simplicity to reduce tool implementation effort, so features that introduce large complexity in exchange for slight abbreviation are left out. The predictability argument is the one to weigh, because it is the reason the language stays a translation layer rather than becoming an elaborator in its own right.

## Interoperability, and the guarantee that matters

Interoperability is one of the three advantages the README lists, and it has two parts. Veryl allows smooth integration and partial replacement with existing SystemVerilog components and projects, so a design can mix the two. And SystemVerilog source code transpiled from Veryl retains high readability, which keeps integration and debugging tractable. The synthesizability guarantee is what makes the transpilation approach workable, and it is described as guaranteeing consistency between simulation results. That is a stronger property than a language that merely compiles, because it means the SystemVerilog you get back can be fed to the same simulator and produce the same answers, which is what lets you drop Veryl into an existing verification flow one module at a time rather than all at once.

## The toolchain, and what the crates tell you

Veryl comes with a rich set of development support tools, including package managers, build tools, real-time checkers compatible with major editors such as VSCode, Vim and Emacs, automatic completion and automatic formatting. The build is a plain cargo invocation:

```bash
cargo build
```

The Cargo workspace shows how that is put together, with separate crates for the parser, the analyzer, the formatter, the emitter, the language server, the synthesizer, the simulator, the translator, the standard library, the migrator, the metadata, the caches, the component and macro handling, and the cosim crate for co-simulation. The supporting crates in the workspace dependencies name the tools used, with parol for the parser generator, miette for diagnostics, clap for the command line, handlebars for templating, and criterion and the codspeed-criterion-compat package for benchmarks. The repository root also has a `Veryl.toml` and a `Veryl.lock`, so the project has its own package manager, and a `bacon.toml` for the background code checker, plus a `doc/` directory and a `testcases/` directory.

## Packaging, and the dynamic linking constraint

The Makefile shows the release process and one constraint worth reading. The published binaries must stay dynamically linked, because a static binary carries no dynamic loader and so can neither dlopen a native verification component nor load the object the AOT-C backend compiles. Building is split from packaging because the release workflow runs it in an old-glibc container, and running it on the host would raise the baseline to whatever the host has. The build targets cover x86_64 and aarch64 Linux, Windows and macOS, and they produce two binaries, `veryl` and `veryl-ls`, the second being the language server, plus a separate `sourcemap-resolver` binary from the support directory. The version string is assembled from the package version, the git revision and the build date, and the whole set is also published as a Docker image under veryllang/veryl.

## Conclusion

Adopt Veryl if you are comfortable with SystemVerilog but want a smaller language to write in, and you can accept that the ecosystem is young. Skip it if your toolchain is locked to Verilog and SystemVerilog linting, since the output is SystemVerilog and the project is still in the exploration phase of language design. Before you commit, read the FAQ entries on what is deliberately not adopted, in particular auto pipelining and the off-side rule, because those are the features you will miss and the reasons are given, and note that the project is Apache-2.0 or MIT with a Docker image and a crates.io release at v0.22.0.

## FAQ

### What is Veryl?

A modern hardware description language based on SystemVerilog, implemented in Rust, with syntax optimized for logic design, synthesizability guarantees for consistency between simulation results, and transpilation to readable SystemVerilog that supports partial replacement of existing designs.

### Why does Veryl not adopt auto pipelining or the off-side rule?

Veryl focuses on equivalency with SystemVerilog at the level of language semantics, so it can predict how the generated SystemVerilog changes when the Veryl source changes, which is what makes it applicable to ASIC flows such as timing improvement and pre or post-mask ECO. Syntax features that add complexity for slight abbreviation are left out to reduce tool implementation effort.

### How does Veryl differ from Chisel and other alternative HDLs?

Many existing alternative HDLs are an inner DSL of a programming language, which brings rapid development and a reusable tooling ecosystem, but the syntax cannot fit hardware description completely and enormous Verilog code is generated, which prevents general ASIC workflows that require flip-flop level modification in Verilog.

### What licence is Veryl under and how is it distributed?

MIT OR Apache-2.0, with the crates published on crates.io, the latest being v0.22.0, and a Docker image published as veryllang/veryl. The published binaries stay dynamically linked so that native verification components and the AOT-C backend object can be loaded at run time.

## Sources

- [Issues](https://github.com/veryl-lang/veryl/issues)
- [License: Apache-2.0](https://github.com/veryl-lang/veryl/blob/master/LICENSE)
- [README](https://github.com/veryl-lang/veryl/blob/master/README.md)
- [Releases](https://github.com/veryl-lang/veryl/releases)
- [veryl-lang/veryl on GitHub](https://github.com/veryl-lang/veryl)

---

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