Integrated Circuit with Debugger and Arbitration Interface

Abstract

The 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 on the subsystems (114A-114N) via the interface (104).

Description

Technical Field

[0001] As new electronic devices are developed and integrated circuit (IC) technology advances, new IC products are commercialized. One exemplary IC product for electronic devices is a system-on-chip (SoC) that includes one or more processor cores. In the SoC market, there is increasing attention to efficiency and productivity. Industries such as factory automation equipment manufacturers, aerospace, defense, power grid infrastructure, building automation, and healthcare have come to require more reliable SoCs. To meet the required reliability specifications, many SoC designs include embedded solutions while balancing performance, size, and overall cost goals. In the case of SoCs, issues of reliability arise due to dependencies on various memory elements and the use of small geometry silicon process technologies.

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, and the debugger is configured to perform debug operations on the subsystem via the interface.

[0003] In another exemplary embodiment, the system includes an integrated circuit, the integrated circuit having terminals adapted to be coupled to peripheral device components, a processor core coupled to the terminals, 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, and the processor core is configured to perform debug operations of the subsystem via the interface.

[0004] In yet another exemplary embodiment, a method includes generating, by a processor core of an integrated circuit, a debug request for a subsystem of the integrated circuit, and generating, by an interface between the processor core and the subsystem, a power processor interrupt in response to the generated debug request. The method also includes providing, by the power processor, a notification to the interface when it is identified that the subsystem associated with the debug request is in an on state, and performing, by the processor core via the interface, a debug operation in response to the notification. BRIEF DESCRIPTION OF THE DRAWINGS

[0005]

Figure 1

[0006]

Figure 2

[0007]

Figure 3

[0008]

Figure 4

[0009]

Figure 5

[0010]

Figure 6

[0011]

Figure 7

[0012]

Figure 8

DETAILED DESCRIPTION OF THE INVENTION

[0013] As described herein, an integrated circuit (IC) includes an embedded debugger for debugging a subsystem of the IC. In some exemplary embodiments, the IC includes at least one processor core and memory, and the debugger is an application stored in the memory for execution by at least one processor core. The IC also includes an interface between the debugger and the subsystem, and the debugger is configured to perform debug operations on the subsystem via the interface. In some exemplary 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 clocks, resets, or other power management tasks of the IC. The power processor may also perform other operations in addition to power management tasks.

[0014] In some exemplary embodiments, the arbitration logic is configured to receive a debug request from a debugger and generate an interrupt to the power processor in response to the received debug request. The power processor is configured to determine the power state of the subsystem associated with the debug request in response to the interrupt, and if the determined power state of the subsystem associated with the debug request is the off 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 the on state, perform a second set of operations associated with the debug request.

[0015] In some exemplary 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 the 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 the off state. In some exemplary 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 the 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, maintaining the subsystem associated with the debug request in the on state.

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

