Support Atomic Operations (A Extension)

[dpretet]

Modify the core to support A extension:

• update the AXI fabric to use AXI4 in place of AXI4-lite to transport atomic info (ALOCK)
• update the RAM model to support ALOCK attribute
• add the A extension decoding
• add the A extension support in the memory controller (memory)
• support A extension in dcache (don't modify the AID attribute) Maybe adding a third AXI interface with a memory dedicated to the AMOs could be a solution. That would avoid, at least at a first glance to modify the cache stage
• develop the test cases in WBA test suite
• add official RISCV test cases and let them pass successfully

[dpretet]

Dev is almost done, to be finished. The dcache implementation needs to be updated to properly support RISC-V atomic memory operations (AMO).
Current behavior:

• The dcache handles all requests (device and memory) uniformly
• Original transaction IDs are replaced with unique IDs to simplify out-of-order request management
• This ID substitution works fine for regular memory and device accesses

Problem:

• Atomic operations (LR/SC) require preserving the original transaction ID
• The target (e.g., RAM controller) needs the specific ID to return the correct response code (EXOKAY for exclusive access)
• The current ID substitution breaks the AMO protocol

Solution:

• Create a dcache wrapper around the existing friscv_dcache core
• Implement a bypass path that:
  • Detects atomic or IOs transactions (based on Apache[1] signal)
  • Routes atomic requests and IOs directly to AXI, preserving original IDs
  • Routes normal requests through the cache with ID substitution
  • Uses a simple FSM to lock the bypass during atomic transaction completion

[dpretet]

During dCache update, the testbench limitations reminded me of itself. See #4. Not blocking issue