Isolated reset for heterogeneous CPU systems and methods

Abstract

The application discloses a kind of heterogeneous CPU system real-time isolation reset device and method, device includes: heterogeneous CPU system includes permission hierarchical security core, application core, at least one subsystem;Security core is the controlled lower-level system as application core when upper system;Application core is the controlled lower-level system as each subsystem when upper system;Upper system is provided with configuration register group;Local mirror register group is set in lower-level system inside;Real-time monitoring module is used to monitor the reset signal of upper system and lower-level system, to make control mode selector switch between local mode and upper takeover mode;According to the real data path between runtime system, the range of reset is dynamically determined by real-time maintenance transaction counter, and only the opposite end system with unfinished transaction is sent reset signal.Using the application, while ensuring the consistency of cross-system state, the real-time dynamic convergence of reset range can be realized, and the service interruption surface is minimized.

Description

Technical Field

[0001] This application relates to the fields of integrated circuit design and embedded device technology, and in particular to a real-time isolation reset device and method for heterogeneous CPU systems. Background Technology

[0002] In heterogeneous multi-core SoC chips used in industrial control and other applications, a hierarchical security core (CPU0), an application core (CPU1), and several subsystems (SUBn) are typically integrated. The security core is responsible for secure system startup and global resource management, the application core is responsible for running general application workloads, and the subsystems handle peripheral control or hardware acceleration functions. In this architecture, the address space of the higher-level system (such as the security core) contains a configuration register set for controlling the clock and reset of the lower-level system (such as the application core). The normal operation of the lower-level system depends on the configuration information provided by the higher-level system through this register set.

[0003] In related technologies, patent application CN119225497A discloses a reset circuit, a reset method, and a multi-core heterogeneous system. This solution, by setting up a monitoring module, a processing module, and a reset control module, selects a target reset signal according to a preset reset mode to achieve selective reset of different modules in a multi-core heterogeneous system.

[0004] However, in this technology, when the upper-level system is reset due to a fault or software upgrade, its configuration register set in its address space becomes invalid, causing the lower-level system to lose its clock and reset configuration source, and it has to reset along with the upper-level system, making it impossible to achieve reset isolation between the upper and lower levels. Secondly, after the lower-level system is reset, its configuration registers are restored to default values, and it must wait for the upper-level system to rewrite the configuration through the bus before it can resume normal operation, resulting in a long recovery delay and a configuration pollution window. Finally, the reset range is manually and statically defined during the design phase, and cannot be dynamically adjusted according to the actual data path between systems during runtime, which can easily lead to an excessively large reset range or omission of related systems, causing secondary faults such as bus jamming or data corruption. Summary of the Invention

[0005] This application provides a real-time isolated reset device for a heterogeneous CPU 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.

[0006] In a first aspect, embodiments of this application provide a real-time isolation reset device for a heterogeneous CPU system, the device comprising:

[0007] The heterogeneous CPU system includes a security core with hierarchical access control, an application core, and at least one subsystem. When the security core is the parent system, the controlled lower-level system is the application core; when the application core is the parent system, each controlled lower-level system is a subsystem. The address space of the upper-level system contains a configuration register set for controlling the clock and reset of the lower-level system; the lower-level system contains a local mirror register set with contents identical to the register set configured in the upper-level system; the real-time monitoring module contains a mode selector, whose two inputs are connected to the local mirror register set and the configuration register set, respectively, and the output of the mode selector is connected to the clock / reset generation logic of the lower-level system; wherein... The real-time monitoring module communicates with the heterogeneous CPU system to monitor the reset signals of the upper-level and lower-level systems. Based on the state of the reset signal, the control mode selector switches between local mode and upper-level takeover mode. A transaction counter is maintained for each bus. When any system reset assertion is detected, the status of the transaction counter is used to determine whether there are any incomplete bus transactions, and a reset signal is sent to the peer system with incomplete transactions.

[0008] Optionally, depending on the state of the reset signal, the control mode selector switches between local mode and superior takeover mode, including: During the startup phase, the local mirror register group is synchronized to be consistent with the contents of the configuration register group, and the control mode selector is switched to local mode, enabling the lower-level system to run autonomously based on the local mirror register group. When the reset signal indicates that the upper-level system has released its reset, the contents of the local mirror register group and the configuration register group are compared to obtain the comparison result. Based on the comparison result, the control mode selector switches between local mode and upper-level takeover mode; or... When the status of the reset signal indicates that the lower-level system is resetting itself, the control mode selector switches to the upper-level takeover mode. After the lower-level system resets and releases, the local mirror register group is resynchronized to be consistent with the contents of the configuration register group.

[0009] Optionally, based on the comparison results, the control mode selector switches between local mode and superior takeover mode, including: If the comparison result indicates that the contents of the local mirror register set and the configuration register set are consistent, the control mode selector switches to the superior takeover mode; or... If the comparison result indicates that the contents of the local mirror register group and the configuration register group are inconsistent, the superior system first corrects the configuration register group according to the contents of the local mirror register group, and then controls the mode selector to switch to the superior takeover mode.

[0010] Optionally, maintain a transaction counter for each bus, including: Maintain a read-in-transit counter and a write-in-transit counter for each bus; Specifically, the read-in-transit counter increments by one during the read address channel handshake and decrements by one during the last handshake of the read data channel; the write-in-transit counter increments by one during the write address channel handshake and decrements by one during the write response channel handshake. The count values ​​of the read-in-transit counter and the write-in-transit counter are used for bus flow control determination to decide whether to allow the initiation of a new read-write transaction; and as a condition for determining whether to propagate a reset signal to the peer system when any system reset assertion is detected.

[0011] Optionally, when any system reset assertion is detected, the existence of incomplete bus transactions is determined based on the status of the transaction counter, including: When a reset assertion from the upper-level system is detected, it is determined whether the transaction counters on the corresponding bus of the lower-level system it is connected to are all zero. If all values ​​are zero, it is determined that there are no incomplete bus transactions. If any value is non-zero, it indicates that there is an incomplete bus transaction.

[0012] Optionally, when any system reset assertion is detected, the existence of incomplete bus transactions is determined based on the status of the transaction counter, including: When a lower-level system reset assertion is detected, it is determined whether the transaction counters on the corresponding bus of the upper-level system to which it is connected are all zero. If all values ​​are zero, it is determined that there are no incomplete bus transactions. If any value is non-zero, it indicates that there is an incomplete bus transaction.

[0013] Optionally, a reset signal may be sent to the peer system where there are incomplete transactions, including: When a reset assertion from a higher-level system is detected and it is determined that an incomplete bus transaction exists in the connected lower-level system, a reset signal is sent to that lower-level system; or, when a reset assertion from a lower-level system is detected and it is determined that an incomplete bus transaction exists in the connected higher-level system, a reset signal is sent to that higher-level system; wherein, The real-time monitoring module is also used for: during a reset, the local mirror register group of each system is reset along with the system reset, and the mode selector automatically switches to the superior takeover mode; after the fault is cleared, the real-time monitoring module coordinates each system to release the reset signal in a consistent manner, and performs a configuration consistency coordination takeover operation on the superior system that has been reset and released. The consistency coordination takeover operation includes: the superior system reading the content value of the configuration register group saved by the real-time monitoring module before the reset from the real-time monitoring module, and restoring the configuration register group and the local mirror register group to the consistent state before the reset based on the content value; before the next reset occurs, controlling the mode selector to switch back to the local mode.

