Skip to main content
Glama
NellyW8

EDA Tools MCP Server

by NellyW8

simulate_verilog

Simulate Verilog hardware designs with Icarus Verilog by providing design and testbench code to verify functionality before implementation.

Instructions

Simulate Verilog code using Icarus Verilog

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
verilog_codeYesThe Verilog design code
testbench_codeYesThe testbench code

Implementation Reference

  • Core handler function in EDAServer class that performs Verilog simulation. Creates temporary directory, writes Verilog design and testbench files, compiles with iverilog, executes simulation, captures stdout/stderr, and returns JSON results including project_id for waveform viewing.
    async simulateVerilog(verilogCode: string, testbenchCode: string): Promise<string> {
      try {
        const projectId = Math.random().toString(36).substring(2, 15);
        const projectDir = join(this.tempDir, `sim_project_${projectId}`);
        await fs.mkdir(projectDir, { recursive: true });
    
        // Store project info
        this.projects.set(projectId, { dir: projectDir, type: "simulation" });
    
        // Write design and testbench files
        await fs.writeFile(join(projectDir, "design.v"), verilogCode);
        await fs.writeFile(join(projectDir, "testbench.v"), testbenchCode);
    
        // Compile and run simulation
        const compileCmd = `iverilog -o simulation design.v testbench.v`;
        const { stdout: compileOut, stderr: compileErr } = await execAsync(compileCmd, {
          cwd: projectDir,
          timeout: 60000,
        });
    
        const { stdout: simOut, stderr: simErr } = await execAsync('./simulation', {
          cwd: projectDir,
          timeout: 60000,
        });
    
        return JSON.stringify({
          project_id: projectId,
          success: true,
          compile_stdout: compileOut,
          compile_stderr: compileErr,
          sim_stdout: simOut,
          sim_stderr: simErr,
          note: `Use view_waveform with project_id: ${projectId} to open GTKWave`
        }, null, 2);
      } catch (error: any) {
        return JSON.stringify({
          success: false,
          error: error.message || String(error),
        }, null, 2);
      }
    }
  • Input schema definition for the simulate_verilog tool, specifying required string parameters verilog_code and testbench_code.
      name: "simulate_verilog",
      description: "Simulate Verilog code using Icarus Verilog",
      inputSchema: {
        type: "object",
        properties: {
          verilog_code: { 
            type: "string", 
            description: "The Verilog design code" 
          },
          testbench_code: { 
            type: "string", 
            description: "The testbench code" 
          },
        },
        required: ["verilog_code", "testbench_code"],
      },
    },
  • src/index.ts:750-766 (registration)
    Tool registration in the MCP server's listTools handler, defining name, description, and schema.
      name: "simulate_verilog",
      description: "Simulate Verilog code using Icarus Verilog",
      inputSchema: {
        type: "object",
        properties: {
          verilog_code: { 
            type: "string", 
            description: "The Verilog design code" 
          },
          testbench_code: { 
            type: "string", 
            description: "The testbench code" 
          },
        },
        required: ["verilog_code", "testbench_code"],
      },
    },
  • Dispatch handler in CallToolRequestSchema that validates inputs and invokes the simulateVerilog method on edaServer instance.
    case "simulate_verilog": {
      const verilogCode = validateRequiredString(args, "verilog_code", name);
      const testbenchCode = validateRequiredString(args, "testbench_code", name);
      
      return {
        content: [{
          type: "text",
          text: await edaServer.simulateVerilog(verilogCode, testbenchCode),
        }],
      };
    }
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions the simulator ('Icarus Verilog') but doesn't disclose execution details (e.g., runtime, output format, error handling, or dependencies). For a simulation tool, this lacks critical context like what gets generated or how results are accessed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It front-loads the core purpose ('Simulate Verilog code') and adds necessary specificity ('using Icarus Verilog'). Every word earns its place without redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and a simulation tool with potential complexity, the description is incomplete. It doesn't explain what the simulation produces (e.g., waveforms, logs), how to interpret results, or error scenarios. For a tool with two required inputs and no structured output documentation, this leaves significant gaps for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents both parameters ('verilog_code' and 'testbench_code'). The description adds no additional parameter semantics beyond what's in the schema, such as format requirements or interaction between the two codes. Baseline 3 is appropriate as the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Simulate') and target ('Verilog code'), and specifies the tool used ('Icarus Verilog'). It distinguishes from siblings like 'synthesize_verilog' by focusing on simulation rather than synthesis. However, it doesn't explicitly contrast with 'view_waveform' which might be related to simulation results.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing testbench code), or how it differs from siblings like 'run_openlane' or 'view_waveform' which might involve simulation-related tasks. The description assumes context without explicit instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/NellyW8/MCP4EDA'

If you have feedback or need assistance with the MCP directory API, please join our Discord server