Extended performance monitoring counters triggered by the debug state machine

Abstract

An integrated circuit (IC) [100] includes a debug controller [102], a debug state machine (DSM) [104], and an extended performance monitoring counter (EPMC) [106]. The debug controller selectively outputs debug data on a debug interconnect [110]. The DSM identifies an event based on the debug data and an event list [304] and outputs a DSM indication [124] identifying the event. The EPMC indicates a plurality of detected events including the identified event. The EPMC indicates the identified event in response to the DSM indication.

Description

Background Art

[0001] As integrated circuits (ICs) increase in complexity, testing, monitoring, and debugging these ICs become more complex. Automatic test equipment (ATE) and logic analyzers are used to provide given input values ​​to manufactured chips. When an error is detected, target signals are used to determine the cause. In many cases, this process is time-consuming and labor-intensive. On-chip logic and performance monitoring counters (PMCs) are used to assist in IC debugging, verification, and performance analysis. PMCs are used to track and indicate the occurrence of specific events during chip verification and normal operation. However, conventional PMCs typically only track a relatively small number of events without physically redesigning the IC. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] By referencing the accompanying drawings, the present disclosure will be better understood and its numerous features and advantages will become readily apparent to those skilled in the art.The use of the same reference numerals in different drawings indicates similar or identical items.

[0003] Figure 1 is a block diagram of an implementation of an integrated circuit including a debug state machine and extended performance monitoring counters, according to some embodiments.

[0004] Figure 2 is a block diagram of another implementation of an integrated circuit including a debug state machine and extended performance monitoring counters according to some embodiments.

[0005] Figure 3 is a block diagram illustrating an exemplary debug state machine according to some embodiments.

[0006] Figure 4 is a flow chart illustrating a method of detecting events and providing debug state machine indications to extended performance monitoring counters according to some embodiments.

[0007] Figure 5 is a block diagram of a processing system including debug state machine triggered extended performance monitoring counters according to some embodiments. DETAILED DESCRIPTION

[0008] As described herein, in various embodiments, an integrated circuit (IC) includes at least one debug state machine (DSM) that sends an indication to an extended performance monitoring counter (EPMC). More specifically, the DSM receives debug data (e.g., via a debug interconnect), pipeline triggers (e.g., data from one or more intellectual property (IP) devices), or both. The DSM compares the received data with a stored event list. In response to a comparison indicating that an event specified by the event list has occurred, the DSM sends a DSM indication to the EPMC. The EPMC indicates via an IC interface that a specified event has been detected. Thus, a specified event is detected and indicated based on debug data, pipeline triggers, or both. In some cases, detecting and indicating information generated based on debug data, pipeline triggers, or both provides additional options for performance analysis, device debugging, verification coverage, or production solutions.

[0009] In some implementations, the event list of the DSM is adjustable, such as via direct user input, via a basic input / output system (BIOS) update, or via a secure firmware update. In some embodiments, the event list is not a formal list of conditions stored together in a storage device, but rather a configuration of the hardware that, upon receiving various specific groups of signals or triggers (e.g., corresponding to various specified events), generates an indication that the corresponding event has been detected. Thus, in some cases, the DSM indicates the occurrence of different events to the EPMC than before the DSM was modified. In addition, the EPMC outputs indications of the occurrence of different events. Thus, in some cases, the event list reported by the EPMC may be modified after the EPMC is manufactured, thereby providing additional chip flexibility.

[0010] Some ICs include performance monitoring counters (PMCs) that are typically not connected to the debug interconnect, pipeline devices (e.g., IP devices), or both. In such systems, the PMCs are limited to indicating data received from other sources, such as event-based interrupts. For example, in some cases, the PMC counts the number of times a particular power state is entered and exited, but does not indicate the number of clock cycles spent in each power state, even though such information is available on the debug interconnect in some systems. Additionally, in some cases, the PMCs have a fixed architecture as part of the manufacture of the PMCs. Thus, in these ICs, the PMCs are limited to indicating a fixed list of events that do not include at least some of the events indicated by the debug interconnect, pipeline triggers, or both. In some cases, it is desirable for a user or programmer to receive indications of events signaled by the debug interconnect, pipeline triggers, or both, or to change the events indicated by the PMCs after the PMCs are manufactured.

[0011] Figure 1An IC 100 is shown according to some embodiments. In the illustrated embodiment, IC 100 includes a debug controller 102, a DSM 104, and an EPMC 106. A debug interconnect 110 connects debug controller 102 to DSM 104. A DSM-EPMC interconnect 112 connects DSM 104 to EPMC 106. Although the illustrated embodiment shows only three components for clarity, other components are contemplated in various embodiments.

