Skip to main content
Glama
gokeshenzhen

io.github.gokeshenzhen/traceweave

by gokeshenzhen

reconstruct_transactions

Reconstruct id-correlated AXI transactions from FSDB/VCD waveforms by matching request beats to completion beats per id, returning per-transaction latency, outstanding curves, and hang/unmatched signatures.

Instructions

Reconstruct id-correlated request/response transactions from two handshake channels: walk every clock edge, match accepted request beats to completion beats by id, and return per-transaction latency plus aggregate facts (outstanding curve incl. per-id peak, ordering, unmatched=hang signature). One generic core, not a tool per protocol. AXI READ: req=AR (req_valid=arvalid, req_ready=arready, req_id=arid), cmp=R (cmp_valid=rvalid, cmp_ready=rready, cmp_id=rid, cmp_last=rlast); AXI WRITE: req=AW (awvalid/awready/awid), cmp=B (bvalid/bready/bid, no cmp_last). Pass req_fields/cmp_fields (e.g. araddr,arlen / rresp) to capture payload per txn; pass req_len (arlen/awlen) to also check each txn's beat_count against AxLEN+1 (beat_count_mismatch). Out-of-order completion across ids is supported (per-id FIFO); reorder_count is an informational FACT (legal in AXI), latency is a distribution not an 'outlier' verdict. Reads waveforms only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
edgeNoClock edge to sample on. Default posedge.posedge
clockYesShared 1-bit clock full path (e.g. AXI aclk).
resetNoOptional reset signal; while asserted, in-flight transactions are cleared so a txn straddling reset is not reported as a phantom hang.
cmp_idNoCompletion id bus (e.g. rid/bid). Optional; see req_id (omit both for in-order FIFO pairing).
req_idNoRequest id bus (e.g. arid/awid). Optional: omit both req_id and cmp_id for an unindexed in-order stream (AXI-Lite, APB) — txns pair in FIFO order and report id=null.
req_lenNoOptional AxLEN bus (arlen/awlen). Each txn's observed beat_count is compared to req_len+1; a mismatch (early/late LAST, dropped/extra beat) is a real burst-length violation, surfaced per-txn (beat_count vs expected_beats) and as beat_count_mismatch_count. x/z len → no check.
cmp_lastNoOptional last-beat signal (e.g. rlast). With it, a multi-beat burst completes one txn on last; without it every completion beat is a txn (e.g. AXI B channel).
cmp_readyYesCompletion channel ready (e.g. rready/bready).
cmp_validYesCompletion channel valid (e.g. rvalid/bvalid).
data_lastNoAXI WRITE only: W-channel last (wlast); marks the end of a write burst's data.
req_readyYesRequest channel ready (e.g. arready/awready).
req_validYesRequest channel valid (e.g. arvalid/awvalid).
wave_pathYesWaveform (FSDB or VCD).
cmp_fieldsNoOptional completion payload signals to capture per txn (e.g. rresp, bresp).
data_readyNoAXI WRITE only: W-channel ready (wready).
data_validNoAXI WRITE only: W-channel valid (wvalid). The W channel carries no id; beats attach in order to the oldest data-incomplete request. Needs data_ready too.
req_fieldsNoOptional request payload signals to capture per txn (e.g. araddr, arlen, arsize, arburst).
active_highNovalid/ready/last polarity. Default true.
cursor_nameNoOptional explicit cursor name.
cursor_noteNoOptional cursor note.
data_fieldsNoAXI WRITE only: W-channel payload to capture per beat (e.g. wdata, wstrb).
end_time_psNoWindow end. -1 = end of trace.
capture_beatsNoInclude per-beat data (data_beats[]) on each txn. Default false (only beat_count). Enable for data-integrity debugging; can be large.
start_time_psNoWindow start (ps int, '@cursor', or unit literal). Default 0.
timeout_cyclesNoOptional: count completed txns with latency above this many cycles (slow_count fact).
max_transactionsNoMax txn records returned (default 256); counts/stats are over ALL. Sets transactions_truncated when exceeded.
reset_active_lowNoreset is active-low (rst_n). Default true.
Behavior5/5

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

With no annotations, the description carries full behavioral burden and does so well: it discloses read-only operation, algorithmic behavior (per-id FIFO, out-of-order support), interpretive caveats (reorder_count is informational, latency is a distribution not verdict), and hang semantics (unmatched=hang signature). This goes well beyond the schema.

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 dense yet tightly constructed. The first sentence encapsulates purpose, method, and outputs; subsequent sentences add protocol mappings and key caveats. There is no filler, and every clause contributes to effective tool selection and invocation.

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 tool with 27 parameters, no output schema, and no annotations, the description is remarkably complete. It explains the core algorithm, protocol-specific parameter meanings, optional payload capture, burst-length checking, reset handling implications, and result semantics. An agent has enough context to invoke the tool correctly across AXI read/write and simple in-order scenarios.

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 100%, so the baseline is 3. The description adds valuable cross-references and protocol mappings, such as explaining that req_len triggers beat_count_mismatch checks and how cmp_last affects transaction completion. It enriches the schema without repeating it verbatim.

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 clearly identifies the tool's function with a specific verb ('reconstruct'), resource ('id-correlated request/response transactions from two handshake channels'), and method ('walk every clock edge, match accepted request beats to completion beats by id'). It distinguishes itself from sibling waveform/signal tools by focusing on transaction-level reconstruction and latency/fact output rather than signal inspection.

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 provides strong contextual guidance, including exact AXI READ/WRITE signal mappings and when to use optional parameters (req_fields/cmp_fields, req_len, cmp_last). However, it does not explicitly name alternatives or exclusion conditions among sibling tools, though none appear to be direct alternatives.

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