Asynchronous AXI bus exception reset detection and automatic repair system and method

Abstract

This application discloses an asynchronous AXI bus abnormal reset detection and automatic repair system and method. The system includes: a CPU subsystem, at least one peripheral subsystem, and a bus repair module; the CPU subsystem and peripheral subsystem integrate an AXI asynchronous bridge; the bus repair module integrates a protocol repair component and a reset management component; the CPU subsystem triggers the bus repair module to enter monitoring mode; when the bus repair module detects a reset signal from the CPU subsystem, it triggers simultaneous resets on both sides of the AXI asynchronous bridge through the reset management component; the protocol repair component analyzes the flag bits in the monitoring data; if the flag bit is idle, no protocol repair is required; if the flag bit is busy, it takes over control of the AXI bus and executes protocol repair. This application can instantly repair AXI bus state machine errors and deadlocks caused by abnormal CPU resets.

Description

Technical Field

[0001] This application relates to the fields of integrated circuit design and embedded system technology, and in particular to an asynchronous AXI bus abnormal reset detection and automatic repair system and method. Background Technology

[0002] In a System-on-Chip (SoC), multiple functional subsystems are typically integrated, such as a central processing unit (CPU) subsystem, a memory subsystem, and various peripheral subsystems. These subsystems often operate at different clock frequencies or power domains. To achieve efficient data communication between them, an AXI bus based on the AXI protocol is commonly used, with cross-clock domain data transmission via an asynchronous bridge. Ideally, the asynchronous bridge can reliably complete protocol conversion and synchronization. In actual operation, the subsystem containing the master device (such as the CPU subsystem) may trigger an unexpected reset due to abnormal conditions such as watchdog timeout or bus occupancy timeout. If there are incomplete data transmission transactions on the asynchronous bus at this time, it will cause a series of serious problems, leading to partial or even complete failure of the chip's functionality.

[0003] In related technologies, the current solutions to the problems caused by the aforementioned abnormal resets are reset isolation and software timeout settings. Reset isolation protects the bus by isolating erroneous resets; software timeout settings prevent deadlock by resetting a specific slave device after a set time interval.

[0004] However, when the master's subsystem resets, if the asynchronous bridge is transmitting data, the reset isolation method can lead to a mismatch in the bus state machines of the two subsystems. Alternatively, it can cause the communicating slave to remain in a waiting state for an extended period due to the master's reset, occupying the bus and resulting in a bus deadlock until the slave's subsystem resets. Software timeout settings can resolve the deadlock problem on the slave due to abnormal resets, but this takes too long on large SoCs and cannot fix state machine issues within the bus.

[0005] Therefore, in multi-subsystem SoCs, when the CPU subsystem experiences an abnormal reset, how to avoid bus deadlock and state machine disorder caused by incomplete transmission on the asynchronous AXI bus across subsystems is a technical problem that urgently needs to be solved. Summary of the Invention

[0006] This application provides an asynchronous AXI bus fault reset detection and automatic repair system. To provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. This summary is not intended as a general description, nor is it intended to identify key / important components or describe the scope of protection of these embodiments. Its sole purpose is to present some concepts in a simple form as a prelude to the detailed description that follows.

[0007] In a first aspect, embodiments of this application provide an asynchronous AXI bus abnormal reset detection and automatic repair system, the system comprising:

[0008] The system comprises a CPU subsystem, at least one peripheral subsystem, and a bus repair module; each peripheral subsystem integrates an AXI asynchronous bridge; the bus repair module integrates a protocol repair component and a reset management component; among these components... The CPU subsystem is connected to each peripheral subsystem via an AXI asynchronous bridge. The CPU subsystem, each peripheral subsystem, and the AXI asynchronous bridge are connected via an AXI bus. The protocol repair component is located on the AXI bus of each peripheral subsystem, and the reset management component is located in both the CPU subsystem and each peripheral subsystem. The CPU subsystem is used to trigger the bus repair module to enter monitoring mode. The bus repair module is used to monitor the AXI bus during AXI bus transmission and obtain monitoring data. When a reset signal is detected in the CPU subsystem, the reset management component triggers simultaneous resets on both sides of the AXI asynchronous bridge to clear the state machine disorder caused by a single-sided reset inside the bridge. At the same time, the protocol repair component analyzes the flag bits in the monitoring data. If the flag is idle, no protocol repair is required, and the reset process is completed; if the flag is busy, control of the AXI bus is taken over and protocol repair is performed.

[0009] Optionally, monitoring data includes incomplete transaction types and the number of recorded missing channel handshakes; The protocol was repaired, including: In the case of an incomplete write transaction, spurious data matching the number of missing channel handshakes is generated and sent to the peripheral subsystem; among which, False data is captured on the peripheral subsystem without being written to a valid value; at the same time, the protocol repair component controls the write response ready signal and waits for the peripheral subsystem to return a write response valid signal until all recorded write transactions have completed the handshake and control of the AXI bus is released.

[0010] Optionally, monitoring data includes incomplete transaction types and the number of recorded missing channel handshakes; The protocol was repaired, including: In the case of an incomplete read transaction, configure a read data ready signal to allow the peripheral subsystem to push all prepared or incomplete data to the AXI bus; at the same time, wait for the peripheral subsystem to send the last read data valid signal until all read transactions are completed, and release control of the AXI bus.

[0011] Optionally, the bus repair module is also used, if the system configuration supports out-of-order transmission capability, for the protocol repair component to additionally check whether there are subsequent transactions where address handshake has been completed but data transmission has not occurred; If it exists, the data transmission corresponding to the remaining addresses will be automatically completed in the original order of initiation to ensure that the transaction queue is cleared.

