Skip to main content
Glama
siliconsmith-mcp

siliconsmith-mcp

by RFingAdam

run_tests

Destructive

Simulate your design's cocotb tests on Icarus Verilog or Verilator, with an optional gate-level netlist run, to confirm tests pass and report the first failing assertion with file:line.

Instructions

Run the project's cocotb tests (every test/test*.py) against the design on Icarus Verilog or Verilator. It first does what emit_verilog does (elaborate, check ports, regenerate the wrapper, lint); only if that is ok does it simulate the Tiny Tapeout testbench test/tb.v. ok is true only if at least one test ran (skipped tests do not count) and none failed. The summary names the first failing test, its file:line, the assertion, and expected vs actual. test_filter is a regex that cocotb searches in '.' (for example 'test.test_wraps_at_255$'); a filtered run never counts as a full run. waves=True keeps a wave file under build/waves/ for inspect_waves. details.tests lists every test with outcome and the requirement ids it covers; details.coverage says which spec.yaml requirements have a passing test. The first Verilator run takes about half a minute; later runs reuse the build.

gl=True runs the tests at gate level (Icarus only; with Verilator it is an error). The tool first does what synthesize does, with the same checks and the same time limits (a design that fails stops there, and so does one far over the size budget; the summary says gate-level simulation could not run. A design only slightly too big is simulated, with a note), then runs the SAME test files on the resulting sky130 netlist, with the cell models of the chip library (a netlist has no RTL names: a test may only use the pins of tb, such as uo_out, and not internal signals). This catches what RTL simulation cannot: logic that behaves differently once it is real gates, such as a missing reset or an uninitialized flip-flop. The summary's first line says "Gate-level simulation" so it is never mistaken for an RTL run. A gate-level run never changes the RTL results or the RTL wave files: its waves are kept apart in build/waves/icarus-gl/ (inspect_waves reads them). It can take up to 25 minutes in the worst case; a small design takes seconds to a minute. details.gl holds the netlist hash.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project": "<project>",
      "simulator": "<simulator>"
    },
    "name": "run_tests"
  }
}

Input Schema

NameRequiredDescriptionDefault
glNo
wavesNo
projectYes
simulatorYes
test_filterNo

Output Schema

NameRequiredDescriptionDefault
okYes
detailsNo
summaryYes
artifactsNo
next_hintsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description discloses substantial behavior: it regenerates the wrapper and lints, writes waves under build/waves/ (and build/waves/icarus-gl/ for GL), reuses builds, and has explicit time limits (about 30s first Verilator run, up to 25 minutes worst-case GL). It also precisely defines ok and what the summary/details contain, including the GL summary first-line marker.

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

Conciseness4/5

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

It is front-loaded with a clear purpose and organized into RTL then GL paragraphs, and most sentences carry non-redundant detail (time limits, ok definition, details fields, GL caveats). It is long and dense, with minor asides (details.gl netlist hash, the 'never mistaken for an RTL run' reassurance) that could be trimmed, but overall it is information-rich rather than padded.

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

Completeness5/5

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

Given five parameters, a mutation/build tool, and the presence of an output schema, the description covers everything an agent needs: when it runs, ok semantics, test_filter behavior, GL prerequisites and limits, artifact locations, and the details.* structure. Nothing material for correct invocation is missing.

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

Parameters4/5

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

With 0% schema coverage, the description compensates well: test_filter is explained as a regex matched in '<module>.<test name>' with an example, gl specifies gate-level semantics and the Verilator error case, and waves specifies the retained file location. project and simulator are only implicitly covered (simulator's enum is self-explanatory), leaving a small gap, but most parameters gain meaningful semantics.

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

Purpose5/5

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

The first sentence states a specific verb, resource, and environment: it runs the project's cocotb tests against the design on Icarus Verilog or Verilator. It also distinguishes itself from siblings by noting it does what emit_verilog does first (and what synthesize does for gl=True), and routes wave inspection to inspect_waves.

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

Usage Guidelines4/5

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

It gives concrete guidance for the variants: test_filter for running a subset (with the caveat that a filtered run never counts as a full run), gl=True for gate-level (Icarus-only, error on Verilator), and waves=True to retain waveforms for inspect_waves. It does not explicitly name a when-to-use-instead alternative for the plain RTL path, but the routing to emit_verilog/synthesize/inspect_waves is clear.

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