[0017] In some exemplary embodiments, the IC is an infotainment IC that includes an interface to assist in communication with a display, sensors, and / or other peripheral devices. In some exemplary embodiments, the IC includes an advanced driver assistance system (ADAS) physical (PHY) interface that assists in communication with ADAS-compatible peripheral devices or applications. In other exemplary embodiments, the IC is an industrial-use IC that includes an interface to assist in communication with a display, sensors, and / or other peripheral devices in factory or industrial use (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 track the power state of the subsystem using a system-on-chip (SoC) map or look-up table (LUT). When the debugger desires the power processor to activate any of the subdomains, the map or LUT is used by the power processor to determine the power state of the subsystem associated with the debug request. Compared to other embedded debugger IC options, the techniques described are less intrusive and avoid complex hardware for safely performing debug operations. The embedded debugger IC options described utilize the available power processor and interrupt protocol to perform power management of the subsystems associated with debug operations. In this way, the IC or SoC achieves embedded secure debug of the IC subsystem while meeting performance, size, and overall cost goals and achieving the target reliability.

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

[0020] In some exemplary embodiments, the arbitration logic 106 is configured to receive a debug request from the debugger 102 and generate an interrupt to the power processor 108 in response to the received debug request. The power processor 108 determines the power state of a subsystem (e.g., one of the subsystems 114A - 114N) associated with the debug request in response to the interrupt, and if the determined power state of the subsystem associated with the debug request is off, performs 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 on, is configured to perform a second set of operations associated with the debug request.

[0021] In some exemplary embodiments, the first set of operations of the power processor 108 includes providing a control signal to the power management network to start the subsystem associated with the debug request, sending a notification to the arbitration logic 106 to confirm that the subsystem associated with the debug request is in an on state, receiving a notification from the 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 an off state. In some examples, the power processor 108 uses the LUT 110, or other organized data, to determine the power state of the subsystems 114A - 114N and perform subsequent operations. In some exemplary embodiments, the second set of operations includes sending a notification to the arbitration logic 106 to confirm that the subsystem associated with the debug request is in an on state, receiving a notification from the arbitration logic 106 that the debug operation associated with the debug request is complete, and in response to the received notification, maintaining the subsystem associated with the debug request in an on state.

[0022] Using IC100, the debug device 102 utilizes the availability of the power processor 108 and the interrupt protocol to perform power management for any of the subsystems 114A - 114N related to the debug operation. In this way, IC100 achieves the embedded secure debug of subsystems 114A - 114N as needed to meet the performance, size, and overall cost goals of IC100 while achieving the target reliability.

[0023] FIG. 2 is a block diagram of a system 200 in some examples. As shown, the device 200 includes IC100A (an example of the integrated circuit 100 of FIG. 1). In some examples, IC100A is an infotainment IC (e.g., for vehicles). As shown, IC100A is coupled to peripheral devices such as a display 202, a sensor 204, and an ADAS PHY interface 208. In some exemplary embodiments, the ADAS PHY interface 208 is omitted. Also, the system 200 includes a power management IC (PMIC) 206 coupled to IC100A and configured to provide power to at least IC100A. PMIC206 is configured to supply power to integrated circuit 100A. In some exemplary embodiments, IC100A is an infotainment IC (e.g., in - vehicle) with debugger operations as described herein. In other exemplary embodiments, IC100A is an industrial IC (factory automation equipment manufacturers, aerospace, defense, power grid infrastructure, building automation, medical applications, etc.). Regardless of the specific use or application example, IC100A achieves the embedded secure debug of its subsystems as described herein to meet the performance, size, and overall cost goals of IC100 while achieving the target reliability.

[0024] FIG. 3 is a block diagram of an IC300 (an example of the IC100 of FIG. 1 or the IC100A of FIG. 2) in some examples. In FIG. 3, the IC300 is an example of an infotainment IC that includes a debugger, an interface, and subsystems as described herein. When associating the IC100 of FIG. 1 with the IC300 of FIG. 3, the debugger 102 of FIG. 1 includes debugger operations that operate in the secure MCU domain or MCU island 336 and other parts of the IC300 of FIG. 3. The interface 104 of FIG. 1 is part of the microcontroller island 336 in FIG. 3. Also, the processor cores 302 and 308 and the memory subsystem 326 of FIG. 3 are examples of the subsystems 114A - 114N of FIG. 1. Other exemplary subsystems include controllers, communication interfaces, programmable circuit elements, or application - specific circuit elements. The IC300 of FIG. 3 is for illustrative purposes only and does not limit the techniques described to a particular set of ICs and related components.

[0025] As shown, the IC300 includes a first processor core 302 that includes a processor 304 and a memory 306 (e.g., a 512 - KB L2 cache with error - correcting code (ECC)). The integrated circuit 300 also includes a second processor core 308 that includes a processor 310 and a memory 312 (e.g., a 512 - KB L2 cache with ECC). In the example of FIG. 3, the first and second cores 302 and 308 are configured to execute software applications that can be stored at least partially in one or both of the processor cores 302 or 308 (e.g., memories 306 and 312) or the memory subsystem 326. As shown, the memory subsystem 326 includes various exemplary blocks such as a multi - core shared memory controller (MSMC) (e.g., a 2 - MB static random - access memory SRAM with ECC), a general - purpose memory controller (GPMC), an extreme learning machine (ELM), an external memory interface (EMIF) with ECC, and the like.

[0026] In FIG. 3, IC300 also includes a graphics module 314 with a graphics processing unit (GPU) 316, an industrial subsystem module 320 with a microcontroller 322 (denoted as PRI_CUSSG) for supporting an Ethernet port, and a navigator subsystem 324. In some exemplary embodiments, the navigator subsystem 324 includes an integrated direct memory access (UDMA) block, a proxy block, a peripheral virtualization unit (PVU) block, a common platform time stamp (CPTS), 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, IC300 also includes a display subsystem 328. In some exemplary embodiments, the display subsystem 328 includes a video pipeline block (e.g., a blend / scale / color space converter or "CSC"), a digital video interface (e.g., OpenLDI) block, and a MIPI interface and display port interface (MIPI DPI) block. Further, IC300 includes a system service module 330. In some exemplary embodiments, the system service module 330 includes a general-purpose (GP) timer, a real-time interrupt (RTI) and windowed watchdog timer (WWDT) block, a peripheral direct memory access (PDMA) block, and a debug block. Also, IC300 includes a video input module 332. In some exemplary embodiments, the video input module 332 includes a CAL block, a MIPI CSI-2 block, a low voltage differential signaling receiver (LVDSRX) block, and a video processing (e.g., BT.656 / 1120) block.

[0028] In FIG. 3, IC 300 also includes a security accelerator module 334. In some exemplary 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 Triple Data Encryption Standard (3DES) block.

[0029] As shown, the MCU island 336 of the IC includes a navigator subsystem 338 and a processor 340. In some exemplary embodiments, the navigator 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, the processor 340 within the MCU island 336 can be used as a power processor, and the debugger can interact with the processor 340 to control various signals provided to the subsystems 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 Signal Module (ESM), an RTI / WDT block, and memory (e.g., 512B scratch pad RAM and 512KB MCUMSRAM). In some exemplary embodiments, the MCU island 336 includes at least a portion of various components related to the techniques described herein, such as the debugger 102 and interface 104 (e.g., arbitration logic 106 and power processor 108) of FIG. 1.

[0030] IC300 also includes an interconnect 342 that enables communication between the MCU island 336 and other components or subsystems of IC300. Exemplary components of IC300 include an automotive interface 344, media and data storage 346, a control interface 348, and audio peripherals 350. The automotive interface 344 includes, for example, a controller area network with a flexible data rate (MCAN_FD) block. Media and data storage 346 includes, for example, a multimedia card (MMC) / secure digital (SD) card 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. Audio peripherals 350 include, for example, a multi-channel audio serial port (MCASP) block.

[0031] As shown, IC300 also includes a general-purpose connection module 352. In some exemplary embodiments, the general-purpose connection 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 general-purpose asynchronous receiver / transmitter (UART) block. IC300 also includes a high-speed serial interface module 354. In some exemplary embodiments, the high-speed serial interface module 354 includes a peripheral component interconnect express (PCIe) block, a USB (universal serial bus) 2.0 block, a USB3.1 block, and an Ethernet block.

[0032] In IC300, a debugger operating within MCU island 336 utilizes the availability of a power processor (e.g., one of processors 340) and an interrupt protocol to perform power management of any of the subsystems (e.g., processor cores 302, 308, memory subsystem 326, or other subsystems) that are compatible with the debug operation. In this way, IC300 achieves embedded secure debug of the subsystems as needed to achieve the target reliability while meeting the performance, size, and overall cost goals of IC300.

[0033] FIG. 4 is a block diagram of an IC400 (an example of IC100 in FIG. 1, IC100A in FIG. 2, and IC300 in FIG. 3). As shown, IC400 includes a debugger subsystem (an example of debugger 102 in FIG. 1) 102A coupled to subsystems 416A - 416N (examples of subsystems 114A - 114N in FIG. 1) via arbitration logic 414 (an example of arbitration logic 106 in FIG. 1). Arbitration logic 414 is also coupled to a power processor 108A (an example of power processor 108 in FIG. 1). In the example of FIG. 4, each of subsystems 416A - 416N includes a debug target central processing unit (CPU) 418A - 418N or other target components. Each of subsystems 416A - 416N also includes a power and sleep controller (PSC) and / or local power and sleep controller (LPSSC) module 420A - 420N. In some examples, the PSC / LPSSC modules 420A - 420N are part of a power management network (e.g., power management network 112) for controlling the clock and / or power for the subsystems 416A - 416N of IC400.

[0034] More specifically, the debugger subsystem 102A includes a debug pin (DP) interface 402 configured to receive JTAG (joint test action group) 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 the power AP) 408 coupled to the bus 404. In operation, the debug authentication interface 408 is configured to convey a debug request to arbitration logic 414.

[0035] In response to a debug request from the debugger subsystem 102A, the arbitration logic 414 asserts an interrupt (Debug Req Int) to the power processor 108A. The power processor 108A, in response to the interrupt, determines the power state of the subsystem related to the debug request and, if the determined power state of the subsystem related to the debug request is the off state, is configured to perform a first set of operations to power up the subsystem related to the debug request. In some exemplary embodiments, the first set of operations performed by the power processor 108A includes providing a control signal 413 to a power management network (e.g., one of each of the PSC / LPSSC modules 420A - 420N) to power on the subsystem related to the debug request and sending a notification (secure device notification) to the arbitration logic 414 to confirm that the subsystem related to the debug request is in the on state. In some exemplary embodiments, the first set of operations performed by the power processor 108A also includes receiving, from the arbitration logic 414, a notification (e.g., using Debug Req Int) that the debug operation related to the debug request is complete and, in response to the received notification, providing a control signal to the power management network (e.g., one of each of the PSC / LPSSC modules 420A - 420N) to restore the subsystem related to the debug request to the off state.

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

[0037] In the example of FIG. 4, the arbitration logic 414 includes memory-mapped registers (MMR) 415 or other storage to track configuration bits or status bits associated with the debug operation. Also, in some exemplary embodiments, the arbitration logic 414 is coupled to the power processor 108A via an interconnect 410 (referred to as the SoC interconnect). In the example of FIG. 4, the power processor 108A and the arbitration block 414 provide an interface (e.g., interface 104 of FIG. 1) for performing debug on any of the subsystems 416A - 416N. Using the IC400, the arbitration logic 414 can utilize the availability of the power processor 108A and the interrupt protocol to perform power management on any of the subsystems 416A - 416N associated with the debug operations of the debugger 102A. In this way, the IC400 achieves embedded secure debug of the subsystems 416A - 416N as needed to meet the performance, size, and overall cost goals of the IC400 while achieving the target reliability.

[0038] FIG. 5 is a diagram of arbitration logic 500 (an example of arbitration logic 106 in FIG. 1 or arbitration logic 414 in FIG. 4) for an IC with an embedded debugger (e.g., IC100 in FIG. 1, IC100A in FIG. 2, IC300 in FIG. 3, or IC400 in FIG. 4) in some examples. As shown, the arbitration logic 500 includes inputs 502, 504, 508, 534, and 538. Input 502 is configured to receive a notification (e.g., a secure device notification) from a power processor as described herein. Input 504 is configured to receive a control signal (ForceActive) from a debugger (e.g., debugger subsystem 102A in FIG. 4). Input 508 is configured to receive another control signal (InhibitSleep) from a debugger (e.g., debugger subsystem 102A in FIG. 4). Input 534 is configured to receive a notification (ForceActiveACK) from a power management network (e.g., one of each of the PSC / LPSSC modules 420A - 420N in FIG. 4). Input 538 is configured to receive a notification (InhibitSleepACK) from a power management network (e.g., one of each of the PSC / LPSSC modules 420A - 420N in FIG. 4).

[0039] As shown, the arbitration logic 500 also includes outputs 506, 510, 532, 536, 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 first type of control signal (e.g., ForceActive) to a power management network (e.g., each one of the PSC / LPSSC modules 420A - 420N in FIG. 4). Output 536 is configured to provide a first type of control signal (e.g., InhibitSleep) to a power management network (e.g., each one of the PSC / LPSSC modules 420A - 420N in FIG. 4). Output 548 is configured to provide an interrupt (debug_forceactive_int) to a power processor (e.g., power processor 108 in FIG. 1, or power processor 108A in FIG. 4) as described herein.