[0012] In some embodiments, as described below with reference to Figure 5 As further discussed, IC 100 is part of a device such as a desktop or laptop computer, a server, a smartphone, a tablet computer, a game console, or other electronic device. The device includes a central processing unit (CPU), a graphics processing unit (GPU), a system memory controller, system input / output (IO) devices and bus controllers, and peripheral coprocessor elements. In various embodiments, any or all of these components include DSMs and performance monitoring counters. In various embodiments, as part of executing various programs or instruction sequences, any or all of these components send instruction-based sampled data 126 to EPMC 106, send debug source information 120 to debug controller 102 at various observable points, or both.

[0013] In the illustrated embodiment, various debug source information 120 (e.g., a cross-trigger signal on a communication interface, a capture signal, a clock stop signal, an error signal, a performance monitoring ("perfmon") signal or event, an interrupt, a breakpoint, a microcode-based trigger (e.g., a breakpoint, performance monitoring, interrupt, and error event), a timer overflow, a fault signal resynchronization, a power state change signal, a power consumption signal, a status signal of specific internal logic of a sending logic block, or any combination thereof) is provided to the debug controller 102. In response to receiving the debug source information 120, the debug controller 102 selectively outputs the debug source information 120 as debug data 122 on the debug interconnect 110 (e.g., a debug bus). For example, in some cases, the debug controller 102 includes one or more multiplexers and rotates between the debug source information 120 inputs, outputting the received data as debug data 122.

[0014] The DSM 104 receives debug data 122 on the debug interconnect 110 and compares the received data to an event list (e.g., programmable event information) stored at the DSM 104. In response to determining that the debug data 122 indicates an event that has completed, the DSM 104 generates a DSM indication 124 indicating that the completed event has been identified. In some embodiments, the event list includes multiple events. In other embodiments, the event list includes only a single event. In some embodiments, the event list is a hardware configuration in the DSM 104 that detects and indicates various events without storing the conditions together in a memory device. In various embodiments, as described below with reference to Figure 3 As further discussed, the DSM 104 identifies single condition events, multiple condition events, or both. For example, in some cases, the DSM 104 generates a DSM indication 124 in response to detecting a fault signal resynchronization. As another example, in some cases, in response to receiving debug data 122 indicating a first power state transition (e.g., a transition to a particular phase), the DSM 104 tracks the number of clock cycles spent in the particular phase of the power state transition. In response to receiving debug data 122 indicating a second power state transition (e.g., a transition out of the particular phase), the DSM 104 generates a DSM indication 124. In some cases, the DSM indication 124 indicates the number of cycles spent in the particular phase. Thus, in various embodiments, the DSM 104 generates the DSM indication 124 in response to debug data 122 indicating a particular state, generates the DSM indication 124 in response to a signal sequence, or does both. Additionally, as described below with reference to Figure 2 As described, in various embodiments, DSM 104 generates various other control signals in response to various inputs (eg, signals received via debug interconnect 110 or from other devices).

[0015] In the illustrated embodiment, the event list of DSM 104 can be modified via event list updates. In some cases, event list updates are received directly from the user (e.g., as a custom event selection input) for use in monitoring, analysis, and debugging as needed. In other cases, event list updates are performed via a basic input / output system (BIOS) update or a secure firmware update (e.g., performed by the manufacturer of IC 100 in response to a request to monitor events from a customer). Thus, in some cases, events identified by DSM 104 via DSM indications 124 are modified after IC 100 is manufactured.

[0016] EPMC 106 counts and outputs indications of various events associated with various operations (e.g., retiring instructions) (e.g., providing sampling analysis or generating input when a predetermined threshold is reached) as event data 128. For example, in some cases, EPMC 106 receives indications of power states entered and exited by one or more devices (e.g., a CPU) of IC 100 via event-based interrupt data 126, counts the number of times a particular power state is entered, and outputs the results as event data 128. Additionally, in the illustrated embodiment, EPMC 106 receives DSM indications 124 as standard events via DSM-EPMC interconnect 112 and outputs DSM event data 130 in response to the DSM indications 124. Thus, in some cases, EPMC 106 outputs event data 128 indicating a count of times a particular power state is entered, and also outputs DSM event data 130 indicating a number of cycles spent in the particular power state. In various embodiments, event data 128, DSM event data 130, or both are output via an input / output (I / O) interface (e.g., a user interface) or saved to an event log in a memory device. Thus, EPMC 106 outputs event data based on debug source information 120 received via debug interconnect 110, which, in some cases, includes additional information compared to event data generated solely based on event-based interrupt data 126. Furthermore, because the event list of DSM 104 is modifiable, EPMC 106 is, in some cases, a customizable performance monitor.

