Skip to main content
Glama

program_device

Programs an FPGA by loading a .bit bitstream, automating the open hardware manager, connect, and program steps via Vivado.

Instructions

编程 FPGA 设备。封装 open_hw_manager → connect → program 多步操作。

只烧 .bit 进 FPGA(掉电即丢)。要掉电自启动须烧 SPI flash,见下面配方。

烧 flash 配方(2019.1,run_tcl 逐步执行):

  1. 查 flash 型号: get_cfgmem_parts -of [lindex [get_hw_devices] 0] (或按板上 flash 用 -filter 选,如 mt25ql128-spi-x1_x2_x4)

  2. 生成 .mcs: write_cfgmem -format mcs -size 16 -interface SPIx4 -loadbit {up 0x0 <top>.bit} -force out.mcs

  3. 建 cfgmem 对象: create_hw_cfgmem -hw_device [current_hw_device] [lindex [get_cfgmem_parts <part>] 0]

  4. 设属性四件套: set_property PROGRAM.FILES {out.mcs} [current_hw_cfgmem]

    • PROGRAM.ERASE 1 / PROGRAM.CFG_PROGRAM 1 / PROGRAM.VERIFY 1

  5. 烧写: program_hw_cfgmem

  6. 烧后 boot_hw_device [current_hw_device] 或断电重启从 flash 加载。 (Zynq 用 .bin: write_cfgmem -format bin -interface SMAPx32 ...)

Args: bitstream_path: 比特流文件路径(.bit 文件)。 target: 目标设备过滤器,默认 "*"(第一个可用设备)。 hw_server_url: 硬件服务器地址,默认 "localhost:3121"。 session_id: 目标会话 ID。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetNo*
session_idNodefault
hw_server_urlNolocalhost:3121
bitstream_pathYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

With no annotations, the description carries full behavioral burden. It discloses the volatile nature of .bit programming and outlines the internal sequence (open_hw_manager → connect → program). It also provides a comprehensive flash recipe, shedding light on what the tool does not do. However, it does not mention potential side effects like interrupting a running design or requiring a live hardware server.

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

Conciseness3/5

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

The description is front-loaded with purpose and scope, but the extensive flash recipe adds significant bulk. While the recipe is useful, it is tangential to the tool's own parameters and could be summarized or referenced. The core description is efficient, but the overall length reduces conciseness.

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

Completeness4/5

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

The description provides rich context for a hardware programming tool: it clarifies the volatile/flash distinction, gives a full alternative procedure, and defines all parameters. It does not mention prerequisites like hardware server availability or error handling, but the presence of an output schema reduces the need to explain return values. Overall, it is sufficiently complete for its complexity.

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?

Schema description coverage is 0%, so the description must compensate. It explains every parameter: bitstream_path as the .bit file, target as a filter defaulting to the first device, hw_server_url as the server address, and session_id as target session ID. This exceeds the bare schema, though target filter syntax and session ID requirements could be more detailed.

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 description starts with '编程 FPGA 设备' (program FPGA device), clearly stating the verb and resource. It further specifies that it wraps the multi-step open_hw_manager → connect → program operation and explicitly notes it only burns .bit files to FPGA, distinguishing it from flash programming and sibling tools like generate_bitstream.

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

Usage Guidelines5/5

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

The description gives explicit usage guidance: use this tool for volatile .bit programming, and for persistent boot use the provided SPI flash recipe via run_tcl. It even includes step-by-step TCL commands as an alternative, making the distinction clear and actionable.

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/mapleleavessssssss-wq/vivado-mcp'

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