[0012] Optionally, after the protocol repair is performed, the following may also be included: When all recorded incomplete transactions are completed through the protocol handshake and the AXI bus returns to an idle state, the protocol repair component relinquishes control of the AXI bus and exits the bus repair mode. The CPU subsystem completes the reset and boot process, and the system returns to normal operation.

[0013] Optionally, each peripheral subsystem acts as a slave device on the AXI bus and operates in a different clock or power domain than the CPU subsystem. The AXI asynchronous bridge is used to realize the synchronous transmission of AXI protocol signals across clock domains. The bus repair module also includes a configuration register and a monitoring unit. The configuration register is located in the configuration register of the peripheral subsystem, and the monitoring unit is connected to the AXI bus interface of the CPU subsystem. The configuration register is used to receive configuration parameters from the CPU, enable the bus repair function, and set system parameters. The monitoring unit is used to collect and record bus transmission protocol signals in real time, including the number of address channel handshakes, the number of data channel handshakes, and the number of response channel handshakes, and to maintain the incomplete transaction counter and transmission flag signal to obtain monitoring data.

[0014] Optionally, a simultaneous reset of both sides of the AXI asynchronous bridge can be triggered via the reset management component, including: The reset management component located in the CPU subsystem is used to monitor the reset signals of the peripheral subsystem; The reset management component located in the peripheral subsystem is used to monitor the reset signal of the CPU subsystem; When any reset management component detects a reset in the opposite subsystem, it triggers both interfaces of the AXI asynchronous bridge to perform a reset operation simultaneously.

[0015] Optionally, analyze the flag bits in the monitoring data, including: After triggering a simultaneous reset on both sides of the AXI asynchronous bridge via the reset management component, the state of the transmission flag signal latched before the reset occurred is read. If the status of the transmission flag signal indicates a busy state, the value of the incomplete transaction counter is read to determine whether there are any pending incomplete transactions. If the value of the incomplete transaction counter is greater than zero, the flag is determined to be busy; If the value of the incomplete transaction counter is zero, the flag is determined to be idle.

[0016] Optionally, the bus repair module may also include a FIFO memory; The FIFO memory is connected to the protocol repair component; During normal SoC operation, the acquired real-time bus transmission protocol signals and the generated incomplete transaction information are written into the FIFO memory for caching; When a reset signal is detected in the CPU subsystem, the protocol repair component reads the monitoring data latched at the time of the reset from the FIFO memory and performs the protocol repair operation based on the incomplete transaction type and the number of missing channel handshakes recorded in the monitoring data.

[0017] Secondly, an asynchronous AXI bus fault reset detection and automatic repair method is applied to the bus repair module, and the method includes: During the transmission process on the AXI bus, the AXI bus is monitored to obtain monitoring data; When a reset signal is detected in the CPU subsystem, the reset management component triggers a simultaneous reset on both sides of the AXI asynchronous bridge to clear the state machine disorder caused by a single-sided reset within the bridge; at the same time, the protocol repair component analyzes the flag bits in the monitoring data. If the flag is free, there is no need to perform protocol repair; the reset process is completed. If the flag is busy, it takes over control of the AXI bus and performs protocol repair.

[0018] Optionally, monitoring data includes incomplete transaction types and the number of recorded missing channel handshakes; The protocol was repaired, including: In the case of an incomplete write transaction, spurious data matching the number of missing channel handshakes is generated and sent to the peripheral subsystem; among which, False data is captured on the peripheral subsystem without being written to a valid value; simultaneously, the protocol repair component controls the write response ready signal and waits for the peripheral subsystem to return a write response valid signal until all recorded write transactions have completed the handshake, releasing control of the AXI bus; or, If a read transaction is incomplete, configure a read data ready signal to allow the peripheral subsystem to push all prepared or incomplete data to the AXI bus; simultaneously, wait for the peripheral subsystem to send the last valid read data signal until all read transactions are completed, then release control of the AXI bus; or, If the system configuration supports out-of-order transmission capability, the protocol repair component additionally checks whether there are subsequent transactions that have completed address handshakes but have not yet transmitted data; if so, it automatically completes the data transmission corresponding to the remaining addresses in the original initiation order to ensure that the transaction queue is cleared.

[0019] Optionally, after the protocol repair is performed, the following may also be included: When all recorded incomplete transactions are completed through the protocol handshake and the AXI bus returns to an idle state, the protocol repair component relinquishes control of the AXI bus and exits the bus repair mode. The CPU subsystem completes the reset and boot process, and the system returns to normal operation.

[0020] In this embodiment, by introducing a reset management component integrated into each subsystem, a simultaneous reset of both sides of the AXI asynchronous bridge is forced when a reset signal is detected, eliminating the potential for state machine disorder caused by unilateral reset from the source. At the same time, the protocol repair component in the bus repair module analyzes the flag bits in the monitoring data in real time. If it is determined to be an abnormal reset, it actively takes over the control of the AXI bus and deceives and releases the Slave in the waiting state by filling in false data. Thus, without needing to reset the Slave subsystem, the physical layer and the protocol layer work together to completely avoid the occurrence of bus deadlock.

[0021] In this embodiment, the bus repair module performs non-intrusive monitoring and accounting during AXI bus transmission. After a reset occurs, no CPU software intervention is required; the hardware directly resets both sides of the asynchronous bridge via the reset management component, and the protocol repair component automatically performs protocol completion based on the recorded number of missing channel handshakes. This process is completed within the hardware timeline, with a response speed far faster than software polling, and it can accurately repair the internal state machine of the bus. This achieves instantaneous restoration of the bus to a usable idle state without affecting other subsystems or resetting the slave.