[0017] Figure 2 is a block diagram illustrating an IC 200 according to some embodiments. In the illustrated embodiment, the IC 200 includes Figure 1 1 , debug controller 102, DSM 104, EPMC 106, debug interconnect 110, and DSM-EPMC interconnect 112, as well as pipeline device 202, pipeline input interconnect 204, and pipeline output interconnect 206. Although the illustrated embodiment shows only three components for clarity, other components are also contemplated in various embodiments.

[0018] As referenced above Figure 1 As described, in some embodiments, debug controller 102 generates debug data 122 based on debug source information 120. DSM 104 generates DSM indication 124 in response to detecting an event based on debug data 122. EPMC 106 generates event data 128 based on event-based interrupt data 126 and generates DSM event data 130 based on DSM indication 124.

[0019] Additionally, in the illustrated embodiment, the DSM 104 generates the DSM indication 124 in response to a pipeline trigger 210 from the pipeline device 202 (e.g., in response to one or more instances of the debug data 122, one or more instances of the pipeline trigger 210, or any combination thereof). In various embodiments, the pipeline device 202 sends the pipeline trigger to the DSM 104 (illustrated for simplicity as the pipeline trigger 210) via the pipeline input interconnect 204. For example, in some cases, the pipeline trigger 210 includes one or more of the following: a capture signal, a clock stop signal, an error signal, a performance monitoring ("perfmon") signal or event, an interrupt signal, a breakpoint indication, a microcode-based trigger (e.g., a breakpoint, performance monitoring, interrupt, and error event), and a timer overflow signal.

[0020] In addition to generating DSM indications 124, in some cases, DSM 104 generates pipeline actions 212 in response to pipeline triggers 210, debug data 122, or both. DSM 104 sends pipeline actions (shown as pipeline actions 212 for simplicity) via pipeline output interconnect 206. Pipeline actions 212 instruct pipeline device 202 to perform various actions. For example, in some cases, pipeline actions 212 include one or more of the following: a local stop clock signal, a full-chip stop clock signal, a self-refresh signal for a memory device, a communication interface receive disable signal, a trace store signal, a machine check exception (MCE) signal, a debug event signal, a debug microcode interrupt trigger, instructions to set and clear various bits in a DSM microcode register, an operation stop signal, a fabric refresh signal, an instruction to start storing debug data into a state capture buffer (e.g., to a debug record buffer (DRB) and overflowing to a reserved cache way or system memory), an instruction to stop storing debug data into the state capture buffer, an instruction to store a clock count into the state capture buffer, and an instruction to change a queue size.

[0021] Thus, in some cases, DSM 104 tracks data that is not indicated by event-based interrupt data 126. However, this tracked data is transparent to the user in some cases because EPMC 106 outputs DSM event data 130. Furthermore, because the event list of DSM 104 is modifiable, the output of EPMC 106 is modifiable after IC 200 is manufactured.

[0022] Figure 3is a block diagram depicting an exemplary DSM 104 according to some embodiments. DSM 104 includes an event detection component 302. Event detection component 302 includes an event list 304. Although in the illustrated example, event list 304 includes multiple events, in other embodiments, event list 304 includes only a single event. Additionally, although in the illustrated example, event list 304 corresponds to data (e.g., event conditions) stored together in a memory device, in other embodiments, event list 304 is a hardware configuration in DSM 104 that detects and indicates various events without storing the event conditions together in a memory device.

[0023] In the illustrated example, the DSM 104 receives debug data 122, pipeline triggers 210, or both. Event detection component 302 compares the received data to event list 304 and, based on the comparison, determines whether an event is detected. In response to detecting an event, the DSM 104 sends a DSM indication 124 indicating the detected event. Furthermore, in the illustrated embodiment, event detection component 302 determines whether to generate pipeline actions 212 based on the received data. However, in other embodiments, pipeline actions 212 are generated using different hardware of the DSM 104.

