Cross-domain wake-up interrupt controller and heterogeneous multi-core chip

Abstract

This invention provides a cross-domain wake-up interrupt controller and a heterogeneous multi-core chip, comprising an event-driven wake-up module deployed in each sub-power domain participating in cross-domain communication, and a central coordination module deployed in the system hardware power management module. When a source sub-power domain needs to communicate with a destination sub-power domain in a low-power state, its event-driven wake-up module sends a wake-up request. The central coordination module is responsible for receiving the wake-up request and coordinating the system hardware power management module to wake up the corresponding destination sub-power domain. Once the destination sub-power domain is ready, the central coordination module immediately notifies the source sub-power domain to begin data transmission. This invention adopts an event-driven, fine-grained power management approach, achieving efficient cross-domain wake-up and data interaction, significantly improving the system's response speed and power optimization capabilities, ultimately enabling the entire system to achieve ultra-low power control while ensuring performance.

Description

Technical Field

[0001] This invention relates to the field of integrated circuit design technology, and in particular to a cross-domain wake-up interrupt controller and a heterogeneous multi-core chip. Background Technology

[0002] To achieve ultra-low power consumption, modern System-on-a-Chip (SoC) typically comprises multiple independent power domains and heterogeneous subsystems, such as a digital core domain (Application core), connectivity modules (CNNT cores, such as Bluetooth and WiFi), and audio modules (AUDIO cores). These subsystems can enter various low-power states (such as Lightsleep or Deepsleep) when not in use to conserve power. However, in complex heterogeneous multi-core architectures, achieving low-power state coordination and efficient communication between subsystems while maximizing power efficiency has become a key design challenge. Traditional power management methods often struggle to balance overall system power performance with the flexible and real-time interaction requirements between subsystems.

[0003] In existing SoC designs, centralized or distributed power management strategies are typically employed. Centralized power management, such as ARM's System Control Processor (SCP), centrally manages the SoC's power and clock states through an independent microcontroller running dedicated firmware, coordinating power domain transitions and dynamic voltage-frequency adjustment (DVFS), and enforcing power dependency rules. However, this firmware-based coordination mechanism has significant shortcomings: every power state switch or cross-domain access request by the SCP requires firmware intervention, introducing software overhead and latency, making it difficult to support fast-response, fine-grained wake-up. This reduces the power management autonomy of the subsystem, preventing it from immediately and autonomously entering low-power mode after task completion, wasting power optimization potential. Furthermore, the SCP's firmware processing flow is complex, making it difficult to achieve microsecond-level hardware pass-through low-latency responses, thus unsuitable for ultra-low latency scenarios.

[0004] Distributed power management allows each subsystem to autonomously request to enter or exit light sleep or deep sleep states. The power management module (PMM) manages the power of the APP core, CNNT core, and AUDIO core, as well as the power of all ROM / RAM memory. While this distributed management gives subsystems a certain degree of autonomy, complex firmware coordination is still required to handle power dependencies and wake-up timings when interacting across subsystems, falling far short of true "event-driven" operation.

[0005] While the aforementioned existing technologies achieve basic low-power management and inter-subsystem wake-up, there is still room for optimization in terms of coordination efficiency and wake-up latency when performing efficient cross-domain access (especially across low-power states) between heterogeneous multi-core SoC systems. They struggle to meet the event-driven characteristics of each subsystem based on its own task completion and external events, and cannot effectively support high-frequency, low-latency fine-grained interactions between subsystems. This results in the system consuming unnecessary power even when some subsystems are idle, hindering the achievement of system-level ultra-low power goals. Summary of the Invention

[0006] In view of the shortcomings of the prior art described above, the purpose of this invention is to provide a cross-domain wake-up interrupt controller and a heterogeneous multi-core chip to solve the technical problems of existing ultra-low power management, such as long wake-up latency, low coordination efficiency of data interaction, complex and variable power management configuration, and insufficient integration and coordination of DMA cross-domain access.

[0007] To achieve the above and other related objectives, this invention provides a cross-domain wake-up interrupt controller applied to a heterogeneous multi-core chip, comprising: multiple heterogeneous sub-power domains and a system hardware power management module. The controller includes: an event-driven wake-up module disposed in each sub-power domain participating in cross-domain communication, used to send a wake-up request from its own sub-power domain as the source sub-power domain for cross-domain communication to the destination sub-power domain; and a central coordination module disposed in the system hardware power management module, used to receive wake-up requests from each event-driven wake-up module, coordinate the system hardware power management module to wake up the corresponding destination sub-power domain through the event-driven wake-up module of the corresponding destination sub-power domain, and notify the corresponding source sub-power domain to perform data transmission after the corresponding destination sub-power domain is ready.

[0008] In one embodiment of the present invention, the cross-domain wake-up interrupt controller is configured to send a query success interrupt request to the source sub-power domain after detecting that the destination sub-power domain is ready, so that the source sub-power domain can transmit data with the destination sub-power domain; and is also configured to send a wake-up interrupt to the destination sub-power domain after the destination sub-power domain is woken up, notifying the destination sub-power domain that its power state has been restored.

[0009] In one embodiment of the present invention, the CPU polling process executed by the cross-domain wake-up interrupt controller includes: the CPU of the source sub-power domain first reads the status bit related to the destination sub-power domain; if the status bit is not set, the CPU of the source sub-power domain initiates a request for cross-domain communication with the destination power domain; after receiving this request, the central coordination module triggers the system hardware power management module to wake up the destination sub-power domain and monitors the destination sub-power domain in real time; once the destination sub-power domain is in a power-ready state, the central coordination module controls the status bit related to the destination sub-power domain and sends a wake-up interrupt to the destination sub-power domain; when the CPU of the source sub-power domain polls the status bit related to the destination sub-power domain, it performs data transmission with the destination sub-power domain; after the data transmission is completed, the CPU of the source sub-power domain sets the write-only bit of the event-driven wake-up module to notify the cross-domain wake-up interrupt controller that the current communication has ended, and the central coordination module coordinates the source sub-power domain and the destination sub-power domain to enter a low-power state as soon as possible.

[0010] In one embodiment of the present invention, the CPU interrupt process is executed through a cross-domain wake-up interrupt controller, including: the CPU of the source sub-power domain reads the status bit related to the destination sub-power domain; if the status bit is not set, the CPU of the source sub-power domain initiates a cross-domain communication request with the destination power domain, and the CPU of the source sub-power domain enters a shallow sleep state; after receiving this request, the central coordination module triggers the system hardware power consumption management module to wake up the destination sub-power domain and monitors the destination sub-power domain in real time; after the destination sub-power domain is in a power-ready state, the central coordination module controls the status bit related to the destination sub-power domain to be set, and sends a query success interrupt request to the interrupt controller of the source sub-power domain; after the CPU of the source sub-power domain responds to the query success interrupt, it checks again whether the status bit related to the destination sub-power domain has been set; if it is confirmed to be set, the CPU of the source sub-power domain clears the query success interrupt and performs data transmission with the destination sub-power domain; after the data transmission is completed, the CPU of the source sub-power domain notifies the event-driven wake-up module that the current data transmission session has ended.

[0011] In one embodiment of the present invention, after the target sub-power domain is woken up in the CPU interrupt process, the central coordination module sends a wake-up interrupt to the target sub-power domain. The target sub-power domain checks whether the write-only bit related to the source sub-power domain is set. If it is set, the wake-up interrupt is cleared. At this time, the target sub-power domain is in a power-ready state.

[0012] In one embodiment of the present invention, the CPU of the source sub-power domain is configured with an internal DMA controller, and the hardware trigger source for its DMA transfer is set to a specific hardware trigger signal from the event-driven wake-up module of the source sub-power domain.