[0022] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0023] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0024] Figure 1 This is a schematic diagram of the system structure of an asynchronous AXI bus abnormal reset detection and automatic repair system provided in an embodiment of this application; Figure 2 This is a schematic diagram illustrating an asynchronous AXI bus abnormal reset detection and automatic repair process provided in an embodiment of this application; Figure 3 This is a flowchart illustrating an asynchronous AXI bus abnormal reset detection and automatic repair method provided in an embodiment of this application; Figure 4 This is a schematic diagram illustrating a flag bit analysis process in monitoring data provided in an embodiment of this application; Figure 5 This is a schematic diagram of an asynchronous AXI bus abnormal reset detection and automatic repair process provided in an embodiment of this application. Detailed Implementation

[0025] The following description and accompanying drawings fully illustrate specific embodiments of this application to enable those skilled in the art to practice them.

[0026] It should be understood that the described embodiments are merely some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0027] In the following description, when referring to the accompanying drawings, the same numbers in different drawings denote the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of systems and methods consistent with some aspects of this application as detailed in the appended claims.

[0028] In the description of this application, it should be understood that the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances. Furthermore, in the description of this application, unless otherwise stated, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0029] Currently, the methods employed are reset isolation and software timeout setting. Reset isolation protects the bus by isolating faulty resets; software timeout setting prevents deadlock by individually resetting a slave device after a set time.

[0030] The inventors realized that when the master's subsystem resets, if the asynchronous bridge is transmitting data, the reset isolation method can lead to a mismatch in the bus state machines of the two subsystems. Alternatively, it can cause the communicating slave to remain in a waiting state for an extended period due to the master's reset, occupying the bus and resulting in a bus deadlock until the slave's subsystem resets. Software timeout settings can solve the deadlock problem on the slave due to abnormal resets, but this takes too long on large SoC chips and cannot repair the state machine issues within the bus.

[0031] In this embodiment, by introducing a reset management component integrated into each subsystem, a simultaneous reset of both sides of the AXI asynchronous bridge is forced when a reset signal is detected, eliminating the potential for state machine disorder caused by unilateral reset from the source. At the same time, the protocol repair component in the bus repair module analyzes the flag bits in the monitoring data in real time. If it is determined to be an abnormal reset, it actively takes over the control of the AXI bus and deceives and releases the Slave in the waiting state by filling in false data. Thus, without needing to reset the Slave subsystem, the physical layer and the protocol layer work together to completely avoid the occurrence of bus deadlock.

[0032] In this embodiment, the bus repair module performs non-intrusive monitoring and accounting during AXI bus transmission. After a reset, no CPU software intervention is required; the hardware directly resets both sides of the asynchronous bridge via the reset management component, and the protocol repair component automatically performs protocol completion based on the recorded number of missing channel handshakes. This process is completed within hardware timing, with a response speed far faster than software polling, and can accurately repair the bus's internal state machine. This achieves instantaneous restoration of the bus to a usable idle state without affecting other subsystems or resetting the slave. The following detailed description uses exemplary embodiments.

[0033] Please see Figure 1 , Figure 1This is a schematic diagram of the system structure of an asynchronous AXI bus abnormal reset detection and automatic repair system provided in an embodiment of this application. The system includes: a CPU subsystem, at least one peripheral subsystem, and a bus repair module; the CPU subsystem and each peripheral subsystem integrate an AXI asynchronous bridge; the bus repair module integrates a protocol repair component and a reset management component; wherein, the CPU subsystem and each peripheral subsystem are connected by an AXI asynchronous bridge, the CPU subsystem, each peripheral subsystem, and the AXI asynchronous bridge are connected by an AXI bus, the protocol repair component is located on the AXI bus of each peripheral subsystem, and the reset management component is located in the CPU subsystem and each peripheral subsystem.

[0034] The CPU subsystem is the core functional module of the SoC chip, housing the central processing unit. As the master in the AXI bus protocol, it is responsible for initiating read / write transfer transactions, executing software instructions, and controlling the overall system operation logic. The peripheral subsystem is a collection of subordinate functional modules (such as memory controllers, DMA controllers, GPIO, etc.) with specific functions, excluding the CPU. This subsystem operates in slave mode, receiving access requests from the CPU subsystem via the AXI bus and completing data interaction according to the protocol. It typically resides in a different clock or power domain than the CPU subsystem. The bus repair module is a hardware logic circuit integrated within the SoC used to detect abnormal resets and automatically repair the bus protocol. This module is independent of the business data processing path, using a combination of passive monitoring and active intervention to ensure the restoration of bus communication capabilities without resetting the slave device. The AXI asynchronous bridge is a cross-clock domain interconnect IP core. Because the CPU subsystem and peripheral subsystem operate at different frequencies, they cannot be directly connected. This bridge is deployed between them, responsible for synchronizing, buffering, and converting signals on one side of the AXI bus (based on clock A), and forwarding them to the other side (based on clock B) to achieve efficient data transmission across clock domains. The protocol repair component is a sub-functional unit integrated within the bus repair module. Physically deployed on the AXI bus on the peripheral subsystem side, it takes over bus control upon detecting an abnormal reset and automatically generates and injects dummy data based on the recorded transmission status to complete incomplete bus protocol handshakes. The reset management component is another sub-functional unit integrated within the bus repair module. Distributed across the CPU and peripheral subsystems, it monitors the reset signals of each subsystem. Once a reset is detected in any subsystem, it forcibly triggers simultaneous resets of the interfaces on both sides of the AXI asynchronous bridge to eliminate state machine errors caused by unilateral resets.

