Skip to main content
Glama

Build gate

gowin_check
Read-onlyIdempotent

Checks Gowin EDA build reports for CI, returning pass, fail, or unknown; lists timing violations and offending paths, and enforces optional utilization and fMax margin thresholds.

Instructions

Pass/fail/unknown gate for CI. Lists timing violations with the offending path for each, plus optional thresholds on utilization and fMax margin. Negative paths between clock domains count as violations even though Gowin leaves them out of the TNS summary (set ignoreCrossDomain when they are declared false paths). A clock whose fMax misses its constraint while its setup TNS is 0 is reported as an fMax-only violation with the .sdc evidence (multicycle / half-cycle relations); waive it per clock with fmaxWaivers. "unknown" means timing could not be verified (no _tr_content.html or .tr, unrecognised report, or no clocks analysed) and is never a pass.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoWhen several builds share one impl/pnr/, pick this one by name (the <name> of <name>.rpt.txt). Default: the most recent, with the others listed under siblings.
pathYesPath to the build: the project directory, its impl/ directory, impl/pnr/ itself, or the .rpt.txt. Either kind of slash.
formatNoOutput format. Default text: a compact rendering, returned as the only content. json: the full JSON as text and as structuredContent.
fmaxWaiversNoClock names (or globs with * and ?) whose fMax-only violation is waived: fMax below the constraint with a setup TNS of 0, which is how Gowin reports a clock covered by set_multicycle_path or half-cycle paths. Listed under ignoredViolations; a TNS violation on the clock is never waived.
maxUtilizationNoFail when CLS, Logic or BSRAM utilization exceeds this percentage (recomputed from used/available, not the rounded column).
minFmaxMarginMhzNoFail when any clock achieves less than constraint + this many MHz.
ignoreCrossDomainNoDefault false. Set true when the paths between clock domains are declared false paths (set_false_path / set_clock_groups in the .sdc): their negative slack is then listed but does not fail the gate.
failOnMissingTimingNoDefault true: an unknown timing status fails the gate. Set false to accept on resources alone.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv0.2.2
    • addedInput schema / $schema
      Added value: +"http://json-schema.org/draft-07/schema#"
    • addedInput schema / properties / failOnMissingTiming
      Added value: +{
      +  "description": "Default true: an unknown timing status fails the gate. Set false to accept on resources alone.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / fmaxWaivers
      Added value: +{
      +  "description": "Clock names (or globs with * and ?) whose fMax-only violation is waived: fMax below the constraint with a setup TNS of 0, which is how Gowin reports a clock covered by set_multicycle_path or half-cycle paths. Listed under ignoredViolations; a TNS violation on the clock is never waived.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / format / description
      Previous value: -"Output format. Defaults to text, which is far more compact."New value: +"Output format. Default text: a compact rendering, returned as the only content. json: the full JSON as text and as structuredContent."
    • addedInput schema / properties / ignoreCrossDomain
      Added value: +{
      +  "description": "Default false. Set true when the paths between clock domains are declared false paths (set_false_path / set_clock_groups in the .sdc): their negative slack is then listed but does not fail the gate.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / maxUtilization
      Added value: +{
      +  "description": "Fail when CLS, Logic or BSRAM utilization exceeds this percentage (recomputed from used/available, not the rounded column).",
      +  "maximum": 100,
      +  "minimum": 0,
      +  "type": "number"
      +}
    • addedInput schema / properties / minFmaxMarginMhz
      Added value: +{
      +  "description": "Fail when any clock achieves less than constraint + this many MHz.",
      +  "type": "number"
      +}
    • addedInput schema / properties / name
      Added value: +{
      +  "description": "When several builds share one impl/pnr/, pick this one by name (the <name> of <name>.rpt.txt). Default: the most recent, with the others listed under siblings.",
      +  "type": "string"
      +}
    • changedInput schema / properties / path / description
      Previous value: -"Path to the build: the project directory, its impl/ directory, or the .rpt.txt itself."New value: +"Path to the build: the project directory, its impl/ directory, impl/pnr/ itself, or the .rpt.txt. Either kind of slash."
  2. First observedv0.1.0-beta.1

TDQS

A3.9/5.0
Behavior5/5

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

Annotations already establish the read-only, idempotent, safe profile, and the description goes well beyond them: it defines what counts as a violation (cross-domain paths Gowin omits from TNS), explains the fMax-only violation case with .sdc evidence, and gives full semantics of the 'unknown' status (no report/tr file, unrecognised report, no clocks) and that it is never a pass.

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-loaded with the one-line purpose ('Pass/fail/unknown gate for CI'), then structured around violation types and the unknown semantics. It is dense and parenthesis-heavy, but nearly every sentence carries actionable semantics rather than filler.

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 complex gating tool with 8 parameters, no output schema, and high schema coverage, the description supplies the decision-relevant context: violation classes, waiver behavior, and unknown-status handling. It does not describe the shape of the returned violation list, but the read-only gate is otherwise well specified.

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

Parameters3/5

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

Schema description coverage is 100% and the individual property descriptions are already detailed, so the baseline is 3. The description restates the rationale behind fmaxWaivers and ignoreCrossDomain rather than adding syntax or value ranges beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: a pass/fail/unknown gate for CI, with concrete outputs (timing violations plus offending paths, utilization and fMax thresholds). The gate framing implicitly separates it from reporting siblings like gowin_timing or gowin_summary, but no sibling is named to make the distinction explicit.

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?

Usage is implied by 'for CI' and by the conditional parameter notes (set ignoreCrossDomain when paths are declared false paths; waive with fmaxWaivers). There is no explicit when-to-use-this-vs-gowin_timing guidance or prerequisite statement, so the agent must infer the CI-gate role.

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