[0014] Optionally, the upper-level system and the lower-level system are connected via a bus; the real-time monitoring module includes a bus listening module, a reset signal detection subunit, a register comparator, and a mode selector; among which, One end of the bus monitoring module is connected to the upper-level system, the lower-level system, and the bus, respectively, and the other end is connected to the reset signal detection subunit. One end of the reset signal detection subunit is connected to the bus monitoring module, and the other end is connected to the upper-level system, the lower-level system, the register comparator, and the mode selector, respectively. The register comparator and the mode selector are connected to the reset signal detection subunit, the upper-level system, and the lower-level system, respectively. The bus monitoring module is used to monitor read and write transactions on the bus and maintain the read in-transit counter and write in-transit counter for each bus. The reset signal detection subunit is used to monitor the reset signals of the upper-level system and the lower-level system, and send the status of the reset signal to the register comparator and the mode selector. The register comparator is used to compare the contents of the local mirror register group and the configuration register group when the reset signal detection subunit detects the reset release of the upper-level system, and sends the comparison result to the mode selector. The mode selector is used to control the switching between local mode and upper-level takeover mode of the lower-level system based on the reset signal status sent by the reset signal detection subunit and the comparison result sent by the register comparator.

[0015] Optionally, the device is integrated into a single system-on-a-chip (SoC) chip, which includes a security core, an application core, at least one subsystem, and a real-time monitoring module. The security core is a secure boot core, the application core is a general-purpose application load core, the subsystem is interconnected with the application core via an on-chip bus, and the security core accesses the subsystem across levels via the security bus.

[0016] Secondly, a real-time isolation reset method for heterogeneous CPU systems, applied to a real-time monitoring module, includes the following: Monitor the reset signals of the superior and subordinate systems; Based on the state of the reset signal, the control mode selector switches between local mode and superior takeover mode; For each bus, maintain a transaction counter. When any system reset assertion is detected, determine whether there are any incomplete bus transactions based on the status of the transaction counter, and send a reset signal to the peer system with incomplete transactions.

[0017] Optionally, depending on the state of the reset signal, the control mode selector switches between local mode and superior takeover mode, including: During the startup phase, the local mirror register group is synchronized to be consistent with the contents of the configuration register group, and the control mode selector is switched to local mode, enabling the lower-level system to run autonomously based on the local mirror register group. When the status of the reset signal indicates that the upper-level system has been reset and released, the contents of the local mirror register group and the configuration register group are compared to obtain the comparison result. If the comparison result indicates that the contents of the local mirror register group and the configuration register group are consistent, the control mode selector switches to the superior takeover mode; or, if the comparison result indicates that the contents of the local mirror register group and the configuration register group are inconsistent, the superior system first corrects the configuration register group according to the contents of the local mirror register group, and then switches the control mode selector to the superior takeover mode. Alternatively, when the status of the reset signal indicates that the lower-level system is resetting itself, the control mode selector switches to the upper-level takeover mode. After the lower-level system resets and releases, the local mirror register group is resynchronized to be consistent with the contents of the configuration register group.

[0018] In this embodiment, on the one hand, by setting a local mirror register group within the lower-level system that has the same contents as the register group configured within the upper-level system, and by having the real-time monitoring module control the mode selector to switch to local mode according to the reset signal status, the lower-level system can operate autonomously based on the local mirror register group during the upper-level system's reset. Its clock and reset configuration no longer depend on the configuration register group in the upper-level system's address space. Therefore, when the upper-level system resets due to a fault or software upgrade, the lower-level system can independently maintain its own configuration without needing to reset along with the upper-level system, achieving true reset isolation between the upper and lower levels and avoiding the problem of the entire link stopping due to the upper-level system's reset.

[0019] On the other hand, by pre-storing a local mirror register set consistent with the configuration of the upper-level system within the lower-level system, and when the real-time monitoring module detects a reset of the lower-level system, the control mode selector switches to the upper-level takeover mode. After the lower-level system resets and releases, the local mirror register set is directly resynchronized to match the configuration register set. Compared to existing technologies that require waiting for the upper-level system to rewrite the configuration field by field via the bus, this application only needs to complete one switching and synchronization operation of the local register set. Furthermore, throughout the entire recovery process, the configuration of the lower-level system is consistently driven by the local mirror register set or the configuration register set, eliminating configuration gaps and fundamentally eliminating the configuration pollution window.

[0020] On the other hand, a real-time monitoring module maintains a transaction counter for each bus. When any system reset assertion is detected, the status of the transaction counter accurately determines whether there are any incomplete bus transactions, and only issues a reset signal to the peer system with incomplete transactions. This mechanism no longer relies on manual static definition during the design phase, but dynamically determines the reset boundary based on the actual data paths between systems during runtime, automatically converging the reset range to the smallest set of systems with real data associations. Peer systems without incomplete transactions are not reset, which avoids expanding the service interruption surface due to an excessively large reset range, and ensures synchronous reset of associated systems, eliminating secondary faults such as bus state machine jamming or data corruption caused by missing associated systems.

[0021] 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

[0022] 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.

[0023] Figure 1 This is a schematic diagram of the device structure of a real-time isolation reset device for a heterogeneous CPU system provided in an embodiment of this application; Figure 2 This is a schematic diagram of an interaction architecture between a higher-level system and a lower-level system provided in an embodiment of this application; Figure 3 This is a schematic diagram of a reset control process for a heterogeneous CPU system provided in an embodiment of this application; Figure 4 This is a schematic diagram of a bus transaction counting and reset determination logic provided in an embodiment of this application; Figure 5 This is a schematic diagram of a reset collaborative processing and mode switching process provided in an embodiment of this application; Figure 6This is a flowchart illustrating a real-time isolation and reset method for a heterogeneous CPU system provided in an embodiment of this application. Detailed Implementation

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

[0025] 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.

[0026] 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 apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0027] 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.

[0028] Currently, patent application CN119225497A discloses a reset circuit, a reset method, and a multi-core heterogeneous system. This solution, by setting up a monitoring module, a processing module, and a reset control module, selects a target reset signal according to a preset reset mode to achieve selective reset of different modules in a multi-core heterogeneous system.

[0029] The inventors realized that in this technology, when the upper-level system is reset due to a fault or software upgrade, the configuration register group in its address space becomes invalid, causing the lower-level system to lose its clock and reset configuration source, and it has to reset along with the upper-level system, making it impossible to achieve reset isolation between the upper and lower levels; secondly, after the lower-level system is reset, its configuration registers are restored to default values, and it must wait for the upper-level system to rewrite the configuration through the bus before it can resume normal operation, resulting in a long recovery delay and a configuration pollution window; finally, the reset range is manually and statically defined during the design phase, and cannot be dynamically adjusted according to the actual data path between systems during runtime, which can easily lead to an excessively large reset range or omission of related systems, causing secondary faults such as bus jamming or data corruption.

