Skip to main content
Glama
gokeshenzhen

io.github.gokeshenzhen/traceweave

by gokeshenzhen

get_signals_by_cycle

Sample multiple signals per clock cycle from waveform files, aligning values to clock edges for debugging state machines, pipelines, and round-based algorithms.

Instructions

Return cycle-by-cycle sampled values for multiple signals aligned to a clock edge. Useful for state machines, pipelines, and round-by-round algorithm checks.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
edgeNoSampling edge. Default: posedgeposedge
wave_pathYesAbsolute path to the waveform file
clock_pathYesFull hierarchical clock path, for example top_tb.des_clk
num_cyclesNoNumber of cycles to sample. Default: 16. The server caps a single query at 256 cycles. Mutually exclusive with end_time_ps.
end_time_psNoAlternative count axis: window end; num_cycles is derived as the count of clock edges in [start, end_time_ps] (inclusive). Mutually exclusive with num_cycles. Accepts an integer (ps), a cursor reference like '@div_3a7c', or a unit literal like '12.34ns'.
start_cycleNoStarting cycle index (0-based). Default: 0. Mutually exclusive with start_time_ps.
signal_pathsYesList of full hierarchical signal paths to sample. A bare bus name (no [msb:lsb]) is auto-completed when unique (see resolved_aliases); unresolved names get did_you_mean entries in signal_suggestions.
start_time_psNoAlternative start axis: window start; snapped to the first clock edge at/after this time. Mutually exclusive with start_cycle. Accepts an integer (ps), a cursor reference like '@div_3a7c', or a unit literal like '12.34ns'.
sample_offset_psNoSampling offset relative to the clock edge in ps. Default: 1, to capture post-delta register values.
Behavior3/5

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

With no annotations, the description carries the full burden, but it only states the sampling alignment and use cases. It doesn't mention the non-obvious 1 ps post-delta offset, the 256-cycle cap, or the resolved_aliases/signal_suggestions behavior, though these appear in parameter descriptions. It is not misleading but is minimal for a tool with this many behavioral nuances.

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?

Two sentences with no filler: the first states the core function with a specific verb and object, the second gives use cases. The 'aligned to a clock edge' qualifier is front-loaded in the first sentence.

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 is effective for a moderately complex tool because the schema covers parameter semantics and the first sentence establishes the sampling model. However, with no output schema, the description doesn't specify the result structure or mention the alias-resolution output, leaving some ambiguity for an agent. The use-case sentence helps compensate, but a note on return shape would make it fully complete.

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%, so the baseline is 3 and the description adds little beyond naming 'multiple signals' and 'clock edge.' The input schema already documents each parameter, including mutual exclusions and defaults, so the description doesn't need to compensate. Score reflects that the schema carries the load.

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?

States a concrete action: 'Return cycle-by-cycle sampled values for multiple signals aligned to a clock edge.' The 'cycle-by-cycle' qualifier clearly distinguishes it from sibling time-domain tools like get_signal_at_time and get_signals_around_time. Also provides domain context with state machines, pipelines, and round-by-round algorithm checks.

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

Usage Guidelines4/5

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

The description explicitly ties use to cycle-aligned analysis: 'Useful for state machines, pipelines, and round-by-round algorithm checks.' This gives an agent a clear heuristic for when to select this tool, though it doesn't name alternatives or exclusion criteria. The sibling list reinforces the distinction from time-based sampling tools.

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/gokeshenzhen/TraceWeave'

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