ARM Cortex-M3 Exclusive Access Issues: LDREX/STREX vs LDR/STR on AXI and AHB-Lite Buses

ARM Cortex-M3 Exclusive Access Failing on AXI and AHB-Lite Buses

The core issue revolves around the incorrect behavior of exclusive access instructions (LDREX/STREX) on an ARM Cortex-M3-based SoC design. The design integrates a Cortex-M3 processor with a custom AHB-Lite to AXI3 bridge, similar to the Xilinx DesignStart platform. The processor boots correctly and executes instructions, but the exclusive access mechanism fails to function as expected. Specifically, the AxLOCK signal on the AXI bus is not set during LDREX/STREX transactions, and STREX instructions consistently return a failure status (1), even when the BRESP signal is set to EX_OKAY (2’b01). Additionally, enabling the DTCM (Data Tightly Coupled Memory) exacerbates the issue, causing exclusive writes to fail entirely.

The problem appears to stem from the translation of exclusive access signals between the AHB-Lite and AXI3 buses. The AHB-Lite protocol does not natively support exclusive access, and the custom bridge implementation fails to properly propagate the EXREQ/EXRESP signals required for exclusive access monitoring. This results in a breakdown of the atomicity guarantees provided by the LDREX/STREX instructions, rendering them functionally equivalent to regular LDR/STR instructions.

Missing EXREQ/EXRESP Signal Propagation and AXI AxLOCK Signal Generation

The root cause of the issue lies in the improper handling of exclusive access signals during the translation from AHB-Lite to AXI3. The Cortex-M3 processor generates EXREQ (Exclusive Request) and EXRESP (Exclusive Response) signals internally to manage exclusive access operations. However, these signals are not correctly propagated through the AHB-Lite to AXI3 bridge, leading to the absence of the AxLOCK signal on the AXI bus. The AxLOCK signal is critical for indicating exclusive access transactions on the AXI bus, and its absence prevents the global monitor from tracking exclusive access sequences.

Another contributing factor is the incorrect handling of the BRESP signal. The AXI protocol requires that the BRESP signal be set to EX_OKAY (2’b01) to indicate a successful exclusive write. However, the custom bridge implementation fails to propagate this response back to the processor, causing the STREX instruction to return a failure status. This issue is further compounded when the DTCM is enabled, as the DTCM does not support the propagation of EXREQ/EXRESP signals, leading to complete failure of exclusive access operations.

The lack of support for CLREX (Clear Exclusive) in the global monitor is another potential issue. The CLREX instruction is used to clear the exclusive access state, but the current implementation does not propagate this signal to the global monitor. This is not strictly necessary for single-processor systems but can lead to subtle issues in multi-processor or multi-threaded environments.

Implementing Correct EXREQ/EXRESP Propagation and AXI AxLOCK Signal Handling

To resolve the issue, the AHB-Lite to AXI3 bridge must be modified to correctly propagate the EXREQ and EXRESP signals. The EXREQ signal should be converted to the AxLOCK signal on the AXI bus, indicating an exclusive access transaction. The global monitor on the AXI bus must be configured to track these transactions and ensure that no invalidating operations occur between the LDREX and STREX instructions.

The bridge must also correctly handle the BRESP signal. When an exclusive write is successful, the BRESP signal should be set to EX_OKAY (2’b01) and propagated back to the processor to clear the EXRESP signal. This ensures that the STREX instruction returns the correct status, indicating a successful exclusive write.

For designs that include DTCM, additional modifications are required to support exclusive access operations. The DTCM implementation must be extended to propagate the EXREQ/EXRESP signals, allowing exclusive access operations to function correctly. This may involve adding additional logic to the DTCM controller to handle exclusive access sequences and ensure proper synchronization with the global monitor.

Finally, the CLREX instruction should be supported in the global monitor to clear the exclusive access state. This can be achieved by propagating the CLREX signal from the processor to the global monitor, ensuring that the exclusive access state is correctly cleared when required. While this is not strictly necessary for single-processor systems, it is a good practice to ensure compatibility with multi-processor or multi-threaded environments.

Detailed Implementation Steps

1. Modify the AHB-Lite to AXI3 Bridge:

   • Add logic to convert the EXREQ signal from the Cortex-M3 processor to the AxLOCK signal on the AXI bus.
   • Ensure that the EXRESP signal is correctly propagated back to the processor when the BRESP signal is set to EX_OKAY.
   • Implement logic to handle the CLREX instruction, propagating it to the global monitor to clear the exclusive access state.

2. Configure the Global Monitor:

   • Ensure that the global monitor tracks exclusive access transactions on the AXI bus.
   • Implement logic to detect invalidating operations between LDREX and STREX instructions.
   • Ensure that the global monitor correctly sets the BRESP signal to EX_OKAY for successful exclusive writes.

3. Extend DTCM Support for Exclusive Access:

   • Modify the DTCM controller to propagate the EXREQ/EXRESP signals.
   • Implement logic to handle exclusive access sequences within the DTCM, ensuring proper synchronization with the global monitor.

4. Verification and Testing:

   • Develop test cases to verify the correct behavior of LDREX/STREX instructions on both the AXI and AHB-Lite buses.
   • Test the modified bridge and global monitor to ensure that exclusive access operations are correctly handled.
   • Verify the behavior of the DTCM with exclusive access operations, ensuring that the EXREQ/EXRESP signals are correctly propagated.

Example Code Snippets

AHB-Lite to AXI3 Bridge Modification

// Convert EXREQ to AxLOCK
always_comb begin
    if (ahb_exreq) begin
        axi_arlock = 1'b1; // Set AxLOCK for exclusive read
        axi_awlock = 1'b1; // Set AxLOCK for exclusive write
    end else begin
        axi_arlock = 1'b0;
        axi_awlock = 1'b0;
    end
end

// Propagate BRESP to EXRESP
always_comb begin
    if (axi_bresp == 2'b01) begin
        ahb_exresp = 1'b0; // Clear EXRESP for successful exclusive write
    end else begin
        ahb_exresp = 1'b1;
    end
end

Global Monitor Configuration

// Track exclusive access transactions
always_ff @(posedge clk or posedge reset) begin
    if (reset) begin
        exclusive_state <= EXCLUSIVE_IDLE;
    end else begin
        case (exclusive_state)
            EXCLUSIVE_IDLE: begin
                if (axi_arlock || axi_awlock) begin
                    exclusive_state <= EXCLUSIVE_ACTIVE;
                end
            end
            EXCLUSIVE_ACTIVE: begin
                if (axi_bresp == 2'b01) begin
                    exclusive_state <= EXCLUSIVE_IDLE;
                end
            end
        endcase
    end
end

DTCM Controller Extension

// Propagate EXREQ/EXRESP signals
always_comb begin
    if (dtcm_exreq) begin
        ahb_exreq = 1'b1;
    end else begin
        ahb_exreq = 1'b0;
    end

    if (ahb_exresp == 1'b0) begin
        dtcm_exresp = 1'b0;
    end else begin
        dtcm_exresp = 1'b1;
    end
end

Conclusion

The successful implementation of exclusive access operations on an ARM Cortex-M3-based SoC requires careful handling of the EXREQ/EXRESP signals and proper translation to the AXI AxLOCK signal. By modifying the AHB-Lite to AXI3 bridge, configuring the global monitor, and extending DTCM support, the exclusive access mechanism can be made to function correctly. Thorough verification and testing are essential to ensure that the modifications work as intended and that the system meets the required performance and reliability standards.