GTKWave: a GTK waveform viewer for VCD, FST and GHW simulation dumps

It is a viewer of finished dumps, not a capture tool

GTKWave is described as a fully featured GTK+ based wave viewer for Unix and Win32 that reads LXT, LXT2, VZT, FST and GHW files as well as standard Verilog VCD and EVCD files and allows their viewing. The distinction that matters in practice is that the input is a finished dump, produced earlier by a simulator or a conversion step, and the application's job is to explore it. It is not a logic analyser, it does not talk to hardware, and it does not stream. A hardware engineer with a board producing live samples is in the wrong place with this tool. An RTL engineer who just ran a simulation and wants to see when a signal changed relative to another is in exactly the right place. The project description calls it a wave viewer, and the README body emphasises the same thing, that it reads those files and allows their viewing.

The format list is the reason to choose it over a text dump

The file formats supported are where the practical value sits. Standard Verilog VCD is the near-universal output of simulators, and EVCD is its extended variant. FST and GHW are the compact alternatives, and the project description also names LXT, LXT2 and VZT. Compact formats matter because a VCD file for a non-trivial design run can be enormous, and the whole reason the FST and GHW formats exist is to store the same trace in a fraction of the space. A viewer that reads all of them means you are not forced to change your simulator's output settings to open a trace, which is the friction that usually pushes people back to grepping a text file. The topic tags on the repository reflect the same list, with fst, ghw and vcd among them.

Build dependencies differ enough per platform to be worth copying

The README gives separate dependency lists for three platforms, and the differences are informative. On Debian and Ubuntu the list includes build-essential, meson, gperf, flex, desktop-file-utils, libgtk-3-dev, libgtk-4-dev, libbz2-dev, libjudy-dev, libgirepository1.0-dev and libjson-glib-dev.

apt install build-essential meson gperf flex desktop-file-utils libgtk-3-dev libgtk-4-dev \
            libbz2-dev libjudy-dev libgirepository1.0-dev libjson-glib-dev

Fedora's equivalent adds tcl and uses gobject-introspection-devel.

dnf install meson gperf flex glib2-devel gcc gcc-c++ gtk3-devel gtk4-devel \
            gobject-introspection-devel desktop-file-utils tcl

On macOS the list is a Homebrew invocation covering desktop-file-utils, shared-mime-info, gobject-introspection, gtk-mac-integration, meson, ninja, pkg-config, gtk+3, gtk4 and json-glib. The gperf and flex entries in particular are the ones a hand-rolled build tends to miss, since the source uses them to generate parser tables.

Meson is the build system, and the sequence is short

GTKWave builds with meson, and the README gives the whole sequence. Clone the repository, change into the directory, configure a build directory with meson setup, and install.

git clone "https://github.com/gtkwave/gtkwave.git"
cd gtkwave
meson setup build && cd build && meson install

The repository root confirms a meson-based project with meson.build and meson_options.txt, and it also carries muon_fmt.ini, which is the formatter configuration meson itself uses. There is a src/ directory, a lib/ directory, a subprojects/ directory for vendored dependencies, a share/ directory for the desktop integration files that the desktop-file-utils package in the dependency list exists to install, and doc/, docs/ and man/ directories for documentation. A macos/ directory and an MSYS2/ directory cover the two platform-specific build paths, and the project includes .clang-format for C style.

Running it takes one argument, and the savefile is the reusable artefact

The invocation is a single command with a path.

gtkwave [path to a .vcd, .fst, .ghw dump file or a .gtkw savefile]

What that last argument type means is the most useful thing in the README. A .gtkw file is a saved view, and the examples directory makes that concrete with des.gtkw and transaction.gtkw alongside the matching .fst files, plus a .stems file and a .tcl script, and a gtkwaverc configuration file. So the intended workflow is to open a dump once, curate the signal list into a saved view, and reopen that view later against a new dump from the same design. That is the difference between a viewer you use once and a tool that becomes part of a debug loop. The README also points to the built in help and the man page for the available command line parameters.

The examples directory doubles as a format tutorial

The examples folder is small and tells you a lot about the supported surfaces. There are.fst files, a.gtkw savefile, a.stems file, a.tcl script, a C source file transaction.c that presumably generates the trace, an sst_exclusion_example.rc configuration, and a gtkwaverc file. The source file next to the dump and the Tcl script is the interesting pairing, because it means the repository demonstrates the whole loop rather than shipping a binary blob with no provenance. The.stems file is the GTKWave mechanism for grouping signals under a stem, which is how a wide design is kept navigable once you have more than a handful of signals on screen.

GPL-2.0 licensed, with the release tags lagging the commits

The licence is GPL-2.0, with LICENSE and LICENSE.TXT both present at the repository root alongside COPYING, and the code has a long history visible in ChangeLog.old and the AUTHORS file. The GPL terms mean that distributing a modified GTKWave requires offering the source, which is the usual consideration for a tool you install on your own machine rather than embed in a product. The maintenance picture needs care in how it is stated. The last push to the repository was on 2026-10-12, and the CHANGELOG.md is present and current, but the only release tag listed is a nightly dated 2020-07-21. In other words, the code is being worked on but the project does not publish versioned GitHub releases, so a user who wants a stable reference point has to take the tip of the default branch or rely on their distribution's package.

A text-based alternative answers a different question

The realistic alternative to a waveform viewer is not another viewer but a text tool, and the difference in approach is instructive. Reading a VCD as text with grep or a small script gives you exact value queries and easy scripting, at the cost of any notion of time. You can find the value of a signal at a specific time, but you cannot see the shape of a waveform, the alignment between buses, or the transition edges that make a design misbehave. A graphical viewer inverts that: it makes the temporal relationships immediately legible and makes precise value extraction tedious. Which one is right depends on the question. If you are debugging why a handshake protocol deadlocked, you want the picture. If you are checking one signal against a threshold across a run of thousands of cases, you want the text.

Editorial conclusion

GTKWave is worth adopting for anyone who already produces VCD or FST output from a simulator, because the format support covers both the human-readable standard and the compact variants, and the .gtkw savefile format lets you keep a curated view of the interesting signals rather than re-selecting them by hand. It is a poor fit if you need to capture from live hardware, since this is a viewer of existing dumps, and a poor fit if you want a scripted analysis pipeline, since the interface is a graphical application. Verify first that your simulator's output format is one of the supported ones, and note that the last push to the repository was on 2026-10-12 even though the only listed release tag is a nightly dated 2020-07-21.

Frequently asked questions

Official sources

1. gtkwave/gtkwave on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases