# Verilator: compiling SystemVerilog into C++ for fast simulation and lint > Verilator reads Verilog and SystemVerilog, lints it, and emits single- or multithreaded C++ or SystemC models. It is fast and openly licensed, but it is not a drop-in replacement for a full commercial simulator. **verilator/verilator** — Verilator open-source SystemVerilog simulator and lint system - Repository: https://github.com/verilator/verilator - Website: https://verilator.org - Stars: 3,977 · Forks: 925 - Language: SystemVerilog - License: NOASSERTION - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/verilator-verilator ## What Verilator is for, and who reaches for it Verilator is a Verilog and SystemVerilog simulator that does not interpret your design. The README states that it reads the source, performs lint checks, optionally inserts assertion checks and coverage-analysis points, and outputs single- or multithreaded .cpp and .h files, the Verilated code. Those files are then compiled and linked into an executable that performs the simulation. The README describes Verilator as accepting Verilog or SystemVerilog, including UVM, and as able to create JSON to front-end your own tools. The audience follows from that design. If you are verifying an RTL block and you want the testbench written in C++ or SystemC, Verilator is built for you. If you want lint as a separate gate over HDL that will never be simulated here, the same binary does that. If you want to migrate SystemVerilog into C++ or SystemC, the README names that migration as a reason to pick the tool. The README also notes out-of-the-box support from Arm and RISC-V vendor IP, which matters if you are integrating third-party cores. The README's own framing of the boundary is worth quoting: it says Verilator "currently may not be the best choice if you are expecting a full-featured replacement for a closed-source Verilog simulator, performing SDF annotation, or mixed-signal simulation." Treat that sentence as the scope statement, not as marketing hedging. ## The compilation model: Verilog in, optimized C++ out The mechanism is a compiler, not an event-driven interpreter. Verilator parses the HDL, applies lint and optional assertion and coverage instrumentation, then emits C++ classes that represent the design hierarchy. The README is explicit that Verilator "does not directly translate Verilog HDL to C++ or SystemC" but rather "compiles your code into a much faster optimized and optionally thread-partitioned model, which is in turn wrapped inside a C++/SystemC module." That two-stage structure is why the output is fast and why the build step exists. You can let Verilator generate the simulator executable itself with --binary, or you can write your own C++/SystemC wrapper that instantiates the generated model. The README also mentions linking Verilator-generated libraries, optionally encrypted, into other simulators. For tool builders, the JSON output is a third exit: your own front end consumes the design description instead of a simulator. Performance claims in the README are relative, not absolute. It states the compiled model executes on a single thread over 10x faster than standalone SystemC and about 100 times faster than interpreted Verilog simulators such as Icarus Verilog, with another 2-10x possible from multithreading. Those are the project's numbers, and the README does not give a benchmark configuration alongside them, so treat them as order-of-magnitude expectations rather than a guarantee for your design. ## Installing Verilator and running a first build The README does not carry install commands. It points to the installation and package directory structure page at https://verilator.org/install, and the repository ships configure.ac, Makefile.in and CMakeLists.txt, so a source build is one supported route. Distro packages exist as well; the README links a repology badge for distro packages and a Docker image at hub.docker.com/r/verilator/verilator. Use the install page for the commands that match your platform rather than copying a build recipe from here. The repository's examples/ directory is the fastest way to see a working flow. It contains make_hello_binary, make_hello_c, make_hello_sc, cmake_hello_c, cmake_hello_sc, and tracing variants for both C and SystemC, plus json_py for the JSON path and protect_lib for encrypted libraries. The make_hello_binary example is the shortest path to a running simulation, because --binary makes Verilator produce the executable for you. Those example directories carry their own makefiles and CMake files, so the build command belongs to the example, not to this article. The README does not print a Verilator invocation anywhere, and the manual it links at https://verilator.org/verilator_doc.html is where the option list lives. Read the makefile in examples/make_hello_binary to see the exact flags the project uses for that example, then adapt them to your own top-level file. If you prefer to drive the generated model yourself, the README describes the alternative: write a C++/SystemC wrapper that instantiates the Verilated model. The examples/make_hello_c and examples/make_hello_sc directories show that pattern, and examples/cmake_hello_c and examples/cmake_hello_sc show the same thing under CMake. Start from those rather than from an empty file. ## Where Verilator is the wrong tool The README names three cases directly. SDF annotation, mixed-signal simulation, and the expectation of a full-featured replacement for a closed-source Verilog simulator are all listed as reasons Verilator may not be the best choice. If your signoff flow depends on back-annotated timing, this is not the simulator for that step. The second limitation is semantic. The README states that tristate-bus (z) and unknowns (x) are "handled in limited contexts, in a special manor for performance." That phrasing is a trade-off, not a bug report: the two-state optimization that makes the compiled model fast is the same thing that limits how faithfully four-state behavior is modeled. Designs that rely on x-propagation to expose uninitialized state, or on z for bus contention checks, need to be evaluated against that constraint before you build a regression around Verilator. The third is the build step itself. Because Verilator emits C++ that must be compiled, a quick edit-and-run loop is not the same as an interpreted simulator's. The README positions Icarus Verilog as the fallback: "If Verilator does not support your needs, perhaps Icarus may." That is the project telling you where its own boundary sits, and it is worth taking at face value. ## Verilator compared with Icarus Verilog The README lists Icarus Verilog under Related Projects and describes it as "a highly-featured interpreted Verilog simulator." The difference in approach is the whole story. Icarus interprets the HDL at run time; Verilator compiles it ahead of time into C++ and then into a native executable. That is why the README can claim roughly 100x single-thread speed over interpreted simulators, and why Verilator costs you a compile step that Icarus does not. The trade runs the other way on coverage. An interpreter can afford to model four-state semantics and less common constructs more completely, because it is not optimizing for throughput. Verilator's README concedes limited handling of z and x and points at Icarus when Verilator does not fit. If your testbench depends on x-propagation or tristate behavior, Icarus is the more faithful choice; if you need throughput on a large design and your testbench is C++ or SystemC, Verilator is the one built for that. A practical split some teams use is lint and fast regression on Verilator, with a second simulator for the checks Verilator cannot do. The README does not describe such a flow, so treat it as a pattern to evaluate rather than a documented recommendation. ## Maintenance, licensing and upgrade cost The repository is not archived, and the last push was on 2026-09-23. That is the only maintenance signal available here; the README does not publish a release cadence, and no recent releases were retrieved. The README does describe the project as community driven, guided by the CHIPS Alliance under the Linux Foundation, with commercial support contracts, design support contracts and enhancement contracts available. If you need a vendor relationship, that path exists, but the README does not describe service levels. Licensing is dual. The README states Verilator is free software under either the GNU Lesser General Public License Version 3 or the Perl Artistic License Version 2.0, and the repository carries both a LICENSE file and a LICENSES/ directory alongside a REUSE.toml file. The SPDX header in the README itself reads LGPL-3.0-only OR Artistic-2.0. This is not legal advice: if you plan to redistribute Verilator or link its output into a product, read the LICENSE and LICENSES/ files yourself and get your own counsel. The README's own note that generated libraries can be optionally encrypted is relevant to anyone shipping a protected model. Upgrade cost is mostly the C++ toolchain, not Verilator flags. Your wrapper code is compiled against the generated headers, so a Verilator upgrade can surface as compiler errors in your testbench. The repository's test_regress directory and the CI workflow files under .github/ are where the project tests itself; there is no compatibility promise in the README for the generated API across versions. ## Conclusion Adopt Verilator when you want a compiled, openly licensed Verilog/SystemVerilog simulator for C++ or SystemC testbenches, for lint, or for feeding JSON to your own tooling, and when your design avoids heavy SDF annotation or mixed-signal work. Do not adopt it if you need a full-featured replacement for a closed-source simulator, or if your flow depends on tristate and x-propagation semantics that the README describes as limited. Before committing, verify the install path on your platform against https://verilator.org/install, confirm that the constructs your design uses are covered, and check the LICENSE and LICENSES/ directory for the exact licensing terms that apply to your use. ## FAQ ### What is Verilator used for? It reads Verilog or SystemVerilog, performs lint checks, optionally inserts assertion and coverage instrumentation, and outputs single- or multithreaded C++ or SystemC models. It can generate a simulator executable with --binary or emit JSON to front-end your own tools. ### Is Verilator free to use? Yes. The README states Verilator is free software under either the GNU Lesser General Public License Version 3 or the Perl Artistic License Version 2.0, and describes it as open and free as in both speech and beer. ### How do I install Verilator? The README does not list install commands; it points to the installation and package directory structure page at https://verilator.org/install. The repository also links distro packages and a Docker image at hub.docker.com/r/verilator/verilator. ### how to use verilator Invoke it with parameters similar to GCC or Synopsys's VCS, let it lint and compile the design, and either use --binary to generate a simulator executable or write a C++/SystemC wrapper that instantiates the generated model. The examples/ directory, including make_hello_binary and make_hello_c, shows working flows. ### how to use verilator in ubuntu The README does not give Ubuntu-specific steps. It points to the installation and package directory structure page at https://verilator.org/install, and it links a repology badge for distro packages, which is where a distribution package for your system would be listed. ### how to install verilator on windows The README does not describe Windows installation. It directs readers to the installation page at https://verilator.org/install and links a Docker image at hub.docker.com/r/verilator/verilator, but it gives no Windows-specific instructions. ## Sources - [Issues](https://github.com/verilator/verilator/issues) - [Project website](https://verilator.org) - [README](https://github.com/verilator/verilator/blob/master/README.md) - [verilator/verilator on GitHub](https://github.com/verilator/verilator) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/verilator-verilator