[0035] In some embodiments of this application, the CPU subsystem is used to trigger the bus repair module to enter the monitoring mode; the bus repair module is used to monitor the AXI bus during AXI bus transmission and obtain monitoring data; when a reset signal is detected in the CPU subsystem, the reset management component triggers simultaneous resets on both sides of the AXI asynchronous bridge to clear the state machine disorder caused by a single-sided reset inside the bridge; at the same time, the protocol repair component analyzes the flag bits in the monitoring data; if the flag bit is idle, no protocol repair is required, and the reset process is completed; if the flag bit is busy, the control of the AXI bus is taken over and the protocol repair is executed.

[0036] The monitoring data consists of snapshots of system status collected and recorded in real time during normal AXI bus transmission. It is structured information containing protocol handshake status. This structured information includes the following: Incomplete transaction type: recording whether the current transaction is a read or write transaction. Channel handshake missing count: specifically referring to the difference in the number of handshakes for the address channel (AW / AR), data channel (W / R), and response channel (B). For example, it records "The address has been sent, but 10 data packets are still missing." Transmission flag signal (Flag): a Boolean value (busy / idle), updated in real time by the monitoring unit based on the incomplete transaction counter. Incomplete transaction counter: records how many transactions are still pending.

[0037] The flag bit refers to the logical status bit of the transmission flag signal. It is a core fast index bit in the monitoring data, used to allow the repair module to determine whether protocol repair is needed as soon as a reset occurs. The status is defined as idle and busy. Idle means that there are no incomplete transmissions on the AXI bus when a reset occurs. Protocol repair is not required in this case. Busy means that there are interrupted transmission transactions on the bus when a reset occurs. Protocol repair must be initiated in this case.

[0038] Protocol repair refers to the process where, after the protocol repair component takes over the bus, it automatically completes or finishes the AXI protocol handshake process that was not completed before the reset through hardware logic, rather than actually transmitting valid data or resuming CPU operation. Its purpose is to deceive the slave into believing that the transmission has ended normally, thereby releasing the bus. For example, for write transactions: sending dummy data (DummyData), which is not written to the slave's real memory area, but only used to complete the WVALID / WREADY handshake, and finally waiting for BVALID. For read transactions: directly pulling RREADY high, causing the slave to send the data (even if no one receives it), until the RLAST signal is received.

[0039] The monitoring data includes incomplete transaction types and the number of missing channel handshakes recorded.

[0040] Specifically, when a write transaction is not completed, a false data signal matching the number of missing channel handshakes is generated and sent to the peripheral subsystem. The false data signal is sent to the peripheral subsystem without writing a valid value. At the same time, the protocol repair component controls the write response ready signal and waits for the peripheral subsystem to return a valid write response signal until all recorded write transactions have completed the handshake and control of the AXI bus is released.

[0041] In some embodiments of this application, when all recorded incomplete transactions are completed through protocol handshake and the AXI bus returns to an idle state, the protocol repair component relinquishes control of the AXI bus and exits the bus repair mode; the CPU subsystem completes the reset and startup process, and the system resumes normal operation.

[0042] In one possible implementation, a scenario is as follows: The CPU subsystem (Master) is writing data to the DDR controller subsystem (Slave). Configuration: The AXI bus width is 32 bits, and the burst length is 4 (i.e., one write transaction requires the transmission of 4 data chips). An exception occurs: Just after the CPU sends the address and the first data chip via the AXI bus, an abnormal reset is triggered due to a watchdog timeout (WDT). In this scenario, the bus repair module first enters monitoring mode. The generated monitoring data includes the following: Incomplete transaction type: Write transaction. Channel handshake missing count: The data channel is still missing 3 data chips (because there are a total of 4, only 1 has been sent). Flag: Busy. Incomplete transaction counter: 1.

[0043] At this point, the reset management component detects a CPU subsystem reset signal. It immediately triggers a simultaneous reset on both sides of the AXI asynchronous bridge. This clears any potentially stuck buffers and state machines within the bridge, preventing a chaotic state where one side is reset while the other is not.

[0044] Next, the protocol repair component reads the flag bit from the monitoring data. The flag bit is busy. At this point, a simple restart is not possible; protocol repair must be performed. The protocol repair component takes over bus control. Based on the 3 data cycles remaining recorded in the monitoring data, the module automatically generates 3 dummy data cycles. The module sends these dummy data cycles to the DDR controller (Slave) via the AXI asynchronous bridge. The module controls the write response ready signal (BREADY signal) and waits for the DDR controller to return a write response valid signal (BVALID signal). At this point, the DDR controller believes that this write transaction (4 data cycles) has been completely completed, releases the bus interface, and no longer waits for the CPU. All incomplete transactions (1 write transaction) complete the handshake. Finally, the protocol repair component relinquishes bus control, and the flag bit becomes idle. The CPU subsystem completes the reset and startup process, the system resumes normal operation, and there is no bus deadlock.

[0045] In some embodiments of this application, when a read transaction is not completed, a read data ready signal is configured, allowing the peripheral subsystem to push all prepared or incomplete data to the AXI bus; at the same time, the system waits for the peripheral subsystem to send the last read data valid signal until all recorded read transactions are completed, and then releases control of the AXI bus.

[0046] In one possible implementation, a scenario is as follows: The CPU subsystem (Master) initiates a read request to the encryption engine subsystem (Slave), requesting to read four 32-bit data bytes (i.e., Burst Length = 4). An exception occurs: Just after the CPU issues the read address (ARADDR) and establishes the address handshake (ARVALID / ARREADY), and the encryption engine has just begun preparing the first data byte, the CPU triggers an abnormal reset due to a program crash.

[0047] At this point, the incomplete transaction type is Read. The monitoring status shows that the address handshake has been completed, but the data channel handshake count is 0 (no RVALID data has been received yet). The flag is Busy.

