ARM AXI Master-Slave Transaction Stalls Due to DRAM Clock Failure
In ARM-based systems utilizing the AXI (Advanced eXtensible Interface) protocol, a critical issue arises when a master device attempts to initiate a transaction with a DRAM (Dynamic Random-Access Memory) slave, but the DRAM clock is not running. This scenario can lead to system stalls, undefined behavior, or even data corruption if not handled properly. The AXI protocol itself does not inherently account for clock failures, as it assumes that all clock domains are operational during transactions. Therefore, the system designer must implement mechanisms to detect and respond to such failures.
When the DRAM clock is not running, the AXI interconnect will not receive a response from the slave, causing the transaction to stall indefinitely. This stall occurs because the AXI protocol relies on the slave to provide a response signal (e.g., OKAY, ERROR, or DECERR) to complete the transaction. Without a functional clock, the DRAM cannot generate this response, leaving the master in a waiting state. This situation is particularly problematic in real-time systems where predictable behavior is critical.
The absence of a DRAM clock can also lead to a decode error (DECERR) if the interconnect is configured to recognize the DRAM’s address space as invalid when the clock is off. However, this behavior is not automatic and requires explicit system-level design to map the DRAM’s address space dynamically based on clock availability. Without such design considerations, the system may fail to handle the clock failure gracefully, leading to potential system crashes or data loss.
Clock Domain Control Logic and Address Mapping Misconfigurations
The root cause of this issue lies in the lack of proper clock domain control logic and address mapping configurations. In a well-designed system, the clock controller should be aware of when the DRAM clock is required and ensure that it is enabled before any transactions are initiated. If the clock is disabled, the system should either prevent transactions to the DRAM or handle them appropriately.
One common cause of this issue is the absence of a clock enable request mechanism in the interconnect. When a transaction is initiated to a DRAM with a stopped clock, the interconnect should ideally trigger a clock enable request to the clock controller. This mechanism ensures that the DRAM clock is activated before the transaction proceeds, preventing stalls. However, many systems lack this feature, leading to the described issues.
Another cause is improper address mapping. When the DRAM clock is stopped, the interconnect should dynamically remove the DRAM from the address map, causing any access to its address space to return a decode error (DECERR). This approach requires coordination between the clock controller and the interconnect to ensure that the address map is updated whenever the DRAM clock state changes. Without this coordination, the system may attempt to access the DRAM even when its clock is off, resulting in undefined behavior.
Additionally, the system may lack an abort handler to manage decode errors caused by DRAM clock failures. An abort handler can reconfigure the interconnect to restore the DRAM to the address map once the clock is enabled and retry the failed transaction. Without this handler, the system may fail to recover from such errors, leading to persistent issues.
Implementing Clock Enable Requests, Dynamic Address Mapping, and Abort Handlers
To address the issue of DRAM clock failures in ARM AXI-based systems, a comprehensive approach involving clock enable requests, dynamic address mapping, and abort handlers must be implemented. These solutions ensure that the system can handle DRAM clock failures gracefully and maintain reliable operation.
Clock Enable Requests
The interconnect should be designed to trigger a clock enable request to the clock controller whenever a transaction is initiated to a DRAM with a stopped clock. This mechanism ensures that the DRAM clock is activated before the transaction proceeds, preventing stalls. The clock controller should then enable the DRAM clock and notify the interconnect once the clock is stable. This approach requires close integration between the interconnect and the clock controller, as well as a well-defined protocol for clock enable requests and acknowledgments.
Dynamic Address Mapping
The system should implement dynamic address mapping to ensure that the DRAM is only accessible when its clock is running. When the DRAM clock is stopped, the interconnect should remove the DRAM from the address map, causing any access to its address space to return a decode error (DECERR). This approach requires coordination between the clock controller and the interconnect to update the address map whenever the DRAM clock state changes. The address mapping logic should be designed to handle these updates efficiently, minimizing latency and overhead.
Abort Handlers
An abort handler should be implemented to manage decode errors caused by DRAM clock failures. When a decode error occurs, the abort handler should check the state of the DRAM clock and