[0013] In one embodiment of the present invention, the DMA interrupt process is executed through a cross-domain wake-up interrupt controller, including: the CPU of the source sub-power domain initiates a DMA wake-up request to the event-driven wake-up module, and the CPU of the source sub-power domain directly enters a shallow sleep state; after receiving this request, the central coordination module triggers the system hardware power management module to wake up the destination sub-power domain and monitors the destination sub-power domain in real time. After the destination sub-power domain is in a power-ready state, the central coordination module notifies the source sub-power domain that the destination sub-power domain is ready; the event-driven wake-up module triggers a hardware DMA request signal from the source sub-power domain to the destination sub-power domain, triggering the DMA controller of the source sub-power domain to perform data transmission; after the DMA transmission is completed, the DMA controller of the source sub-power domain notifies the event-driven wake-up module of the source sub-power domain that the DMA transmission is complete, the DMA controller sets its own DMA completion interrupt, and the CPU of the source sub-power domain exits the shallow sleep state; the event-driven wake-up module of the source sub-power domain sets a DMA completion interrupt signal to notify the destination sub-power domain that the DMA transmission is complete.

[0014] In one embodiment of the present invention, after the destination sub-power domain is woken up in the DMA interrupt process, the destination sub-power domain determines that the wake-up interrupt has been enabled, and when in the DMA transfer, the CPU of the destination sub-power domain enters a shallow sleep state. After the transfer is completed and the DMA completion interrupt signal of the cross-domain wake-up interrupt controller is received, the CPU of the destination sub-power domain exits the shallow sleep state and clears the wake-up interrupt.

[0015] In one embodiment, the cross-domain wake-up interrupt controller is further provided with cross-clock domain signal synchronization, event flip detection, cross-voltage domain isolation and level conversion, and a two-way handshake mechanism.

[0016] To achieve the above and other related objectives, the present invention provides a heterogeneous multi-core chip, including: the cross-domain wake-up interrupt controller.

[0017] As described above, this invention is a cross-domain wake-up interrupt controller and a heterogeneous multi-core chip, which has the following beneficial effects: The cross-domain wake-up interrupt controller of this invention includes an event-driven wake-up module arranged in each sub-power domain participating in cross-domain communication, and a central coordination module arranged in the system hardware power management module. When a source sub-power domain needs to communicate with a destination sub-power domain that is in a low-power state, its event-driven wake-up module sends a wake-up request. The central coordination module is responsible for receiving the wake-up request and coordinating the system hardware power management module to wake up the corresponding destination sub-power domain. Once the destination sub-power domain is ready, the central coordination module immediately notifies the source sub-power domain to start data transmission. This invention adopts an event-driven, fine-grained power management approach, realizing efficient cross-domain wake-up and data interaction, significantly improving the system's response speed and power optimization capabilities, and ultimately enabling the entire system to achieve ultra-low power control while ensuring performance. Attached Figure Description

[0018] Figure 1 The diagram shown is a structural schematic of a cross-domain wake-up interrupt controller according to an embodiment of the present invention.

[0019] Figure 2 The diagram shown is a structural schematic of a cross-domain wake-up interrupt controller according to an embodiment of the present invention.

[0020] Figure 3 The diagram shown is a schematic diagram of the cross-domain wake-up interrupt controller topology extension in one embodiment of the present invention.

[0021] Figure 4 The diagram shown is a schematic of the CDWIC CPU polling process in one embodiment of the present invention.

[0022] Figure 5 The diagram shown is a schematic of the CDWIC CPU interrupt process in one embodiment of the present invention.

[0023] Figure 6 The diagram shown is a structural schematic of a sub-power domain in one embodiment of the present invention.

[0024] Figure 7 The diagram shown is a schematic of the CDWIC combined DMA process in one embodiment of the present invention.

[0025] Figure 8 The diagram shown illustrates the sleep efficiency of CDWIC in one embodiment of the present invention.

[0026] Figure 9 The diagram shown is a structural schematic of an electronic terminal according to an embodiment of the present invention. Detailed Implementation

[0027] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that, unless otherwise specified, the following embodiments and features described therein can be combined with each other.

[0028] It should be noted that in the following description, reference is made to the accompanying drawings, which illustrate several embodiments of the invention. It should be understood that other embodiments may also be used, and changes in mechanical composition, structure, electrical system, and operation may be made without departing from the spirit and scope of the invention. The following detailed description should not be considered limiting, and the scope of the embodiments of the invention is defined only by the claims of the published patents. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. Spatially related terms, such as “upper,” “lower,” “left,” “right,” “below,” “below,” “lower part,” “above,” “upper part,” etc., may be used herein to illustrate the relationship between one element or feature shown in the figures and another element or feature.

[0029] Throughout this specification, when it is said that a part is "connected" to another part, this includes not only "direct connection" but also "indirect connection" by placing other elements in between. Furthermore, when it is said that a part "includes" a certain constituent element, unless otherwise stated otherwise, this does not exclude other constituent elements, but rather means that other constituent elements may also be included.

[0030] The terms "first," "second," and "third," etc., used herein are for the purpose of describing various parts, components, regions, layers, and / or segments, but are not limiting. These terms are used only to distinguish one part, component, region, layer, or segment from others. Therefore, the "first part," "component," "region," "layer," or "segment" described below may refer to a "second part," "component," "region," "layer," or "segment" without departing from the scope of this invention.

[0031] Furthermore, as used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It should be further understood that the terms “comprising,” “including,” indicate the presence of the stated feature, operation, element, component, item, kind, and / or group, but do not preclude the presence, occurrence, or addition of one or more other features, operations, elements, components, items, kinds, and / or groups. The terms “or” and “and / or” as used herein are interpreted as inclusive, or mean any one or any combination thereof. Thus, “A, B, or C” or “A, B, and / or C” means “any one of: A; B; C; A and B; A and C; B and C; A, B, and C.” Exceptions to this definition arise only when combinations of elements, functions, or operations are inherently mutually exclusive in some manner.

[0032] This invention provides a cross-domain wake-up interrupt controller, comprising an event-driven wake-up module deployed in each sub-power domain participating in cross-domain communication, and a central coordination module deployed in the system hardware power management module. When a source sub-power domain needs to communicate with a destination sub-power domain in a low-power state, its event-driven wake-up module sends a wake-up request. The central coordination module is responsible for receiving the wake-up request and coordinating the system hardware power management module to wake up the corresponding destination sub-power domain. Once the destination sub-power domain is ready, the central coordination module immediately notifies the source sub-power domain to begin data transmission. This invention employs an event-driven, fine-grained power management approach, achieving efficient cross-domain wake-up and data interaction, significantly improving the system's response speed and power optimization capabilities, ultimately enabling the entire system to achieve ultra-low power control while ensuring performance.

[0033] Before providing a further detailed description of the present invention, the nouns and terms used in the embodiments of the present invention are explained, and the nouns and terms used in the embodiments of the present invention are subject to the following interpretations:

[0034] <1> SoC (System-on-Chip): System-on-a-chip;

[0035] <3> PMM (Power Management Module): Power management module;

[0036] <3> CDWIC (Cross Domain Wakeup Interrupt Controller): Cross-domain wakeup interrupt controller;

[0037] <4> DMA (Direct Memory Access);

[0038] <5> CDWIC_INTF (CDWIC Interface): The CDWIC interface module, located within each subsystem, is used to initiate wake-up.

[0039] <6> CDWIC_AON (CDWIC Always-On): The CDWIC normally open controller, located in the normally open power domain, coordinates all requests;

[0040] <7> WFI (Wait For Interrupt): Wait for an interrupt, a processor instruction that puts the processor into a low-power state;

[0041] <8> DMA (Direct Memory Access);

[0042] <9> CPU (Central Processing Unit): The central processing unit;

[0043] <10> WIC_QUERY_SET: CDWIC queries the start bit; writing 1 initiates a wake-up process.

[0044] <11> WIC_QUERY_CLR: CDWIC query clear bit, write 1 to end the current cross-domain wake-up access transaction;

[0045] <12> WIC_QUERY_STS: CDWIC power-ready status, the status bit is used to determine whether it is accessible;

[0046] <13> WIC_DMA_REQ: CDWIC initiates a DMA start request in collaboration with hardware;

[0047] <14> WIC_DMA_ACK: CDWIC collaboratively initiates DMA completion confirmation, and sends a signal to confirm the completion of the DMA transfer.

[0048] The present invention will now be described in detail with reference to the accompanying drawings, so that those skilled in the art can readily implement it. The present invention can be embodied in many different forms and is not limited to the embodiments described herein.