[0048] Secondly, the reset management component triggers a simultaneous reset on both sides of the AXI asynchronous bridge, clearing the bridge's internal state. The protocol repair component reads monitoring data and finds the flag is busy, indicating a read transaction. After taking over the bus, the repair module immediately pulls the RREADY signal high. The encryption engine (Slave), which was already preparing data, detects RREADY is high and begins pushing data sequentially onto the AXI bus. Even if the CPU crashes at this point, the repair module keeps RREADY active, allowing the peripheral subsystem to push out all four prepared data packets. The repair module waits for the encryption engine to send the last read data valid signal (RLAST). When the fourth data packet is received along with the RLAST signal, it indicates that the read transaction is complete. The repair module confirms the completion of all read transactions, relinquishes bus control, and the bus returns to idle.

[0049] In some embodiments of this application, the bus repair module is further configured to, when the system configuration supports out-of-order transmission capability, have the protocol repair component additionally check whether there are subsequent transactions that have completed address handshakes but have not yet transmitted data; if so, automatically complete the data transmission corresponding to the remaining addresses in the original initiation order to ensure that the transaction queue is cleared.

[0050] In one possible implementation, a scenario is as follows: The SoC chip supports out-of-order transfer capability (depth set to 2), meaning the CPU can initiate the next read request consecutively without waiting for the previous read request to return data. The CPU initiates read transaction #1 (address 0x1000, length 4) to the DDR controller (Slave A). After the address handshake is completed, the CPU, without waiting for data to return, immediately initiates read transaction #2 (address 0x2000, length 2) to the UART controller (Slave B). Just as Slave A is about to send the first data, and before Slave B has begun to respond, the CPU experiences an abnormal reset.

[0051] At this point, the incomplete transaction type is a read transaction. The Outstanding status includes: Transaction #1: Address handshake completed, data channel incomplete (4 data bytes missing). Transaction #2: Address handshake completed, data channel not yet started (2 data bytes missing). Flag: Busy. The reset management component triggers simultaneous resets on both sides of the AXI asynchronous bridge. The protocol repair component reads monitoring data, determines it to be a read transaction, and confirms the system supports Outstanding capabilities. The protocol repair component checks for subsequent transactions that have completed address handshakes but haven't transmitted data. It then detects Transaction #2 (although Transaction #1 hasn't finished processing, the address for #2 has already been sent).

[0052] Finally, complete the process in the original order of initiation: 1. First, process transaction #1: The repair module pulls RREADY high, receives all four data packets sent by the DDR controller, and waits for RLAST. 2. Next, process transaction #2: The repair module continues to pull RREADY high, receives all two data packets sent by the UART controller, and waits for RLAST. Ensure the transaction queue is cleared: The repair module strictly follows the order in which the CPU initiated the process (#1 first, then #2), completing the protocol flow for both backlogged read transactions. Once all data from #1 and #2 has completed the handshake, the repair module confirms that the bus has returned to idle and relinquishes control.

[0053] For example Figure 2 As shown, Figure 2 This is a schematic diagram of an asynchronous AXI bus abnormal reset detection and automatic repair process provided in this application. First, in the system configuration phase, the CPU completes the basic configuration of each subsystem and activates the internal bus repair module; then the system enters the normal transmission phase, and the bus repair module continuously records the ongoing transmission transaction information (such as transmission length, ID, address / data / response handshake count, etc.). When a single subsystem reset is detected, the system proceeds to different branches depending on whether there are ongoing transmission transactions: If there are no ongoing transactions (normal transmission), only the AXI asynchronous bridge connected to this subsystem is reset at both ends, followed by the normal reset phase (the CPU subsystem enters the reset state); if there are ongoing transactions (abnormal transmission), the connected asynchronous bridge is also reset at both ends first, and then processed according to the transmission type: If it is a write transmission, the bus repair module takes over the bus, replenishes the remaining data of the interrupted transmission (if there is an outstanding transmission, it replenishes all data of the remaining unopened transmission addresses), then waits for the transmission completion signal, and releases the bus after all recorded handshake transactions are completed; if it is a read transmission, the bus repair module takes over the bus and pulls the ready signal high, waiting for the communicating slave to push data, then also waits for the transmission completion signal, and releases the bus after all recorded handshake transactions are completed. Finally, all branch processes converge to the startup phase, the CPU subsystem restarts, and the system resumes operation.

[0054] In some embodiments of this application, each peripheral subsystem acts as a slave device on the AXI bus and operates in a different clock domain or power domain than the CPU subsystem; the AXI asynchronous bridge is used to realize the synchronous transmission of AXI protocol signals across clock domains; the bus repair module also includes a configuration register and a monitoring unit. The configuration register is located in the configuration register of the peripheral subsystem, and the monitoring unit is connected to the AXI bus interface of the CPU subsystem; wherein, the configuration register is used to receive configuration parameters from the CPU, enable the bus repair function, and set system parameters; the monitoring unit is used to collect and record bus transmission protocol signals in real time, including the number of address channel handshakes, the number of data channel handshakes, and the number of response channel handshakes, and maintain an incomplete transaction counter and transmission flag signal to obtain monitoring data.

[0055] In some embodiments of this application, the specific process of triggering simultaneous reset on both sides of the AXI asynchronous bridge through the reset management component includes: a reset management component located in the CPU subsystem is used to monitor the reset signal of the peripheral subsystem; a reset management component located in the peripheral subsystem is used to monitor the reset signal of the CPU subsystem; when either reset management component monitors that the other subsystem has been reset, it triggers simultaneous reset operations on both sides of the AXI asynchronous bridge interface.

