Skip to main content
Glama
gokeshenzhen

io.github.gokeshenzhen/traceweave

by gokeshenzhen

get_signals_around_time

Inspect signal values and transitions in a narrow window around a target timestamp to trace causal chains at a specific failure time. Ideal for localized debugging of simulation failures.

Instructions

Return values and transitions for multiple signals in a NARROW window around a target timestamp (typically the failure time). Designed for local causal-chain inspection; NOT for bulk trace extraction. For round-by-round or multi-cycle sampling use get_signals_by_cycle.

Unit reminder: all times are picoseconds. If the sim log reports Time: X ns, set center_time_ps = X*1000 (example: 75,100 ns -> 75,100,000 ps).

Typical window_ps:

  • Glitch inspection: 1,000 - 5,000 ps

  • One clock cycle: = clock_period_ps (NOT exposed by get_waveform_summary; use get_signals_by_cycle after you identify a clock_path, or read it from your sim environment / compile log)

  • N cycles around fail: N * clock_period_ps

The server enforces a cap of MAX_WAVE_WINDOW_CYCLES (default 256) clock cycles per call, computed at runtime from an auto-detected clock_period_ps. It also rejects center_time_ps past the recorded simulation end. For multi-cycle sampling, get_signals_by_cycle still requires an explicit clock_path. FSDB support depends on fsdb_runtime.enabled.

If a value_at_center is a SUB-CYCLE TRANSIENT — a combinational glitch at the clock edge that settles back within the same cycle (e.g. an interconnect mux re-settling to idle for ~1ns at each edge) — the result sets transient_note and the signal carries center_transient/center_settles_to/center_settle_ps. Treat the SETTLED value as the protocol value; do not attribute a root cause to an edge-sampled value that is flagged transient.

return_mode="values_only" keeps the atomic multi-signal sample but strips the transition lists from every signal: each entry carries value_at_center + window_transition_count (+ any transient annotation, computed before stripping). Use it when you only need the values at one instant — e.g. comparing the same time point across several traces — instead of paying for transition history or falling back to one get_signal_at_time call per signal.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
wave_pathYes
window_psNoHalf-window in ps (center +/- window_ps). Default: 2000. Hard cap: MAX_WAVE_WINDOW_CYCLES clock cycles. For N-cycle sweeps prefer get_signals_by_cycle.
return_modeNovalues_only drops transitions_in_window/pre_window_transitions from every signal, returning value_at_center + window_transition_count (+ transient annotation). Compact point-sample mode for multi-trace value comparison.full
signal_pathsYesList of full hierarchical signal paths. 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.
center_time_psYesCenter time in PICOSECONDS (not ns). Convert sim-log ns via *1000. Must be within the waveform duration reported by get_waveform_summary. Accepts an integer (ps), a cursor reference like '@div_3a7c', or a unit literal like '12.34ns'.
extra_transitionsNoExtra transitions to include before the time window. Default: 5. 0 means none.
Behavior5/5

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

With no annotations, the description carries the full behavioral burden, and it excels: it discloses the server-enforced MAX_WAVE_WINDOW_CYCLES cap, runtime clock-period detection, rejection of center_time_ps past simulation end, FSDB dependency, and transient-flag semantics. This goes well beyond the schema and helps the agent anticipate non-obvious runtime behavior.

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 every paragraph carries unique, operationally relevant information: purpose, usage boundaries, window sizing, server limits, transient handling, and return-mode semantics. It is front-loaded with the core purpose and the most important exclusion, and the structure allows an agent to extract what it needs quickly.

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?

Despite no output schema and rich sibling context, the description covers the tool's behavior, constraints, units, edge cases, and mode variations. It explains how to convert units, what limits apply, what the transient fields mean, and when to prefer values_only, making it effectively self-contained for correct invocation.

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?

Even though schema coverage is 83%, the description adds substantial meaning beyond the schema: unit conversion from ns to ps with a concrete example, typical window_ps values for different inspection scenarios, the hard cap on window size, and the effect of return_mode='values_only' on returned fields. These details are not inferable from the schema alone.

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 specific verb and resource: 'Return values and transitions for multiple signals in a NARROW window around a target timestamp'. Explicitly contrasts with bulk extraction and names the alternative get_signals_by_cycle, so an agent can distinguish it from siblings without opening schemas.

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?

Provides explicit when-to-use guidance: local causal-chain inspection around a failure time, not bulk trace extraction. Offers alternatives for round-by-round or multi-cycle sampling, gives typical window_ps values for glitch inspection and clock cycles, and clarifies when get_signals_by_cycle requires a clock_path.

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