[0049] like Figure 1 A schematic diagram of a cross-domain wake-up interrupt controller according to an embodiment of the present invention is shown.

[0050] The cross-domain wake-up interrupt controller includes:

[0051] This system is applied to heterogeneous multi-core chips and includes multiple heterogeneous sub-power domains and a system hardware power management module. The chip is functionally divided into multiple independent power domains, each of which can be independently powered on or off. The power state of each sub-power domain is directly controlled by the system hardware power management module. The system hardware power management module (PMM) is a purely hardware-implemented logic module located within the chip's normally-on power domain. The PMU receives power state requests from each sub-power domain, sends drive signals to the corresponding sub-power domain according to a preset hardware timing sequence to bring it into the target state, and generates PMU control signals.

[0052] The Cross-Domain Wake-Up Interrupt Controller (CDWIC) is not a single, isolated module, but rather operates in a distributed, collaborative manner. Its design aims to grant greater power management autonomy to each sub-power domain within a heterogeneous multi-core system-on-a-chip (SoC). Unlike ordinary wake-up interrupt controllers (WICs), this invention does not focus on single-core wake-up, but rather performs cross-domain hardware wake-up operations across multiple sub-power domains, while also integrating support for Joint Hardware Direct Memory Access (DMA).

[0053] The overall architecture of the controller consists of two main modules. The first is the event-driven wake-up module (CDWIC_INTF, i.e., CDWIC Interface), which is closely connected to the digital logic of each sub-power domain. The second is the central coordination module (CDWIC_AON, i.e., CDWIC Always-On) located in the system hardware power management module (PMM) within the always-on (AON) power domain.

[0054] Among them, the event-driven wake-up module, deployed in each heterogeneous sub-power domain participating in cross-domain communication, undertakes the crucial task of sending wake-up requests. Specifically, when the sub-power domain, acting as the source sub-power domain, needs to wake up a specific destination sub-power domain, this module will issue a corresponding wake-up request. For example, within each sub-power domain participating in cross-domain communication, such as the APP core, the convolutional neural network acceleration core (CNNT core), and the audio processing core (AUDIO core), a CDWIC_INTF module is configured. This module is the key interface for the sub-power domain to implement autonomous power management and event-driven wake-up functions.

[0055] The central coordination module, located within the system hardware power management module, is responsible for receiving wake-up requests from various event-driven wake-up modules. It coordinates the system hardware power management module to wake up the corresponding destination sub-power domain through its event-driven wake-up module. Furthermore, once the destination sub-power domain is ready, it promptly notifies the corresponding source sub-power domain to initiate data transmission. Specifically, a dedicated CDWIC_AON module is set up within the PMM. As the core coordinator of event-driven power management, the CDWIC_AON module's main responsibility is to receive requests from various CDWIC_INTF modules and work closely with the PMM's power management logic to handle wake-up requests and receive status notifications across power domains. Each CDWIC_INTF module communicates with the PMM's internal CDWIC_AON module via a specific interface to send wake-up requests and receive status notifications across power domains. This mechanism effectively supports mutual wake-up events between sub-power domains based on CDWIC.

[0056] In one embodiment, the Cross-Domain Wake-Up Interrupt Controller (CDWIC) defines a fixed naming mapping for cross-domain communication between different sub-power domains to simplify software and hardware design and support efficient interconnection in heterogeneous multi-core systems. When any sub-power domain initiates access as the source sub-power domain, the destination sub-power domain it needs to access is abstractly named R1, R2, etc. This mapping is pre-fixed and symmetrical.

[0057] Taking a sub-power domain system containing three cores (APP core, CNNT core, and AUDIO core) as an example: When the APP core initiates an operation as the source sub-power domain, the convolutional neural network acceleration core (CNNT core) module connected to it will be mapped to R1. At this time, the configuration and status register bits related to this module will be named with "(r1)" as a suffix; while the audio processing core (AUDIO core) module will be mapped to R2, and its corresponding register bits will be named with "(r2)" as a suffix.

[0058] This fixed mapping relationship applies to each sub-power domain as either a source or a destination, ensuring system-level uniformity and scalability, and enabling complex heterogeneous multi-core systems to communicate and coordinate between sub-power domains in a standardized manner.

[0059] like Figure 2From the perspective of the system architecture's physical layout, each major heterogeneous sub-power domain, such as the APP core, CNNT core, and AUDIO core, as well as the system hardware power management module (PMM), has a clearly defined location and power domain. Within each sub-power domain, a CDWIC_INTF module is configured. This module is equipped with key interfaces, including an interrupt interface, a connection interface with the DMA controller, and a communication interface with the PMM / CDWIC_AON. The CDWIC_INTF module resides in the clock domain of the register access space, allowing for faster access by software.

[0060] Within the PMM, there is a CDWIC_AON module, which also has key interfaces, including connection interfaces with each CDWIC_INTF module and interaction interfaces with the PMM power state machine. The CDWIC_AON module resides in the clock domain of the PMM hardware control logic, and its access speed is typically relatively slow, and its clock is asynchronous with that of the CDWIC_INTF module. In actual operation, the CDWIC_INTF module plays a crucial role in receiving query access requests from the CPU or DMA and forwarding these requests across clock domains to the CDWIC_AON module. The CDWIC_AON module, based on the received requests, coordinates the PMM to wake up the corresponding destination sub-power domain and promptly notifies the source sub-power domain once the destination sub-power domain is ready.

[0061] It is particularly important to emphasize that the CDWIC involved in this invention does not limit the specific number of heterogeneous multi-cores, possessing high flexibility and scalability, and can adapt to any different heterogeneous topologies. For example, in a six-core fully symmetric structure, such as Figure 3 As shown in diagram a, C0 to C5 represent independent heterogeneous cores located in different voltage domains. Each connection in the diagram is indicated by a double-headed arrow, meaning that any core can actively wake up other cores, and may also be woken up by other cores. Another example is a six-core star structure, such as... Figure 3 As shown in b, C0 is located at the center. This demonstrates that the overall structure of CDWIC is completely universal for different topologies; only the mapping relationship between "source" and "destination" in each sub-power domain needs to be adjusted appropriately according to the actual situation.

[0062] In one embodiment, the cross-domain wake-up interrupt controller is configured to send a query success interrupt request to the event-driven wake-up module of the source sub-power domain after detecting that the destination sub-power domain is ready, so that the source sub-power domain can transmit data with the destination sub-power domain; it is also configured to send a wake-up interrupt to the destination sub-power domain after the destination sub-power domain is woken up, notifying the destination sub-power domain that its power state has been restored.

[0063] Specifically, when a source sub-power domain (taking the APP core as an example) initiates a query or wake-up request to a cross-domain destination sub-power domain (such as the AUDIO core), and the destination sub-power domain has been successfully woken up and is in a ready state, the Cross-Domain Wake-up Interrupt Controller (CDWIC) sends a corresponding query success interrupt to the source sub-power domain. This interrupt is a signal that the source sub-power domain actively initiates event-driven cross-domain access, explicitly informing the source sub-power domain that data transmission can begin immediately without relying on continuous polling and waiting in the firmware, thus improving data transmission efficiency. Each source sub-power domain is equipped with two such interrupts, corresponding to its mapped cross-domain destination sub-power domains R1 and R2, ensuring the accuracy and flexibility of cross-domain access.

[0064] When a destination sub-power domain (such as the AUDIO core) is successfully woken up by another source sub-power domain (such as the APP core or CNNT core) using the CDWIC mechanism, CDWIC sends a wake-up interrupt to the destination sub-power domain. This interrupt allows the destination sub-power domain to quickly perceive the change in its power state and prepare in advance to receive subsequent tasks. Each destination sub-power domain also has two such interrupts, used to indicate whether it has been woken up by the source sub-power domains mapped as R1 and R2, respectively, ensuring the orderliness and controllability of the wake-up process.

[0065] Table 1: CDWIC related interrupt descriptions (taking the CNNT core power domain as an example)