[0040] In FIG. 5, arbitration logic 500 includes logic OR gates between inputs 502, 504, 508, 534, and 538 and 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, the other input to AND gate 528 results from the output of another AND gate 524, and one of the inputs to AND gate 524 is coupled to input 504. The other input to AND gate 524 is coupled to a bypass override register 550 (BYPASS_OVERRIDE). In FIG. 5, bypass override register 550 is one of various registers 550, 552, 554, 556, 558, 560, 562, 564, 566, 568, 570, 572, and 574 of arbitration logic 500, which are examples of MMR415 in FIG. 4. In the example of FIG. 5, these registers are coupled to interface 540, thereby enabling a debugger or other IC component to inspect or clear configuration bits and / or status bits related to the operation of arbitration logic 500.

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

[0042] In the example of FIG. 5, output 506 is coupled to the output of multiplexer 512. As shown, input 534 is coupled to the first input to multiplexer 512. The second input of multiplexer 512 is coupled to the first control signal positive response set register (FORCEACTIVE_ACK_SET) 560, and the control signal for multiplexer 512 is provided by bypass override block 550. Also, output 510 is coupled to the output of another multiplexer 514. As shown, input 538 is coupled to the first input to multiplexer 514. The second input of multiplexer 514 is coupled to the second control signal positive response set register (INHIBITSLEEP_ACK_SET) 554, and the control signal for multiplexer 514 is 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 the first control signal positive response set block 560. The output of XOR gate 516 is coupled to a control block (REQ EVT SET / CLR) 518 configured to provide a signal to the first control signal interrupt status register (FORCEACTIVE_INT_RAW_STAT_SET) 570 to set or clear an interrupt related to 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 the second control signal positive response set register 554. The output of XOR gate 520 is coupled to a control block (REQ EVT SET / CLR) 522 configured to provide a signal to the second control signal interrupt status register (INHIBITSLEEP_INT_RAW_STAT_SET) 568 to set or clear an interrupt related to the second control signal (InhibitSleep).

[0044] In the example of FIG. 5, the arbitration logic 500 also includes an interrupt generator 546 coupled to a second control signal interrupt status block 568 and a first control signal interrupt status block 570 via an OR gate 544. Also, the OR gate 544 receives requests from an interrupt request source (IRQ_*_STAT ports [31:1]) 542 that notifies when an interrupt request is received at various ports. The output of the interrupt generator 546 is coupled to an output 548. In some exemplary embodiments, the interrupt generator 546 is selectively enabled by a control signal from an interrupt enable clear register (INT_EN_CLR) 574.

[0045] As shown, the arbitration logic 500 also includes a second control signal positive response clear register 556 (INHIBITSLEEP_ACK_CLR), a first control signal positive response clear register 562 (FORCEACTIVE_ACK_CLR), a second control signal interrupt enable status clear register 564 (INHIBITSLEEP_INT_EN_STAT_CLR), and a first control signal interrupt enable status clear register 566 (FORCEACTIVE_INT_EN_STAT_CLR). In different exemplary embodiments, the arbitration logic 500 varies with respect to the specific logic, gates, and registers used to handle debug requests, interrupts, and notifications as described herein.

[0046] FIG. 6 is a flowchart of an embedded debug operation 600 of an IC (e.g., IC100 of FIG. 1, IC100A of FIG. 2, IC300 of FIG. 3, IC400 of FIG. 4, etc.) in some examples. As shown, the embedded debug operation 600 includes authenticating a secure session at block 602 in response to a request to debug a subsystem, as described herein. If the authentication fails (decision block 604), the power processor does not respond to the request at block 608. If the authentication is successful (decision block 604), the power processor responds to the request at block 606. At block 610, the power processor checks the arbitration logic to the ID requester, enables the phase-locked loop (PLL), firmware (FW), additional MMR setup, enhances the power wake-up dependency, enables the channel from the arbitration logic to the target subsystem, and completes the subsystem enable process.

