JanusHDL

October 2026 · Rune Bæverrud

Meet JanusHDL

JanusHDL is an HDL simulator. It runs your VHDL testbenches today, from VHDL-1993 to VHDL-2019 with PSL, and Verilog and SystemVerilog are next. It is free of charge, for anyone and any use. It runs on Windows and Linux, on x86 and ARM, and yes, on a Raspberry Pi. And it is fast. Let me show you around.

Written from the standard up

JanusHDL was written from scratch, from the IEEE standards, rule by rule. Not from anyone's habits, not from folklore about what simulators usually let you get away with: from the text of the language reference manual. Every rule the standard makes is a rule JanusHDL checks, and when it says no, it tells you which clause says so and how to fix your code.

That sounds strict, and it is. But it is strict the friendly way:

error[undeclared]: `uvvm_util_context` is not declared in `uvvm_util`
  = help: library `uvvm_util` has no design units yet: analyze its
          sources into it first, before the files that use it
  = LRM 8.3

An error that says what is wrong, where, why, and what to do about it. That is the bar for every message.

Correct first

A simulator is only worth running if you can trust what it tells you. So correctness comes first, and it is measured, on every single change:

  • 6,867 Open Logic tests, 1,338 of VUnit's own, OSVVM's 314, UVVM's 123 and its demo testbenches: all passing.
  • 3,652 of the 3,657 cases of the VHDL-93 conformance suite.
  • Testbench code is compiled to machine code as it runs, and that compiled code is checked against the interpreter on every change: the same values, the same messages, the same failures.
  • The same design gives the same result on every run and every machine. Deterministic, every time.

Then FAST!

Correct is the floor, not the ceiling. JanusHDL compiles the busiest parts of your testbench to native machine code while the simulation runs, on by default, so long UVVM and OSVVM regressions get the same attention as small RTL tests.

And the waveforms keep up. The viewer reads a recording only where the screen needs it, so a run's waveforms open whatever their size. I tried it on a recording of 1.8 billion value changes, a 5.2 GB file: open in under four seconds, in less than a gigabyte of memory, so an ordinary laptop has room to spare. Zoom all the way out and it draws from summaries stored in the file, showing exactly what it would show if it had read every change.

Try it in five minutes

No installer, no account, no licence server. Unzip it, put its bin folder on your path, and point it at a testbench you already have:

jhdl counter.vhd counter_tb.vhd --top counter_tb
jhdl -f project.f --top mylib.tb --stop-time 10us --wave run.jhw
jhdlw run.jhw

The first line analyzes, elaborates and runs. The second records every signal while it runs. The third opens the waves. Or skip the command line entirely: jhdlw opens the window, where you can run a design, watch its output and its waves as they happen, edit the code in the built-in editor, and ask why a signal has its value: its drivers, what they read, and the one input that changed last.

Your scripts keep working

You have scripts. Everybody has scripts. JanusHDL comes with front ends that take the commands your flow already calls: put one folder on your path instead of another, and your existing scripts run as they are. VUnit's run.py works the same way.

And old code? Code that relies on things the standard forbids (it happens to the best libraries) runs one switch away: --compat. Each such spot becomes a warning with its clause, instead of an error, so you know exactly what to fix, when you get around to it.

Races: found, not hidden

Two processes that wake up at the same moment and touch the same shared variable, file or log: that is a race, and on most days it hides. The test passes, the next run passes, and one day, on another machine, it does not.

JanusHDL runs processes in one fixed order, so your results never wobble. And when you want to know whether they would, give it another order: --order-seed shuffles which process runs first. If the result changes, you have a race, and now you know where to look. Running the demo testbenches of a well-known verification library this way turned up two of them, in one demo, with the exact time steps where the order mattered.

Who is behind it

Me: Rune Bæverrud, an engineer who makes tools for engineers. LinkLab is another one.

JanusHDL is built with an AI coding assistant at my side, and I am happy to say so. The assistant writes a lot of code, fast. What it does not get to do is decide what is right: the language reference manual decides that, and thousands of tests check it on every change. That combination is how one person can build a simulator that takes the standard this seriously.

What's next

Verilog and SystemVerilog are next, on the same core, so mixed-language designs come with them. Until then: download JanusHDL, run something you know well, and see what it tells you. It costs nothing to find out.