[0030] To address the problems existing in the prior art, in this embodiment, on the one hand, a local mirror register group with the same contents as the register group configured in the upper-level system is set up within the lower-level system. The real-time monitoring module controls the mode selector to switch to local mode based on the reset signal status. This allows the lower-level system to operate autonomously based on the local mirror register group during the upper-level system's reset, and its clock and reset configuration no longer depend on the configuration register group in the upper-level system's address space. Therefore, when the upper-level system resets due to a fault or software upgrade, the lower-level system can independently maintain its own configuration without resetting along with the upper-level system. This achieves true reset isolation between the upper and lower levels, avoiding the problem of the entire link stopping due to the upper-level system's reset.

[0031] On the other hand, by pre-storing a local mirror register set consistent with the configuration of the upper-level system within the lower-level system, and when the real-time monitoring module detects a reset of the lower-level system, the control mode selector switches to the upper-level takeover mode. After the lower-level system resets and releases, the local mirror register set is directly resynchronized to match the configuration register set. Compared to existing technologies that require waiting for the upper-level system to rewrite the configuration field by field via the bus, this application only needs to complete one switching and synchronization operation of the local register set. Furthermore, throughout the entire recovery process, the configuration of the lower-level system is consistently driven by the local mirror register set or the configuration register set, eliminating configuration gaps and fundamentally eliminating the configuration pollution window.

[0032] On the other hand, a transaction counter is maintained for each bus through a real-time monitoring module. When any system reset assertion is detected, the existence of incomplete bus transactions is accurately determined based on the state of the transaction counter, and a reset signal is issued only to the peer system with incomplete transactions. This mechanism no longer relies on manual static definition during the design phase, but dynamically determines the reset boundary based on the actual data path between systems during runtime, so that the reset range automatically converges to the smallest set of systems with real data association. Peer systems without incomplete transactions are not reset, which avoids the expansion of the service interruption surface caused by an excessively large reset range, and ensures synchronous reset of related systems, eliminating secondary faults such as bus state machine jamming or data corruption caused by missing related systems. The following is a detailed description using an exemplary embodiment.

[0033] Please see Figure 1 , Figure 1 This is a schematic diagram of the device structure of a real-time isolation and reset device for a heterogeneous CPU system provided in an embodiment of this application. The device includes a heterogeneous CPU system and a real-time monitoring module. The heterogeneous CPU system includes a security core with hierarchical access control, an application core, and at least one subsystem.

[0034] Among them, the security core refers to the central processing unit with the highest authority, which is responsible for the secure startup of the system and the management of global resources; the application core refers to the central processing unit with the next highest authority, which is responsible for running general application workloads; and the subsystem refers to the dedicated module that undertakes peripheral control or hardware acceleration functions, including but not limited to display controllers, audio DSPs or NPUs.

[0035] Specifically, when the security core is the upper-level system, the controlled lower-level system is the application core; when the application core is the upper-level system, the controlled lower-level systems are each subsystem. The upper-level system's address space contains a configuration register group for controlling the clock and reset of the lower-level system. The lower-level system contains a local mirror register group with contents identical to the register group configured within the upper-level system. The real-time monitoring module includes a mode selector, whose two inputs are connected to the local mirror register group and the configuration register group, respectively, and whose output is connected to the clock / reset generation logic of the lower-level system.

[0036] In this hierarchical hierarchy, the upper-level system refers to the master control unit, which holds a higher position in the hierarchical authority structure and has the authority to configure and reset lower-level systems. The lower-level system refers to the controlled unit, which holds a lower position in the hierarchical authority structure and is controlled and managed by the upper-level system. The configuration register set is a group of registers located in the address space of the upper-level system, used to store configuration parameters controlling the bus clock gating, clock division, reset release, and reset retention of the lower-level system. The local mirror register set is a group of registers located within the lower-level system, whose contents are completely identical to those of the configuration register set within the upper-level system. This allows the lower-level system to independently maintain its own clock and reset configuration even when disconnected from the upper-level system. The mode selector is a selection switch located within the lower-level system. Its two inputs are connected to the local mirror register set and the configuration register set, respectively. Its output is connected to the clock / reset generation logic of the lower-level system, used to select the configuration source currently driving the lower-level system based on control signals. Through this structure, the lower-level system can operate autonomously based on the local mirror register set during the upper-level system's reset, without needing to reset along with the upper-level system, thus achieving reset isolation between the upper and lower levels.

[0037] For example Figure 1 As shown, the CPU0 system (security core) has the highest privileges and is responsible for overall initialization, secure startup, and management of lower-level cores; the CPU1 system (application core) has the next highest privileges, its configuration registers are managed by CPU0, and it further manages the lower-level subsystems; the subsystem SUBn has the lowest privileges, its configuration registers are managed by CPU1, and it undertakes peripheral or acceleration functions, all of which support read and write access by CPU0 and CPU1.

[0038] In one possible implementation, each CPU and subsystem is assigned an independent reset domain, configured with mutually isolated reset signal lines and clock domains; multiple registers storing clock and reset configuration information from lower-level systems are placed within the address space of the higher-level system. For example, a configuration register group, denoted as R, is set up within the CPU0 system to control the CPU1 system bus clock gating, clock division, reset release, and reset retention. CPU0→CPU1 CPU0 controls the clock and reset of the CPU1 system by writing to this set of registers. Within the CPU1 system, a configuration register set, denoted as RCPU1→SUBn, is set up to control the clock and reset of each subsystem (Subsystem 1, Subsystem 2, etc.). CPU1 controls the clock and reset of each subsystem by writing to this set of registers. CPU0 manages and accesses CPU1 via the security bus, while CPU1 manages and accesses SUB1 / SUB2 via the system bus. CPU0 can also read and write to lower-level systems across different levels.

[0039] In addition, register mirroring needs to be configured, for example Figure 2As shown, taking the upper-level system U (CPU0 / CPU1) and its controlled lower-level system i (CPU1 / SUBn) as an example, a local mirror register group R'i is added in the lower-level i, which is completely identical to the upper-level configuration register group RU→i in the upper-level system U (the entire group is mirrored, without explaining the meaning of each bit). Specifically: R′CPU1, which is completely identical to RCPU0→CPU1, is added in the CPU1 system; R′SUBn, which is completely identical to RCPU1→SUBn, is added in each subsystem SUBn. A mode selector MODE[i] is also set in the lower-level i, with two inputs connected to R′i (local) and RU→i (upper-level takeover), and the output is sent to the clock / reset generation logic of the system. At this time, the mirroring enables the controlled system to "carry" a configuration equivalent to the upper-level view, thereby having the ability to maintain its own clock / reset configuration independently without the upper level, providing the material basis for "local autonomous operation".

[0040] In some embodiments of this application, after all the above system configurations are completed, the real-time monitoring module is connected to the heterogeneous CPU system to monitor the reset signals of the upper-level and lower-level systems; according to the state of the reset signal, the control mode selector switches between local mode and upper-level takeover mode; a transaction counter is maintained for each bus, and when any system reset assertion is detected, the status of the transaction counter is used to determine whether there are any incomplete bus transactions, and a reset signal is sent to the peer system with incomplete transactions.