[0024] For illustration purposes, Figure 3 Four examples of potential events that may result in the generation of a DSM indication 124 are shown. Specifically, in response to debug data 122 indicating an internal power state monitoring count (wherein the power state monitor indicates a value greater than a first value), the DSM 104 sends a DSM indication 124 indicating the power state monitoring count. As another example, in response to debug data 122 indicating an internal power state monitoring count (wherein the power state monitor indicates a value less than a second value), the DSM 104 sends a DSM indication 124 indicating the power state monitoring count. In some embodiments, the first value, the second value, or both are proxy values ​​indicating a die voltage observed within a die voltage range of the integrated circuit. In other embodiments, the first value, the second value, or both are actual voltages. Furthermore, in response to debug data 122 indicating that a fault signal has resynchronized high or in response to a pipeline trigger 210 being active, the DSM 104 sends a DSM indication 124. Furthermore, in some cases, the events in the event list 304 are multi-condition events. For example, in response to debug data 122 indicating that a first power state change has occurred, DSM 104 begins counting clock cycles (e.g., by incrementing a counter or by marking a current counter value). In response to debug data 122 indicating that a second power state change has occurred, DSM 104 stops counting clock cycles and sends the number of counted clock cycles as DSM indication 124.

[0025] Figure 4 In some embodiments, method 400 is performed by, for example, Figure 1 The DSM 400 is implemented by the DSM 104. In some embodiments, the method 400 is initiated by one or more processors in response to one or more instructions stored by a computer-readable storage medium.

[0026] At block 402, the DSM receives event data. For example, in some cases, the DSM 104 receives debug data 122, pipeline triggers 210, or both. At block 404, the DSM determines whether the event data matches the next condition of a multi-condition event in the DSM's event list. For example, in some cases, the event data indicates that a power state phase transition has occurred, as described above with reference to FIG. Figure 3 In response to the event data matching the next condition of the multi-condition event, the method 400 proceeds to block 406. In response to the event data not matching the next condition of the multi-condition event, the method 400 proceeds to block 402.

[0027] At block 406, in response to the event data matching the next condition of the multi-condition event, the DSM determines whether the event is complete due to receipt of the event data. For example, in some cases, the event data indicates that a second power state phase transition has occurred. In response to the event being complete, method 400 proceeds to block 410. In response to the event not being complete, method 400 proceeds to block 402. At block 408, in response to the event data failing to match the next condition of the multi-condition event, the DSM determines whether the event data matches a single-condition event in the event list. For example, in some cases, the event data indicates that a fault signal resynchronized high or a pipeline trigger was asserted. In response to the event data matching a single-condition event, method 400 proceeds to block 410. In response to the event data failing to match a single-condition event, method 400 proceeds to block 402.

[0028] At block 410, in response to completing a multi-condition event or in response to event data matching a single-condition event, the DSM sends a DSM indication to the extended performance monitoring counter. For example, in response to identifying a completed event, the DSM 104 sends the DSM indication 124 to the EPMC 106. The method 400 then returns to block 402. Accordingly, a method for detecting events and providing debug state machine indications to the extended performance monitoring counter is described.

[0029] Figure 51 is a block diagram of a processing system 500 that includes an extended performance monitoring counter triggered by a debug state machine according to some embodiments. In the illustrated embodiment, various components within the processing system 500 include a DSM and an EPMC for investigating and tracking the functionality of on-chip hardware. As described above, the DSM receives triggers (e.g., debug data or pipeline triggers) from one or more sources and selects a given action (e.g., sending a DSM indication or pipeline action) based on these triggers. These sources include components within the same core or controller, other on-chip components outside the same core or controller, and additional off-chip components. In some embodiments, the DSM is interconnected via a network (e.g., covering a bidirectional cross-trigger network). Although the illustrated embodiment includes a DSM and EPMC in various components, in other embodiments, the DSM and EPMC are included in fewer, additional, or different components. In addition, although the DSM and EPMC appear in pairs in the illustrated embodiment, in other embodiments, the DSM, EPMC, or both appear separately.

[0030] In some cases, multiple time-sharing sequences may be present within processing system 500. For example, in some cases, a sequence comprises a software process, a software thread, a system-level transaction, or a power-performance state (p-state). A sequence comprises one or more instructions to be executed on the IC under test, scheduled by an operating system (OS) or on-chip hardware. A sequence identifier (ID) is used to distinguish between sequences. For example, a process ID, a thread ID, a system-level transaction ID, a p-state ID, or any combination thereof may be used. In some cases, a sequence shares hardware resources within the IC (e.g., execution units, queues, schedulers, process states, or memory space) with other sequences.

