Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Verilator MCP Server simulate my counter.v design with waveform capture"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An intelligent Model Context Protocol (MCP) server for Verilator that provides RTL simulation, automatic testbench generation, and natural language query capabilities. This tool bridges the gap between AI assistants and hardware verification, making RTL simulation more accessible and intelligent.
Automatic Testbench Generation: Intelligently generates testbenches when none exist
Smart Simulation: Compile and run simulations with automatic dependency management
Natural Language Queries: Ask questions about your simulation in plain English
Waveform Analysis: Generate and analyze simulation waveforms
Coverage Collection: Track code coverage metrics
Protocol-Aware: Built-in support for standard protocols (AXI, APB, etc.)
"Run simulation on counter.v"
"Simulate my design with waveform capture"
"Execute the CPU testbench with coverage enabled"
"Compile and run my ALU module"
"Generate a testbench for my FIFO module"
"Create an AXI testbench for the memory controller"
"Make a testbench with random stimulus for my ALU"
"Generate a protocol-aware testbench for my APB slave"
"Why is data_valid low at 1000ns?"
"What caused the assertion failure at time 5000?"
"Show me when the reset signal changes"
"Why is my output signal X?"
"Debug the state machine transitions"
"Show me the coverage report"
"Which code blocks are not tested?"
"How can I improve coverage for the controller?"
"Generate tests for uncovered scenarios"
"Explain how the CPU module works"
"What are the inputs and outputs of the ALU?"
"Analyze timing performance"
"Show the module hierarchy"
"What's the maximum operating frequency?"
Related MCP server: Waveform MCP Server
Node.js 16+
Verilator 5.0+ installed and in PATH
Git
Verilator must be installed before using this MCP server.
brew install verilatorsudo apt-get update
sudo apt-get install verilatorgit clone https://github.com/verilator/verilator
cd verilator
autoconf
./configure
make -j `nproc`
sudo make installverilator --version
# Should output: Verilator 5.0 or higher# Clone the repository
git clone https://github.com/ssql2014/verilator-mcp.git
cd verilator-mcp
# Install dependencies
npm install
# Build the project
npm run build
# Test the server
npm test
# Or run diagnostic
./diagnose.shAdd to your Claude Desktop configuration file (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"verilator": {
"command": "node",
"args": ["/path/to/verilator-mcp/dist/index.js"],
"env": {
"LOG_LEVEL": "info"
}
}
}
}After updating the configuration, restart Claude Desktop to load the MCP server.
LOG_LEVEL: Set logging level (debug, info, warn, error)
VERILATOR_PATH: Override Verilator installation path
Compile Verilog/SystemVerilog designs to C++.
Parameters:
files (required): Array of design files
topModule: Top module name
optimization: Optimization level (0-3)
trace: Enable waveform generation
coverage: Enable coverage collection
Example:
{
"files": ["cpu.v", "alu.v"],
"topModule": "cpu",
"optimization": 2,
"trace": true
}Run RTL simulation with automatic testbench generation.
Parameters:
design (required): Design file or directory
testbench: Testbench file (auto-generated if missing)
autoGenerateTestbench: Enable auto-generation (default: true)
enableWaveform: Generate waveforms (default: true)
simulationTime: Override simulation duration
Example:
{
"design": "counter.v",
"autoGenerateTestbench": true,
"enableWaveform": true,
"simulationTime": 10000
}Generate intelligent testbenches for modules.
Parameters:
targetFile (required): Verilog file containing module
targetModule (required): Module name
template: Template style (basic, uvm, cocotb, protocol)
protocol: Protocol type (axi, apb, wishbone, avalon)
stimulusType: Stimulus generation (directed, random, constrained_random)
Example:
{
"targetFile": "fifo.v",
"targetModule": "fifo",
"template": "basic",
"stimulusType": "constrained_random",
"generateAssertions": true
}Process natural language queries about simulation.
Parameters:
query (required): Natural language question
context: Current simulation context
history: Previous query history
Example:
{
"query": "Why did the assertion fail at time 5000?",
"context": {
"currentSimulation": {
"design": "cpu.v",
"waveformFile": "simulation.vcd"
}
}
}The server provides access to simulation artifacts through MCP resources:
simulation://[project]/logs/[sim_id] - Simulation output logs
simulation://[project]/waves/[sim_id] - Waveform data
simulation://[project]/coverage/[sim_id] - Coverage reports
design://[project]/hierarchy - Module hierarchy
design://[project]/interfaces - Interface definitions
Clock and reset signal identification
Port direction and width analysis
Protocol recognition
Parameter extraction
Clock generation with configurable frequency
Reset sequences with proper polarity
Directed and random stimulus
Basic assertions and checkers
Coverage points
Waveform dumping
Built-in templates for:
AXI (AXI4, AXI4-Lite, AXI-Stream)
APB (APB3, APB4)
Wishbone
Avalon
Custom protocols
Signal value analysis
Assertion failure investigation
X/Z propagation tracking
Timing relationship analysis
Performance metrics
Resource utilization
Critical path analysis
Power estimation
Coverage statistics
Uncovered code identification
Test scenario suggestions
Testbench creation
Stimulus pattern generation
Assertion generation
Coverage point creation
// 1. Compile design
{
"tool": "verilator_compile",
"arguments": {
"files": ["alu.v"],
"topModule": "alu",
"trace": true
}
}
// 2. Run simulation (auto-generates testbench)
{
"tool": "verilator_simulate",
"arguments": {
"design": "alu.v",
"autoGenerateTestbench": true,
"enableWaveform": true
}
}
// 3. Query results
{
"tool": "verilator_naturallanguage",
"arguments": {
"query": "Show me any errors in the simulation"
}
}// Natural language: "Generate a testbench and run simulation for counter.v"
{
"tool": "verilator_naturallanguage",
"arguments": {
"query": "Generate a testbench and run simulation for counter.v with coverage"
}
}
// Response will trigger testbench generation and simulation automatically// After simulation fails, ask why
{
"tool": "verilator_naturallanguage",
"arguments": {
"query": "Why did my simulation fail?",
"context": {
"currentSimulation": {
"design": "fifo.v",
"testbench": "tb_fifo.sv",
"waveformFile": "sim_output/simulation.vcd"
}
}
}
}
// Follow up with specific signal investigation
{
"tool": "verilator_naturallanguage",
"arguments": {
"query": "Why is the full signal high when count is only 5?",
"context": {
"currentSimulation": {
"design": "fifo.v",
"waveformFile": "sim_output/simulation.vcd"
}
}
}
}// Ask for coverage analysis
{
"tool": "verilator_naturallanguage",
"arguments": {
"query": "What's my current code coverage and how can I improve it?"
}
}
// Generate specific tests for uncovered code
{
"tool": "verilator_naturallanguage",
"arguments": {
"query": "Generate test cases for the error handling paths"
}
}// Ask about module functionality
{
"tool": "verilator_naturallanguage",
"arguments": {
"query": "Explain how the AXI arbiter module works and what are its key signals"
}
}
// Analyze performance
{
"tool": "verilator_naturallanguage",
"arguments": {
"query": "What's the critical path in my design and how can I optimize it?"
}
}// Generate AXI testbench
{
"tool": "verilator_testbenchgenerator",
"arguments": {
"targetFile": "axi_slave.v",
"targetModule": "axi_slave",
"template": "protocol",
"protocol": "axi",
"generateAssertions": true
}
}
// Or use natural language
{
"tool": "verilator_naturallanguage",
"arguments": {
"query": "Create an AXI testbench with burst transactions for my memory controller"
}
}// Step 1: Initial query
User: "I have a new UART module, help me verify it"
Assistant: "I'll help you verify your UART module. Let me first generate a testbench..."
// Step 2: Run simulation
User: "Run the simulation with baud rate 115200"
Assistant: "Running simulation with 115200 baud rate..."
// Step 3: Debug issue
User: "The parity bit seems wrong"
Assistant: "Looking at the waveform, I can see the parity calculation is using even parity..."
// Step 4: Fix and verify
User: "Generate a test specifically for odd parity mode"
Assistant: "I'll create a directed test case for odd parity verification..."npm install
npm run buildnpm testLOG_LEVEL=debug npm startRun the diagnostic script to check your setup:
./diagnose.shVerilator not found
# Install Verilator first!
brew install verilator # macOS
sudo apt-get install verilator # Ubuntu/Debian
# Verify installation
verilator --versionServer not starting in Claude Desktop
Ensure Verilator is installed (see above)
Check paths in Claude Desktop config are absolute
Restart Claude Desktop after configuration changes
Run ./diagnose.sh to check setup
Compilation errors
Check file paths are correct
Verify SystemVerilog syntax
Review error messages in logs
Testbench generation fails
Ensure module has standard port declarations
Check for unsupported constructs
Try simpler template options
For detailed troubleshooting, see TROUBLESHOOTING.md
Contributions are welcome! Please:
Fork the repository
Create a feature branch
Add tests for new features
Submit a pull request
MIT License - see LICENSE file for details
Built on the Model Context Protocol by Anthropic
Powered by Verilator open-source simulator
Natural language processing using Natural library
Compile Verilog/SystemVerilog design files to C++ using Verilator
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | Verilog/SystemVerilog files to compile | |
| trace | No | Enable waveform tracing | |
| defines | No | Macro definitions | |
| threads | No | Number of threads for compilation | |
| coverage | No | Enable coverage collection | |
| includes | No | Include directories | |
| language | No | HDL language standard | systemverilog |
| warnings | No | Warning flags to enable | |
| makeFlags | No | Additional make flags | |
| outputDir | No | Output directory for compiled files | obj_dir |
| topModule | No | Top module name | |
| traceFormat | No | Waveform format | vcd |
| optimization | No | Optimization level | |
| verilatorFlags | No | Additional Verilator flags | |
| suppressWarnings | No | Warning flags to suppress |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the basic compile action. It does not disclose side effects (e.g., overwriting output directory), resource usage, or authentication needs, which are important for such a tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence. While it is appropriately concise, it could include more useful context without becoming overly verbose, so it is not a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (15 parameters, no output schema), the description is insufficient. It does not explain return values, success/failure behavior, or prerequisites. The absence of an output schema increases the need for description completeness, which is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the baseline is 3. The tool description adds no additional meaning to any parameter, but it does not need to since the schema describes all parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('compile'), the resource ('Verilog/SystemVerilog design files'), the output ('to C++'), and the tool ('using Verilator'). This distinguishes it from sibling tools like 'verilator_simulate' and 'verilator_testbenchgenerator', which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings (e.g., verilator_simulate for simulation, verilator_testbenchgenerator for testbenches). It lacks explicit context, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Process natural language queries about RTL simulation, debugging, and analysis
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language query about simulation | |
| context | No | ||
| history | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'process natural language queries' without indicating safety, side effects, authentication needs, or whether it modifies state or returns results. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise but lacking structure. It is front-loaded, but brevity sacrifices important details. It is under-specified for the tool's complexity, earning a middle score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters including nested objects, no annotations, and no output schema, the description is severely incomplete. It fails to explain return values, side effects, or how to use the parameters. This is a significant gap for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the tool description does not mention any of the three parameters (query, context, history). It adds no meaning beyond the schema, failing to compensate for the low coverage. Parameters are entirely undocumented in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it processes natural language queries about RTL simulation, debugging, and analysis. It distinguishes from sibling tools which are about compilation, simulation, and testbench generation. However, the verb 'process' is somewhat vague and could be more specific (e.g., answer, interpret).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings (verilator_compile, verilator_simulate, verilator_testbenchgenerator) or any context for appropriate usage. No when-not-to-use or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run RTL simulation with automatic testbench generation if needed
| Name | Required | Description | Default |
|---|---|---|---|
| design | Yes | Design file or compiled directory | |
| defines | No | Macro definitions | |
| timeout | No | Simulation timeout in milliseconds | |
| verbose | No | Verbose output | |
| plusargs | No | Plusargs to pass to simulation | |
| outputDir | No | Output directory for simulation artifacts | sim_output |
| testbench | No | Testbench file (will auto-generate if missing) | |
| topModule | No | Top module name | |
| waveformFile | No | Waveform output file | |
| coverageTypes | No | Coverage types to collect | |
| enableCoverage | No | Enable coverage collection | |
| enableWaveform | No | Generate waveform dump | |
| simulationTime | No | Override simulation time | |
| waveformFormat | No | Waveform format | vcd |
| enableAssertions | No | Enable assertion checking | |
| useExistingBuild | No | Use existing compiled output | |
| optimizationLevel | No | Optimization level | |
| autoGenerateTestbench | No | Auto-generate testbench if missing |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like file creation, side effects, error handling, and performance impacts. It only hints at conditional testbench generation but fails to explain the simulation process, resource usage, or that it modifies output directories. This is insufficient for an agent to anticipate the tool's full behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence, capturing the core action. It is front-loaded with the main purpose. However, given the tool's complexity (18 parameters), the description may be too brief to be fully informative; a slightly longer description could add useful context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about return values (no output schema), simulation results, error handling, and the overall workflow. For a complex tool with many parameters, the description is not sufficiently complete to guide an agent on expected outcomes or process steps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the baseline is 3. The tool description adds no additional meaning or context for the parameters beyond what the schema already provides. Thus it meets the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the primary action (run RTL simulation) and highlights a key feature (automatic testbench generation). However, it does not explicitly differentiate from sibling tools like verilator_testbenchgenerator, which also generates testbenches. The purpose is largely clear but lacks distinct context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not specify when to use this tool over verilator_compile, verilator_testbenchgenerator, or other alternatives. There are no prerequisites, conditions, or exclusions mentioned, leaving the agent without guidance on appropriate deployment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate intelligent testbenches for Verilog/SystemVerilog modules with automatic stimulus generation
| Name | Required | Description | Default |
|---|---|---|---|
| protocol | No | Protocol type for protocol-aware testbench | |
| template | No | Testbench template style | basic |
| parseOnly | No | Only parse module, don't generate testbench | |
| outputFile | No | Output testbench file path | |
| targetFile | Yes | Verilog file containing the module to test | |
| clockPeriod | No | Clock period in time units | |
| stimulusType | No | Type of stimulus to generate | directed |
| targetModule | Yes | Module name to generate testbench for | |
| resetDuration | No | Reset duration in time units | |
| simulationTime | No | Total simulation time | |
| generateCheckers | No | Generate response checkers | |
| generateCoverage | No | Generate coverage points | |
| generateAssertions | No | Generate assertions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions 'intelligent' and 'automatic' stimulus generation but does not disclose behaviors like overwriting files, dependencies, or side effects. Some behavioral traits (e.g., generating checkers) are only implied via parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key action. It is appropriately sized but could include more structure (e.g., a brief list of capabilities). No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 13 parameters, no output schema, and no annotations, the description is too high-level. It does not explain return values, file creation, error handling, or what constitutes a successful generation. The complexity demands more completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond parameter names and types. It does not explain relationships or constraints among parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates testbenches for Verilog/SystemVerilog modules with automatic stimulus generation, and the verb 'generate' and resource 'testbenches' are specific. It effectively distinguishes from siblings like compile, simulate, and natural language.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies use when needing testbenches, it provides no explicit guidance on when to use this tool vs alternatives like verilator_compile or verilator_simulate. No when-not-to-use or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: compilation, natural language processing, simulation, and testbench generation. There is no overlap in functionality, and the descriptions make it easy to differentiate between them.
All tool names follow a consistent verb_noun pattern with the prefix 'verilator_' followed by a descriptive action (e.g., compile, simulate). This uniformity makes the tool set predictable and easy to navigate.
With 4 tools, the server is well-scoped for its purpose of RTL simulation and analysis. Each tool serves a specific and necessary function in the workflow, avoiding bloat or oversimplification.
The tools cover core RTL simulation tasks (compile, simulate, generate testbenches) and add a natural language interface for queries. Minor gaps might include more advanced debugging or analysis tools, but the set supports basic to intermediate workflows effectively.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Run, build, and validate firmware on virtual hardware from your AI agent. Hardware knowledge corpus.
Evaluate, benchmark, and simulate AI agents on the VerifyAX agent-evaluation platform.
Design, save, and run outcome-aligned AI workflows and verifiers, with reliable image output.
Direct access to Cypress tests results and accessibility reports in your AI workflow.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ssql2014/verilator-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