[0041] The real-time monitoring module refers to a hardware logic unit coupled to the heterogeneous CPU system, used to monitor the reset status of each system in real time and coordinate reset operations. The reset signal is a digital level signal that characterizes whether the system is in a reset state, including both active high and active low forms. The reset signal state includes reset assertion state and reset release state. Reset assertion means the reset signal is activated to an active level, indicating that the corresponding system has begun the reset process; reset release means the reset signal is deactivated to an inactive level, indicating that the corresponding system has exited the reset process and resumed operation.

[0042] In this context, "local mode" refers to the operating mode where the mode selector chooses the local mirror register set as the output source. In this mode, the lower-level system operates independently based on its own configuration. "Upper-level takeover mode" refers to the operating mode where the mode selector chooses the configuration register set of the upper-level system as the output source. In this mode, the configuration of the lower-level system is directly controlled by the upper-level system. "Bus" refers to the on-chip communication channel connecting the upper-level and lower-level systems, including but not limited to AMBA, AXI, AHB, or APB bus protocols.

[0043] Herein, the transaction counter refers to a register disposed inside the real-time monitoring module for recording the number of outstanding read and write transactions on the bus, including a read in-flight counter and a write in-flight counter; the read in-flight counter increments upon handshake of the read address channel and decrements upon handshake of the last beat of the read data channel; the write in-flight counter increments upon handshake of the write address channel and decrements upon handshake of the write response channel. An outstanding bus transaction refers to a bus read / write operation for which an address request has been initiated but data transmission has not been completed, and its corresponding count value in the transaction counter is non-zero. The peer system refers to another system directly connected via the bus to the system where reset occurs, including an upper-level system or a lower-level system. The reset signal refers to a control signal issued by the real-time monitoring module for triggering the peer system to enter a reset state. Accordingly, the real-time monitoring module dynamically switches the working mode of the mode selector according to the state of the reset signal, and accurately determines the reset propagation range based on the real-time value of the transaction counter, so as to realize linkage reset in the minimum range.

[0044] In some embodiments of the present application, the specific process of controlling the mode selector to switch between the local mode and the upper-level takeover mode according to the state of the reset signal includes: in the startup phase, synchronizing the local mirror register set to be consistent with the content of the configuration register set, and controlling the mode selector to switch to the local mode, so that the lower-level system operates independently based on the local mirror register set; when the state of the reset signal indicates that the upper-level system reset is released, comparing whether the content of the local mirror register set is consistent with that of the configuration register set to obtain a comparison result; controlling the mode selector to switch between the local mode and the upper-level takeover mode according to the comparison result; or, when the state of the reset signal indicates that the lower-level system itself is reset, controlling the mode selector to switch to the upper-level takeover mode, and resynchronizing the local mirror register set to be consistent with the content of the configuration register set after the lower-level system reset is released.

[0045] Herein, synchronization refers to the process of writing the value of each register in the local mirror register set one by one to be the same as the value of each corresponding register in the configuration register set, so as to ensure that the contents of the two are completely equivalent. After the synchronization is completed, the real-time monitoring module controls the mode selector to switch to the local mode, so that the lower-level system operates independently based on the local mirror register set. Independent operation means that the lower-level system does not rely on real-time intervention from the upper-level system, and maintains a normal clock frequency and reset state only by means of the configuration parameters in the locally carried local mirror register set.

[0046] The comparison result refers to the logic signal output by the register comparator inside the real-time monitoring module after comparing the contents of the two sets of registers bit by bit. This includes two states: a consistent signal and an inconsistent signal. A consistent signal indicates that the contents of the local mirror register set and the configuration register set are completely identical, indicated by a high or low level flag output by the comparator. An inconsistent signal indicates that the contents of the two register sets differ by at least one bit, indicated by an opposite level flag output by the comparator. Specifically, when the comparison result is a consistent signal, the control mode selector switches to the superior takeover mode, allowing the superior system to directly take over the configuration control of the subordinate system. When the comparison result is an inconsistent signal, the superior system first corrects the configuration register set according to the contents of the local mirror register set. Correction refers to the process of rewriting the values ​​of each register in the configuration register set to be consistent with the local mirror register set, and then the control mode selector switches to the superior takeover mode.

[0047] Specifically, based on the comparison results, the process of switching the control mode selector between local mode and superior takeover mode includes: if the comparison result indicates that the contents of the local mirror register group and the configuration register group are consistent, the control mode selector switches to superior takeover mode; or, if the comparison result indicates that the contents of the local mirror register group and the configuration register group are inconsistent, the superior system first corrects the configuration register group according to the contents of the local mirror register group, and then the control mode selector switches to superior takeover mode.

[0048] Specifically, when the reset signal indicates that the lower-level system is resetting, the real-time monitoring module switches the control mode selector to the upper-level takeover mode. After the lower-level system releases its reset, the local mirror register group is resynchronized to match the configuration register group. Resynchronization refers to updating the contents of the local mirror register group to match the configuration register group again after the lower-level system exits the reset state, ensuring that the lower-level system has the correct configuration parameters when running in local mode subsequently.

[0049] In one possible implementation, the monitoring module simultaneously monitors the reset signal of the upper-level system and the reset signal of the lower-level system itself, and combines them with... Figure 2 The four action nodes drive MODE[i] via comparators and control lines: First, R′i←RU→i (the local mirror group is written exactly the same as the upper level), then MODE[i]=LOCAL (local mode) is set, switching to autonomous operation using the local register group. Thereafter, during normal operation, the lower level always drives the clock / reset logic using the local mirror group.

[0050] Secondly, when the monitoring module detects that the upper-level system has been reset and released, it compares whether R′i and RU→i are consistent: if they are consistent, it directly sets MODE[i]=TAKEOVER (upper-level takeover mode); if they are inconsistent, it first modifies RU→i←R′i (modifies the upper-level register according to the local mirror group content) based on the contents of the lower-level local register group, and then sets MODE[i]=TAKEOVER.

[0051] Finally, when the monitoring module detects that the lower-level system has reset, it immediately sets MODE[i] = TAKEOVER (upper-level takeover mode) and returns control of the lower-level system to the upper-level system (because the local mirror group R′i is pushed back to the default value and is unreliable during the lower-level reset); when the lower-level reset is detected to be released, R′i←RU→i (resynchronize the local mirror group to be consistent with the upper-level content), and maintains TAKEOVER until the next upper-level reset before switching back uniformly.

[0052] Furthermore, before the next reset of the upper level occurs, MODE[i] is set to LOCAL to restore the lower level's isolated operation based on the local mirror group.

