Skip to main content
Glama

load_systemverilog

Load local SystemVerilog RTL into the active design session to elaborate it for connectivity queries, with file lists, preprocessor defines, and unresolved-module black-boxing.

Instructions

Elaborate local SystemVerilog sources into the active design session. Use this for SystemVerilog RTL; use load_vhdl for VHDL (beta), or load_verilog with load_liberty/load_primitives for a structural gate netlist. Requires at least files or flist and changes the in-memory design session. Anonymous lowered objects are addressable by #. defines are preprocessor -D entries ("NAME" or "NAME=VALUE"). allow_unknown_designs=True blackboxes any module still undefined instead of failing (e.g. undelivered hard macros in a partly-open-source design). intent=True retains naja's in-engine SNL↔slang link for get_intent.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topNoTop module name; omit to use najaeda's inferred top.
filesNoLocal SystemVerilog source file paths; optional when flist is provided.
flistNoPath to a simulator-style file list; optional when files are provided.
intentNoRetain the live SNL-to-slang link required by get_intent; uses more memory.
definesNoPreprocessor definitions as "NAME" or "NAME=VALUE" entries.
keep_assignsNoPreserve continuous assignments as explicit lowered objects.
allow_unknown_designsNoBlack-box unresolved module definitions instead of failing elaboration.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.1.9
    • addedInput schema / properties / allow_unknown_designs
      Added value: +{
      +  "default": false,
      +  "description": "Black-box unresolved module definitions instead of failing elaboration.",
      +  "title": "Allow Unknown Designs",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / defines
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Preprocessor definitions as \"NAME\" or \"NAME=VALUE\" entries.",
      +  "title": "Defines"
      +}
    • addedInput schema / properties / files / description
      Added value: +"Local SystemVerilog source file paths; optional when flist is provided."
    • addedInput schema / properties / flist / description
      Added value: +"Path to a simulator-style file list; optional when files are provided."
    • addedInput schema / properties / intent / description
      Added value: +"Retain the live SNL-to-slang link required by get_intent; uses more memory."
    • addedInput schema / properties / keep_assigns / description
      Added value: +"Preserve continuous assignments as explicit lowered objects."
    • addedInput schema / properties / top / description
      Added value: +"Top module name; omit to use najaeda's inferred top."
  2. First observedv0.1.8

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only cover the generic safety profile; the description adds real behavioral context: it mutates the in-memory design session, anonymous lowered objects are addressable by #<id>, allow_unknown_designs blackboxes undefined modules instead of failing, and intent=True costs memory to retain the SNL↔slang link for get_intent.

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

Conciseness4/5

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

Front-loads purpose and sibling routing before requirements and option semantics; every sentence carries information. It is dense and multi-clause, but not padded.

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?

For a 7-parameter mutation tool with no output schema, the description covers inputs, session effect, and key flags. Minor gap: it does not say how this interacts with existing loaded designs or reset_universe/load_snapshot, but nothing essential to correct invocation is missing.

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 coverage is already 100%, so the baseline is 3. The description still adds meaning beyond the schema: the #<id> addressing convention for anonymous objects, the motivation behind intent=True (get_intent link, memory cost) and a concrete use case for allow_unknown_designs (undelivered hard macros).

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?

Opens with a specific verb+resource and scope: 'Elaborate local SystemVerilog sources into the active design session.' It goes further by explicitly naming what it is not (load_vhdl, load_verilog with load_liberty/load_primitives), so an agent can distinguish it from siblings without reading any schema.

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?

Explicit selection guidance: 'Use this for SystemVerilog RTL; use load_vhdl for VHDL (beta), or load_verilog with load_liberty/load_primitives for a structural gate netlist.' It also states the input precondition (requires at least `files` or `flist`) and the side effect on the session.

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