[0066] CNNT core 0 cdwic_query_int_cnnt2aud CNNT core As a CDWIC source, it indicates that the query for the AUDIO core power domain was successful (i.e., the AUDIO core is ready). CNNT Core 1 cdwic_query_int_cnnt2app CNNT core As a CDWIC source, it indicates that the query for the APP core power domain was successful (i.e., the APP core is ready). CNNT Core 2 cdwic_waken_up_int_aud2cnnt CNNT core As a CDWIC purpose, it is instructed to be woken up by the AUDIO core power domain. CNNT Core 3 cdwic_waken_up_int_app2cnnt CNNT core As a CDWIC purpose, it instructs the device to be woken up by the APP core power domain. CNNT Core 4 cdwic_dma_int_aud2cnnt CNNT core As a CDWIC purpose, it instructs that the DMA completion interrupt initiated by CDWIC be woken up by the AUDIO core power domain. CNNT Core 5 cdwic_dma_int_app2cnnt CNNT core As a CDWIC purpose, it instructs that the DMA completion interrupt initiated by CDWIC be woken up by the APP core power domain.

[0067] In heterogeneous multi-core systems, each sub-power domain core is typically configured with an Interrupt Controller (INTC) to aggregate and manage all interrupt requests generated by that core. The Interrupt Controller then sends notifications to the sub-power domain cores via aggregated interrupt signals. The following explanation uses the interrupt controller corresponding to the CNNT core sub-power domain as an example, which has six interrupts related to CDWIC. The other two sub-power domains, the AUDIO core and the APP core, each also have the same six interrupts, perfectly symmetrically. For example, in Table 1, interrupt numbers 0 to 3 all belong to the CNNT core sub-power domain and are mapped to the CNNT core's INTC. The interrupt mapping for other sub-power domains follows the same pattern.

[0068] CDWIC supports three main workflows: CPU polling, CPU interrupt, and DMA interrupt, to adapt to cross-domain access requirements in different scenarios of heterogeneous multi-core SoCs. The following examples illustrate these three workflows:

[0069] In one embodiment, a CPU polling process is executed through a cross-domain wake-up interrupt controller. This process describes how the source sub-power domain CPU queries and wakes up the cross-domain destination sub-power domain via CDWIC and performs data interaction. The core of this process is to achieve low-latency wake-up between sub-power domains based on event-driven mechanisms.

[0070] The CPU polling process, executed through the cross-domain wake-up interrupt controller, includes: the CPU of the source sub-power domain first reads the status bit related to the destination sub-power domain; if the status bit is not set, the CPU of the source sub-power domain initiates a request for cross-domain communication with the destination power domain; after receiving this request, the central coordination module triggers the system hardware power management module to wake up the destination sub-power domain and monitors the destination sub-power domain in real time; once the destination sub-power domain is in a power-ready state, the central coordination module controls the status bit related to the destination sub-power domain and sends a wake-up interrupt to the destination sub-power domain; when the CPU of the source sub-power domain polls the status bit related to the destination sub-power domain, it performs data transmission with the destination sub-power domain; after the data transmission is completed, the CPU of the source sub-power domain sets the write-only bit of the event-driven wake-up module, notifying the cross-domain wake-up interrupt controller that the current communication has ended, and the central coordination module coordinates the source and destination sub-power domains to enter a low-power state as soon as possible.

[0071] Specifically, as shown in Figure 4, the source polling process in the CPU query process includes the following steps:

[0072] Step 1: The CPU of the source sub-power domain reads the status bit WIC_QUERY_STS(R2) related to the destination sub-power domain from CDWIC to check whether the destination sub-power domain is ready. This step fully demonstrates the initiative of the source sub-power domain in initiating event queries, providing a basis for subsequent operations.

[0073] Step 2: If WIC_QUERY_STS(R2) is not set, it indicates that the power consumption status of the destination sub-power domain is not ready, and the CPU of the source sub-power domain executes step 3; if it is set, meaning the destination sub-power domain is ready, then directly jump to step 6. Since this status bit is in the clock domain where CDWID_INTF resides, the CPU can perform accurate and real-time queries. For cases where the destination sub-power domain is ready, directly jumping to step 6 can greatly shorten the query process and improve system response speed.

[0074] Step 3: The CPU in the source power domain sets the write-only bit WIC_QUERY_SET of the CDWIC QUERY.

[0075] (R2) Initiates a cross-domain query / wake-up request for the target sub-power domain to the corresponding CDWIC_AON. This operation is a key step for the source sub-power domain to actively initiate cross-domain interaction, laying the foundation for the subsequent wake-up of the target sub-power domain.

[0076] Step 4: Upon receiving this request, CDWIC_AON triggers the PMM to wake up the target sub-power domain and monitors its power readiness status in real time. The target sub-power domain may be in various power states, including normally on (ON), light sleep (LIGHTSLEEP), deep sleep (DEEPSLEEP), power off (OFF), or even an intermediate state during power state transition. This step is the core action of the source sub-power domain initiating "event-driven" wake-up between sub-power domains, ensuring that the target sub-power domain can be accurately woken up according to actual needs.

[0077] Step 5: The CPU continuously polls the WIC_QUERY_STS(R2) status bit of the source sub-power domain. If this bit is still 0, meaning the destination sub-power domain is not ready, polling continues until the bit becomes 1, indicating that the destination sub-power domain is ready, then proceeds to the next step. This continuous polling process ensures that the source sub-power domain can obtain the ready status of the destination sub-power domain in a timely manner, preparing for data transmission.

[0078] Step 6: Once WIC_QUERY_STS(R2) is set, the CPU of the source sub-power domain confirms that the destination sub-power domain is ready and can begin data transfer or resource access with the destination sub-power domain. At this point, the destination sub-power domain has successfully responded to the event and is in a ready state, capable of meeting the interaction requirements of the source sub-power domain.

[0079] Step 7: If the data transfer or resource access is complete, the CPU of the source sub-power domain notifies CDWIC of the end of this query / access session by setting the write-only bit WIC_QUERY_CLR(R2) of CDWIC. This operation enables CDWIC to promptly coordinate with the destination sub-power domain to enter low-power mode as soon as possible, reducing system power consumption.

[0080] Step 8: At this point, the source polling process in the entire CPU query process has ended, the system has completed a complete cross-domain interaction operation, and is ready to enter a low-power state.

[0081] In one embodiment, a CPU interrupt procedure is executed through a Cross-Domain Wake-up Interrupt Controller (CDWIC). This procedure details how the source subsystem CPU uses the CDWIC to query and wake up the cross-domain destination subsystem. Specifically, the source subsystem is notified of the interrupt by querying, and the destination subsystem is notified of the interrupt by waking it up, thereby enabling data interaction between the two. The core of this procedure is to achieve a low-latency wake-up mechanism based on event-driven mechanisms between subsystems.

[0082] The CPU interrupt process includes the following steps: The CPU of the source sub-power domain reads the status bit related to the destination sub-power domain. If the status bit is not set, the CPU of the source sub-power domain initiates a cross-domain communication request with the destination power domain, and the CPU of the source sub-power domain enters a light sleep state. After receiving this request, the central coordination module triggers the system hardware power management module to wake up the destination sub-power domain and monitors the destination sub-power domain in real time. Once the destination sub-power domain is in a power-ready state, the central coordination module controls the status bit related to the destination sub-power domain and sends a query success interrupt request to the interrupt controller of the source sub-power domain. After the CPU of the source sub-power domain responds to the query success interrupt, it checks again whether the status bit related to the destination sub-power domain is set. If it is confirmed to be set, the CPU of the source sub-power domain clears the query success interrupt and performs data transmission with the destination sub-power domain. After the data transmission is completed, the CPU of the source sub-power domain notifies the event-driven wake-up module that the data transmission session has ended.

[0083] During the CPU interrupt process, after the destination sub-power domain is woken up, the central coordination module sends a wake-up interrupt to the destination sub-power domain. The destination sub-power domain checks whether the write-only bit associated with the source sub-power domain is set. If it is set, the wake-up interrupt is cleared, and the destination sub-power domain is in a power-ready state.

[0084] Specifically, such as Figure 5 As shown, this process is divided into a source interrupt flow and a destination interrupt flow:

[0085] The source interrupt flow includes:

[0086] Step 1: The CPU of the source sub-power domain reads the status bit WIC_QUERY_STS(R2) related to the destination sub-power domain in CDWIC to confirm whether the destination sub-power domain is ready.

[0087] Step 2: If WIC_QUERY_STS(R2) is not set (indicating the destination sub-power domain power consumption status is not ready), the CPU of the source sub-power domain executes step 3; if it is set (ready), it jumps directly to step 5. Since this status bit is in the clock domain of CDWID_INTF, the CPU query result is accurate and real-time. For the "ready" case, it can jump directly to step 6, thus greatly shortening the query process.

[0088] Step 3: The CPU in the source power domain enables the query success interrupt related to CDWIC in the interrupt controller of the source power domain (WIC_QUERY_INT_APP2AUD in this example).

[0089] Step 4: Configure the corresponding polling interrupt enable bit WIC_QUERY_INT_ in the source power domain's CPU settings CDWIC.

[0090] EN(R2)=1. (The destination R2 corresponds to the destination power domain in the source power domain).

[0091] Step 5: The CPU in the source power domain initiates a cross-domain query / wake-up request to CDWIC by setting the write-only bit WIC_QUERY_SET(R2) of CDWIC.

[0092] Step 6: The CPU in the source power domain executes the WFI instruction to enter the Wait for Interrupt (WFI) state. Compared to the polling method, the interrupt method better highlights the immediacy of event-driven processing.

[0093] Step 7: Upon receiving this request, CDWIC_AON triggers the PMM to wake up the target sub-power domain subsystem and monitors its power readiness status. The target sub-power domain may be in various power states, such as normally powered on (ON), light sleep (LIGHTSLEEP), deep sleep (DEEPSLEEP), powered off (OFF), or even in an intermediate state during power state transition. This step is the core action for the source subsystem to initiate "event-driven" wake-up between subsystems.

[0094] Step 8: When the destination sub-power domain subsystem is woken up and ready, CDWIC_AON will send an interrupt request to the interrupt controller of the source sub-power domain.

[0095] Step 9: (In the Interrupt Service Routine ISR) After the CPU of the source power domain responds to the interrupt, check the status bit WIC_QUERY_INT_STS(R2) again to confirm that the interrupt was indeed caused by the CDWIC query success event. At this time, the bit should be set.

[0096] Step 10: (In the Interrupt Service Routine) The CPU in the source sub-power domain clears the interrupt by setting the write-only bit WIC_QUERY_INT_CLR(R2) of CDWIC.

[0097] Step 11: The CPU of the source sub-power domain confirms that the destination sub-power domain is ready and can begin data transfer or resource access with the destination sub-power domain.

[0098] Step 12: If data transfer or resource access is complete, the CPU of the source sub-power domain notifies CDWIC of the end of the current query / access session by setting the write-only bit WIC_QUERY_CLR(R2) of CDWIC. This allows the destination subsystem to switch to a low-power state as quickly as possible under event-driven completion of the task, optimizing system power consumption.

[0099] Step 13: After the process is completed, the source subsystem can issue a sleep request again as soon as possible and quickly enter a low-power sleep state. This low-power sleep state can be either light sleep (LIGHTSLEEP) or deep sleep (DEEPSLEEEP). If a rapid response to subsequent wake-up events is required, it can choose to enter LIGHTSLEEP, in which case the subsystem only shuts down the clock and does not power off; the static power consumption is relatively higher than in deep sleep.

[0100] The CDWIC cross-domain awareness wake-up interrupt support of this invention significantly reduces the overall wake-up latency. For light sleep, the optimized wake-up latency can reach the 2µs level; for deep sleep, the optimized wake-up latency can typically reach the 2-5µs level. Such efficient wake-up response greatly increases the possibility that each subsystem core will enter sleep mode during idle intervals while processing data streams to reduce power consumption, truly forming a data stream-driven sleep-wake process, and ultimately achieving the goal of data stream event-driven power management for heterogeneous multi-core SoC systems.

[0101] like Figure 5 The destination interrupt flow includes:

[0102] Step 1: The destination sub-power domain receives an interrupt from CDWIC, indicating that it has been woken up by the source sub-power domain. This is a response to an event-driven wake-up from CDWIC.

[0103] Step 2: The destination sub-power domain re-checks the wake-up-related status bit WIC_WAKEN_UP_INT_STS(R1) in its ISR to confirm that it has been woken up by the source sub-power domain.

[0104] Step 3: Set the corresponding write-only bit WIC_WAKEN_UP_INT_CLR(R1) in the target sub-power domain to clear the wake-up interrupt.

[0105] Step 4: After the wake-up process is completed, the destination sub-power domain is now in a ready state, waiting for the source subsystem to access data (interaction can be completed using normal inter-core communication IPC). This process ensures that the destination sub-power domain can respond to the wake-up event in a timely manner with low latency.

[0106] Step 5: After the data processing is completed, the target sub-power domain can issue a sleep request again as soon as possible and quickly enter a low-power sleep state.

[0107] In one embodiment, a major improvement of the present invention lies in supporting a DMA (Direct Memory Access)-assisted cross-domain access mechanism. This mechanism allows for large-volume data transfers across domains without frequent CPU intervention, thereby significantly improving the data interaction efficiency of heterogeneous multi-core SoC systems and greatly optimizing system-level ultra-low power consumption. Figure 6 The CPU in the source sub-power domain configures its internal DMA controller, setting its DMA transfer hardware trigger source to a specific hardware trigger signal from the event-driven wake-up module in the source sub-power domain. The following process details the cross-domain communication sequence combined with DMA, the core of which lies in achieving efficient data transfer and wake-up coordination between subsystems based on event-driven mechanisms at the hardware level.

[0108] Executing the DMA interrupt procedure through cross-domain wake-up interrupt controller includes:

[0109] The CPU of the source sub-power domain initiates a DMA wake-up request to the event-driven wake-up module, and the CPU of the source sub-power domain directly enters a shallow sleep state. After receiving this request, the central coordination module triggers the system hardware power management module to wake up the destination sub-power domain and monitors the destination sub-power domain in real time. Once the destination sub-power domain is in a power-ready state, the central coordination module notifies the source sub-power domain that the destination sub-power domain is ready. The event-driven wake-up module will trigger a hardware DMA request signal from the source sub-power domain to the destination sub-power domain, triggering the DMA controller of the source sub-power domain to perform data transmission. After the DMA transmission is completed, the DMA controller of the source sub-power domain will notify the event-driven wake-up module of the source sub-power domain that the DMA transmission is complete. The DMA controller will set its own DMA completion interrupt, and the CPU of the source sub-power domain will exit the shallow sleep state. The event-driven wake-up module of the source sub-power domain sets the DMA completion interrupt signal to notify the destination sub-power domain that the DMA transmission is complete.

[0110] During the DMA interrupt process, after the destination sub-power domain is woken up, the destination sub-power domain determines that the wake-up interrupt has been enabled. When the DMA transfer is in progress, the CPU of the destination sub-power domain enters a shallow sleep state. After the transfer is completed and the DMA completion interrupt signal from the cross-domain wake-up interrupt controller is received, the CPU of the destination sub-power domain exits the shallow sleep state and clears the wake-up interrupt.

[0111] Specifically, such as Figure 7 As shown, this process is divided into a source interrupt flow and a destination interrupt flow:

[0112] The DMA interrupt process includes:

[0113] Step 1: The source sub-power domain configures its internal DMA controller, setting the hardware trigger source for DMA transfers to a specific hardware trigger signal from the source sub-power domain's CDWIC_INTF. This hardware trigger signal is provided by CDWIC after the destination subsystem is ready; this hardware triggering method is key to implementing DMA event-driven operations.

[0114] Step 2: The source sub-power domain initiates a DMA query / wake-up request to CDWIC_INTF by setting the write-only bit WIC_QUERY_DMA_SET(R2) of CDWIC. This operation is equivalent to the source sub-power domain issuing an instruction to initiate a DMA transfer event.