[0053] It should be noted that, since the lower-level system operates in LOCAL mode during normal operation, it runs independently of the local mirror group R′i during the upper-level system reset, without relying on the upper-level system. Its configuration is not polluted by the upper-level reset (isolated reset). After the upper-level system resets, a consistency comparison is performed, and the system either takes over directly or converges first and then takes over, thus achieving configuration coordination between the upper and lower levels without creating a pollution window. However, when the lower-level system resets itself, control is first returned to the upper-level system, and the monitoring module resynchronizes the local mirror group after the reset is released, preventing the lower-level system from running incorrectly with default values. Compared to the traditional "waiting for the upper-level system to reconfigure field by field after reset," recovery is only a single switch / coordination of the local register group, without waiting for the upper-level system to reconfigure via the bus, thus significantly reducing configuration recovery latency.

[0054] For example Figure 3 As shown, Figure 3 This application provides a schematic diagram of a reset control flow for a heterogeneous CPU system. First, during the startup phase, the local mirror register set and configuration register set are synchronized. Then, the system switches to local mode to allow the lower-level system to run autonomously. Next, the system enters the reset signal status judgment stage. If a reset release from the upper-level system is detected, the contents of the local mirror register set and configuration register set are compared. If they match, the system directly switches to the upper-level takeover mode. If they do not match, the upper-level system corrects the configuration register set before switching back to the upper-level takeover mode. If a reset of the lower-level system itself is detected, the system switches to the upper-level takeover mode. After the lower-level system releases its reset, the local mirror register set is resynchronized, ultimately completing the reset control flow loop and ensuring that the system achieves configuration self-consistency and minimum-range isolation during the reset process.

[0055] In some embodiments of this application, the specific process of maintaining a transaction counter for each bus includes: maintaining a read-in-transit counter and a write-in-transit counter for each bus; wherein, the read-in-transit counter is incremented by one during the read address channel handshake and decremented by one during the last handshake of the read data channel; the write-in-transit counter is incremented by one during the write address channel handshake and decremented by one during the write response channel handshake. The count values ​​of the read-in-transit counter and the write-in-transit counter are also used for bus flow control determination to decide whether to allow the initiation of a new read / write transaction; and as a condition for determining whether to propagate a reset signal to the peer system when any system reset assertion is detected.

[0056] The read-in-transit counter is a register used to record the number of incomplete read transactions on the bus, and its initial value is zero. The write-in-transit counter is a register used to record the number of incomplete write transactions on the bus, and its initial value is zero. A read transaction refers to a data read operation initiated by a master device to a slave device, including two stages: address request on the read address channel and data return on the read data channel. A write transaction refers to a data write operation initiated by a master device to a slave device, including three stages: address request on the write address channel, data transfer on the write data channel, and completion confirmation on the write response channel.

[0057] The read address channel handshake refers to the moment when the master device sends a read address signal on the read address channel and the slave device confirms receipt; at this time, the read-in-transit counter increments by one. The read data channel final handshake refers to the moment when the slave device sends the last data on the read data channel and the master device confirms receipt; at this time, the read-in-transit counter decrements by one. The write address channel handshake refers to the moment when the master device sends a write address signal on the write address channel and the slave device confirms receipt; at this time, the write-in-transit counter increments by one. The write response channel handshake refers to the moment when the slave device sends a write completion response on the write response channel and the master device confirms receipt; at this time, the write-in-transit counter decrements by one. Through the above counting mechanism, the read-in-transit counter and the write-in-transit counter can reflect the number of incomplete read and write transactions on each bus in real time, providing a quantitative basis for the accurate determination of the subsequent reset range.

[0058] In one possible implementation, the bus monitoring subunit of the real-time monitoring module simultaneously monitors the security bus, system bus 1, system bus 2, and system bus 3, maintaining a read-in-transit counter ar_cnt and a write-in-transit counter aw_cnt for each bus. ar_cnt is incremented by one during the read address channel (AR) handshake and decremented by one during the last handshake of the read data channel (RLAST); aw_cnt is incremented by one during the write address channel (AW) handshake and decremented by one during the write response channel (B) handshake.

[0059] In some embodiments of this application, when any system reset assertion is detected, the specific process of determining whether there are any incomplete bus transactions based on the state of the transaction counter includes: when a reset assertion of the upper-level system is detected, determining whether the transaction counters on the corresponding buses of the lower-level systems connected to it are all zero; if they are all zero, determining that there are no incomplete bus transactions; if any one is non-zero, determining that there are incomplete bus transactions.

[0060] The reset assertion refers to the moment when the reset signal is activated to an active level, indicating that the corresponding system has entered the reset process. The transaction counter status refers to the current value combination of the read-in-transit counter and the write-in-transit counter, including three cases: both zero, either non-zero, or both non-zero. Both zero means that the values ​​of both the read-in-transit counter and the write-in-transit counter are equal to zero, indicating that there are no initiated but incomplete read / write transactions on the bus, i.e., the bus is in an idle state. Either non-zero means that at least one of the read-in-transit counters is not equal to zero, indicating that there is at least one initiated but incomplete read / write transaction on the bus, i.e., the bus is in a busy state. If both values ​​are zero, it is determined that there are no incomplete bus transactions. This means there are no pending read / write operations on the bus, and the peer system does not need to be reset. If any value is non-zero, it is determined that there are incomplete bus transactions. This means there is still at least one read / write operation on the bus that has not completed data transmission, indicating an unresolved data dependency between the peer system and the reset system. The peer system needs to be reset as well to prevent the bus state machine from freezing or data corruption. Through this determination logic, the real-time monitoring module can accurately identify the lower-level systems that need to be reset synchronously when the upper-level system is reset, avoiding accidental resets of unrelated systems and achieving adaptive convergence of the reset range.

[0061] In one possible implementation, when the real-time monitoring module detects any system reset assertion, it distinguishes between upper-level reset and lower-level reset: for upper-level reset assertions, it checks whether ar_cnt / aw_cnt are both zero on each bus: if both are zero, there are no residual transactions on that bus and the connected lower level is not reset; if either is non-zero, there are incomplete transactions and a reset signal is sent to that lower level. In some embodiments of this application, when any system reset assertion is detected, the specific process of determining whether there is an incomplete bus transaction based on the state of the transaction counter includes: when a lower-level system reset assertion is detected, determining whether the transaction counters on the bus corresponding to the upper-level system to which it is connected are all zero; if they are all zero, determining that there is no incomplete bus transaction; if any one is non-zero, determining that there is an incomplete bus transaction.

[0062] The lower-level system reset assertion refers to the moment when the lower-level system's reset signal is activated to an active level, indicating that the lower-level system has entered the reset process due to a fault or external trigger. The corresponding upper-level system bus refers to the on-chip communication channel connecting the lower-level system and its direct upper-level system; this bus carries all read and write transactions between them. Transaction counters include read-in-progress and write-in-progress counters, whose current values ​​reflect the number of incomplete read and write transactions on the bus. If both are zero (i.e., the values ​​of both the read-in-progress and write-in-progress counters are equal to zero), it is determined that there are no incomplete bus transactions, indicating that the upper-level system has no pending read / write operations waiting for a response from the lower-level system at the time of the lower-level system reset; therefore, the upper-level system does not need to reset along with the lower-level system. If either the read-in-progress counter or the write-in-progress counter is non-zero, it indicates the existence of an incomplete bus transaction. This means the upper-level system has sent at least one read / write transaction to the lower-level system but has not yet received data or confirmation. An unresolved data dependency exists between the upper and lower-level systems. If the upper-level system is not reset, its bus state machine will become permanently stuck waiting for a response that will never arrive, potentially leading to data corruption or system crash. Through this logic, the real-time monitoring module can accurately identify the upper-level systems that need to be reset synchronously when the lower-level system is reset. This minimizes the reset range while ensuring cross-system state consistency, preventing secondary failures caused by overlooking related systems.

