Skip to content

fix(axi4_bfm): fix _captureWriteData and _respondWrite in Axi4MemorySubordinate#289

Open
caflore1 wants to merge 2 commits into
intel:mainfrom
caflore1:fix/axi4-bfm-write-data
Open

fix(axi4_bfm): fix _captureWriteData and _respondWrite in Axi4MemorySubordinate#289
caflore1 wants to merge 2 commits into
intel:mainfrom
caflore1:fix/axi4-bfm-write-data

Conversation

@caflore1

@caflore1 caflore1 commented Jun 5, 2026

Copy link
Copy Markdown

Summary

Axi4SubordinateMemoryAgent._captureWriteData was reading wIntf.data.value
directly to build each Axi4DataPacket. The W-channel monitor fires once per
burst
with all beats already aggregated in packet.data via
_dataBuf.rswizzle(), so wIntf.data.value holds only the last beat's
data
at that point. Every address in a multi-beat write burst ended up storing
the last beat's value.

Bugs Fixed

  1. Multi-beat burst data corruption — read packet.data and unpack each
    beat with getRange(i*dw, (i+1)*dw) instead of reading wIntf.data.value.

  2. Stale beat-0 entry on simultaneous AW+W_receiveWrite can enqueue a
    beat-0 packet when AW and the first W beat arrive together; clear the queue
    before unpacking so the complete authoritative burst data is used.

  3. Queue accumulation across back-to-back bursts_writeDataQueue was
    never cleared after _respondWrite completed, causing stale entries to
    corrupt subsequent transactions. Added a clear() call after the response
    is sent.

Changes

  • lib/src/models/amba/amba4_bfm/axi4_memory_subordinate.dart — surgical fix
    to _captureWriteData and _respondWrite
  • test/amba/amba4/axi4_bfm_test.dart — new test
    multi-beat write burst stores each beat at its own address verifies a
    4-beat INCR burst writes distinct data to each consecutive address

Testing

All 1354 tests pass (dart test). The new test explicitly exercises the bug
that was previously silent.

…ubordinate

_captureWriteData previously read wIntf.data.value directly, capturing only
the last beat's data for multi-beat bursts. The W-channel monitor fires once
per burst with all beats aggregated in packet.data via rswizzle(); unpack
individual beats using getRange(i*dw, (i+1)*dw) instead.

Also clear _writeDataQueue[mapIdx] before unpacking to remove any beat-0
entry that _receiveWrite may have added during simultaneous AW+W handshake,
and set _writeReadyToOccur unconditionally (monitor fires only on WLAST).

In _respondWrite, clear _writeDataQueue[mapIdx] after processing to prevent
stale entries from accumulating across back-to-back transactions.

Co-authored-by: Copilot <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant