Integrated circuit with debugger and arbitration interface

Abstract

An integrated circuit (100) includes a debugger (102) and an interface (104) coupled to the debugger (102). The interface (104) has arbitration logic (106) coupled to the debugger (102), a power processor (108) coupled to the arbitration logic (106), and a power management network (112) coupled to the power processor (108). The integrated circuit (100) also includes subsystems (114A-114N) coupled to the interface (104). The debugger (102) is configured to perform debugging operations of the subsystems (114A-114N) via the interface (104).

Description

Background Technology

[0001] With the development of new electronic devices and advancements in integrated circuit (IC) technology, new IC products are being commercialized. An example IC product used in electronic devices is a System-on-a-Chip (SoC) with one or more processor cores. The SoC market is increasingly focused on efficiency and productivity. Industries such as factory automation equipment manufacturers, aerospace, defense, power grid infrastructure, building automation, and medical require SoCs with higher reliability. To meet stringent reliability specifications, many SoC designs incorporate embedded solutions while balancing performance, size, and overall cost targets. For SoCs, the reliance on various memory components and the use of small-geometry silicon process technologies present reliability challenges. Summary of the Invention

[0002] In one example embodiment, an integrated circuit includes: a debugger; and an interface coupled to the debugger. The interface has: arbitration logic coupled to the debugger; a power processor coupled to the arbitration logic; and a power management network coupled to the power processor. The integrated circuit also includes a subsystem coupled to the interface, wherein the debugger is configured to perform debugging operations of the subsystem via the interface.

[0003] In another example embodiment, a system includes an integrated circuit having: a terminal adapted for coupling to peripheral components; a processor core coupled to the terminal; and a memory coupled to the processor core and storing a debugger for execution by the processor core. The integrated circuit also includes an interface coupled to the processor. The interface has: arbitration logic; a power processor coupled to the arbitration logic; and a power management network coupled to the power processor. The integrated circuit also includes a subsystem coupled to the interface, wherein the processor core is configured to perform debugging operations of the subsystem via the interface.

[0004] In yet another example embodiment, a method includes: generating a debug request for a subsystem of the integrated circuit via a processor core of the integrated circuit; and generating a power processor interrupt via an interface between the processor core and the subsystem in response to the generated debug request. The method further includes: providing a notification to the interface via the power processor once the subsystem associated with the debug request is identified as being in an on state; and performing a debug operation via the interface via the processor core in response to the notification. Attached Figure Description

[0005] Figure 1 These are block diagrams of integrated circuits (ICs) in some examples.

[0006] Figure 2 These are block diagrams of some example systems.

[0007] Figure 3 These are block diagrams of ICs in some examples.

[0008] Figure 4 These are block diagrams of ICs in some examples.

[0009] Figure 5 These are schematic diagrams of the arbitration logic of ICs with embedded debuggers in some examples.

[0010] Figure 6 These are flowcharts of embedded debugging operations for some example ICs.

[0011] Figure 7 These are flowcharts of power-down sequences for IC lookup table (LUT) operations, as shown in some examples.

[0012] Figure 8 These are flowcharts illustrating some examples of debugging methods for ICs. Detailed Implementation

[0013] As described herein, an integrated circuit (IC) includes an embedded debugger for debugging a subsystem of the IC. In some example embodiments, the IC includes at least one processor core and memory, wherein the debugger is an application stored in the memory for execution by the at least one processor core. The IC also includes an interface between the debugger and the subsystem, wherein the debugger is configured to perform debugging operations on the subsystem via the interface. In some example embodiments, the interface includes: arbitration logic coupled to the debugger; a power processor coupled to the arbitration logic; and a power management network coupled to the power processor. As used herein, a "power processor" is a processor that manages the IC's clock, reset, or other power management tasks. In addition to power management tasks, the power processor may also perform other operations.

[0014] In some example embodiments, the arbitration logic is configured to: receive a debug request from a debugger; and, in response to the received debug request, generate an interrupt to the power processor. The power processor is configured to: in response to the interrupt, determine the power state of the subsystem associated with the debug request; if the determined power state of the subsystem associated with the debug request is in a shutdown state, perform a first set of operations associated with the debug request; and if the determined power state of the subsystem associated with the debug request is in a conduction state, perform a second set of operations associated with the debug request.

[0015] In some example embodiments, the first set of operations includes: providing a control signal to the power management network to activate the subsystem associated with the debug request; sending a notification to the arbitration logic to confirm that the subsystem associated with the debug request is in an on state; receiving a notification from the arbitration logic that the debug operation associated with the debug request is complete; and, in response to the received notification, providing a control signal to the power management network to restore the subsystem associated with the debug request to a off state. In some example embodiments, the second set of operations includes: sending a notification to the arbitration logic to confirm that the subsystem associated with the debug request is in an on state; receiving a notification from the arbitration logic that the debug operation associated with the debug request is complete; and, in response to the received notification, keeping the subsystem associated with the debug request in an on state.

[0016] In some example embodiments, the IC includes a secure microcontroller (MCU) domain (sometimes referred to as an "MCU island") that includes some of the components for a debugger and interface. For example, the secure microcontroller domain may include a processor that executes at least a portion of the debugger. Furthermore, in some example embodiments, the secure microcontroller domain may include a power processor and arbitration logic. In some example embodiments, the described techniques relate to on-chip emulators to support communication between the secure microcontroller domain and other components of the IC as needed.

[0017] In some example embodiments, the IC is an infotainment IC that includes interfaces supporting communication with displays, sensors, and / or other peripheral devices. In some example embodiments, the IC includes an Advanced Driver Assistance Systems (ADAS) physical (PHY) interface to support communication with ADAS-compatible peripheral devices or applications. In other example embodiments, the IC is an industrial application IC having interfaces supporting communication with displays, sensors, and / or other peripheral devices in factory or industrial applications (e.g., factory automation equipment manufacturers, aerospace, defense, power grid infrastructure, building automation, and / or medical applications).

[0018] In operation, the interface and / or power processor can use a System-on-Chip (SoC) map or lookup table (LUT) to track the power state of the subsystem. When the debugger wants the power processor to activate any subdomain, the power processor uses the map or LUT to determine the power state of the subsystem associated with the debug request. Compared to other embedded debugger IC options, the described technique is less invasive and avoids complex hardware for safely performing debug operations. The described embedded debugger IC option leverages available power processors and interrupt protocols to perform power management of the subsystem associated with the debug operation. In this way, the IC or SoC enables embedded secure debugging of the IC subsystem to achieve target reliability while meeting performance, size, and overall cost objectives.

[0019] Figure 1 This is a block diagram of IC 100 in some examples. As shown, IC 100 includes an interface 104 coupled between debugger 102 and subsystems 114A-114N. In some example embodiments, debugger 102 is an application stored in memory and executed by the processor core of IC 100. Additionally or alternatively, debugger 102 may include hard-coded logic to perform at least some of the debugging operations described herein. Figure 1 In this process, debugger 102 interacts with subsystems 114A-114N via interface 104, which includes arbitration logic 106, power processor 108, and power management network 112.

[0020] In some example embodiments, arbitration logic 106 is configured to: receive a debug request from debugger 102; and generate an interrupt to power processor 108 in response to the received debug request. Power processor 108 is configured to: in response to the interrupt, determine the power state of a subsystem (e.g., one of subsystems 114A-114N) associated with the debug request; if the determined power state of the subsystem associated with the debug request is in a shutdown state, perform a first set of operations associated with the debug request; and if the determined power state of the subsystem associated with the debug request is in a conduction state, perform a second set of operations associated with the debug request.

[0021] In some example embodiments, a first set of operations for the power processor 108 includes: providing a control signal to the power management network to activate the subsystem associated with the debug request; sending a notification to arbitration logic 106 to confirm that the subsystem associated with the debug request is in an on state; receiving a notification from arbitration logic 106 that the debug operation associated with the debug request is complete; and, in response to the received notification, providing a control signal to the power management network 112 to restore the subsystem associated with the debug request to a off state. In some examples, the power processor 108 uses LUT 110 or other organized data to determine the power state of subsystems 114A-114N and perform subsequent operations. In some example embodiments, a second set of operations includes: sending a notification to arbitration logic 106 to confirm that the subsystem associated with the debug request is in an on state; receiving a notification from arbitration logic 106 that the debug operation associated with the debug request is complete; and, in response to the received notification, keeping the subsystem associated with the debug request in an on state.

[0022] For IC 100, debugger 102 utilizes the availability of power processor 108 and interrupt protocols to perform power management for any subsystems 114A-114N related to debug operations. In this way, IC 100 enables embedded secure debugging of subsystems 114A-114N as needed to achieve target reliability while meeting IC 100's performance, size, and overall cost objectives.

[0023] Figure 2 These are block diagrams of system 200 in some examples. As shown, system 200 includes IC 100A ( Figure 1 Examples of integrated circuit 100. In some examples, IC 100A is an infotainment IC (e.g., for use in vehicles). As shown, IC 100A is coupled to peripheral devices such as display 202, sensor(s)204, and ADAS PHY interface 208. In some example embodiments, ADAS PHY interface 208 is omitted. System 200 also includes a power management IC (PMIC) 206 coupled to IC 100A and configured to at least power IC 100A. PMIC 206 is configured to power integrated circuit 100A. In some example embodiments, IC 100A is an infotainment IC with debugger operation as described herein (e.g., for use in vehicles). In other example embodiments, IC 100A is an industrial IC (e.g., for factory automation equipment manufacturers, aerospace, defense, power grid infrastructure, building automation, or medical applications). Regardless of specific purpose or application, the IC100A implements embedded secure debugging of its subsystems as described in this article to achieve target reliability while meeting the performance, size, and overall cost targets of the IC 100.

[0024] Figure 3 These are some examples of IC 300 ( Figure 1 IC 100 or Figure 2 A block diagram of IC 100A (example). Figure 3 In this document, IC 300 is an example of an infotainment IC with a debugger, interface, and subsystems as described herein. Figure 1 IC 100 and Figure 3 Related to IC 300, Figure 1 The debugger 102 includes the secure MCU domain or MCU island 336 and Figure 3 Debugger operations running in other parts of the IC 300. Figure 1 Interface 104 is Figure 3 It is part of MCU Island 336. Furthermore... Figure 3 The processor cores 302 and 308 and the memory subsystem 326 are Figure 1Examples of subsystems 114A-114N are provided. Other example subsystems include controllers, communication interfaces, programmable circuit systems, or special-purpose circuit systems. Figure 3 IC 300 is for illustrative purposes only and does not limit the technology described to any particular IC and related set of components.

[0025] As shown in the figure, IC 300 includes a first processor core 302 (e.g., a 512KB L2 cache with error correction codes (ECC)) having one or more processors 304 and memory 306. Integrated circuit 300 also includes a second processor core 308 (e.g., a 512KB L2 cache with ECC) having one or more processors 310 and memory 312. Figure 3 In the example, the first core 302 and the second core 308 are configured to run a software application, which may be at least partially stored in one or both of processor cores 302 or 308 (e.g., in memories 306 and 312) or in memory subsystem 326. As shown, memory subsystem 326 includes various example blocks such as a multi-core shared memory controller (MSMC) (e.g., a 2MB static random access memory SRAM with ECC), a general-purpose memory controller (GPMC), an extreme learning machine (ELM), and an external memory interface (EMIF) with ECC.

[0026] exist Figure 3 In addition, IC 300 also includes: a graphics module 314 with a graphics processing unit (GPU) 316; an industrial subsystem module 320 with a microcontroller 322 (labeled PRU_ICSSG) to support an Ethernet port; and a navigation subsystem 324. In some example embodiments, the navigation subsystem 324 includes a unified direct memory access (UDMA) block, a proxy block, a peripheral virtualization unit (PVU) block, a common platform timestamp (CPTS) block, a ring accelerator (RA) proxy data buffer, a memory cyclic redundancy check (MCRC) accelerator, interrupt blocks (INTR and INTA), a mailbox block, a spinlock block, a timer manager (TIMER_MGR) block, and a channelized firmware (FW) block.

[0027] As shown in the figure, IC 300 also includes a display subsystem 328. In some example embodiments, the display subsystem 328 includes a video pipeline block (e.g., a mix / scale / color space converter or "CSC"), a digital video interface (e.g., open LDI) block, and a MIPI interface and display port interface (MIPI DPI) block. Furthermore, IC 300 includes a system service module 330. In some example embodiments, system service module 330 includes a general purpose (GP) timer, a real-time interrupt (RTI) and window watchdog timer (WWDT) block, a peripheral direct memory access (PDMA) block, and a debug block. Additionally, IC 300 includes a video input module 332. In some example embodiments, video input module 332 includes a CAL block, a MIPI CSI-2 block, a low voltage differential signal receiver (LVDSRX) block, and a video processing (e.g., BT.656 / 1120) block.

[0028] exist Figure 3 In addition, IC 300 also includes a security accelerator module 334. In some example embodiments, the security accelerator module 334 includes an Advanced Encryption Standard (AES) block, a Secure Hash Standard (SHA) block, a Public Key Accelerator (PKA) block, a Deterministic Random Bit Generator (DRBG), a Message Digest Algorithm (MD5) block, and a Data Encryption Standard (3DES) block.

[0029] As shown in the figure, the MCU island 336 of the IC includes a navigation subsystem 338 and one or more processors 340. In some example embodiments, the navigation subsystem 338 includes an RA block, a UDMA block, a proxy block, an MCRC block, interrupt blocks (INTR and INTA), and a channelized FW block. In one example, one or more processors 340 within the MCU island 336 can be used as a power processor, and a debugger can interact with the processor 340 to control various signals provided to the subsystem being debugged, such as power, clock, and / or reset, or to perform other power management tasks. The MCU island 336 also includes various other components, including a PDMA block, a GP timer, an error signaling module (ESM), an RTI / WWDT block, and memory (e.g., scratchpad RAM 512B and MCU_MSRAM 512KB). In some example embodiments, the MCU island 336 includes various components related to the techniques described herein, such as... Figure 1 At least some of the debugger 102 and interface 104 (e.g., arbitration logic 106 and power processor 108).

[0030] IC 300 also includes interconnects 342 that enable communication between MCU island 336 and other components or subsystems of IC 300. Example components of IC 300 include an auto interface 344, a media and data storage device 346, a control interface 348, and an audio peripheral 350. The auto interface 344 includes, for example, a controller area network with a flexible data rate (MCAN_FD) block. The media and data storage device 346 includes, for example, a multimedia card (MMC) / secure digital card (SD) block. The control interface 348 includes an enhanced high-resolution pulse width modulation (eHRPWM) block, an enhanced capture (eCAP) block, and an enhanced quadrature encoder pulse (eQEP) block. The audio peripheral 350 includes, for example, a multi-channel audio serial port (MCASP) block.

[0031] As shown in the figure, IC 300 also includes a general-purpose connectivity module 352. In some example embodiments, the general-purpose connectivity module includes a general-purpose input / output (GPIO) block, an octal serial peripheral interface (OSPI) and Hyperbus block, a communication interface (e.g., I2C) block, a multi-channel serial port interface (MCSPI) block, an analog-to-digital converter (ADC), and a universal asynchronous receiver / transmitter (UART) block. IC 300 also includes a high-speed serial interface module 354. In some example embodiments, the high-speed serial interface module 354 includes a peripheral component interconnect fast (PCIe) block, a universal serial bus (USB) 2.0 block, a USB 3.1 block, and an Ethernet block.

[0032] For IC 300, the debugger running in MCU island 336 utilizes the availability of a power processor (e.g., one of processors 340) and interrupt protocols to perform power management for any subsystem (e.g., processor cores 302, 308, memory subsystem 326, or other subsystems) compatible with debug operations. In this way, IC 300 enables embedded secure debugging of subsystems as needed to achieve target reliability while meeting IC 300's performance, size, and overall cost objectives.

[0033] Figure 4 These are some examples of IC 400 ( Figure 1 IC 100 in Figure 2 IC 100A or Figure 3 A block diagram of IC 300 (example of IC 300). As shown in the figure, IC 400 includes a debugger subsystem (DebugSS) 102A ( Figure 1 Example of debugger 102), the debugger subsystem 102A via arbitration logic 414 ( Figure 1 Example of arbitration logic 106 in the example) is coupled to subsystems 416A-416N ( Figure 1Examples of subsystems 114A-114N in the example). Arbitration logic 414 is also coupled to power processor 108A ( Figure 1 (Example of power processor 108 in the example). Figure 4 In the examples, each of subsystems 416A-416N includes a debug target central processing unit (CPU) 418A-418N or other target components(s). Each of subsystems 416A-416N also includes a corresponding power and sleep controller (PSC) and / or local power and sleep controller (LPSC) module 420A-420N. In some examples, the PSC / LPSC module 420A-420N is part of a power management network (e.g., power management network 112) to control the clock and / or power supply of subsystems 416A-416N of IC 400.

[0034] More specifically, the debugger subsystem 102A includes a debug pin (DP) interface 402 configured to receive Joint Test Action Group (JTAG) communication. The DP interface 402 is coupled to a bus (DAPBUS) 404. As shown, the debugger subsystem 102A also includes a bridge 406 and a debug authentication interface (referred to as Power-AP) 408 coupled to the bus 404. In operation, the debug authentication interface 408 is configured to transmit debug requests to arbitration logic 414.

[0035] In response to a debug request from debugger subsystem 102A, arbitration logic 414 asserts an interrupt (Debug Req Int) to power processor 108A. Power processor 108A is configured to: in response to the interrupt, determine the power state of the subsystem associated with the debug request; and if the determined power state of the subsystem associated with the debug request is off, perform a first set of operations to power on the subsystem associated with the debug request. In some example embodiments, the first set of operations performed by power processor 108A includes: providing control signal 413 to the power management network (e.g., a corresponding one of PSC / LPSC modules 420A-420N) to start the subsystem associated with the debug request; and sending a notification (safety device notification) to arbitration logic 414 to confirm that the subsystem associated with the debug request is on. In some example embodiments, the first set of operations performed by the power processor 108A further includes: receiving a notification from the arbitration logic 414 that a debug operation related to the debug request has been completed (e.g., using Debug Req Int); and in response to the received notification, providing a control signal to the power management network (e.g., a corresponding one of the PSC / LPSC modules 420A-420N) to restore the subsystem related to the debug request to a shutdown state.

[0036] In some example embodiments, the power processor 108A is configured to perform a second set of operations if the determined power state of the subsystem associated with the debug request is in an on state. In one example, the second set of operations includes: sending a notification (security device notification) to arbitration logic 414 to confirm that the subsystem associated with the debug request is in an on state; receiving a notification from arbitration logic 414 that the debug operation associated with the debug request has been completed (e.g., using Debug Req Int); and, in response to the received notification, keeping the subsystem associated with the debug request in an on state.

[0037] exist Figure 4 In the example, arbitration logic 414 includes a memory-mapped register (MMR) 415 or other storage to track configuration or status bits associated with debug operations. Furthermore, in some example embodiments, arbitration logic 414 is coupled to power processor 108A via interconnect 410 (labeled as SoC interconnect). Figure 4 In the example, the power processor 108A and the arbitration block 414 provide interfaces (e.g., Figure 1 Interface 104 in IC 400 allows debugging of any of subsystems 416A-416N. For IC 400, arbitration logic 414 enables debugger 102A to utilize the availability of power processor 108A and interrupt protocols to perform power management of any subsystem 416A-416N related to debug operations of debugger 102A. In this way, IC 400 implements embedded secure debugging of subsystems 416A-416N as needed to achieve target reliability while meeting IC 400's performance, size, and overall cost objectives.

[0038] Figure 5 These are some examples of ICs with embedded debuggers (e.g., Figure 1 IC 100 in Figure 2 IC100A in Figure 3 IC 300 or Figure 4 Arbitration logic 500 (IC 400) Figure 1 Arbitration logic 106 or Figure 4 A schematic diagram of an example of arbitration logic 414 is shown. As shown, arbitration logic 500 includes inputs 502, 504, 508, 534, and 538. Input 502 is configured to receive notifications (e.g., security device notifications) from a power processor as described herein. Input 504 is configured to receive notifications (e.g., from a debugger, etc.) from a debugger. Figure 4 The debugger subsystem 102A receives a control signal (ForceActive). Input 508 is configured to receive a control signal from the debugger (e.g., ...). Figure 4The debugger subsystem 102A in the middle receives another control signal (InhibitSleep). Input 534 is configured to receive a signal from the power management network (e.g., Figure 4 The corresponding PSC / LPSC module in the 420A-420N receives a notification (ForceActiveACK). Input 538 is configured to receive a notification from the power management network (e.g., Figure 4 The corresponding PSC / LPSC module in the 420A-420N receives the notification (InhibitSleepACK).

[0039] As shown in the figure, the arbitration logic 500 also includes outputs 506, 510, 532, 536, and 548. Output 506 is configured to provide a first type of notification (e.g., ForceActiveACK) to the debugger. Output 510 is configured to provide a second type of notification (e.g., InhibitSleepACK) to the debugger. Output 532 is configured to provide a second type of notification (e.g., InhibitSleepACK) to the power management network (e.g., Figure 4 The corresponding PSC / LPSC module 420A-420N in the PSC / LPSC module 536 provides a first type of control signal (e.g., ForceActive). Output 536 is configured to provide a first type of control signal (e.g., ForceActive) to the power management network (e.g., Figure 4 The corresponding PSC / LPSC module 420A-420N in the PSC / LPSC module 548 provides a first type of control signal (e.g., InhibitSleep). Output 548 is configured to supply a power processor as described herein (e.g., Figure 1 The power processor 108 or Figure 4 The power processor 108A in the middle provides an interrupt (debug_forceactive_int).

[0040] exist Figure 5 In this configuration, arbitration logic 500 includes OR gates between inputs 502, 504, 508, 534, and 538 and different inputs among 506, 510, 532, and 536. As shown, arbitration logic 500 includes a buffer 511 coupled to input 502. The output of buffer 511 is one of the inputs to AND gate 528. The output of the AND gate is provided to output 532. As shown, another input to AND gate 528 comes from the output of another AND gate 524, where one input to AND gate 524 is coupled to input 504. The other input to AND gate 524 is coupled to bypass override register 550 (BYPASS_OVERRIDE). Figure 5In this context, the bypass override register 550 is one of the various registers 550, 552, 554, 556, 558, 560, 562, 564, 566, 568, 570, 572, and 574 of the arbitration logic 500. These registers are... Figure 4 An example of MMR 415. In Figure 5 In the example, these registers are coupled to interface 540, which enables a debugger or other IC component to inspect or clear configuration and / or status bits related to the operation of arbitration logic 500.

[0041] As shown in the figure, input 504 is also coupled to: the first control signal port status register (FORCEACTIVE_PORT_STAT) 558; and the input of another AND gate 530. The output of AND gate 530 is coupled to output 536. Another input of AND gate 530 comes from the output of another AND gate 526. As shown in the figure, one input of ABD gate 526 is coupled to input 508, while the other input of AND gate 526 is coupled to bypass override register 550. As shown in the figure, input 508 is also coupled to the second control signal port status register 552 (INHIBITSLEEP_PORT_STAT).

[0042] exist Figure 5 In the example, output 506 is coupled to the output of multiplexer 512. As shown, input 534 is coupled to the first input of multiplexer 512. The second input of multiplexer 512 is coupled to the first control signal confirmation set register (FORCEACTIVE_ACK_SET) 560, and the control signals for multiplexer 512 are provided by bypass override block 550. Furthermore, output 510 is coupled to the output of another multiplexer 514. As shown, input 538 is coupled to the first input of multiplexer 514. The second input of multiplexer 514 is coupled to the second control signal confirmation set register (INHIBITSLEEP_ACK_SET) 554, and the control signals for multiplexer 514 are provided by bypass override register 550.

[0043] Arbitration logic 500 also includes an XOR gate 516 having a first input coupled to input 504 and a second input coupled to a first control signal confirmation setting block 560. The output of XOR gate 516 is coupled to a control block (REQ EVT SET / CLR) 518, which is configured to provide a signal to a first control signal interrupt status register (FORCEACTIVE_INT_RAW_STAT_SET) 570 to set or clear an interrupt associated with the first control signal (ForceActive). Arbitration logic 500 also includes an XOR gate 520 having a first input coupled to input 508 and a second input coupled to a second control signal confirmation setting register 554. The output of XOR gate 520 is coupled to control block (REQ EVT SET / CLR) 522, which is configured to provide a signal to the second control signal interrupt status register (INHIBITSLEEP_INT_RAW_STAT_SET) 568 to set or clear the interrupt associated with the second control signal (InhibitSleep).

[0044] exist Figure 5 In the example, arbitration logic 500 also includes an interrupt generator 546, which is coupled to a second control signal interrupt state block 568 and a first control signal interrupt state block 570 via an OR gate 544. The OR gate 544 also receives requests from an interrupt request source (IRQ_*_STAT Ports[31:1]) 542, which is configured to signal when an interrupt request is received at each IC port. The output of interrupt generator 546 is coupled to output 548. In some example embodiments, interrupt generator 546 is selectively enabled by a control signal from an interrupt enable clear register (INT EN CLR) 574.

[0045] As shown in the figure, the arbitration logic 500 further includes: a second control signal confirmation clear register 556 (INHIBITSLEEP_ACK_CLR); a first control signal confirmation clear register 562 (FORCEACTIVE_ACK_CLR); a second control signal interrupt enable state clear register 564 (INHIBITSLEEP_INT_EN_STAT_CLR); and a first control signal interrupt enable state clear register 566 (FORCEACTIVE_INT_EN_STAT_CLR). In different example embodiments, the arbitration logic 500 varies with the specific logic, gates, and registers used to handle debug requests, interrupts, and notifications as described herein.

[0046] Figure 6 These are some examples of ICs (e.g., Figure 1 IC 100 in Figure 2 IC 100A in Figure 3 IC 300 or Figure 4 The flowchart illustrates the embedded debug operation 600 of IC 400. As shown, the embedded debug operation 600 includes authenticating a secure session in response to a request from the debug subsystem (as described herein) at block 602. If authentication fails (decision block 604), the power processor does not service the request at block 608. If authentication succeeds (decision block 604), the power processor servicees the request at block 606. At block 610, the power processor: checks the arbitration logic for the ID requester; enables the phase-locked loop (PLL), firmware (FW), and additional MMR settings; enforces power wake-up dependencies; enables the channel from the arbitration logic to the target subsystem; and completes the subsystem enable process.

[0047] Figure 7 These are some examples of ICs (e.g., Figure 1 IC 100 in Figure 2 IC 100A in Figure 3 IC 300 or Figure 4 The flowchart illustrates the power-down sequence 700 of the LUT operation for IC 400 in the diagram. As shown, the power-down sequence 700 includes the debugger initiating a lookup action at block 702. At block 704, the debugger requests an activity in the subsystem. At block 706, the clock source for the requested subsystem activity is set. At block 708, other clock sources that the requested subsystem depends on are set. At block 710, other power domains that the requested subsystem depends on are set. At block 712, the power domain of the requested subsystem is set. At block 714, the clock gating of the requested subsystem is removed. At block 716, all security settings allowing access to / from the requested subsystem are configured. At block 718, all other settings allowing the requested subsystem to enter activity are configured. At block 720, the requested subsystem is released, reset, or not stopped. In some example embodiments, the subsystem is disabled by executing sequence 700 in reverse (e.g., after a secure debug session).

[0048] Figure 8 These are flowcharts of method 800 in some examples. Method 800 is provided by IC (e.g., Figure 1 IC 100 Figure 2 IC100A, Figure 3 IC 300 or Figure 4 The method 800 is executed by the processor core of the integrated circuit (e.g., one of processor cores 302 and 308) at block 802. As shown, the method includes the following steps at block 802: Figure 4The debugger subsystem 102A in the middle generates a subsystem for integrated circuits (e.g., Figure 1 One of the subsystems 114A-114N, or Figure 4 Debugging requests for one of the subsystems 416A-416N in the system (e.g., Figure 5 In ForceActive or InhibitSleep). At box 804, in response to the generated debug request, through the interface between the processor core and the subsystem (e.g., ForceActive or InhibitSleep). Figure 1 Interface 104 in Figure 4 The arbitration logic 414 and power processor 108A in the block generate a power processor interrupt. At block 806, once the subsystem associated with the debug request is identified as being in a conducting state, a notification is provided to the interface via the power processor (e.g., ...). Figure 5 (ForceActiveACK or InhibitSleepACK in the code). At box 808, in response to a notification, debug operations are performed via the interface through the processor core.

[0049] In some example embodiments, method 800 includes additional operations such as: in response to a power processor interrupt, determining, via the power processor, the power state of the subsystem associated with the debug request; and if the determined power state of the subsystem associated with the debug request is in a shutdown state, performing a first set of operations via the power processor to start the subsystem. In some example embodiments, performing the first set of operations via the power processor for method 800 includes: providing a control signal to the power management network of the integrated circuit to start the subsystem associated with the debug request; sending a notification to the arbitration logic of the integrated circuit to confirm that the subsystem associated with the debug request is in a conduction state; receiving a notification from the arbitration logic that the debug operation associated with the debug request has been completed; and in response to the received notification, providing a control signal to the power management network to restore the subsystem associated with the debug request to a shutdown state. In some example embodiments, method 800 further includes performing a second set of operations via the power processor if the determined power state of the subsystem associated with the debug request is in a conduction state. In some example embodiments, performing a second set of operations for method 800 via a power processor includes: sending a notification to the arbitration logic of the integrated circuit to confirm that the subsystem associated with the debug request is in an on state; receiving a notification from the arbitration logic that the debug operation associated with the debug request has been completed; and, in response to the received notification, keeping the subsystem associated with the debug request in an on state.

[0050] The term "coupled" is used throughout this specification. This term can encompass a connection, communication, or signal path that achieves a functional relationship consistent with this description. For example, if device A generates a signal to control device B to perform an action, in the first example, device A is coupled to device B; or in the second example, if the intervening component C substantially does not alter the functional relationship between device A and device B, device A is coupled to device B via the intervening component C, such that control signals generated by device B via device A are controlled by device A.

[0051] Modifications to the described embodiments are possible within the scope of the claims, and other embodiments are also possible.

Claims

1. An integrated circuit, comprising: debugger; An interface coupled to the debugger, the interface having: Arbitration logic, which is coupled to the debugger; A power management processor coupled to the arbitration logic; and A power management network coupled to the power management processor; as well as Subsystem, which is coupled to the interface, wherein: The debugger is configured to perform debugging operations via the interface by providing the arbitration logic with a debug request associated with the subsystem; The arbitration logic is configured to provide an interrupt associated with the subsystem to the power management processor based on the debug request; and The power management processor is configured to operate based on the interrupt: The power management network is prompted to start the subsystem in response to determining that the subsystem is in an inactive state, and to provide the arbitration logic with a first notification indicating that the subsystem is in an active state; Receive a second notification from the arbitration logic that the debugging operation related to the debugging request has been completed; and This causes the power management network to put the subsystem in the inactive state.

2. The integrated circuit according to claim 1, wherein, The integrated circuit is an infotainment integrated circuit, the interface is part of a secure microcontroller domain, and the subsystem includes at least one of a processor or a memory.

3. The integrated circuit according to claim 1, wherein, The arbitration logic is configured as follows: Set the clock source that the requested subsystem depends on to be active; Set the power domain on which the subsystem depends to be active; as well as Remove the clock gating of the requested subsystem.

4. The integrated circuit according to claim 1, wherein: The interrupt is the first interrupt; and The second notification is the second interruption.

5. The integrated circuit of claim 4, wherein the first interrupt and the second interrupt are different assertions of a single interrupt signal.

6. The integrated circuit according to claim 1, wherein, To enable the power management network to start the subsystem, each clock source on which the subsystem depends is set to an on state, and the security associated with the subsystem is configured to allow the debugger to access and from the subsystem before the debugging operation is performed.

7. An integrated circuit, comprising: debugger; An interface coupled to the debugger, the interface having: Arbitration logic, which is coupled to the debugger; A power management processor coupled to the arbitration logic; and A power management network coupled to the power management processor; as well as Subsystem, which is coupled to the interface, wherein: The debugger is configured to perform debugging operations via the interface by providing the arbitration logic with a debug request associated with the subsystem; The arbitration logic is configured to provide an interrupt associated with the subsystem to the power management processor based on the debug request; and The power management processor is configured to respond to the interrupt: Determine the power state of the subsystem; The power management network is prompted to start the subsystem and put it into an active state in response to determining that the subsystem is in an inactive state; and Based on the power state being the startup state, a notification is provided to the arbitration logic to confirm that the subsystem is in the startup state.

8. The integrated circuit according to claim 7, wherein: The notification is the first notification; and The power management processor is configured to, based on the power state being the startup state: Receive a second notification from the arbitration logic that the debugging operation related to the debugging request has been completed; and This causes the subsystem to remain in the startup state.

9. A system comprising: Integrated circuits have the following characteristics: A terminal that is suitable for coupling to peripheral components; A processor core, which is coupled to the terminal; A memory coupled to the processor core and storing a debugger for execution by the processor core; An interface coupled to the processor core, the interface having: Arbitration logic; A power management processor coupled to the arbitration logic; and A power management network coupled to the power management processor; as well as Subsystem, which is coupled to the interface, wherein: The processor core is configured to perform debugging operations via the interface by providing the arbitration logic with a debug request associated with the subsystem; The arbitration logic is configured to provide an interrupt to the power management processor based on the debug request; and The power management processor is configured to respond to the interrupt: Determine the power state of the subsystem; The power management network is prompted to start the subsystem and put it into the startup state in response to determining that the subsystem is in an inactive state; Provide the arbitration logic with a first notification to indicate that the subsystem is in the startup state; and Receive a second notification from the arbitration logic that the debugging operation related to the debugging request has been completed.

10. The system according to claim 9, wherein, The power management processor is configured to: The power management network is prompted to restore the subsystem to the inactive state based on the second notification.

11. The system according to claim 9, wherein, The power management processor is configured to: In response to the second notification, the subsystem remains in the startup state.

12. The system according to claim 9, wherein, To enable the power management network to start the subsystem and place it in the startup state, each clock source on which the subsystem depends is set to the on state, and the security associated with the subsystem is configured to allow access to and from the subsystem by the debugger before the debugging operation is performed.

13. A method comprising: The processor core of the integrated circuit generates a debug request for the subsystem of the integrated circuit. In response to the debug request, a power management processor interrupt is generated through the interface between the processor core and the subsystem; Based on the power management processor interrupt: The power management processor determines whether the subsystem is in an on state; When it is determined that the subsystem is in the off state, the power management processor causes the subsystem to be in the on state; as well as Once the subsystem associated with the debugging request is identified as being in the on state, a first notification is provided to the interface via the power management processor; In response to the notification, a debugging operation is performed via the processor core through the interface; as well as The power management processor receives a second notification that the debugging operation related to the debugging request has been completed, wherein the second notification indicates whether the subsystem should remain in the on state or return to the off state.

14. The method of claim 13, further comprising: Based on the second notification, the subsystem is prompted to return to the shutdown state.

15. The method of claim 13, further comprising: Based on the second notification, the subsystem is kept in the on state.

16. The method according to claim 13, wherein, The power management processor causes the subsystem to be in the on state, which includes setting each clock source on which the subsystem depends to the on state, and the method further includes configuring security associated with the subsystem to allow access to and from the subsystem prior to performing the debugging operation.

Images