[0115] Step 3: The source power domain does not need to wait for and participate in the subsequent data transmission process. It directly executes the WFI instruction to put the CPU into a shallow sleep state, thereby reducing the CPU's own dynamic power consumption.

[0116] Step 4: After receiving the DMA query request, the CDWIC_AON module of CDWIC will coordinate with the PMM to ensure that the target sub-power domain is woken up (if it is in a low-power state). The target sub-power domain may be in various power states, including normal on (ON), light sleep (LIGHTSLEEP), deep sleep (DEEPSLEEP), power off (OFF), or even in an intermediate state during the power state transition, until the power of the target sub-power domain reaches the ready state (ON).

[0117] Step 5: After the destination sub-power domain is woken up and ready, the CDWIC_AON module of CDWIC will notify CDWIC_INTF that the destination power is ready.

[0118] Step 6: CDWIC_INTF will trigger a hardware DMA request signal (WIC_DMA_REQ) from the source sub-power domain to the destination sub-power domain. This signal is directly connected to the DMA controller of the source sub-power domain and serves as the start trigger signal for the DMA transfer. This hardware triggering method ensures low latency for DMA startup.

[0119] Step 7: At this point, it has been ensured that the power status of both the source subsystem where the DMA originates and the destination subsystem where the DMA destination is located is ready, and the DMA begins data transfer.

[0120] Step 8: After the hardware DMA transfer is completed, the DMA controller inside the source sub-power domain will notify the source sub-power domain (source sub-system) of the DMA completion acknowledgment signal (WIC_DMA_ACK) via CDWIC_INTF. At the same time, the DMA controller will set its own DMA completion interrupt (DMA_INT) to notify the source software DMA data transfer that the data transfer has been completed.

[0121] Step 9: After receiving the DMA completion acknowledgment signal (WIC_DMA_ACK) from the source sub-power domain's CDWIC_INTF, it will set a WIC_DMA completion interrupt signal WIC_DMA_DONE_INT to notify the destination sub-system that the cross-domain DMA transaction has been completed. The DMA completion event is promptly notified to the destination sub-power domain via CDWIC, enabling it to process the relevant data immediately.

[0122] Step 10: The source sub-power domain enters a low-power state starting from Step 3 of this process, until it receives its own DMA completion interrupt (DMA_INT) in Step 8, at which point it exits the WFI state and begins preparing for the next stage of data processing. If there is no next data processing event, the source sub-power domain will first clear the WIC query DMA flag, then execute a new WFI instruction, and initiate a request to enter a lower-power state (subsystem-level LIGHTSLEEP or DEEPSLEEP).

[0123] Step 11: After receiving a sleep request from the source sub-power domain, the power control state machine of the PMM normally open domain will cause the source sub-system to enter a low-power state.

[0124] It is important to note that in CDWIC DMA mode, the source sub-power domain typically does not receive an independent poll success interrupt via CDWIC. Instead, the source sub-power domain only generates a DMA completion interrupt via its own DMA controller after the entire DMA transaction (including wake-up and transfer) is completed. This design simplifies the software processing logic on the source side, allowing the firmware to focus more on data processing rather than complex power state coordination, thus achieving more efficient event-driven task management.

[0125] In one specific embodiment, the subsystem has no scheduled tasks before the destination sub-power domain receives data transferred from the source DMA. Thanks to the low latency and high convenience of CDWIC's wake-up capability, the destination sub-power domain can quickly put its subsystem into a low-power sleep state. Users can choose between light sleep or deep sleep modes according to their actual needs. Once the destination sub-power domain is successfully woken up, the software only needs to ensure that the CDWIC wake-up interrupt function is enabled, specifically by setting WIC_DMA_INT_EN(R1)=1. In this way, the destination sub-power domain can receive an interrupt notification promptly upon wake-up; this channel is the response path for the wake-up event. Since the data transfer from the source to the destination must be completed after wake-up, the software has no tasks to process while data transfer is still in progress. At this time, the WFI instruction can be executed directly to put the CPU into a light sleep state, thereby effectively reducing the CPU's dynamic power consumption. Once the DMA data transfer is complete, the destination sub-power domain receives the WIC_DMA_DONE_INT signal. Upon receiving this interrupt, the CPU immediately exits the WFI state. Subsequently, the software performs the necessary configuration to clear the WIC_DMA interrupt status. At this point, the destination sub-power domain can begin processing the received data. After completing data processing, the destination sub-power domain executes a new WFI instruction and initiates a request to enter a lower power state (subsystem-level LIGHTSLEEP or DEEPSLEEP). In this way, the destination sub-power domain can enter a low-power mode as quickly as possible after completing its task, further saving system power consumption.

[0126] In one specific embodiment, when using CDWIC for cross-domain wake-up and querying, the source subsystem is typically in an ON (full-function) state, while the destination sub-power domain can be in an ON, LIGHTSLEEP, or DEEPSLEEP state. The presence of CDWIC enables truly fine-grained power state switching between sub-power domains and timely responses to wake-up events. Minimal latency occurs when the destination sub-power domain needs to wake from deep sleep. Through CDWIC's optimization mechanism, its wake-up latency can be controlled within 2-5 microseconds, a significant improvement over traditional software-coordinated wake-up processes, enabling it to meet the needs of more real-time applications. This low-latency characteristic is key to achieving ultra-low power consumption in heterogeneous multi-core SoC systems because it allows subsystems to enter deep sleep more frequently and autonomously when idle, rather than remaining active to handle potential cross-domain interactions.

[0127] Next, we will use specific examples to illustrate in detail the effect of CDWIC on improving sleep efficiency.

[0128] Figure 8 The paper presents a typical data flow and processing scenario in a three-core heterogeneous system, assuming that the data flow passes through the CNNT core, AUDIO core and APP core in sequence.

[0129] Among them, the data processing flow without CDWIC support is as follows Figure 8 The upper part of the diagram, without CDWIC support, shows all three cores in sleep mode initially. When a system-level wake-up event is received (potentially triggered by an external GPIO or a timed wake-up), because the power state coordination between the three cores relies entirely on software, it can only handle coarse-grained sleep and wake-up requests. Therefore, this event will simultaneously wake up all subsystems required for data processing. After the three cores wake up, the CNNT core begins processing data, while the AUDIO and APP cores remain idle as they have no data to process. Their CPUs can execute WFI instructions to reduce their dynamic power consumption. After the CNNT core finishes processing the data, it can transfer the data to subsequent subsystems via either direct CPU transfer or DMA. The diagram shows DMA used to transfer data to the AUDIO core, while the APP core remains idle. After the first DMA operation, the AUDIO core begins processing data, while the CNNT and APP cores remain idle. After the AUDIO core finishes processing the data, it initiates DMA to transfer the data to the APP core, while the CNNT core remains idle. After the second DMA operation, the APP core begins processing data, while the CNNT and AUDIO cores remain idle. After the APP core completes data processing, it needs to coordinate with each other through IPC and other software among the three cores to confirm that the data processing is complete before allowing a new sleep process to be initiated uniformly.

[0130] Data processing workflows supported by CDWIC include: Figure 6The lower half shows a schematic diagram with CDWIC support. Similarly, all three cores initially enter a sleep state. Upon receiving a system-level wake-up event, due to the power state coordination between the three cores supported by CDWIC, fine-grained sleep and wake-up requests are supported. At this time, the system-level wake-up event is only mapped to the first CNNT core that needs to process data. After the CNNT core is woken up, the AUDIO and APP cores do not need to be woken up and can continue sleeping. The CNNT core begins processing data, while the AUDIO and APP cores remain asleep. After the CNNT core finishes processing the data, it requests the data to the AUDIO core via CDWIC hardware DMA, and its CPU executes WFI to enter an idle state. During the first DMA, the APP core is asleep; after the DMA is completed, the CNNT core is interrupted and exits WFI, immediately entering the sleep process; the AUDIO core immediately begins processing data, while the CNNT and APP cores remain asleep. After the AUDIO core finishes processing the data, it requests the data to the APP core via CDWIC hardware DMA, and its CPU executes WFI to enter an idle state. During the second DMA operation, the CNNT core remains in sleep mode. After the DMA completes, the AUDIO core is interrupted and exits WFI, immediately entering a sleep state. The APP core immediately begins processing data, while both the CNNT and AUDIO cores remain in sleep mode. Once the APP core has finished processing the data, it immediately enters a sleep state.