[0063] For example Figure 4 As shown, Figure 4 This application provides a schematic diagram of a bus transaction counting and reset determination logic. First, a read-in-transit counter and a write-in-transit counter are maintained for each bus. The read-in-transit counter is incremented by one during the read address channel handshake and decremented by one during the last handshake of the read data channel. The write-in-transit counter is incremented by one during the write address channel handshake and decremented by one during the write response channel handshake. Subsequently, when any system reset assertion is detected, two determination paths are triggered in parallel: first, it is determined whether the transaction counters on the corresponding bus of the lower-level system are all zero; second, it is determined whether the transaction counters on the corresponding bus of the upper-level system are all zero. If both determination results are zero, it is finally determined that there are no incomplete transactions. If either determination result is non-zero, it is finally determined that there are incomplete transactions, thereby achieving accurate identification and minimization control of the reset impact range.

[0064] In some embodiments of this application, the specific process of issuing a reset signal to a peer system with incomplete transactions includes: when a reset assertion of an upper-level system is detected and it is determined that there are incomplete bus transactions in the lower-level system it is connected to, a reset signal is issued to the lower-level system; or, when a reset assertion of a lower-level system is detected and it is determined that there are incomplete bus transactions in the upper-level system it is connected to, a reset signal is issued to the upper-level system. The real-time monitoring module is also used for: during a reset, the local mirror register group of each system is reset along with the system reset, and the mode selector automatically switches to the superior takeover mode; after the fault is cleared, the real-time monitoring module coordinates each system to release the reset signal in a consistent manner, and performs a configuration consistency coordination takeover operation on the superior system that has been reset and released. The consistency coordination takeover operation includes: the superior system reading the content value of the configuration register group saved by the real-time monitoring module before the reset from the real-time monitoring module, and restoring the configuration register group and the local mirror register group to the consistent state before the reset based on the content value; before the next reset occurs, controlling the mode selector to switch back to the local mode.

[0065] It should be noted that since both the upper and lower levels are reset, the registers automatically switch to the upper level MODE[i] = TAKEOVER. After the reset is released, the two sets of registers need to be configured to be consistent before switching to the local mode MODE[i] = LOCAL before the next reset.

[0066] It should be noted that the clock of the real-time monitoring module is independent of the system. During normal system operation, it stores the register contents before the reset in real time. After the system reset is completed, the upper level reads the values ​​of the register contents saved by the monitoring module to restore the two sets of registers to their pre-reset configuration.

[0067] The real-time monitoring module operates in a normally-on power domain and an independent clock domain, which are independent of each CPU system in the heterogeneous CPU system. The transaction counter and the latched configuration state inside the real-time monitoring module are kept intact during the reset of the upper-level system or the lower-level system.

[0068] In one possible implementation, during a lower-level reset assertion, the system checks if both ar_cnt and aw_cnt are zero on the bus connecting the lower-level system and its parent system. If both are zero, the parent system is not reset; otherwise, a reset signal is sent to the parent system of the lower-level system. During the reset, each system maintains its local mirror group R′. After the fault is cleared, the system releases in a coordinated manner and performs a consistent takeover / convergence process on the reset and released parent system. Before the next reset, the system switches back to the local mirror group.

[0069] For example Figure 5 As shown, Figure 5This application provides a schematic diagram of a reset coordination process and mode switching process. First, after determining that there are incomplete transactions, a reset signal is sent to the peer system. Then, during the reset, the local mirror register groups of each system are reset along with the system reset, and the mode selector automatically switches to the superior takeover mode. After the fault is cleared, the reset signal is released in a coordinated manner to ensure the reset timing of the upper and lower level systems is synchronized. Subsequently, configuration consistency coordination takeover is performed on the superior system that was released by the reset to rebuild the configuration alignment relationship between the systems. Finally, before the next reset, the system switches back to the local mode to restore the system's autonomous operation capability, thereby achieving closed-loop control of transaction security isolation, stable configuration state maintenance, and orderly switching of system modes throughout the entire reset cycle.

[0070] It should be noted that the reset range is determined precisely in both directions based on the real-time status of the in-transit counter. When the upper level resets, it only resets the lower-level subsystems with incomplete bus transactions (ar_cnt≠0 or aw_cnt≠0), and when the lower level resets, it only resets the upper-level system with incomplete transactions. The peer without residual transactions is not affected. Therefore, the reset range automatically converges to the minimum in either direction. At the same time, residual transactions are accurately detected and processed, avoiding bus state machine jamming and data corruption, and achieving coordinated and consistent reset of multiple systems within the minimum range.

[0071] It is important to note that the purpose of the transaction counter in this application differs fundamentally from the in-transit transaction tracking in conventional bus protocols. In conventional bus protocols such as AMBA and AXI, in-transit transaction counting is primarily used for bus flow control and QoS arbitration, i.e., determining whether new read / write transactions should be allowed. This application creatively introduces the in-transit transaction count into a reset decision domain, using it as the criterion for determining whether a reset signal should propagate across the system: when a reset assertion is detected, the real-time monitoring module does not simply prevent new transactions from being issued (as is the conventional flow control purpose), but instead uses the zero / non-zero state of the transaction counter as the condition for determining the scope of reset propagation.

[0072] In some embodiments of this application, the upper-level system and the lower-level system are connected via a bus; the real-time monitoring module includes a bus monitoring module, a reset signal detection subunit, a register comparator, and a mode selector; wherein, one end of the bus monitoring module is connected to the upper-level system, the lower-level system, and the bus, and the other end is connected to the reset signal detection subunit; one end of the reset signal detection subunit is connected to the bus monitoring module, and the other end is connected to the upper-level system, the lower-level system, the register comparator, and the mode selector; the register comparator and the mode selector are connected to the reset signal detection subunit, the upper-level system, and the lower-level system, respectively.

[0073] Specifically, the bus monitoring module is used to monitor read and write transactions on the bus and maintain read-in-transit counters and write-in-transit counters for each bus; the reset signal detection subunit is used to monitor the reset signals of the upper-level and lower-level systems and send the status of the reset signals to the register comparator and the mode selector; the register comparator is used to compare the contents of the local mirror register group and the configuration register group when the reset signal detection subunit detects a reset release from the upper-level system, and send the comparison result to the mode selector; the mode selector is used to control the lower-level system to switch between local mode and upper-level takeover mode based on the reset signal status sent by the reset signal detection subunit and the comparison result sent by the register comparator.