[0047] FIG. 7 is a flowchart of a power-down sequence 700 for an LUT operation for an IC (e.g., IC100 of FIG. 1, IC100A of FIG. 2, IC300 of FIG. 3, or IC400 of FIG. 4) in some examples. As shown, power-down sequence 700 includes, at block 702, a debugger power-on lookup action. At block 704, the debugger requires that one of the subsystems be active. At block 706, a clock source for the required subsystem active is set. At block 708, other clocks that the required subsystem depends on are set. At block 710, other power domains that the required subsystem depends on are set. At block 712, the power domain of the required subsystem is set. At block 714, clock gating for the required subsystem is removed. At block 716, all security is configured to permit access to / from the required subsystem. At block 718, all other settings are configured to enable the required subsystem to become active. At block 720, the required subsystem is either released, reset, or not stopped. In some exemplary embodiments, the subsystem is disabled by performing the sequence 700 in reverse (e.g., after a secure debug session).

[0048] FIG. 8 is a flowchart of method 800 in some examples. Method 800 is implemented by an IC (e.g., IC 100 of FIG. 1, IC 100A of FIG. 2, IC 300 of FIG. 3, or IC 400 of FIG. 4). As shown, method 800 includes generating, by a processor core of the integrated circuit (either processor cores 302 and 308, or debugger subsystem 102A of FIG. 4), a debug request (e.g., ForceActive or InhibitSleep of FIG. 5) for a subsystem of the integrated circuit (e.g., one of subsystems 114A - 114N of FIG. 1, or one of subsystems 416A - 416N of FIG. 4) at block 802. At block 804, in response to the generated debug request, a power processor is generated by an interface between the processor and the subsystem (e.g., interface 104 of FIG. 1, arbitration logic 414 and power processor 108A of FIG. 4). At block 806, when the subsystem associated with the debug request is identified as being in an on state, a notification (e.g., ForceActiveACK or InhibitSleepACK in FIG. 5) is provided to the interface by the power processor. At block 808, in response to the notification, a debug operation is performed via the interface by the processor core.

[0049] In some exemplary embodiments, method 800 includes additional operations such as, by a power processor, determining a power state of a subsystem related to a debug request in response to a power processor interrupt; and, by the power processor, performing a first set of operations to activate the subsystem if the determined power state of the subsystem related to the debug request is an off state. In some exemplary embodiments, performing the first set of operations by the power processor for method 800 includes providing a control signal to a power management network of an integrated circuit to provide power to a subsystem related to the debug request; sending a notification to arbitration logic of the integrated circuit to confirm that the subsystem related to the debug request is in an on state; receiving, from the arbitration logic, a notification that debug operations related to the debug request are complete; and in response to the received notification, providing a control signal to the power management network to restore the subsystem related to the debug request to an off state. In some exemplary embodiments, method 800 also includes, if the determined power state of the subsystem related to the debug request is an on state, performing, by the power processor, a second set of operations. In some exemplary embodiments, performing the second set of operations by the power processor for method 800 includes sending a notification to arbitration logic of the integrated circuit to confirm that the subsystem related to the debug request is in an on state; receiving, from the arbitration logic, a notification that debug operations related to the debug request are complete; and in response to the received notification, maintaining the subsystem related to the debug request in an on state.

[0050] The term "coupled" is used throughout this specification. This term can encompass connections, communications, or signal paths that enable functional relationships consistent with this description. For example, if device A generates a signal for controlling device B to perform a certain action, in a first example, device A is coupled to device B, or in a second example, device A is coupled to device B via an intervening component C if the intervening component C does not substantially change the functional relationship between device A and device B such that device B is controlled by device A via the control signal generated by device A.

[0051] Within the scope of the claims of the present invention, modifications may be made to the illustrated embodiments described, and other embodiments are possible.

Claims

1. An integrated circuit, comprising: a debugger; an interface coupled to the debugger, the interface including arbitration logic coupled to the debugger, a power management processor coupled to the arbitration logic, and a power management network coupled to the power management processor; a subsystem coupled to the interface; wherein the debugger is configured to perform a debug operation via the interface by providing a debug request related to the subsystem to the arbitration logic; the arbitration logic is configured to provide a first interrupt related to the subsystem to the power management processor based on the debug request; the power management processor, based on the first interrupt, powers on the subsystem in response to determining that the subsystem is in a power-off state in the power management network, and provides a first notification indicating that the subsystem is in a power-on state to the arbitration logic; receives a second notification from the arbitration logic that a debug operation related to the debug request has been completed; and causes the power management network to power off the subsystem. An integrated circuit configured as such.

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 and a memory.