[0031] In some embodiments, one or more processor cores (e.g., multithreaded processor cores 532-1 to 532-2 or graphics processor core 542) in processing system 500 execute multithreaded applications. Additionally, in some cases, processing system 500 operates in one of a plurality of power performance states. Furthermore, in some cases, multiple independent system-level transaction levels operate on processing system 500. Each of a process, a thread, and a p-state is an example of a sequence.

[0032] In some embodiments, one or more of the DSMs 520, 534 (DSMs 534-1 to 534-2), or 544 in the processing system 500 tracks statistical data and operational behavior, including on-chip interconnect status and I / O device interconnect status. The DSMs 520, 534, 544, or any combination thereof, provide state information, stored parameters, and combined control logic for testing the on-chip hardware during processing of independent sequences. Rather than duplicating a complete instance of the DSM for each sequence processed by the hardware, some static resources, such as state and stored parameters, are shared. As described above, one or more of the DSMs 520, 534, and 544 include a list of events that can be modified after the processing system 500 is manufactured. Therefore, in some cases, the various tests and parameters tracked by the DSMs 520, 534, and 544 change after the processing system 500 is manufactured.

[0033] As described above, one or more of EPMCs 522, 536 (EPMCs 536-1 to 536-2), or 546 similarly tracks and provides state information for debugging, code analysis and refinement, and operating system operations. In the illustrated embodiment, EPMCs 522, 536, and 546 receive DSM indications from one or more of DSMs 520, 534, and 544. In some cases, EPMCs 522, 536, and 546 output the received DSM indications as DSM event data. Furthermore, in some cases, EPMCs 522, 536, and 546 combine the received DSM indications with the received event-based interrupt data to generate event data.

[0034] As shown, processing system 500 includes various units 508 (general processing units 508-1 through 508-2) and unit 510 (e.g., a graphics processing unit). Unit 508 includes a corresponding general-purpose multi-threaded processor core 532 and a corresponding cache subsystem 530 (e.g., cache subsystems 530-1 through 530-2). Similarly, unit 510 includes a graphics processor core 542 and a buffer 540.

[0035] In some embodiments, each multi-threaded processor core 532 includes a superscalar microarchitecture having one or more multi-stage pipelines. In some cases, a multi-threaded software application causes each of its software threads to be processed by a corresponding separate pipeline in the multi-threaded processor core 532. Alternatively, each thread can be processed by a pipeline that can handle multiple threads via control at certain functional units. In another example, each of these threads is processed by the pipeline using a combination of dedicated resources for a corresponding thread in the multiple threads and shared resources used by all the multiple threads. In various embodiments, each multi-threaded processor core 532 includes circuitry for processing instructions according to a given general instruction set.

[0036] Typically, each multithreaded processor core 532 accesses a level 1 (L1) cache for data and instructions. In some cases, there are multiple on-chip levels of cache (L2, L3, etc.). In some embodiments, one or more of these levels of cache are located outside the processor core and within a corresponding cache memory subsystem in the cache memory subsystem 530. Additionally, in some cases, the processing system 500 includes one or more specialized cores, such as a GPU, another type of single instruction multiple data (SIMD) core, or a digital signal processor (DSP). In the illustrated embodiment, the processing system 500 includes a unit 510. In the illustrated embodiment, the unit 510 includes multiple parallel data paths, which include multiple pipeline stages, each of which has multiple arithmetic logic unit (ALU) components and operates on a single instruction for multiple data values ​​in the data stream.

[0037] In the illustrated embodiment, processing system 500 also includes a shared cache subsystem 504 connected to units 508 and 510 through a crossbar 506. Units 508 and 510 have direct access to local memory and off-chip memory via crossbar 506 and memory controller 502.

[0038] In some cases, memory controller 502 connects processing system 500 to off-chip memory devices, such as dynamic random access memory (DRAM), disk storage, and offline archival storage. Thus, memory controller 502 includes control circuitry for interfacing with the memory devices. Additionally, in some embodiments, memory controller 502 includes a request queue for queuing memory requests. Similar to units 508 and 510, in the illustrated embodiment, memory controller 502 includes a DSM 520 and an EPMC 522.

[0039] In the illustrated embodiment, interface 512 includes integrated channel circuits to link signals directly to other processing nodes, such as another processor. Therefore, in some cases, interface 512 utilizes one or more coherent links to perform inter-node access to the processor on-chip cache and off-chip memory of another processing node. Examples of this technology include HyperTransport and QuickPath. I / O interface 550 provides an interface for I / O devices from processing system 500 to shared cache memory subsystem 504 and units 508 and 510. In addition, in some cases, I / O interface 550 provides an interface to one or more EPMCs in EPMC 522, 536 and 546. In some cases, I / O interface 550 also communicates with the platform and I / O controller hub (not shown) to perform data control and access. In some cases, the hub responds to the control packets and messages received on the corresponding links, and generates control packets and response packets in response to the information and commands received from processing system 500. In some cases, the hub performs operations on-chip that are usually performed off-chip by a conventional south bridge chipset. In some embodiments, the hub also includes a corresponding DSM, EPMC, or both.

[0040] The test interface 514 comprises an interface for testing the processing system 500 according to a given protocol, such as the IEEE 1149.1 Standard Test Access Port and Boundary Scan Architecture or the Joint Test Action Group (JTAG) standard. In some cases, the test interface 514 is used to program one or more of the DSMs 520, 534, and 544 via the DSM interface 560. In some embodiments, programming a DSM includes writing specific values ​​to registers corresponding to a given DSM, such as registers corresponding to an event list. In some cases, programming a DSM determines which triggers the DSM responds to and the type of action taken in response.

[0041] In some cases, each of the DSMs 520, 534, and 544 is programmed differently. Alternatively, in some cases, two or more of the DSMs 520, 534, and 544 are programmed in a similar manner. Furthermore, in some cases, any given one of the DSMs 520, 534, and 544 takes a specific action in response to a specific trigger event, regardless of the programming performed. Similarly, in various embodiments, the EPMCs 522, 536, and 546 are designed similarly or differently and report similar data or different data.

[0042] As disclosed herein, in some embodiments, an integrated circuit (IC) includes: a debug controller configured to selectively output debug data on a debug interconnect; a debug state machine (DSM) configured to identify an event based on the debug data and output a DSM indication in response to identifying the event, wherein the DSM is configured to identify the event based on programmable event information; and an extended performance monitoring counter (EPMC) configured to indicate a plurality of detected events, including the identified event, wherein the EPMC is configured to indicate the identified event in response to the DSM indication. In one aspect, the EPMC is further configured to output event data in response to receiving event-based interrupt data, wherein the event-based interrupt data is different from the debug data. In another aspect, the DSM is further configured to identify the event based on at least one pipeline trigger. In yet another aspect, the DSM is configured to receive the programmable event information via a basic input / output system (BIOS) update or a secure firmware update.

[0043] In one aspect, the DSM is configured to receive programmable event information from a user. In another aspect, the identified event is a multi-condition event, and wherein the DSM is further configured to output a DSM indication in response to determining that the debug data indicates a last condition of the identified event. In yet another aspect, the DSM indication includes a count of cycles that have elapsed between a first condition of the identified event and a last condition of the identified event. In yet another aspect, indicating the identified event includes storing data describing the identified event in an event log of a memory device. In another aspect, indicating the identified event includes sending data describing the event to a user interface.

[0044] In some embodiments, a method includes: receiving, by a debug state machine (DSM) via a debug interconnect, first debug data; comparing, by the DSM, the first debug data to an event list stored in the DSM; and, in response to the first debug data matching a first portion of a first entry of the event list, sending a DSM indication to an extended performance monitoring counter (EPMC) indicating that the first event has been detected. In one aspect, the method includes: before receiving the first debug data, receiving, by the DSM, second debug data matching a second portion of the first entry, the first entry corresponding to a multi-condition event, and the first portion of the first entry corresponding to a last condition of the multi-condition event. In another aspect, the method includes receiving, by the DSM, an update to the event list after sending the DSM indication.

[0045] In one aspect, the method includes: after receiving an update to the event list, receiving, by the DSM via a debug interconnect, second debug data; comparing, by the DSM, the second debug data to the event list; and, in response to the second debug data matching a first portion of an update to a first entry of the event list, sending a second DSM indication to the EPMC indicating that a second event has been detected, wherein the second event is different from the first event, and wherein the DSM indication is the same as the second DSM indication. In another aspect, receiving the update to the event list includes receiving the update via a basic input / output system (BIOS) update or a secure firmware update. In yet another aspect, receiving the update to the event list includes receiving the update from a user.

[0046] In some embodiments, a method includes: a debug state machine (DSM) configured to, in response to receiving debug data and pipeline trigger data, identify an event based on an event list stored at the DSM, and output a DSM indication in response to identifying the event; and an extended performance monitoring counter (EPMC) configured to, in response to receiving event-based interrupt data, the DSM indication, or both, indicate one or more of a plurality of detected events, including the identified event. In one aspect, indicating the identified event includes indicating a count of clock cycles during which the identified event occurred. In another aspect, the identified event includes a power state phase transition. In yet another aspect, the DSM indication includes a power state monitoring count. In yet another aspect, the identified event includes a fault event resynchronization.