[0056] In some embodiments of this application, the specific process of analyzing the flag bits in the monitoring data includes: after triggering a simultaneous reset on both sides of the AXI asynchronous bridge through the reset management component, reading the status of the transmission flag signal latched before the reset occurs; if the status of the transmission flag signal indicates a busy state, reading the value of the incomplete transaction counter to determine whether there are any pending incomplete transactions; if the value of the incomplete transaction counter is greater than zero, determining that the flag bit is busy; if the value of the incomplete transaction counter is zero, determining that the flag bit is idle.

[0057] The bus repair module also includes a FIFO memory. The FIFO memory is connected to the protocol repair component.

[0058] In some embodiments of this application, during normal operation of the SoC, the collected real-time bus transmission protocol signals and the generated incomplete transaction information are written into the FIFO memory for caching; when a reset signal is detected in the CPU subsystem, the protocol repair component reads the monitoring data latched at the time of the reset from the FIFO memory, and performs the protocol repair operation according to the incomplete transaction type and the number of missing channel handshakes recorded in the monitoring data.

[0059] For example, the steps for asynchronous AXI bus abnormal reset detection and automatic repair are as follows: The first step is that during the system startup phase, the CPU (master device) writes configuration parameters to the bus repair module integrated in each subsystem through the configuration register so that it enters the monitoring mode. The second step involves the repair module performing non-intrusive monitoring of the AXI bus and recording transactions in real time during normal SoC operation.

[0060] Third, when a reset signal is detected in the CPU subsystem, the repair module queries the current transmission flag signal and the incomplete transaction counter. If the flag is idle (no incomplete transactions), no protocol repair is required, and the system directly completes the reset process. If the flag is busy (there are incomplete transactions), the bus repair mode is triggered. Fourth, regardless of whether the reset is determined to be normal or abnormal, the reset management module must first execute reset operations on both sides of the asynchronous bridge to clear any state machine errors that might occur due to a unilateral reset, ensuring physical link consistency. Subsequently, based on the determination result in step three, a differentiated process is executed: Branch A: Normal reset process (no transaction residue). Since there are no incomplete transactions, after the reset on both sides of the asynchronous bridge is completed, there is no need to perform protocol repair, and the system directly completes the reset.

[0061] Branch B: Abnormal Reset Process (with Transaction Residuals). After resetting both sides of the asynchronous bridge, it enters bus repair mode. The repair module takes over the bus, performs protocol completion operations based on the recorded incomplete transaction information, and does not reset the Slave subsystem. 1. For write transactions: The repair module replaces the CPU and automatically sends dummy data based on the recorded number of handshakes. This ensures the data volume is complete (the slave does not write valid values, only to complete the protocol), controls the BREADY signal, and waits for the slave to return a BVALID response. The bus is released only after all write transactions have completed the handshake.

[0062] 2. For read transactions: The repair module replaces the CPU, configures the RREADY signal, allowing the Slave to push out all prepared or incomplete read data (even if the data is discarded), and waits for the Slave to send the RLAST signal. The bus is released only after all read transactions are completed.

[0063] 3. For Outstanding Transactions: If the system is configured with Outstanding capability, the module additionally checks for any subsequent transactions that have completed address handshakes but have not yet transmitted data. If such transactions exist, the module automatically completes the transmissions corresponding to the remaining addresses in the original order of initiation, ensuring that the transaction queue is cleared.

[0064] Fifth, after all recorded incomplete transactions (including outstanding transactions) have completed the protocol handshake, the repair module confirms that the bus has returned to an idle state. The repair module revokes bus control and exits repair mode. The CPU subsystem completes the reset and startup process, and the system resumes normal operation.

[0065] In this embodiment, by introducing a reset management component integrated into each subsystem, a simultaneous reset of both sides of the AXI asynchronous bridge is forced when a reset signal is detected, eliminating the potential for state machine disorder caused by unilateral reset from the source. At the same time, the protocol repair component in the bus repair module analyzes the flag bits in the monitoring data in real time. If it is determined to be an abnormal reset, it actively takes over the control of the AXI bus and deceives and releases the Slave in the waiting state by filling in false data. Thus, without needing to reset the Slave subsystem, the physical layer and the protocol layer work together to completely avoid the occurrence of bus deadlock.

[0066] In this embodiment, the bus repair module performs non-intrusive monitoring and accounting during AXI bus transmission. After a reset occurs, no CPU software intervention is required; the hardware directly resets both sides of the asynchronous bridge via the reset management component, and the protocol repair component automatically performs protocol completion based on the recorded number of missing channel handshakes. This process is completed within the hardware timeline, with a response speed far faster than software polling, and it can accurately repair the internal state machine of the bus. This achieves instantaneous restoration of the bus to a usable idle state without affecting other subsystems or resetting the slave.

[0067] Please see Figure 3 This document presents a flowchart illustrating an asynchronous AXI bus fault reset detection and automatic repair method, applicable to a bus repair module. Figure 3 As shown, the detection method in this application embodiment may include the following steps: S101 monitors the AXI bus during AXI bus transmission and obtains monitoring data; S102, when a reset signal is detected in the CPU subsystem, the reset management component triggers simultaneous resets on both sides of the AXI asynchronous bridge to clear the state machine disorder caused by a single-sided reset inside the bridge; at the same time, the protocol repair component analyzes the flag bits in the monitoring data. S103: If the flag is idle, no protocol repair is required, and the reset process is completed; if the flag is busy, control of the AXI bus is taken over and protocol repair is performed.

[0068] The monitoring data includes incomplete transaction types and the number of missing channel handshakes recorded.

[0069] In some embodiments of this application, the specific process of performing protocol repair includes: in the case of an incomplete write transaction, generating and sending spurious data matching the number of missing channel handshakes to the peripheral subsystem; wherein, the spurious data is sent to the peripheral subsystem without writing a valid value; at the same time, the protocol repair component controls the write response ready signal and waits for the peripheral subsystem to return a write response valid signal until all recorded write transactions have completed the handshake and the control of the AXI bus is released.