3. The integrated circuit according to claim 1, wherein the power management processor sets a clock source on which a requested subsystem depends to be active, sets a power domain on which the requested subsystem depends to be active, and removes clock gating for the requested subsystem. An integrated circuit further configured as such.

4. The integrated circuit according to claim 1, wherein the second notification is a second interrupt.

5. The integrated circuit according to 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, To power on the subsystem in the power management network, each clock source on which the subsystem depends is set to the on state, An integrated circuit in which the security related to the subsystem is configured to permit access to and from the subsystem by the debugger before the debug operation is performed. **Claim 7** An integrated circuit comprising: A debugger; An interface coupled to the debugger, the interface including arbitration logic coupled to the debugger, a power management processor coupled to the arbitration logic, and a power management network coupled to the power management processor; A subsystem coupled to the interface; Including: The debugger is configured to perform a debug operation via the interface by providing a debug request related to the subsystem to the arbitration logic; The arbitration logic is configured to provide a first interrupt related to the subsystem to the power management processor based on the debug request; Based on the first interrupt, the power management processor Determines the power state of the subsystem, Responds to determining that the subsystem is in the power-off state by causing the power management network to power on the subsystem and place it in the power-on state, Provides a first notification to the arbitration logic to confirm that the subsystem is in the power-on state based on the power state being the power-on state. An integrated circuit configured as described above. **Claim 8** The integrated circuit according to claim 7, wherein Based on the power state being the power-on state, the power management processor Receives a second notification from the arbitration logic that the debug operation related to the debug request is completed, Causes the subsystem to maintain the power-on state. An integrated circuit further configured as described above. **Claim 9** A system comprising: An integrated circuit, Terminals adapted to be coupled to peripheral device components, A processor core coupled to the terminals, A memory coupled to the processor core, the memory storing a debugger for execution by the processor core. An interface coupled to the processor core, the interface including arbitration logic, a power management processor coupled to the arbitration logic, and a power management network coupled to the power management processor, a subsystem coupled to the interface, the integrated circuit including the above, the processor core being configured to perform a debug operation via the interface by providing a debug request related to the subsystem to the arbitration logic, the arbitration logic being configured to provide an interrupt to the power management processor based on the debug request, the power management processor, based on the interrupt, determining a power state of the subsystem, in response to determining that the subsystem is in a power-off state, powering on the subsystem by the power management network to place the subsystem in a power-on state, providing a first notification indicating that the subsystem is in a power-on state to the arbitration logic, receiving a second notification from the arbitration logic that a debug operation related to the debug request has been completed, a system configured as such.

10. The system according to claim 9, wherein the power management processor is further configured to restore the subsystem to the power-off state by the power management network based on the second notification.

11. The system according to claim 9, wherein the power management processor is further configured to maintain the subsystem in the power-on state in response to the second notification.

12. The system according to claim 9, wherein each clock source on which the subsystem depends is set to an on state to power on the subsystem by the power management network to place the subsystem in the power-on state, and security related to the subsystem is configured to permit access to and from the subsystem by a debugger before the debug operation is performed.

13. A method, comprising: generating, by a processor core of an integrated circuit, a debug request for a subsystem of the integrated circuit, Generating a power management processor interrupt in response to the debug request by an interface between the processor core and the subsystem; Based on the power management processor interrupt; Determining, by the power management processor, whether the subsystem is in an on state; Causing the subsystem to be in the on state when the power management processor determines that the subsystem is in an off state; Providing a first notification to the interface when the power management processor identifies that the subsystem related to the debug request is in the on state; Performing a debug operation by the processor core in response to the first notification via the interface; Receiving, by the power management processor, a second notification that a debug operation related to the debug request has been completed, the second notification indicating whether the subsystem is maintaining the on state or has reverted to the off state; A method comprising.

14. The method according to claim 13, further comprising: Causing the subsystem to revert to the off state based on the second notification.

15. The method according to claim 13, further comprising: Maintaining the subsystem in the on state based on the second notification.

16. The method according to claim 13, wherein: Causing the subsystem to be in the on state by the power management processor includes setting each clock source upon which the subsystem depends to the on state; The method further comprises: Configuring security related to the subsystem to permit access to and from the subsystem before the debug operation is performed.

Images