Two commands inside Claude Code. Then a one-liner for VHDL if you need it. The full path, end-to-end, in five steps.
You need a working Claude Code install and, for VHDL only, a Rust toolchain so cargo install vhdl_ls can build the binary. SystemVerilog/Verilog needs nothing else on Linux x64 — the pinned Verible binary downloads on first session.
Run these two commands inside Claude Code. The first registers nyavana/fpga-lsp as a marketplace, the second installs the plugin from it.
› /plugin marketplace add nyavana/fpga-lsp › /plugin install fpga-lsp@fpga-lsp
On Linux x64, the pinned Verible binary auto-installs into the plugin's data directory on first session. SystemVerilog and Verilog work immediately — open a .sv file and edits start producing diagnostics.
The plugin shipped three skills (sv-lint, sv-format, sv-diff), one agent (sv-reviewer), and a session-start hook that walks the workspace and writes .fpga-lsp/verible.filelist for cross-file resolution. If your repo already commits a verible.filelist, the plugin respects it byte-for-byte.
vhdl_lscargo install vhdl_ls alone is not enough. The binary it installs cannot resolve library ieee; or use ieee.std_logic_1164.all; without a vhdl_ls.toml at your project root that tells it where standard libraries live.
cargo install vhdl_ls
# vhdl_ls.toml at project root [libraries] mylib.files = [ "src/**/*.vhd", ]
Replace mylib with your design library name and update the glob to match your source layout. Add more libraries by repeating the <lib>.files = [ ... ] block. Standard libraries usually come from rust_hdl's bundled stdlib — vhdl_ls auto-locates std/ and ieee/.
If you maintain several VHDL projects, set VHDL_LS_CONFIG to a global config that holds standard-library paths. The project-local vhdl_ls.toml still takes precedence for [libraries] declared there.
export VHDL_LS_CONFIG="$HOME/.config/vhdl_ls/global.toml"
See VHDL-LS/rust_hdl for current details on bundled stdlib resolution and config search order.
Linux x64 is the only auto-install target in v1. On other platforms, the LSP wrapper prints a clear, README-pointing error on first launch — not a generic command not found — so the failure mode is obvious. Pick the matching asset from the Verible release page and unpack it.
curl -L \ https://github.com/chipsalliance/verible/releases/download/v0.0-4053-g89d4d98a/<asset> \ -o /tmp/verible.tar.gz tar xzf /tmp/verible.tar.gz -C ~/.local/ # Then add to your shell rc (bash/zsh/fish): export PATH="$HOME/.local/verible-v0.0-4053-g89d4d98a/bin:$PATH"
The plugin's verible-ls wrapper resolves the binary from $PATH first, then falls back to the plugin-managed download. A manual install is picked up automatically.
Open any HDL file in your project. Within a beat, you should see diagnostics surface and the agent acknowledge them without a tool call. The four checks below mirror the v1 success criteria — run them against nyavana/pvz-fpga if you want a known-good repo.
.sv file and parse errors / lint warnings appear automatically — no agent tool call required.sv-lint, sv-format, sv-diff are available — direct or auto-picked by relevance.sv-reviewer runs verible-verilog-lint first and cites Verible rule IDs in its findings.verible-verilog-ls --version
The wrapper prints a clear error pointing at this page. Most failures are a missing vhdl_ls.toml, a stale $PATH after manual install, or running on a not-yet-auto-supported platform. See the FAQ.