[0070] In other embodiments of this application, the specific process of performing protocol repair includes: when the incomplete transaction type is a read transaction, configuring a read data ready signal to allow the peripheral subsystem to push all prepared or incomplete data to the AXI bus; at the same time, waiting for the peripheral subsystem to send the last read data valid signal until all recorded read transactions are completed, and releasing control of the AXI bus.

[0071] In other embodiments of this application, the bus repair module is further configured to, when the system configuration supports out-of-order transmission capability, have the protocol repair component additionally check whether there are subsequent transactions that have completed address handshakes but have not yet transmitted data; if so, automatically complete the data transmission corresponding to the remaining addresses in the original initiation order to ensure that the transaction queue is cleared.

[0072] In some embodiments of this application, after the protocol repair is performed, the following operations are also required: when all recorded incomplete transactions are completed through the protocol handshake and the AXI bus returns to the idle state, the protocol repair component revokes control of the AXI bus and exits the bus repair mode; the CPU subsystem completes the reset and startup process, and the system resumes normal operation.

[0073] For example Figure 4 As shown, Figure 4 This is a schematic diagram illustrating the flag bit analysis process in monitoring data provided in this application. First, the system continuously monitors the AXI bus to obtain the current transmission status; then, it checks whether a reset signal has occurred in the CPU subsystem. If no reset occurs, the system continues to monitor in a loop; if a reset signal is detected, the system triggers two key actions in parallel: first, it triggers simultaneous resets on both sides of the asynchronous bridge to clear the bridge's state machine; second, it analyzes the flag bits in the monitoring data. Subsequently, the system judges based on the status of the flag bit: if the flag bit is idle, it means there are no incomplete transmissions on the bus when the reset occurs, and the system directly completes the reset; if the flag bit is busy, it means there are interrupted transactions on the bus, and the system takes over bus control and executes the subsequent protocol repair process.

[0074] For example Figure 5 As shown, Figure 5This application provides a schematic diagram of an asynchronous AXI bus abnormal reset detection and automatic repair process. The bus repair module takes over bus control and then determines the type of incomplete transactions left over from the reset: if it is a write transaction, it generates a dummy data block and controls the write response to be ready, waiting for a valid write response signal; if it is a read transaction, it configures a read data ready signal and waits for the last valid read data signal; if it is an out-of-order transmission, it additionally checks subsequent incomplete transactions and completes the data transmission of the remaining addresses according to the original initiation order. After completing the above targeted data interaction, the module releases bus control and determines whether all transactions have been completed and the bus is idle; if the conditions are met, it revokes control, exits the repair mode, and finally triggers a CPU reset to start system recovery.

[0075] In this embodiment, by introducing a reset management component integrated into each subsystem, a simultaneous reset of both sides of the AXI asynchronous bridge is forced when a reset signal is detected, eliminating the potential for state machine disorder caused by unilateral reset from the source. At the same time, the protocol repair component in the bus repair module analyzes the flag bits in the monitoring data in real time. If it is determined to be an abnormal reset, it actively takes over the control of the AXI bus and deceives and releases the Slave in the waiting state by filling in false data. Thus, without needing to reset the Slave subsystem, the physical layer and the protocol layer work together to completely avoid the occurrence of bus deadlock.

[0076] In this embodiment, the bus repair module performs non-intrusive monitoring and accounting during AXI bus transmission. After a reset occurs, no CPU software intervention is required; the hardware directly resets both sides of the asynchronous bridge via the reset management component, and the protocol repair component automatically performs protocol completion based on the recorded number of missing channel handshakes. This process is completed within the hardware timeline, with a response speed far faster than software polling, and it can accurately repair the internal state machine of the bus. This achieves instantaneous restoration of the bus to a usable idle state without affecting other subsystems or resetting the slave.

[0077] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program for asynchronous AXI bus abnormal reset detection and automatic repair can be stored in a computer-readable storage medium. When executed, the program can include the processes of the embodiments of the above methods. The storage medium for asynchronous AXI bus abnormal reset detection and automatic repair can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0078] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. An asynchronous AXI bus fault reset detection and automatic repair system, characterized in that, The system includes: The system comprises a CPU subsystem, at least one peripheral subsystem, and a bus repair module; each peripheral subsystem integrates an AXI asynchronous bridge; the bus repair module integrates a protocol repair component and a reset management component; wherein... The CPU subsystem and each peripheral subsystem are connected by the AXI asynchronous bridge. The CPU subsystem, each peripheral subsystem, and the AXI asynchronous bridge are connected via an AXI bus. The protocol repair component is located on the AXI bus of each peripheral subsystem, and the reset management component is located in each of the CPU subsystems and each peripheral subsystem. The CPU subsystem is used to trigger the bus repair module to enter monitoring mode; The bus repair module is used to monitor the AXI bus during the AXI bus transmission process and obtain monitoring data; when a reset signal is detected in the CPU subsystem, the reset management component triggers simultaneous reset on both sides of the AXI asynchronous bridge to clear the state machine disorder caused by a single-sided reset inside the bridge; at the same time, the protocol repair component analyzes the flag bits in the monitoring data. If the flag is idle, no protocol repair is required, and the reset process is completed; if the flag is busy, control of the AXI bus is taken over and protocol repair is performed.

2. The system according to claim 1, characterized in that, The monitoring data includes incomplete transaction types and the number of missing channel handshakes recorded. The execution protocol repair includes: In the case where the incomplete transaction type is a write transaction, spurious data matching the number of missing channel handshakes is generated and sent to the peripheral subsystem; wherein, The false data is not written to the peripheral subsystem with a valid value; at the same time, the protocol repair component controls the write response ready signal and waits for the peripheral subsystem to return a write response valid signal until all recorded write transactions have completed the handshake and the control of the AXI bus is released.

