Skip to main content
Glama
NellyW8

EDA Tools MCP Server

by NellyW8

simulate_verilog

Execute Verilog code simulation with Icarus Verilog to test hardware designs using provided design and testbench code.

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 for 'simulate_verilog' tool. Creates a temporary project directory, writes the provided Verilog design and testbench code to files, compiles using iverilog, executes the simulation, captures compile and simulation outputs, and returns a JSON object with results including a project_id for subsequent 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 for the 'simulate_verilog' tool, defining required string parameters 'verilog_code' and 'testbench_code'.
    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:749-766 (registration)
    Tool registration entry in the ListToolsRequestSchema handler, defining name, description, and input schema for 'simulate_verilog'.
    {
      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:880-890 (registration)
    Dispatch handler in CallToolRequestSchema switch statement: validates input arguments and invokes edaServer.simulateVerilog method.
    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 the full burden of behavioral disclosure. It states the action ('simulate') but doesn't explain what the simulation does (e.g., runs tests, generates waveforms), potential side effects, error handling, or output format. This leaves critical behavioral traits unspecified for a tool that likely produces results or logs.

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 and includes the tool implementation detail ('Icarus Verilog'), making it appropriately sized and easy to parse.

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 the complexity of simulation tools, no annotations, and no output schema, the description is incomplete. It doesn't cover what the simulation returns (e.g., success/failure, waveforms, logs), error conditions, or how it integrates with siblings like 'view_waveform'. This gap makes it insufficient for an agent to fully understand the tool's behavior and outputs.

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?

The input schema has 100% description coverage, clearly documenting both parameters ('verilog_code' and 'testbench_code'). The description adds no additional parameter semantics beyond what the schema provides, such as code format expectations or examples. The baseline score of 3 reflects adequate schema coverage without extra value from the description.

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'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'synthesize_verilog' or 'view_waveform', which might be related operations in the same domain.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing both design and testbench code), compare to siblings like 'run_openlane' or 'view_waveform', or specify scenarios where simulation is appropriate over other tools.

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/mcp-EDA'

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