Simulating a design that already has a testbench is a build command; getting a clock, a reset with the right polarity, stimulus and basic assertions written for a module you just wrote is the part that normally costs an afternoon. The generator infers clock and reset signals, port widths and protocol from the module itself, so the useful first move is to run a simulation on a bare .v file and read what it produced.
A front end for Verilator aimed at the moment before you have a testbench. Point it at a Verilog or SystemVerilog file and it will compile, generate stimulus, run the simulation, and let you ask about the result in ordinary sentences.
- `verilator_compile` builds a design to C++, taking the file list and a top module, with optimisation level, waveform tracing and coverage as options
- `verilator_simulate` runs the simulation and generates the testbench automatically when one is missing, with waveform capture on by default
- `verilator_testbenchgenerator` writes a testbench for a named module — templates for basic, UVM, cocotb and protocol styles, protocol awareness for AXI, APB, Wishbone and Avalon, and directed, random or constrained-random stimulus
- `verilator_naturallanguage` answers questions about a run — why a signal is low at a given time, what caused an assertion failure, where coverage is missing
- Simulation artefacts are exposed as resources: logs, waveform data, coverage reports, module hierarchy and interface definitions
Verilator 5.0+ installed and on PATH — the server does not bundle it — plus Node.js 16+ and Git. Clone, install, build, and point the client at the compiled entry point; published as @mcp/verilator-server, version 0.2.0. LOG_LEVEL sets verbosity and VERILATOR_PATH overrides the Verilator location. A diagnostic script in the repo checks the setup.