[0074] Specifically, the device is integrated into a single System-on-a-Chip (SoC) chip, which includes a security core, an application core, at least one subsystem, and a real-time monitoring module. The security core is a secure boot core, the application core is a general-purpose application load core, the subsystem is interconnected with the application core via an on-chip bus, and the security core can access the subsystem across levels via the security bus.

[0075] In this embodiment, on the one hand, by setting a local mirror register group within the lower-level system that has the same contents as the register group configured within the upper-level system, and by having the real-time monitoring module control the mode selector to switch to local mode according to the reset signal status, the lower-level system can operate autonomously based on the local mirror register group during the upper-level system's reset. Its clock and reset configuration no longer depend on the configuration register group in the upper-level system's address space. Therefore, when the upper-level system resets due to a fault or software upgrade, the lower-level system can independently maintain its own configuration without needing to reset along with the upper-level system, achieving true reset isolation between the upper and lower levels and avoiding the problem of the entire link stopping due to the upper-level system's reset.

[0076] On the other hand, by pre-storing a local mirror register set consistent with the configuration of the upper-level system within the lower-level system, and when the real-time monitoring module detects a reset of the lower-level system, the control mode selector switches to the upper-level takeover mode. After the lower-level system resets and releases, the local mirror register set is directly resynchronized to match the configuration register set. Compared to existing technologies that require waiting for the upper-level system to rewrite the configuration field by field via the bus, this application only needs to complete one switching and synchronization operation of the local register set. Furthermore, throughout the entire recovery process, the configuration of the lower-level system is consistently driven by the local mirror register set or the configuration register set, eliminating configuration gaps and fundamentally eliminating the configuration pollution window.

[0077] On the other hand, a real-time monitoring module maintains a transaction counter for each bus. When any system reset assertion is detected, the status of the transaction counter accurately determines whether there are any incomplete bus transactions, and only issues a reset signal to the peer system with incomplete transactions. This mechanism no longer relies on manual static definition during the design phase, but dynamically determines the reset boundary based on the actual data paths between systems during runtime, automatically converging the reset range to the smallest set of systems with real data associations. Peer systems without incomplete transactions are not reset, which avoids expanding the service interruption surface due to an excessively large reset range, and ensures synchronous reset of associated systems, eliminating secondary faults such as bus state machine jamming or data corruption caused by missing associated systems.

[0078] Please see Figure 6 This document provides a flowchart illustrating a real-time isolation and reset method for a heterogeneous CPU system, applicable to a real-time monitoring module. Figure 6 As shown, the detection method in this application embodiment may include the following steps: S101 monitors the reset signals of the upper-level system and the lower-level system; S102, depending on the state of the reset signal, the control mode selector switches between local mode and superior takeover mode; In some embodiments of this application, during the startup phase, the local mirror register group is synchronized to be consistent with the configuration register group, and the mode selector is switched to local mode, enabling the lower-level system to run autonomously based on the local mirror register group. When the status of the reset signal indicates that the upper-level system has reset and released, the contents of the local mirror register group and the configuration register group are compared to obtain a comparison result. If the comparison result indicates that the contents of the local mirror register group and the configuration register group are consistent, the mode selector is switched to upper-level takeover mode. Alternatively, if the comparison result indicates that the contents of the local mirror register group and the configuration register group are inconsistent, the upper-level system first corrects the configuration register group according to the contents of the local mirror register group, and then the mode selector is switched to upper-level takeover mode. Alternatively, when the status of the reset signal indicates that the lower-level system has reset itself, the mode selector is switched to upper-level takeover mode, and after the lower-level system has reset and released, the local mirror register group is resynchronized to be consistent with the contents of the configuration register group.

[0079] S103 maintains a transaction counter for each bus. When any system reset assertion is detected, it determines whether there are any incomplete bus transactions based on the status of the transaction counter and sends a reset signal to the peer system with incomplete transactions.

[0080] In this embodiment, on the one hand, by setting a local mirror register group within the lower-level system that has the same contents as the register group configured within the upper-level system, and by having the real-time monitoring module control the mode selector to switch to local mode according to the reset signal status, the lower-level system can operate autonomously based on the local mirror register group during the upper-level system's reset. Its clock and reset configuration no longer depend on the configuration register group in the upper-level system's address space. Therefore, when the upper-level system resets due to a fault or software upgrade, the lower-level system can independently maintain its own configuration without needing to reset along with the upper-level system, achieving true reset isolation between the upper and lower levels and avoiding the problem of the entire link stopping due to the upper-level system's reset.

[0081] On the other hand, by pre-storing a local mirror register set consistent with the configuration of the upper-level system within the lower-level system, and when the real-time monitoring module detects a reset of the lower-level system, the control mode selector switches to the upper-level takeover mode. After the lower-level system resets and releases, the local mirror register set is directly resynchronized to match the configuration register set. Compared to existing technologies that require waiting for the upper-level system to rewrite the configuration field by field via the bus, this application only needs to complete one switching and synchronization operation of the local register set. Furthermore, throughout the entire recovery process, the configuration of the lower-level system is consistently driven by the local mirror register set or the configuration register set, eliminating configuration gaps and fundamentally eliminating the configuration pollution window.

[0082] On the other hand, a real-time monitoring module maintains a transaction counter for each bus. When any system reset assertion is detected, the status of the transaction counter accurately determines whether there are any incomplete bus transactions, and only issues a reset signal to the peer system with incomplete transactions. This mechanism no longer relies on manual static definition during the design phase, but dynamically determines the reset boundary based on the actual data paths between systems during runtime, automatically converging the reset range to the smallest set of systems with real data associations. Peer systems without incomplete transactions are not reset, which avoids expanding the service interruption surface due to an excessively large reset range, and ensures synchronous reset of associated systems, eliminating secondary faults such as bus state machine jamming or data corruption caused by missing associated systems.

[0083] 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 real-time isolation reset of heterogeneous CPU systems 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 real-time isolation reset of heterogeneous CPU systems can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0084] 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. A real-time isolation reset device for a heterogeneous CPU system, characterized in that, The device includes: A heterogeneous CPU system and a real-time monitoring module are provided. The heterogeneous CPU system includes a security core with hierarchical access control, an application core, and at least one subsystem. When the security core is the upper-level system, the controlled lower-level system is the application core. When the application core is the upper-level system, each controlled lower-level system is a subsystem. The address space of the upper-level system contains a configuration register group for controlling the clock and reset of the lower-level system; the lower-level system contains a local mirror register group with contents identical to the register group configured in the upper-level system; the real-time monitoring module includes a mode selector, whose two inputs are connected to the local mirror register group and the configuration register group, respectively, and whose output is connected to the clock / reset generation logic of the lower-level system; wherein... The real-time monitoring module is communicatively connected to the heterogeneous CPU system and is used to monitor the reset signals of the upper-level system and the lower-level system. Based on the state of the reset signal, it controls the mode selector to switch between local mode and upper-level takeover mode, including: during the startup phase, synchronizing the local mirror register group to be consistent with the contents of the configuration register group, and controlling the mode selector to switch to local mode, enabling the lower-level system to run autonomously based on the local mirror register group; when the state of the reset signal indicates that the upper-level system has released its reset, comparing the contents of the local mirror register group and the configuration register group to obtain a comparison result; and based on the comparison result, controlling the mode selector to switch between local mode and upper-level takeover mode. Switching between upper-level takeover modes; when the status of the reset signal indicates that the lower-level system itself is resetting, the mode selector is controlled to switch to upper-level takeover mode. After the lower-level system releases its reset, the local mirror register group is resynchronized to be consistent with the contents of the configuration register group; a transaction counter is maintained for each bus. When any system reset assertion is detected, the status of the transaction counter is used to determine whether there are any incomplete bus transactions, and a reset signal is issued to the peer system with incomplete transactions; the peer system refers to another system directly connected to the system that has been reset via the bus, including upper-level or lower-level systems; the reset signal refers to the control signal issued by the real-time monitoring module to trigger the peer system to enter the reset state.