[0047] In some embodiments, the computer-readable storage medium includes any non-transitory storage medium or combination of non-transitory storage media that can be accessed by a computer system during use to provide instructions and / or data to the computer system. In various embodiments, such storage media include, but are not limited to, optical media (e.g., compact discs (CDs), digital versatile discs (DVDs), Blu-ray discs), magnetic media (e.g., floppy disks, tapes, or magnetic hard disks), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or flash memory), or microelectromechanical system (MEMS)-based storage media. In some embodiments, the computer-readable storage medium is embedded in a computing system (e.g., system RAM or ROM), fixedly attached to a computing system (e.g., a magnetic hard drive), removably attached to a computing system (e.g., an optical disc or flash memory based on a universal serial bus (USB)), or coupled to a computer system via a wired or wireless network (e.g., a network accessible storage device (NAS)).

[0048] In some embodiments, certain aspects of the technology described above are implemented by one or more processors of a processing system that executes software. The software includes one or more executable instruction sets stored or otherwise tangibly embodied on a non-transitory computer-readable storage medium. In some embodiments, the software includes instructions and certain data that manipulate one or more processors to execute one or more aspects of the technology described above when executed by one or more processors. For example, in some cases, a non-transitory computer-readable storage medium includes a magnetic or optical disk storage device, a solid-state storage device (such as a flash memory, a cache, a random access memory (RAM) or one or more other non-volatile memory devices), etc. In some embodiments, the executable instructions stored on the non-transitory computer-readable storage medium are source code, assembly language code, object code, or other instruction formats that are interpreted or otherwise executed by one or more processors.

[0049] It should be noted that not all activities or elements described above in the general description are required, that a portion of a particular activity or device is not required, and that one or more other activities are performed, or that elements other than those described are included. Furthermore, the order in which the activities are listed is not necessarily the order in which the activities are performed. In addition, the corresponding concepts have been described with reference to specific embodiments. However, it will be understood by those skilled in the art that various modifications and changes may be made without departing from the scope of the present disclosure as set forth in the appended claims. Accordingly, this specification and drawings are to be regarded as illustrative rather than restrictive, and all such modifications are intended to be included within the scope of the present disclosure.

[0050] The benefits, other advantages, and solutions to problems have been described above with reference to specific embodiments. However, the benefits, advantages, solutions to problems, and any features that make any benefit, advantage, or solution to the problem appear or become more prominent should not be construed as key, required, or essential features of any or all of the claims. Furthermore, the specific embodiments disclosed above are illustrative only, as the disclosed subject matter may be modified and practiced in different but equivalent manners that will be apparent to those skilled in the art having the benefit of the teachings herein. No limitation is intended to the details of construction or design shown herein, except as described in the appended claims. It is apparent, therefore, that the specific embodiments disclosed above may be altered or modified, and all such variations are considered to be within the scope of the disclosed subject matter. The protection sought herein is therefore as set forth in the appended claims.

[0051] In this disclosure, in some cases, different entities (which are variously referred to as "components," "units," "devices," etc.) are described or claimed as being "configured" to perform one or more tasks or operations. The scheme ([entity] is configured to [perform one or more tasks]) is used herein to refer to a structure (i.e., a physical thing, such as an electronic circuit). More specifically, the scheme is used to indicate that the structure is arranged to perform one or more tasks during operation. A structure can be said to be "configured to" perform some task even if the structure is not currently being operated. "A storage device configured to store data" is intended to cover, for example, an integrated circuit having circuits that store data during operation, even if the integrated circuit in question is not currently being used (e.g., it is not connected to a power source). Thus, an entity described or referenced as being "configured to" perform some task refers to a physical thing, such as a device, a circuit, a memory that stores program instructions that can be executed to implement a task, etc. The phrase is not used herein to refer to something intangible. Furthermore, the term "configured to" does not mean "configurable to." For example, an unprogrammed field programmable gate array would not be considered "configured to" perform some specific function, although it could be "configurable to" perform that function after being programmed. Furthermore, the explicit intent in the appended claims reciting a structure "configured to" perform one or more tasks should not be construed as having means-plus-function elements.

Claims

