Maintain transaction accounting through flush and reset

Cancellation is an explicit design event

Reset returns control to a known state; flush cancels specified outstanding work. Clearing data alone is insufficient. If valid remains high, zero can become a fake transaction. Old data bits with valid zero are harmless. Clear the appropriate ownership state: full in a one-slot buffer, count and pointers in a FIFO, or FSM state and result valid.

Our synchronous, single-clock contract excludes acceptance and delivery on a reset edge at both endpoints and cancels all outstanding work there. Resetting only one endpoint while the other counts old valid as delivery violates that agreement. Document reset scope and readiness policy. New inputs after reset belong to a new transaction interval.

With cancellation, use accepted-delivered-canceled=outstanding. Cancel each undelivered transaction exactly once. The reference queue must also remove canceled work, while checking that no stale result enters the new interval.

An external memory request may survive an internal flush. Distinguish late responses using a generation identifier, or wait for old requests to finish before restarting. Reusing a small generation field too soon can confuse an old response with a current one. Our capstone has no external delayed responses and only cancels internal buffers.

Selective flush may retain work older than a branch while removing younger wrong-path operations. That requires defined ordering and commit rules. Invalid work must not update storage or participate in forwarding. Test reset while empty, stalled, full, and during potential simultaneous transfers. Startup reset alone does not exercise outstanding-work cancellation.