Skip to main content
Glama

edit_interface

Modify FPGA interface designs (.peri.xml) by applying GPIO, PLL, pin, and property operations with validation, backup, and optional dry-run.

Instructions

Change the Interface Designer design (.peri.xml). Operations run in order; if any fails, nothing is saved. After the operations the design check runs, and the file is saved only if no new design-check errors appeared (allow_new_errors=True saves anyway). dry_run=True applies and checks without saving. A .peri.xml.bak backup is written before saving. If the project has no .peri.xml yet, one is created for the project's device.

Values are validated against the allowed values (see get_interface_block); I/O standards may be written as '3.3 V LVCMOS' or '3.3_V_LVCMOS'.

Operations (each is an object with "op"): {"op": "create_gpio", "name": "led", "mode": "output", "pin": "U4", "properties": {"IO_STANDARD": "1.8 V LVCMOS"}} mode: input | output | inout | open_drain_output | clock_input | regional_clock_input | pll_clock_input | pll_ext_feedback | mipi_clock_input | pcie_perstn | clockout | global_control | vref | unused. A bus: add "msb": 7, "lsb": 0 (input/output/inout); buses can't take "pin", so place members with assign_pin on "led[0]" etc. "resource" (e.g. "GPIOB_P_31") can be given instead of "pin". {"op": "create_block", "name": "pll0", "type": "PLL", "resource": "PLL_TL0", "properties": {...}} type: any of block_types_supported from get_interface_design (PLL, OSC, LVDS_TX, LVDS_RX, MIPI_DPHY_RX, DDR, JTAG, PMA_DIRECT, ...). Optional "params" are passed to the API's create_block (tx_mode / rx_conn_type for LVDS, mode / conn_type for MIPI lanes). {"op": "set_properties", "name": "led", "properties": {"PULL_OPTION": "WEAK_PULLUP", "DRIVE_STRENGTH": "8"}} On a bus name, sets every member. Add "type" if a name is ambiguous. {"op": "assign_pin", "name": "led", "pin": "U4"} (GPIO package ball) {"op": "assign_resource", "name": "pll0", "resource": "PLL_TR1"} Both refuse a resource already used by another instance unless "override": true. {"op": "delete", "name": "old_sig"} {"op": "set_bank_voltage", "bank": "4B", "voltage": "1.8"} {"op": "auto_calc_pll", "name": "pll0", "targets": {"CLKOUT0_FREQ": 200, "CLKOUT1_FREQ": 100}} Solves and applies M/N/O and dividers. Enable the outputs first (CLKOUTn_EN=1, CLKOUTn_PIN). PLL output frequencies are read-only properties; this is how they are set. {"op": "gen_pll_ref_clock", "name": "pll0", "refclk_name": "pll_refclk", "pll_res": "PLL_TL0"} Creates the reference-clock GPIO on the pin that feeds that PLL. {"op": "set_unused_gpio_state", "state": "INPUT_WITH_WEAK_PULLUP"} {"op": "import_isf", "file": "C:/path/settings.isf"} (Interface Scripting File)

After saving, run_flow(compile) rebuilds with the new interface. If the project is open in the Efinity GUI, close it or reload it there, or the GUI may save its old copy over these changes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dry_runNo
projectYes
operationsYes
allow_new_errorsNo

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?

Even with annotations present, the description adds substantial behavioral detail: operations run in order, failure means nothing is saved, design checks gate saving, allow_new_errors bypasses the gate, dry_run avoids persistence, a .bak is written before save, and missing .peri.xml files are auto-created. This goes far beyond the annotation hints and gives the agent a precise execution model.

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

Conciseness5/5

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

The description is long but information-dense: every sentence adds a necessary semantic detail such as atomicity, validation rules, backup behavior, or op-specific constraints. It is front-loaded with the core purpose and then structured cleanly by operation type.

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?

For a complex mutation tool with no output schema and minimal schema annotations, this description covers everything an agent needs: execution order, failure atomicity, save conditions, dry-run behavior, backups, PLL rules, valid values, post-save flow, and a GUI conflict warning. Missing return-value details are not material for a tool whose side effects and outcome conditions are so thoroughly specified.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full parameter burden, and it succeeds. 'project', 'operations', 'dry_run', and 'allow_new_errors' are all explained, with the operations array documented operation-by-operation including modes, bus syntax, resource assignment, override behavior, and example objects.

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 opens with a specific verb and resource: 'Change the Interface Designer design (.peri.xml).' This clearly distinguishes the tool from sibling read/check tools like get_interface_design, check_interface, and export_interface_isf by framing it as the mutation entry point.

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

Usage Guidelines3/5

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

The description provides strong operational context, such as dry_run behavior, error-check gates, backup creation, and the GUI reload warning, but it never explicitly states when to choose this tool over alternatives like calc_pll or check_interface. Usage is implied rather than directly contrasted with siblings.

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