MCP server giving AI assistants a complete FPGA toolchain -- lint, simulate, synthesize, place-and-route, and a live IP core registry
fpgaZeroMCP defines 13 tools with complete input schemas and descriptions. Naming follows verb_noun convention (lint_hdl, synthesize, place_and_route). Descriptions are detailed (100-300 chars) and explain WHAT, WHEN, and key parameters. However, output schemas are NOT documented, the rubric requires documented return types for A+ tools. Parameters have types and descriptions, but several lack constraints (e.g., timeout accepts any integer; device/package strings are free-form). Error handling is minimal, no recovery guidance or actionable error messages visible in definitions. Tool composition is sound (each does one thing), but some tools combine multiple concerns (place_and_route does synthesis + routing in one call, which is domain-appropriate but reduces composability). No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels (import_github_core and program_fpga are WRITE operations).
Format HDL source code using Verible (Verilog/SystemVerilog) or other formatters. Returns formatted code.
Generate a parameterized instance of an IP core. Accepts parameter overrides and returns the instantiation code snippet and the resolved parameters.
Get linting diagnostics (warnings, errors) for HDL code using Verible. Returns structured diagnostic information.
Retrieve a specific IP core by name. Returns the core manifest (metadata) and all HDL source files.
Import an IP core from a GitHub repository. Downloads the repository, extracts HDL files and metadata, and registers the core locally.
Lint HDL source code using iverilog/verilator (Verilog/SystemVerilog) or ghdl (VHDL). Use linter='verilator' to enable -Wall checks including multidriven net detection.
Output schemas not documented. Tools return structured data (stats, bitstream_path, diagnostics) but LLMs cannot see what fields to expect. This violates pattern:tool and forces LLMs to guess field names for downstream operations.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint). import_github_core and program_fpga are WRITE operations that modify state, but lack destructiveHint. Agents cannot distinguish safe reads from risky writes without explicit hints.
Parameter constraints are incomplete. device and package parameters accept free-form strings with no enum or pattern validation. timeout parameters accept any integer with no min/max bounds. This invites invalid input from LLMs.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | 2025-06-18+ | v2 |
Lint multiple HDL files together so cross-module references resolve. Pass a dict of filename-to-source pairs. All files are compiled in one invocation of iverilog/verilator (Verilog/SystemVerilog) or ghdl (VHDL). Use linter='verilator' to enable -Wall checks including multidriven net detection.
List all available IP cores in the registry, optionally filtered by category or search query. Returns core metadata (name, version, description, language, category, tags).
Synthesize HDL with Yosys then place-and-route with nextpnr in one step. Provide source as: code (single string), files (dict of filename→source), or project_dir (path to HDL files on disk). If backend=litex, runs LiteX build and ignores HDL inputs. Returns max frequency, critical path, resource utilization, and bitstream_path — a file on disk ready for program_fpga. Set return_bitstream_b64=true to also get the bitstream inline. Supported targets: ice40, ecp5, nexus, gowin. Common device/package values: ice40: device=hx1k|hx8k|up5k|lp1k package=tq144|qn84|sg48|cm81 ecp5: device=25k|45k|85k package=CABGA256|CABGA381 nexus: device=LIFCL-40-9BG400C (package embedded in device string) gowin: device=GW1N-UV4LQ144C6/I5 (package embedded in device string)
Program an FPGA with a bitstream file. Requires the bitstream path and target device/programmer configuration.
Search GitHub for open-source FPGA IP repositories matching a query. Filters by license (MIT, BSD, Apache-2.0, etc.) and returns repository metadata with download links.
Simulate HDL using iverilog (Verilog/SystemVerilog) or ghdl (VHDL). Provide design and testbench as code strings. Returns stdout/stderr and success flag. Useful for verifying logic before synthesis.
Synthesize HDL (Verilog, SystemVerilog, or VHDL) using Yosys or run LiteX backend. Provide source as: code (single string), files (dict of filename→source), or project_dir (path to HDL files on disk). Returns structured resource statistics (stats field: wires, cells, cells_by_type, ...) and the list of inferred modules. Logs are truncated on success; full logs are kept on failure. Supported targets: generic, ice40, ecp5, gowin, xilinx, intel.
Error handling guidance missing. No recovery hints in tool descriptions. If synthesis fails, LLM has no guidance on whether to retry, adjust parameters, or ask user. Violates pattern:recovery-guide.
place_and_route combines synthesis + routing in one tool. While domain-appropriate, this reduces composability. Agents cannot run synthesis alone without routing, or route pre-synthesized designs. Consider splitting into separate tools for advanced workflows.