[0131] The comparison shows that with CDWIC support, each of the three cores has a greater chance of entering a low-power sleep state when completing the same cross-domain data transfer task, effectively improving sleep efficiency. As can be seen from the lower half of the current curve diagram, the curve optimized by CDWIC (solid line) is significantly lower than the original curve (dashed line). It should be noted that the diagram only illustrates a typical data flow scenario. In actual applications, task scheduling, interaction order, and current waveforms may be more complex, and the power consumption curves will differ under different application loads. However, the overall trend is consistent: CDWIC can significantly increase the sleep rate and reduce system power consumption.

[0132] In one embodiment, in the system involved in this invention, the INTF interface of the CDWIC module and the AON module are deployed in different sub-power domains and clock domains. Given the potential metastability issues and signal consistency risks during cross-clock domain transmission (CDC) and cross-voltage domain transmission (PDC), we have meticulously designed the following series of hardware safeguards to ensure stable and reliable system operation:

[0133] Cross-clock domain signal synchronization mechanism: For all critical control signals, such as request signals (REQ), acknowledge signals (ACK), and DMA request signals, synchronization is achieved using a two-stage cascaded flip-flop approach on the signal receiving side. This design effectively prevents the propagation of metastability in the system, thereby ensuring the accuracy and stability of signal transmission between different clock domains.

[0134] Event Flip Detection Mechanism: To prevent misinterpretation of level signals during transmission, we employ bit-flip encoding to trigger event state changes. In the destination domain, precise detection of the flip edge triggers subsequent state machine actions. This mechanism significantly improves the accuracy and reliability of event detection, ensuring the system responds correctly to various events.

[0135] Cross-voltage domain isolation and level shifting mechanism: In the signal transmission path, we cleverly insert isolation cells and level shifters. Isolation cells can effectively isolate different power domains to prevent signal interference; while level shifters can accurately convert signal levels between different voltage domains, ensuring that communication between power domains remains legal and stable under low power or power-down conditions, thus guaranteeing normal communication of the system in different operating modes.

[0136] REQ / ACK bidirectional handshake mechanism: The source power domain initiates a REQ signal request via CDWIC_INTF. Upon receiving this signal, the CDWIC_AON terminal captures it using the CDC mechanism and initiates a finite state machine (FSM) for corresponding response processing, subsequently sending an ACK signal back to the source power domain. Throughout this process, both REQ and ACK signals must be processed across the CDC and PDC. This rigorous bidirectional handshake mechanism provides a solid guarantee for reliable communication between the source power domain and the CDWIC_AON terminal.

[0137] The aforementioned series of meticulously designed hardware safeguards endow the CDWIC module with highly robust characteristics in complex heterogeneous multi-core SoC environments. It can easily handle frequent event-driven wake-up operations and data interaction needs, effectively achieving the goal of system-level low-power collaborative control and providing reliable support for the stable and efficient operation of the entire system.

[0138] This invention also provides a schematic diagram of a heterogeneous multi-core chip. The chip includes: multiple heterogeneous sub-power domains, a system hardware power management module, and the cross-domain wake-up interrupt controller described in the above embodiments;

[0139] The cross-domain wake-up interrupt controller includes:

[0140] An event-driven wake-up module is deployed in each sub-power domain participating in cross-domain communication to send a wake-up request to the destination sub-power domain for which the source sub-power domain needs to communicate across domains.

[0141] The central coordination module, located in the system hardware power management module, is used to receive wake-up requests from each event-driven wake-up module, coordinate the system hardware power management module to wake up the corresponding destination sub-power domain through the event-driven wake-up module of the corresponding destination sub-power domain, and notify the corresponding source sub-power domain to perform data transmission after the corresponding destination sub-power domain is ready.

[0142] Since the implementation principle of the cross-domain wake-up interrupt controller has been described in the previous embodiments, it will not be repeated here.

[0143] The cross-domain wake-up interrupt controller provided in this embodiment of the invention can be implemented on the terminal side or the server side. For the hardware structure of the electronic terminal, please refer to [link to relevant documentation]. Figure 9 This is a schematic diagram of an optional hardware structure of an electronic terminal 1000 provided in an embodiment of the present invention. The terminal 1000 can be a mobile phone, computer device, tablet device, personal digital processing device, factory back-end processing device, etc. The terminal 1000 includes: at least one processor 1001, a memory 1002, at least one network interface 10010, and a user interface 1009. The various components in the device are coupled together through a bus system 1005. It is understood that the bus system 1005 is used to realize the connection and communication between these components. In addition to a data bus, the bus system 1005 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 9 The general will label all buses as bus systems.

[0144] The user interface 1009 may include a monitor, keyboard, mouse, trackball, clicker, button, touchpad, or touch screen.

[0145] It is understood that memory 1002 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM) or programmable read-only memory (PROM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM) and synchronous static random access memory (SSRAM). The memories described in the embodiments of this invention are intended to include, but are not limited to, these and any other suitable categories of memory.

[0146] In this embodiment of the invention, the memory 1002 is used to store various types of data to support the operation of the terminal 1000. Examples of this data include: any executable program for operation on the terminal 1000, such as the operating system 10021 and application program 10022; the operating system 10021 contains various system programs, such as the framework layer, core library layer, driver layer, etc., for implementing various basic services and handling hardware-based tasks. The application program 10022 may contain various applications, such as a media player, browser, etc., for implementing various application services. The cross-domain wake-up interrupt controller provided in this embodiment of the invention may be included in the application program 10022.

[0147] The methods disclosed in the above embodiments of the present invention can be applied to or implemented by the processor 1001. The processor 1001 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in the processor 1001 or by instructions in the form of software. The processor 1001 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor 1001 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. The general-purpose processor 1001 may be a microprocessor or any conventional processor, etc. The steps of the accessory optimization method provided in the embodiments of the present invention can be directly reflected as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software module may be located in a storage medium, which is located in a memory. The processor reads the information in the memory and combines it with its hardware to complete the steps of the aforementioned method.

[0148] In an exemplary embodiment, the terminal 1000 may be used to execute the aforementioned method by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), or complex programmable logic devices (CPLDs).

[0149] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented using computer program-related hardware. The aforementioned computer program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0150] In the embodiments provided in this application, the computer-readable and writable storage medium may include read-only memory, random access memory, EEPROM, CD-ROM or other optical disc storage devices, disk storage devices or other magnetic storage devices, flash memory, USB flash drive, portable hard drive, or any other medium capable of storing desired program code in the form of instructions or data structures and accessible by a computer. Additionally, any connection may be appropriately referred to as a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. However, it should be understood that computer-readable and writable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are intended for non-transient, tangible storage media. The disks and optical discs used in the application include compact optical discs (CDs), laser optical discs, optical discs, digital multifunction optical discs (DVDs), floppy disks, and Blu-ray discs, where disks typically copy data magnetically, while optical discs use lasers to copy data optically.

[0151] The present invention has the following advantages over the prior art:

[0152] 1. Achieve truly event-driven, fine-grained power management, significantly reducing power consumption: This invention introduces CDWIC as a hardware coordinator, breaking the traditional firmware dependency model and enabling each subsystem of a heterogeneous multi-core SoC to autonomously and finely manage its power state based on its own events. After completing its tasks, each subsystem can quickly enter a deep low-power mode, significantly reducing overall power consumption and achieving the system-level ultra-low power goal.

[0153] 2. Significantly reduced wake-up latency and low-latency wake-up response: With the assistance of CDWIC hardware and the PMM sub-power domain timing FSM acceleration mechanism, this invention reduces the wake-up latency of the subsystem from deep sleep to less than 2-5 microseconds. This low-latency wake-up capability ensures that the system still has excellent real-time response capability under ultra-low power consumption, improving the user experience.

