vivado-red-mcp — Vivado MCP server, Red Pitaya edition
An MCP server that lets an AI assistant such as Claude drive AMD/Xilinx Vivado directly: create projects, build block designs, synthesize, implement, simulate, read timing/utilization reports and generate bitstreams — without opening the Vivado GUI.
It has first-class support for the Red Pitaya STEMlab 125-14 (Zynq
xc7z010clg400-1): you can go from a natural-language description to a
.bit.bin running on the board, using either pure RTL or the official
RedPitaya-FPGA PS+PL (ARM + FPGA) backbone, and deploy it over SSH.
Forked from coreyhahn/vivado_mcp and heavily extended (93 tools): block design / IP Integrator, IP catalog, Hardware Manager, advanced reports, Red Pitaya RTL and PS+PL flows, SSH deploy.
Current version: 0.5.0 — see What's new and CHANGELOG.md.
Not to be confused with the unrelated
vivado-mcppackage on PyPI. This project isvivado-red-mcp: Python modulevivado_red_mcp, commandvivado-red-mcp.
Contents
- What it can do
- Tested with
- Requirements
- Installation
- First steps
- Red Pitaya
- What's new in 0.5.0
- Troubleshooting
- Available tools
- Architecture
- License
What it can do
- Persistent Vivado session — one Vivado process in Tcl mode is kept alive, so commands don't pay the 20–30 s startup each time.
- Projects and design flow — create/open projects, add HDL and XDC files, synthesis, implementation, bitstream, run strategies.
- Block design (IP Integrator) — ports, IP cores, RTL module cells, nets, PS7 presets, validation, wrapper generation.
- Reports — timing (WNS/TNS/WHS/THS), utilization, clocks, power, DRC, methodology, QoR; returned as parsed values, not just raw text.
- Simulation (xsim) — behavioral and post-synthesis/implementation, read signal values, breakpoints.
- Red Pitaya — one-shot RTL build, full PS+PL build from the official
RedPitaya-FPGA repo, bundled board constraints,
.bit.bingeneration, SSH deploy. - Raw Tcl — anything not covered by a tool can be run as Tcl (multi-line scripts supported).
Tested with
| Status | |
|---|---|
| Vivado 2026.1, Windows 11 | Validated end-to-end in 0.4.0: session, RTL and PS+PL Red Pitaya builds, reports, behavioral + post-synthesis xsim, block design, RedPitaya-FPGA tutorials (see below) |
| Vivado 2020.1, Linux | Original development target (0.3.x). Not re-tested on 0.4.0 |
| Other Vivado releases | Expected to work (the generic tools use standard Tcl); not tested |
| Red Pitaya board | STEMlab 125-14 (Z10) only for the Red Pitaya flows |
| Python | 3.10 – 3.12 |
| MCP Python SDK | 1.x only (mcp>=1.0,<2, pinned automatically) |
The RedPitaya-FPGA tutorials in prj/Examples (Led_blink, Knight_rider, Stopwatch,
Frequency_counter) build to a bitstream through the server. Led_blink and
Knight_rider rebuilt from scratch with MCP tools only produce byte-identical
bitstreams to the tutorials' own scripts.
Requirements
- Python 3.10+
- AMD Vivado (the free edition is enough for the Red Pitaya
xc7z010). When installing, you only need Vivado and, under devices, SoCs → Zynq-7000; Vitis Model Composer and DocNav are not needed. - A Vivado license file — also for the free edition on 2025.x/2026.x.
Without it Vivado refuses to start (
a valid license was not found):- open the Vivado License Manager (
<Vivado>/bin/vlm.baton Windows,vlmon Linux); - Obtain License → on the AMD site tick Vivado Basic Tier License, Node Locked License (no charge, no expiry) → Generate Node-Locked License;
- host ID: the MAC address of your network card (shown under View Host Information). The license is tied to the PC, not to the network you use;
- load the received
Xilinx.licwith Load License → Copy License.
- open the Vivado License Manager (
- Vivado reachable by the server, either:
- on
PATH(Linux:source <Vivado>/settings64.sh; Windows: add<Vivado>\bintoPATH), or - by telling Claude the full path, which it passes to
start_session(e.g.C:\AMDDesignTools\2026.1\Vivado\bin\vivado.bat).
- on
pexpect (Linux/macOS) or pywinpty (Windows) is installed automatically.
Installation
1. Get the code and install it
git clone https://github.com/sinemortal/vivado-red-mcp.git
cd vivado-red-mcp
python -m venv .venv
# Windows: .venv\Scripts\activate
# Linux/macOS: source .venv/bin/activate
pip install -e .
pip pins the MCP SDK to 1.x by itself. Do not upgrade mcp to 2.x: the server
would not start ('Server' object has no attribute 'list_tools').
2. Register it with Claude Code
Once, for all your projects:
claude mcp add --transport stdio --scope user vivado -- vivado-red-mcp
If vivado-red-mcp is not on PATH when Claude Code starts (typical with a virtual
environment), point to the venv's Python instead:
# Windows
claude mcp add --transport stdio --scope user vivado -- "C:\path\to\vivado-red-mcp\.venv\Scripts\python.exe" -m vivado_red_mcp
# Linux/macOS
claude mcp add --transport stdio --scope user vivado -- /path/to/vivado-red-mcp/.venv/bin/python -m vivado_red_mcp
Or share it with a single project through a .mcp.json at the project root:
{
"mcpServers": {
"vivado": {
"type": "stdio",
"command": "vivado-red-mcp"
}
}
}
Check it with claude mcp list: vivado should show as connected.
3. Optional: disable the RedPitaya-FPGA auto-download
On startup the server downloads the RedPitaya-FPGA repo (source zip) into its
working directory if it is missing, for the PS+PL flow. Set the
environment variable VIVADO_MCP_NO_AUTOFETCH=1 to turn this off; the
rp_fetch_repo tool can still download it on demand.
First steps
Talk to Claude in plain language, for example:
- "Start a Vivado session" (add the path if Vivado is not on
PATH) - "Open my project at
C:/work/my_proj/my_proj.xpr" - "Synthesize and implement it, then tell me if timing is met"
- "Show me the resource utilization"
- "Generate the bitstream"
- "Stop the Vivado session"
Claude picks the tools; you never have to call them by name.
Red Pitaya
Two flows, depending on whether you need the ARM processor:
| Flow | Tool | Use it for |
|---|---|---|
| RTL only (no PS7) | create_redpitaya_project_rtl |
Logic clocked by the 125 MHz ADC clock: LEDs, counters, expansion-connector GPIO. One call does create → sources → XDC → synth → impl → bitstream → .bit.bin |
| PS + PL | rp_fetch_repo → rp_setup_workspace → rp_build_project |
Designs that need the ARM, DDR or AXI. Reuses the PS7 block design shipped by RedPitaya-FPGA instead of reconfiguring the Zynq by hand |
Example prompt:
Make an LED blinker at 1 Hz for the Red Pitaya using the 125 MHz ADC clock on
led_o[0], build it and give me the.bit.bin.
To load the result on the board, ask Claude to use deploy_to_redpitaya (SSH,
default credentials root/root; works with OS 1.04 xdevcfg and OS 2.00
fpgautil), or copy it yourself:
scp led_blinker.bit.bin root@rp-xxxxxx.local:/tmp/
ssh root@rp-xxxxxx.local 'cat /tmp/led_blinker.bit.bin > /dev/xdevcfg'
PS+PL and the RedPitaya-FPGA repo. The current upstream master targets
Vivado 2025.1; older checkouts targeted 2020.1. Both layouts are supported.
rp_setup_workspace copies the repo into a separate workspace and patches only
that copy, so the scripts run on the Vivado you have installed (their exported
block-design/IP scripts otherwise refuse any other release) and without a git
checkout. Your downloaded repo is never modified. Details:
get_vivado_doc redpitaya_ps_pl_flow.
Bundled board data (data/boards/):
red_pitaya_125_14_full.xdc— full pinout (ADC, DAC, LEDs, expansion connector, XADC), port names as in the officialred_pitaya_top(adc_dat_i[ch][bit],dac_dat_o,exp_p_io, …); checked pin by pin against upstreamsdc/red_pitaya.xdc.red_pitaya_125_14_leds_min.xdc— 125 MHz differential ADC clock + 8 LEDs, for hello-world designs.red_pitaya_125_14_info.json— part number and board metadata.
The RedPitaya tutorials (prj/Examples) use different port names
(adc_dat_a_i, adc_clk_p_i, …) and a PS7 preset (cfg/red_pitaya.xml); use
their own cfg/ files when rebuilding them.
More Italian prompt examples and the step-by-step low-level flow: USAGE.md.
What's new in 0.5.0
Renamed to vivado-red-mcp (package, Python module vivado_red_mcp, command
vivado-red-mcp), so it no longer clashes with the unrelated vivado-mcp package on
PyPI. If you installed an earlier version, reinstall it and re-register it with
Claude Code using the new command (see Installation).
0.4.0
Works on Vivado 2026.1 and with the current RedPitaya-FPGA repo.
Fixed:
- Server failed to start with MCP SDK 2.x → SDK pinned to 1.x.
- Simulation never worked when the server was started by Claude Code on
Windows (xsim:
Spawn failed) → fixed. - Multi-line Tcl sent through
run_tclwas silently corrupted on Windows → fixed. get_timing_summaryalways returned empty values;get_utilizationmisread newer reports → both parse current Vivado output.- Reports right after a build failed with no message (
No open design) → the latest completed run is opened automatically. get_synthesis_errors_parsedalways returned 0 errors → now reads the run logs, including failed IP runs.launch_simulationmodes rejected by recent Vivado → fixed.generate_bitstreamtimed out after 300 s and didn't check the result → now verified, returns the.bitpath.- Missing license (or any startup failure) now reports Vivado's own message in seconds instead of a generic error after 2 minutes.
- Bundled
red_pitaya_125_14_full.xdchad 6 wrong pins (ADC channel A MSB anddac_dat_o[8..12]) → corrected. - PS+PL flow broken by the new RedPitaya-FPGA layout → both layouts supported.
New tools: create_bd_port, add_module_to_bd, configure_bd_cell,
set_run_strategy. Full list in CHANGELOG.md.
Troubleshooting
| Symptom | Cause / fix |
|---|---|
start_session fails with valid license was not found |
Vivado 2025.x/2026.x needs a license file even for the free edition — see Requirements |
start_session cannot find Vivado |
Put <Vivado>/bin on PATH or give Claude the full path of vivado.bat / vivado |
Server does not start: 'Server' object has no attribute 'list_tools' |
MCP SDK 2.x installed. Run pip install "mcp>=1.0,<2" |
claude mcp list shows vivado as failed |
vivado-red-mcp not on PATH for Claude Code: register it with the venv's Python (see Installation) |
A RedPitaya example fails synthesis with red_pitaya_pll ... port does not exist |
Upstream issue in prj/Examples/Simple_moving_average (it pulls in rtl_250), not in this server |
Occasional Could not open 'C' for writing in an IP run |
Intermittent Vivado issue with parallel out-of-context runs; re-run synthesis |
| Long paths on Windows | Keep projects in short paths; Vivado and IP generation hit the 260-character limit |
Available tools
Session management
start_session- Start a persistent Vivado Tcl session (optionalvivado_path)stop_session- Stop the Vivado sessionsession_status- Session statisticscheck_session_health- Detect a hung/dead session, optionally recoverget_host_status- Host CPU/memory status
Project management
create_project- Create a project on disk (default partxc7z010clg400-1)open_project/close_project- Open or close an.xprget_project_info- Part, directory, top, …add_sources/add_constraints- Attach HDL and XDC files
Design flow
run_synthesis- Run synthesis (verified run status)run_implementation- Run place and route (verified run status)generate_bitstream- Generate the bitstream (verified status +.bitpath)set_run_strategy- Set the synthesis/implementation run strategy
Reports & analysis
Report tools open the latest completed run automatically if no design is open.
get_timing_summary- WNS, TNS, WHS, THS, pulse width, met / not metget_timing_paths- Detailed timing paths for failing/critical pathsget_utilization- LUTs, FFs, BRAMs, DSPs, IOsget_clocks- Clock informationget_messages- Synthesis/implementation messages
Design queries
get_design_hierarchy- Module/instance hierarchyget_ports- Top-level portsget_nets/get_cells- Search nets and cells
Simulation (xsim)
set_simulation_top- Set the testbench modulelaunch_simulation- Behavioral, post-synthesis or post-implementation (functional/timing)run_simulation/step_simulation/restart_simulation/close_simulationget_simulation_timeget_signal_value/get_signal_values- Read signalsget_simulation_objects/get_scopes- Browse the hierarchyadd_signals_to_waveadd_breakpoint/remove_breakpointsget_simulation_messages
Block design (IP Integrator) — Zynq / AXI
create_block_design- Create a block design and make it currentcreate_bd_port- Scalar, vector or interface portsadd_ip_to_bd- Add an IP core (VLNV) withCONFIG.*propertiesadd_module_to_bd- Add an RTL module as a module-reference cellconfigure_bd_cell- SetCONFIG.*on an existing cell (e.g. PS7 board preset import)connect_bd_net/connect_bd_intf_net- Wire pins/ports and AXI interfacesauto_connect_axi-apply_bd_automationfor AXI master ↔ slaveapply_ps7_preset- Zynq PS7 automation (FIXED_IO/DDR external)validate_block_design- Run BD DRCassign_bd_address- Auto-assign AXI address rangesregenerate_bd_layout- Tidy the layoutsave_bd_design/close_bd_design- Persist or close the BDlist_bd_cells- List cellsgenerate_bd_wrapper-make_wrapper+ add to fileset + set as top
IP catalog
create_ip/configure_ip- Create and configure catalog IPsgenerate_ip_target/synth_ip- Output products, out-of-context synthesisupgrade_ip/report_ip_status- Upgrade and audit IP versions
Hardware Manager (JTAG)
open_hw_manager/close_hw_managerconnect_hw_server- Connect tohw_server(defaultlocalhost:3121)program_device- Program a.bitover JTAGrefresh_hw_device- Re-read the JTAG chain
Advanced reports
report_power- Total/dynamic/static powerreport_drc- DRC violations grouped by severityreport_methodology- UltraFast methodology checksreport_qor_assessment- QoR scorereport_clock_interaction- Cross-clock pathsgenerate_full_report/read_report_section- Full reports to file, read them in pieces
Red Pitaya — RTL flow
list_boards/get_board_info- Bundled board metadata and XDC paths (no Vivado needed)load_board_xdc- Add a bundled board XDC to the projectcreate_redpitaya_project_rtl- One-shot RTL build; returnsbit_path,bin_path, parsedtiming_summaryandutilizationgenerate_cfgmem-.bit→.bit.binfor/dev/xdevcfg/fpgautilget_synthesis_errors_parsed- Structured errors from the run logs, including failed IP runs
Red Pitaya — PS+PL flow
rp_fetch_repo- Download RedPitaya-FPGA (source zip, no git needed)rp_setup_workspace- Isolated, patched copy of the repo to build inrp_list_projects- Listprj/*projects, flag the Z10-capable onesrp_workspace_info- Which projects are already builtrp_create_custom_project- Clone a base project for your own PL logicrp_build_project- Setup → synth → impl → bitstream →.bit.bin, with parsed timing
Red Pitaya — deploy (SSH, no Vivado needed)
deploy_to_redpitaya- Upload a.bit.binand load it (xdevcfgon OS 1.04,fpgautilon OS 2.00)ssh_redpitaya_exec- Run a shell command on the board
Documentation (offline)
list_vivado_docs/get_vivado_doc- Bundled topics (block_design,ps7_zynq,timing_constraints,synthesis_strategies,simulation_xsim,red_pitaya_125_14,redpitaya_ps_pl_flow,tcl_quoting,hw_manager,ip_integrator,pitfalls_2020_1), each with links to the AMD user guides
Raw Tcl and misc
run_tcl- Run any Tcl command or multi-line scriptrun_tcl_script- Source a.tclfilerequest_feature/list_feature_requests
Architecture
┌─────────────────┐ MCP (JSON-RPC) ┌─────────────────┐
│ Claude Code │◄──────over stdio──────►│ vivado-red-mcp │
│ (AI client) │ │ server │
└─────────────────┘ └────────┬────────┘
│ pexpect (Linux)
│ pywinpty/ConPTY (Windows)
▼
┌─────────────────┐
│ Vivado process │
│ (-mode tcl) │
└─────────────────┘
The server keeps one Vivado process in Tcl mode and talks to it through a
pseudo-terminal, using the Vivado% prompt to know when a command has finished.
Each tool family lives in its own module under tools/; see CLAUDE.md
for the design conventions and known Vivado Tcl pitfalls.
Contributing
Issues and pull requests are welcome. There is no automated Vivado test in CI (it only checks that every tool has a handler); changes to the Vivado-facing code should be validated against a real Vivado install.
License
MIT — see LICENSE. Bundled third-party material (Red Pitaya board XDC
files, 3-clause BSD) is listed in THIRD-PARTY-NOTICES.md.
Acknowledgments
- Forked from coreyhahn/vivado_mcp (MIT)
- Red Pitaya flows build on RedPitaya/RedPitaya-FPGA
- Developed with Claude (Anthropic)
- Uses the Model Context Protocol
- Integrates with AMD Vivado
Metadata
Release files for vivado-red-mcp 0.5.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| vivado_red_mcp-0.5.0.tar.gz | 90.3 kB | Without provenance | Details for vivado_red_mcp-0.5.0.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| vivado_red_mcp-0.5.0-py3-none-any.whl | Python 3 | none | any | Details for vivado_red_mcp-0.5.0-py3-none-any.whl |
Total release size: 192.5 kB
Release files / vivado_red_mcp-0.5.0.tar.gz
| Download URL | vivado_red_mcp-0.5.0.tar.gz |
|---|---|
| Size | 90.3 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
3105bf2ab3180b57ed44fc62878b460522ddfbbff5fe5a8ba70852bb8a278730
|
|
BLAKE2b-256 checksum How to use checksums |
2e6aeb6ea7659526688bc7e109a49c72a713e4496ed16d82852091777d3fd0a3
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.12.7
|
Release files / vivado_red_mcp-0.5.0-py3-none-any.whl
| Download URL | vivado_red_mcp-0.5.0-py3-none-any.whl |
|---|---|
| Size | 102.3 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
f1335e0c25a8cecd4813706ec345e8af94b566de6640b2bdf08e2ec8ef569fb1
|
|
BLAKE2b-256 checksum How to use checksums |
54db070a6bcce894ef21f8b6f97771d429e8aa572b3a19d6c49318bc36066281
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.12.7
|
Security for vivado-red-mcp 0.5.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.