1. An integrated circuit [100], comprising: a debug controller [102] configured to selectively output debug data [122] over a debug interconnect [110]; A debug state machine [104], wherein the debug state machine is configured to: identifying an event based on the debug data and the programmable event information; and outputting a debug state machine indication [124] on the interconnect (112) in response to identifying the event; as well as An extended performance monitoring counter [106] comprising one or more hardware counters, the extended performance monitoring counter being configured to: a count indicating one or more power states entered by one or more devices of the integrated circuit; and A number of cycles spent in the one or more power states by the one or more devices is indicated based on the debug state machine indication received via the interconnect.

2. The integrated circuit of claim 1 , wherein the count of one or more power states entered by one or more devices of the integrated circuit is based on event-based interrupt data [126] and wherein the event-based interrupt data is different from the debug data.

3. An integrated circuit according to claim 1 or claim 2, wherein the debug state machine is further configured to identify the event based on at least one pipeline trigger [210].

4. The integrated circuit of claim 1 or 2, wherein the debug state machine is configured to receive the programmable event information via a basic input / output system (BIOS) update or a secure firmware update. 5 . The integrated circuit according to claim 1 , wherein the debug state machine is configured to receive the programmable event information from a user.

6. The integrated circuit of claim 1 , wherein the identified event is a multi-condition event including a first power phase transition and a second power phase transition, and wherein the debug state machine is further configured to output the debug state machine indication in response to determining that the debug data indicates the second power phase transition of the identified event.

7. The integrated circuit of claim 6, wherein the debug state machine indication comprises a count of cycles that elapsed between a first condition of the identified event and a last condition of the identified event.

8. The integrated circuit of claim 1 or 2, wherein indicating the identified event comprises storing data describing the identified event in an event log of a memory device.

9. The integrated circuit of claim 1 or 2, wherein indicating the identified event comprises sending data describing the event to a user interface.

10. A method comprising: receiving, by a debug state machine [104] of the integrated circuit, first debug data [122] from a debug controller via a debug interconnect [110]; identifying, by the debug state machine, an event based on the first debug data and programmable event information; Based on identifying the event, sending a debug state machine indication [124] on the interconnect (112) to an extended performance monitoring counter [126] indicating that a first event has been detected; as well as One or more hardware counters of the extended performance monitoring counters indicate a count of one or more power states entered by one or more devices of the integrated circuit, and indicate a number of cycles spent by the one or more devices in the one or more power states based on the debug state machine indication received via the interconnect.

11. The method of claim 10 , wherein the first debug data matches a first portion of a first entry of an event list stored at the debug state machine, and wherein the method further comprises: Prior to receiving the first debug data, second debug data matching a second portion of the first entry is received by the debug state machine, wherein the first entry corresponds to a multi-condition event, and wherein the first portion of the first entry corresponds to a last condition of the multi-condition event.

12. The method of claim 10, wherein the first debug data matches a first portion of a first entry of an event list stored at the debug state machine, and wherein the method further comprises receiving, by the debug state machine, an update to the event list after sending the debug state machine indication.

13. The method according to claim 12, further comprising: receiving, by the debug state machine via the debug interconnect, second debug data after receiving the update to the event list; Comparing the second debugging data with the event list by the debugging state machine; as well as In response to the second debug data matching the first portion of the update of the first entry of the event list, sending a second debug state machine indication to the extended performance monitoring counter indicating that a second event has been detected, wherein the second event is different from the first event, and wherein the debug state machine indication is the same as the second debug state machine indication.

14. The method of claim 12 or claim 13, wherein receiving the update to the event list comprises receiving the update via a basic input / output system (BIOS) update or a secure firmware update.

15. The method of claim 12 or 13, wherein receiving the update to the event list comprises receiving the update from a user.

16. An integrated circuit [100], comprising: A debug state machine [104], wherein the debug state machine is configured to: In response to receiving debug data [122] and pipeline trigger data [210], identifying an event based on an event list [304] stored at the debug state machine; and outputting a debug state machine indication [124] on the interconnect (112) in response to identifying the event; An extended performance monitoring counter [106] comprising one or more hardware counters, the extended performance monitoring counter being configured to: a count indicating one or more power states entered by one or more devices of the integrated circuit; and A number of cycles spent in the one or more power states by the one or more devices is indicated based on the debug state machine indication received via the interconnect.

17. The integrated circuit of claim 16, wherein indicating the identified event comprises a count of clock cycles indicating the occurrence of the identified event.

18. The integrated circuit of claim 17, wherein the identified event comprises a power state phase transition.

19. An integrated circuit as claimed in claim 17 or claim 18, wherein the debug state machine indication comprises a power state monitoring count.

20. The integrated circuit of claim 16, wherein the identified event comprises a fault event resynchronization.

Images