[0154] 3. Simplify firmware collaboration and enhance the autonomy of multi-core systems: CDWIC automates the process of source subsystem query, destination subsystem wake-up, and power preparation notification, reducing the complexity of firmware processing timing and collaboration logic, lowering the difficulty and cost of software development, and giving each subsystem greater autonomy and flexibility, enabling it to efficiently focus on its own tasks.

[0155] 4. High-efficiency DMA cross-domain access and data flow optimization: This invention provides a CDWIC-assisted hardware-triggered DMA cross-domain access mechanism, allowing the source subsystem to directly trigger DMA transfers to the destination subsystem, even when it is in a low-power state. CDWIC ensures that the destination subsystem is correctly woken up and notifies of the transfer completion, optimizing large data volume transfers and reducing system-level power consumption.

[0156] 5. Enhanced System Robustness and Reliability: As a dedicated hardware module, CDWIC enhances system robustness through strict timing control and state synchronization, achieving excellent stability in frequent sleep states under complex low-power scenarios. It avoids scheduling delays, race conditions, or deadlocks associated with pure software solutions, reducing system crashes or anomalies.

[0157] 6. Improve sleep efficiency: Through the above innovations, the efficiency of the subsystem in entering and exiting sleep in a timely manner during data stream processing is significantly improved, the average power consumption is reduced, and the overall power consumption performance of the system is further optimized.

[0158] In summary, the cross-domain wake-up interrupt controller and heterogeneous multi-core chip of this invention include an event-driven wake-up module deployed in each sub-power domain participating in cross-domain communication, and a central coordination module deployed in the system hardware power management module. When a source sub-power domain needs to communicate with a destination sub-power domain that is in a low-power state, its event-driven wake-up module sends a wake-up request. The central coordination module is responsible for receiving the wake-up request and coordinating the system hardware power management module to wake up the corresponding destination sub-power domain. Once the destination sub-power domain is ready, the central coordination module immediately notifies the source sub-power domain to start data transmission. This invention adopts an event-driven, fine-grained power management approach, achieving efficient cross-domain wake-up and data interaction, significantly improving the system's response speed and power optimization capabilities, and ultimately enabling the entire system to achieve ultra-low power control while ensuring performance. Therefore, this invention effectively overcomes the various shortcomings of the prior art and has high industrial application value.

[0159] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the invention. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in the present invention should still be covered by the claims of the present invention.

Claims

1. A cross-domain wake-up interrupt controller, characterized in that, Applied to heterogeneous multi-core chips, the controller includes: multiple heterogeneous sub-power domains and a system hardware power management module, wherein the controller includes: An event-driven wake-up module is deployed in each sub-power domain participating in cross-domain communication to send a wake-up request to the destination sub-power domain for which the source sub-power domain needs to communicate across domains. The central coordination module, located in the system hardware power management module, is used to receive wake-up requests from each event-driven wake-up module, coordinate the system hardware power management module to wake up the corresponding destination sub-power domain through the event-driven wake-up module of the corresponding destination sub-power domain, and notify the corresponding source sub-power domain to transmit data after the corresponding destination sub-power domain is ready. The CPU interrupt process is executed through the cross-domain wake-up interrupt controller, including: the CPU of the source sub-power domain reads the status bit related to the destination sub-power domain. If the status bit is not set, the CPU of the source sub-power domain initiates a cross-domain communication request with the destination power domain, and the CPU of the source sub-power domain enters a light sleep state; after receiving this request, the central coordination module triggers the system hardware power management module to wake up the destination sub-power domain and monitors the destination sub-power domain in real time. Once the destination sub-power domain is in a power-ready state, the central coordination module controls the status bit related to the destination sub-power domain and sends a query success interrupt request to the interrupt controller of the source sub-power domain. After the CPU of the source sub-power domain responds to the query success interrupt, it checks again whether the status bit related to the destination sub-power domain is set. If it is confirmed to be set, the CPU of the source sub-power domain clears the query success interrupt and performs data transmission with the destination sub-power domain; after the data transmission is completed, the CPU of the source sub-power domain notifies the event-driven wake-up module that the data transmission session has ended.

2. The cross-domain wake-up interrupt controller according to claim 1, characterized in that, The cross-domain wake-up interrupt controller is used to send a query success interrupt request to the source sub-power domain after detecting that the destination sub-power domain is ready, so that the source sub-power domain can transmit data with the destination sub-power domain; it is also used to send a wake-up interrupt to the destination sub-power domain after the destination sub-power domain is woken up, to notify the destination sub-power domain that its power status has been restored.

3. The cross-domain wake-up interrupt controller according to claim 1, characterized in that, The CPU polling process, executed through the cross-domain wake-up interrupt controller, includes: the CPU of the source sub-power domain first reads the status bit related to the destination sub-power domain; if the status bit is not set, the CPU of the source sub-power domain initiates a request for cross-domain communication with the destination power domain; after receiving this request, the central coordination module triggers the system hardware power management module to wake up the destination sub-power domain and monitors the destination sub-power domain in real time; once the destination sub-power domain is in a power-ready state, the central coordination module controls the status bit related to the destination sub-power domain and sends a wake-up interrupt to the destination sub-power domain; when the CPU of the source sub-power domain polls the status bit related to the destination sub-power domain, it performs data transmission with the destination sub-power domain; after the data transmission is completed, the CPU of the source sub-power domain sets the write-only bit of the event-driven wake-up module, notifying the cross-domain wake-up interrupt controller that the current communication has ended, and the central coordination module coordinates the source and destination sub-power domains to enter a low-power state as soon as possible.

4. The cross-domain wake-up interrupt controller according to claim 1, characterized in that, During the CPU interrupt process, after the destination sub-power domain is woken up, the central coordination module sends a wake-up interrupt to the destination sub-power domain. The destination sub-power domain checks whether the write-only bit associated with the source sub-power domain is set. If it is set, the wake-up interrupt is cleared, and the destination sub-power domain is in a power-ready state.

5. The cross-domain wake-up interrupt controller according to claim 1, characterized in that, The CPU in the source power domain configures its internal DMA controller, setting the hardware trigger source for its DMA transfer to a specific hardware trigger signal from the event-driven wake-up module of the source power domain.

6. The cross-domain wake-up interrupt controller according to claim 5, characterized in that, The DMA interrupt process is executed through a cross-domain wake-up interrupt controller, including: the CPU of the source sub-power domain initiates a DMA wake-up request to the event-driven wake-up module, and the CPU of the source sub-power domain directly enters a shallow sleep state; after receiving this request, the central coordination module triggers the system hardware power management module to wake up the destination sub-power domain and monitors the destination sub-power domain in real time. Once the destination sub-power domain is in a power-ready state, the central coordination module notifies the source sub-power domain that the destination sub-power domain is ready; the event-driven wake-up module triggers a hardware DMA request signal from the source sub-power domain to the destination sub-power domain, triggering the DMA controller of the source sub-power domain to perform data transmission; after the DMA transmission is completed, the DMA controller of the source sub-power domain notifies the event-driven wake-up module of the source sub-power domain that the DMA transmission is complete, and the DMA controller sets its own DMA completion interrupt, and the CPU of the source sub-power domain exits the shallow sleep state; the event-driven wake-up module of the source sub-power domain sets the DMA completion interrupt signal to notify the destination sub-power domain that the DMA transmission is complete.

7. The cross-domain wake-up interrupt controller according to claim 6, characterized in that, During the DMA interrupt process, after the destination sub-power domain is woken up, the destination sub-power domain determines that the wake-up interrupt has been enabled. When the DMA transfer is in progress, the CPU of the destination sub-power domain enters a shallow sleep state. After the transfer is completed and the DMA completion interrupt signal from the cross-domain wake-up interrupt controller is received, the CPU of the destination sub-power domain exits the shallow sleep state and clears the wake-up interrupt.

8. The cross-domain wake-up interrupt controller according to claim 1, characterized in that, The cross-domain wake-up interrupt controller is also equipped with cross-clock domain signal synchronization, event flip detection, cross-voltage domain isolation and level conversion, and a two-way handshake mechanism.

9. A heterogeneous multi-core chip, characterized in that, The chip includes: a cross-domain wake-up interrupt controller as described in any one of claims 1 to 8.

Images