# Verible parses un-preprocessed SystemVerilog, which is what makes linting possible > Verible is a C++ suite of SystemVerilog tools from the Chips Alliance: a parser, style linter, formatter, language server, lexical differ and obfuscator, distributed as static binaries for Linux and Windows and packaged for Nix and macOS. **chipsalliance/verible** — Verible is a suite of SystemVerilog developer tools, including a parser, style-linter, formatter and language server - Repository: https://github.com/chipsalliance/verible - Website: https://chipsalliance.github.io/verible/ - Stars: 1,968 · Forks: 309 - Language: C++ - License: NOASSERTION - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/chipsalliance-verible ## Parsing un-preprocessed source is the design decision Verible's stated mission is to parse SystemVerilog as specified in IEEE 1800-2017 for a wide variety of applications, including developer tools. The design decision that shapes everything else is stated next: the project was born out of a need to parse un-preprocessed source files, which is what single-file applications like style linting and formatting need. Many compiler flows run preprocessing first, with includes resolved and macros expanded. A linter does not: it needs to see the file as written, with the author's line numbers intact, so it can point at a line in the repository rather than a generated file. Verible parses the un-preprocessed form and states that it can be adapted to parse preprocessed source when a toolchain requires it. The rationale is about economics rather than elegance. The README argues that no one should have to develop a SystemVerilog parser for their own application, because a standard-compliant parser is an enormous task given the syntactic complexity of the language. Verification against that claim is at least partly external: the parser is regularly tested against a growing suite of tool-independent language compliance tests hosted by the SymbiFlow project. There is a secondary objective worth noting, that the language-agnostic components of Verible be usable for rapidly developing language support tools for other languages. ## Eight tools, one syntax tree Everything in the suite sits on the same parser, which is why the tools agree with each other. verible-verilog-syntax is the standalone viewer for the structure the lexer and parser understand. It exports the concrete syntax tree as JSON, which is what makes integration with external tools practical, and the repository ships a Python wrapper module with example scripts for that export. verible-verilog-lint finds constructs a style guide calls undesirable, with many rules implemented as syntax tree pattern matching rather than text matching. Its documented features are style guide citations in diagnostics, rule deck configurability, waiver mechanisms both in-file and through an external waiver file, and a GitHub SystemVerilog linter action for CI. verible-verilog-format handles whitespace: indentation, syntax-context-aware spacing between tokens, line wrapping to a column limit, incremental formatting of only changed lines, interactive accept or decline of formatting changes, and tabular alignment. The feature list marks several of these as various degrees of work-in-progress. verible-verilog-ls is a language server speaking the standardized protocol, giving formatting and linting inside an editor, with quick-fixes where possible. The remaining tools are narrower: verible-verilog-diff compares two files for equivalence, verible-verilog-project works across a whole project as a diagnostic and transformation tool, verible-verilog-kythe-extractor emits Kythe indexing facts for cross-references in an IDE, and verible-verilog-obfuscate replaces identifiers with obfuscated names of the same length while preserving all other text, writing to stdout, which is for handing sensitive test cases to a tool vendor. ## Installing static binaries, or building with Bazel and C++20 Installation is deliberately boring. The project provides regular binary releases for Linux and Windows, including statically linked binaries for x86 and Arm so they run on almost any Linux distribution. Nix has binaries for Linux x86 and Arm, and there is a homebrew package for macOS. The macOS story is the one to check first if that is your platform, because the primary release artifacts are described as Linux and Windows and macOS is covered through Homebrew. The README does not state a minimum macOS version or an architecture list for the Homebrew package. Building from source needs the bazel build system and a C++20 compatible compiler, with dependencies installed by your package manager. On a system with the nix package manager, nix-shell is enough to get a build environment. That is a heavy requirement for what is otherwise a set of command line tools, and it is the reason most users should take a binary release. For browsing the source, the README recommends a fully indexed and searchable mirror hosted by Google, rather than reading the tree in the GitHub interface. ## Waivers are the difference between a linter people keep A style linter in an existing codebase fails for one reason: it reports thousands of findings nobody is going to fix, so the team silences the tool permanently. Verible designs around that with two specific mechanisms. First, rule deck configurability. Rules are named and can be turned on and off, so a project can adopt the rules it agrees with and add the rest later. Second, waiver mechanisms, in two forms. An in-file waiver annotates the source where the violation is, which survives code motion because it travels with the line. An external waiver file collects exceptions in one place, which is what makes a staged adoption possible: you record the existing debt once and only new violations fail the build. Diagnostics also cite the style guide, which matters more than it sounds. When a build fails on a rule, the developer can find the rule's origin and decide whether it is a real defect or a style preference they disagree with. Without the citation, a linter rule is an oracle. The formatter is deliberately not in the same category. Formatting a whole file is a large diff, and the listed features point at incremental work: formatting only touched lines, and interactive accept or decline. The README's goal for the formatter is editor-independent consistency, which is a claim about tooling rather than about enforcing a style. ## The preprocessor is not there yet verible-verilog-preprocessor is described in the README as a collection of preprocessor-like tools, with an explicit parenthetical that it does not include a fully-featured Verilog preprocessor yet. That is the clearest limitation in the tool list. It matters for a specific workflow. If your build compiles preprocessed output, or your lint step needs macro expansion to see the real code, Verible cannot be the whole pipeline on its own. The main answer is that Verible's parser can be adapted for preprocessed input, which implies the work is on your side or in the surrounding toolchain rather than in the shipped command line tools. The formatter and linter also have documented incompleteness, with the feature lists describing them as being at various degrees of work-in-progress. For a project with heavy macro use or unusual constructs, the honest test is to run verible-verilog-syntax over your real sources and see what comes back before you wire anything into CI. The project tool is similarly scoped: verible-verilog-project is a multi-tool for whole projects, described as a diagnostic tool for analysing and potentially transforming project-level sources. That is early language for something that transforms code. ## Versioning is a rolling snapshot, so pin deliberately The tag names are unusual and they tell you how to manage upgrades. Recent releases are v0.0-4296-g0f262651 from 2026-09-23, v0.0-4294-gc1d8f5e8 from 2026-09-20 and v0.0-4283-ga1b0580b from 2026-09-18, which are describe-style tags from the commit count and hash rather than semantic versions. Practically, there is no stable version number to put in a requirements file. Pinning by tag means pinning to a specific commit, and different tools in the suite ship in the same build, so a pin keeps the formatter and the linter consistent with each other. The last push was on 2026-09-23 and the repository is not archived. The licence is a detail worth resolving early for a commercial project. The repository metadata classifies the licence as a custom one GitHub cannot categorise, while the README badge points at Apache License 2.0. Those two statements should be reconciled against the LICENSE file before you vendor Verible into a product, because the README badge is the weaker evidence. The project sits under the Chips Alliance with CI, codecov coverage and contribution documentation, and the README's contributing guide and development resources are the entry points for working on it. ## Conclusion Verible suits a hardware team that wants one SystemVerilog toolchain shared across editors, CI and scripts, and that needs lint waivers rather than blanket formatting enforcement, since it ships in-file and external waiver files and a GitHub linter action. It is the wrong choice if you need a full preprocessor, because the README states verible-verilog-preprocessor is a collection of preprocessor-like tools without a fully-featured Verilog preprocessor yet. Verify first that your source parses cleanly with verible-verilog-syntax on un-preprocessed files, and pin a release tag, since the project's tag names are rolling snapshots such as v0.0-4296-g0f262651 and change with almost every commit. ## FAQ ### How do I install Verible? Binary releases are published for Linux and Windows, including statically linked builds for x86 and Arm. Nix carries binaries for Linux x86 and Arm, and macOS is covered by a homebrew package. Building locally needs bazel and a C++20 compatible compiler. ### Does Verible include a full SystemVerilog preprocessor? No. The README describes verible-verilog-preprocessor as a collection of preprocessor-like tools and states explicitly that it does not include a fully-featured Verilog preprocessor yet. ### How do I suppress Verible lint rules for existing code? The linter supports waiver mechanisms in two forms, an in-file waiver and an external waiver file, plus rule deck configurability so individual rules can be enabled or disabled. ## Sources - [chipsalliance/verible on GitHub](https://github.com/chipsalliance/verible) - [Issues](https://github.com/chipsalliance/verible/issues) - [Project website](https://chipsalliance.github.io/verible/) - [README](https://github.com/chipsalliance/verible/blob/master/README.md) - [Releases](https://github.com/chipsalliance/verible/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/chipsalliance-verible