2. The apparatus according to claim 1, characterized in that, The step of controlling the mode selector to switch between local mode and superior takeover mode based on the comparison result includes: If the comparison result indicates that the contents of the local mirror register group and the configuration register group are consistent, the mode selector is controlled to switch to the superior takeover mode; or... If the comparison result indicates that the contents of the local mirror register group and the configuration register group are inconsistent, the upper-level system first corrects the configuration register group according to the contents of the local mirror register group, and then controls the mode selector to switch to the upper-level takeover mode.

3. The apparatus according to claim 1, characterized in that, The maintenance of a transaction counter for each bus includes: Maintain a read-in-transit counter and a write-in-transit counter for each bus; Specifically, the read-in-transit counter increments by one during the read address channel handshake and decrements by one during the last handshake of the read data channel; the write-in-transit counter increments by one during the write address channel handshake and decrements by one during the write response channel handshake. The count values ​​of the read-in-transit counter and the write-in-transit counter are used for bus flow control determination to decide whether to allow the initiation of a new read-write transaction; and as a condition for determining whether to propagate a reset signal to the peer system when any system reset assertion is detected.

4. The apparatus according to claim 1, characterized in that, When any system reset assertion is detected, determining whether there are any incomplete bus transactions based on the state of the transaction counter includes: When the upper-level system reset assertion is detected, it is determined whether the transaction counters on the corresponding bus of the lower-level system to which it is connected are all zero; If all values ​​are zero, it is determined that there are no incomplete bus transactions. If any value is non-zero, it indicates that there is an incomplete bus transaction.

5. The apparatus according to claim 1, characterized in that, When any system reset assertion is detected, determining whether there are any incomplete bus transactions based on the state of the transaction counter includes: When a reset assertion of the lower-level system is detected, it is determined whether the transaction counters on the bus corresponding to the upper-level system to which it is connected are all zero. If all values ​​are zero, it is determined that there are no incomplete bus transactions. If any value is non-zero, it indicates that there is an incomplete bus transaction.

6. The apparatus according to claim 4 or 5, characterized in that, The step of issuing a reset signal to the peer system with incomplete transactions includes: When a reset assertion is detected in the upper-level system and it is determined that there are incomplete bus transactions in the lower-level system it is connected to, a reset signal is sent to the lower-level system; or, when a reset assertion is detected in the lower-level system and it is determined that there are incomplete bus transactions in the upper-level system it is connected to, a reset signal is sent to the upper-level system; wherein, The real-time monitoring module is also used for: during a reset, the local mirror register group of each system is reset along with the system reset, and the mode selector automatically switches to the superior takeover mode; after the fault is cleared, the real-time monitoring module coordinates each system to release the reset signal in a consistent manner, and performs a configuration consistency coordination takeover operation on the superior system that has been reset and released. The consistency coordination takeover operation includes: the superior system reading the content value of the configuration register group saved by the real-time monitoring module before the reset from the real-time monitoring module, and restoring the configuration register group and the local mirror register group to the consistent state before the reset based on the content value; before the next reset occurs, controlling the mode selector to switch back to the local mode.

7. The apparatus according to claim 1, characterized in that, The upper-level system and the lower-level system are connected via a bus; the real-time monitoring module includes a bus listening module, a reset signal detection subunit, a register comparator, and a mode selector; wherein... One end of the bus monitoring module is connected to the upper-level system, the lower-level system, and the bus, respectively, and the other end is connected to the reset signal detection subunit; one end of the reset signal detection subunit is connected to the bus monitoring module, and the other end is connected to the upper-level system, the lower-level system, the register comparator, and the mode selector, respectively; the register comparator and the mode selector are respectively connected to the reset signal detection subunit, the upper-level system, and the lower-level system; wherein... The bus monitoring module is used to monitor read and write transactions on the bus and maintain read in-transit counters and write in-transit counters for each bus. The reset signal detection subunit is used to monitor the reset signals of the upper-level system and the lower-level system, and send the status of the reset signal to the register comparator and the mode selector; The register comparator is used to compare the contents of the local mirror register group and the configuration register group when the reset signal detection subunit detects the upper-level system reset release, and send the comparison result to the mode selector. The mode selector is used to control the lower-level system to switch between local mode and upper-level takeover mode based on the reset signal status sent by the reset signal detection subunit and the comparison result sent by the register comparator.

8. The apparatus according to claim 1, characterized in that, The device is integrated into a single System-on-a-Chip (SoC) chip. The SoC chip includes the security core, the application core, the at least one subsystem, and the real-time monitoring module. The security core is a secure boot core, the application core is a general-purpose application load core, the subsystem is interconnected with the application core via an on-chip bus, and the security core accesses the subsystem across levels via the security bus.

9. A real-time isolation reset method for a heterogeneous CPU system implemented using the apparatus according to any one of claims 1-8, characterized in that, The method, applied to the real-time monitoring module, includes: Monitor the reset signals of the upper-level system and the lower-level system; Based on the state of the reset signal, the mode selector is controlled to switch between local mode and superior takeover mode; For each bus, maintain a transaction counter. When any system reset assertion is detected, determine whether there are any incomplete bus transactions based on the state of the transaction counter, and issue a reset signal to the peer system with incomplete transactions.

10. The method according to claim 9, characterized in that, The step of controlling the mode selector to switch between local mode and superior takeover mode based on the state of the reset signal includes: During the startup phase, the local mirror register group is synchronized to be consistent with the contents of the configuration register group, and the mode selector is controlled to switch to local mode, so that the lower-level system can run autonomously based on the local mirror register group. When the status of the reset signal indicates that the upper-level system has been reset and released, the contents of the local mirror register group and the configuration register group are compared to obtain the comparison result. If the comparison result indicates that the contents of the local mirror register group and the configuration register group are consistent, the mode selector is controlled to switch to the upper-level takeover mode; or, if the comparison result indicates that the contents of the local mirror register group and the configuration register group are inconsistent, the upper-level system first corrects the configuration register group according to the contents of the local mirror register group, and then controls the mode selector to switch to the upper-level takeover mode. Alternatively, when the status of the reset signal indicates that the lower-level system is resetting itself, the mode selector is controlled to switch to the upper-level takeover mode, and after the lower-level system resets and releases, the local mirror register group is resynchronized to be consistent with the contents of the configuration register group.

Images