3. The system according to claim 1, characterized in that, The monitoring data includes incomplete transaction types and the number of missing channel handshakes recorded. The execution protocol repair includes: In the case where the incomplete transaction type is a read transaction, a read data ready signal is configured, allowing the peripheral subsystem to push all prepared or incomplete data to the AXI bus; at the same time, wait for the peripheral subsystem to send the last read data valid signal until all recorded read transactions are completed, and release control of the AXI bus.

4. The system according to claim 2 or 3, characterized in that, The bus repair module is also used, when the system configuration supports out-of-order transmission capability, for the protocol repair component to additionally check whether there are subsequent transactions that have completed address handshake but have not transmitted data; If it exists, the data transmission corresponding to the remaining addresses will be automatically completed in the original order of initiation to ensure that the transaction queue is cleared.

5. The system according to claim 1, characterized in that, After the execution protocol is repaired, it also includes: When all recorded incomplete transactions are completed through protocol handshake and the AXI bus returns to an idle state, the protocol repair component relinquishes control of the AXI bus and exits the bus repair mode. The CPU subsystem completes the reset and startup process, and the system resumes normal operation.

6. The system according to claim 1, characterized in that, Each peripheral subsystem acts as a slave device on the AXI bus and operates in a different clock domain or power domain than the CPU subsystem. The AXI asynchronous bridge is used to realize the synchronous transmission of AXI protocol signals across clock domains; The bus repair module further includes a configuration register and a monitoring unit. The configuration register is located in the configuration register of the peripheral subsystem, and the monitoring unit is connected to the AXI bus interface of the CPU subsystem. The configuration register is used to receive configuration parameters from the CPU, enable the bus repair function, and set system parameters. The monitoring unit is used to collect and record bus transmission protocol signals in real time, including the number of address channel handshakes, the number of data channel handshakes, and the number of response channel handshakes, and to maintain an incomplete transaction counter and transmission flag signal to obtain monitoring data.

7. The system according to claim 1, characterized in that, The step of triggering simultaneous resets on both sides of the AXI asynchronous bridge via the reset management component includes: The reset management component located in the CPU subsystem is used to monitor the reset signal of the peripheral subsystem; The reset management component located in the peripheral subsystem is used to monitor the reset signal of the CPU subsystem; When any reset management component detects a reset in the opposite subsystem, it triggers both interfaces of the AXI asynchronous bridge to perform a reset operation simultaneously.

8. The system according to claim 1, characterized in that, The analysis of the flag bits in the monitoring data includes: After the reset management component triggers a simultaneous reset on both sides of the AXI asynchronous bridge, the state of the transmission flag signal latched before the reset occurs is read. If the status of the transmission flag signal indicates a busy state, the value of the incomplete transaction counter is read to determine whether there are any pending incomplete transactions. If the value of the incomplete transaction counter is greater than zero, then the flag is determined to be busy; If the value of the incomplete transaction counter is zero, then the flag is determined to be idle.

9. The system according to claim 1, characterized in that, The bus repair module also includes a FIFO memory; The FIFO memory is connected to the protocol repair component; During normal SoC operation, the acquired real-time bus transmission protocol signals and the generated incomplete transaction information are written into the FIFO memory for caching; When a reset signal is detected in the CPU subsystem, the protocol repair component reads the monitoring data latched at the time of the reset from the FIFO memory, and performs a protocol repair operation based on the incomplete transaction type and the number of missing channel handshakes recorded in the monitoring data.

10. A method for detecting and automatically repairing asynchronous AXI bus abnormal resets using the system described in any one of claims 1-9, characterized in that, Applied to a bus repair module, the method includes: During the AXI bus transmission process, the AXI bus is monitored to obtain monitoring data; When a reset signal is detected in the CPU subsystem, the reset management component triggers a simultaneous reset on both sides of the AXI asynchronous bridge to clear the state machine disorder caused by a single-sided reset within the bridge; at the same time, the protocol repair component analyzes the flag bits in the monitoring data. If the flag bit is free, then no protocol repair is required, and the reset process is completed. If the flag is busy, then take over control of the AXI bus and perform protocol repair.

11. The method according to claim 10, characterized in that, The monitoring data includes incomplete transaction types and the number of missing channel handshakes recorded. The execution protocol repair includes: In the case where the incomplete transaction type is a write transaction, spurious data matching the number of missing channel handshakes is generated and sent to the peripheral subsystem; wherein, The false data is recorded and no valid value is written to the peripheral subsystem; simultaneously, the protocol repair component controls the write response ready signal and waits for the peripheral subsystem to return a write response valid signal until all recorded write transactions have completed the handshake, releasing control of the AXI bus; or, In the case where the incomplete transaction type is a read transaction, a read data ready signal is configured, allowing the peripheral subsystem to push all prepared or incomplete data to the AXI bus; simultaneously, the system waits for the peripheral subsystem to send the last read data valid signal until all recorded read transactions are completed, at which point control of the AXI bus is released; or, When the system configuration supports out-of-order transmission capability, the protocol repair component additionally checks whether there are subsequent transactions that have completed address handshakes but have not yet transmitted data; if so, it automatically completes the data transmission corresponding to the remaining addresses in the original initiation order to ensure that the transaction queue is cleared.

12. The method according to claim 10, characterized in that, After the execution protocol is repaired, it also includes: When all recorded incomplete transactions are completed through protocol handshake and the AXI bus returns to an idle state, the protocol repair component relinquishes control of the AXI bus and exits the bus repair mode. The CPU subsystem completes the reset and startup process, and the system resumes normal operation.

Images