Enhanced performance monitor counters triggered by the debug state machine

Abstract

The integrated circuit (IC) [100] includes a debug controller [102], a debug state machine (DSM) [104], and an extended performance monitor 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 index [124] that identifies the event. The EPMC indicates multiple detected events, including the identified event. The EPMC indicates the identified event according to the DSM index.

Description

[Background technology]

[0001] As integrated circuits (ICs) become more complex, testing, monitoring and debugging those ICs becomes more complex. Automatic test equipment (ATE) and logic analyzers are used to provide predefined input values ​​to the manufactured chips. When an error is detected, the signals of interest are tapped to identify the cause. This process is often time and labor intensive. On-chip logic and performance monitor counters (PMCs) are used to assist in debugging, verifying and performance profiling the ICs. PMCs are used to track and indicate the occurrence of specific events both during chip verification and during normal operation. However, without physically redesigning the IC, traditional PMCs typically track only a relatively small set of selected events.

[0002] The present disclosure may be better understood, and its numerous features and advantages made apparent to those skilled in the art by reference to the following drawings, in which the same reference numbers are used in different drawings to indicate similar or identical items. [Brief description of the drawings]

[0003] [Figure 1] 1 is a block diagram of an embodiment of an integrated circuit including a debug state machine and extended performance monitor counters in accordance with some embodiments. [Diagram 2] FIG. 2 is a block diagram of another embodiment of an integrated circuit including a debug state machine and extended performance monitor counters in accordance with some embodiments. [Diagram 3] 1 is a block diagram illustrating an example debug state machine in accordance with some embodiments. [Figure 4] FIG. 1 is a flow diagram illustrating a method for detecting events and providing debug state machine indications to extended performance monitor counters according to some embodiments. [Diagram 5]1 is a block diagram of a processing system including extended performance monitor counters triggered by a debug state machine according to some embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0004] 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 monitor 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 to a stored event list. In response to the comparison indicating that an event specified in the event list has occurred, the DSM sends a DSM indication to the EPMC. The EPMC indicates, via the IC interface, that the specified event has been detected. Thus, the specified event is detected and indicated based on the debug data, the pipeline trigger, or both. In some cases, detecting and indicating information generated based on the debug data, the pipeline trigger, or both provides additional options for performance profiling, device debugging, validation coverage, or production workarounds.

[0005] In some embodiments, the event list of the DSM is adjustable, such as by direct user input, a basic input / output system (BIOS) update, or 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 hardware that generates an indication that a corresponding event has been detected when a set of various specific signals or triggers (e.g., corresponding to various specified events) is received. As a result, in some cases, the DSM indicates to the EPMC the occurrence of various events compared to before modifying the DSM. Additionally, the EPMC outputs an indication of the occurrence of various events. Thus, in some cases, the list of events reported by the EPMC is modified after the EPMC is manufactured, providing additional chip flexibility.

[0006] Some ICs include performance monitor counters (PMCs) that are not typically 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, etc. For example, the PMC counts specific power states entered and exited, but does not indicate the number of clock cycles spent in each power state, even if such information is available on the debug interconnect in some systems. Furthermore, in some cases, the PMC has a fixed architecture as part of the manufacture of the PMC. As a result, in these ICs, the PMC is limited to indicating a fixed list of events that does 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 an indication of events signaled by the debug interconnect, pipeline triggers, or both, or to change the events indicated by the PMC after the manufacture of the PMC.

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

[0008] In some embodiments, as described further below with reference to FIG. 5, the IC 100 is part of a device such as a desktop computer, laptop computer, server, smartphone, tablet, 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 co-processor elements. In various embodiments, any or all of these components incorporate DSM and performance monitor counters. In various embodiments, any or all of these components send instruction-based sampling data 126 to the EPMC 106, send debug source information 120 at various observability points to the debug controller 102 as part of executing various programs or instruction sequences, or both.

[0009] In the illustrated embodiment, various debug source information 120 (e.g., cross trigger signals, trap signals, clock stop signals, error signals, performance monitor (perfmon) signals or events on a communications interface, interrupts, breakpoints, microcode-based triggers (e.g., breakpoints, performance monitors, interrupts, and error events), timer overflows, resynchronization fault signals, power state change signals, power consumption signals, status signals of particular internal logic of a sending logic block, or any combination thereof) are provided to debug controller 102. In response to receiving debug source information 120, debug controller 102 selectively outputs debug source information 120 as debug data 122 on debug interconnect 110 (e.g., a debug bus). For example, in some cases, debug controller 102 includes one or more multiplexers that alternate between inputting debug source information 120 and outputting received data as debug data 122.

[0010] DSM 104 receives debug data 122 over debug interconnect 110 and compares the received data to an event list (e.g., programmable event information) stored in DSM 104. In response to determining that debug data 122 indicates a completed event, DSM 104 generates a DSM indicator (DSM display) 124 indicating that a 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 of DSM 104 that detects and indicates various events without storing the conditions together in a memory device. In various embodiments, DSM 104 identifies single condition events, multiple condition events, or both, as described further below with reference to FIG. 3. For example, in some cases, DSM 104 generates DSM indicator 124 in response to detecting a resynchronization of a fault signal. 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), DSM 104 tracks the number of clock cycles spent in a 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 a particular phase), DSM 104 generates DSM index 124. In some cases, DSM index 124 indicates the number of cycles spent in a particular phase. Thus, in various embodiments, DSM 104 generates DSM index 124 in response to debug data 122 indicating a particular state, generates DSM index 124 in response to a sequence of signals, or both. Additionally, as described below with reference to FIG. 2, in various embodiments, DSM 104 generates various other control signals in response to various inputs (e.g., signals received via debug interconnect 110 or from other devices).

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

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

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

[0014] 1, in some embodiments, debug controller 102 generates debug data 122 based on debug source information 120. DSM 104 generates DSM indicator 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 indicator 124.

[0015] 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 a pipeline trigger (shown as a pipeline trigger 210 for simplicity) to the DSM 104 via the pipeline input interconnect 204. For example, in some cases the pipeline trigger 210 includes a trap signal, a clock stop signal, an error signal, a performance monitor (perfmon) signal or event, an interrupt signal, a breakpoint indication, a microcode-based trigger (e.g., a breakpoint, a performance monitor, an interrupt, an error event), and a timer overflow signal.

[0016] 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) over 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 a local stop clock signal, a die-wide stop clock signal, a memory device self-refresh signal, a communication interface receive invalid 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 DSM microcode registers, an operation stall signal, a structure flush signal, instructions to start storing debug data to a state capture buffer (e.g., to a debug record buffer (DRB) and to a reserved cache way or spill to system memory), instructions to stop storing debug data to a state capture buffer, instructions to store a clock count to a state capture buffer, and instructions to resize a queue.

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

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

[0019] In the illustrated example, the DSM 104 receives the debug data 122, the pipeline trigger 210, or both. The event detection component 302 compares the received data to an event list 304 and determines, based on the comparison, whether an event is detected. In response to detecting an event, the DSM 104 transmits a DSM indicator 124 indicative of the detected event. Additionally, in the illustrated embodiment, the event detection component 302 determines, based on the received data, whether a pipeline action 212 is generated. However, in other embodiments, the pipeline action 212 is generated using different hardware of the DSM 104.

[0020] For purposes of illustration, FIG. 3 illustrates four examples of potential events that may result in generating a DSM indicator 124. In particular, in response to the debug data 122 indicating an internal power state monitor count where the power state monitor indicates a value greater than a first value, the DSM 104 transmits a DSM indicator 124 indicative of the power state monitor count. As another example, in response to the debug data 122 indicating an internal power state monitor count where the power state monitor indicates a value less than a second value, the DSM 104 transmits a DSM indicator 124 indicative of the power state monitor count. In some embodiments, the first value, the second value, or both, are proxy values ​​indicative of an observed die voltage within a range of die voltages of the integrated circuit. In other embodiments, the first value, the second value, or both, are actual voltages. Additionally, the DSM 104 transmits a DSM indicator 124 in response to the debug data 122 indicating a resync fault signal is high or in response to the pipeline trigger 210 being active. Additionally, in some cases, an event in the event list 304 is a multi-condition event. 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), and in response to debug data 122 indicating that a second power state change has occurred, DSM 104 stops counting clock cycles and transmits the number of counted clock cycles as DSM index 124.

[0021] 4 is a flow diagram illustrating a method 400 for detecting events and providing debug state machine indications for extended performance monitor counters, according to some embodiments. Method 400 is performed in some embodiments by a DSM, such as DSM 104 of FIG. 1. In some embodiments, method 400 is initiated by one or more processors in response to one or more instructions stored by a computer-readable storage medium.

[0022] At block 402, the DSM receives event data. For example, in some cases, the DSM 104 receives the debug data 122, the pipeline trigger 210, or both. At block 404, the DSM determines whether the event data matches a next condition of a multi-condition event in an event list of the DSM. For example, in some cases, the event data indicates that a phase change in power state has occurred, as described above with reference to FIG. 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.

[0023] At block 406, in response to the event data matching a next condition of the multi-condition event, the DSM determines whether the event completes as a result of receiving the event data. For example, in some cases, the event data indicates that a second power state phase change has occurred. In response to the event completing, the method 400 proceeds to block 410. In response to the event not completing, the method 400 proceeds to block 402. At block 408, in response to the event data not matching a next condition of the multi-condition event, the DSM determines whether the event data matches a single condition of the event list. For example, in some cases, the event data indicates that a resync fault signal is high or a pipeline trigger is asserted. In response to the event data matching a single condition event, the method 400 proceeds to block 410. In response to the event data not matching a single condition event, the method 400 proceeds to block 402.

[0024] At block 410, in response to the multi-condition event completing or in response to the event matching a single condition event, the DSM sends a DSM indicator to the extended performance monitor counters. For example, in response to identifying a completed event, the DSM 104 sends a DSM indicator 124 to the EPMC 106. The method 400 then returns to block 402. Thus, a method for detecting an event and providing a debug state machine indication to extended performance monitor counters is shown.

[0025] FIG. 5 is a block diagram illustrating a processing system 500 including enhanced performance monitor counters 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-die hardware. As described above, the DSM receives triggers (e.g., debug data or pipeline triggers) from one or more sources and selects a predetermined action (e.g., sending a DSM indicator or pipeline action) based on the trigger. The sources include components within the same core or controller, other on-die components outside the same core or controller, and additionally, off-die components. In some embodiments, the DSMs are interconnected via a network (e.g., an overlay bidirectional cross-trigger network). While the illustrated embodiment includes the DSM and EPMC in various components, in other embodiments, the DSM and EPMC are included in fewer, additional, or different components. Additionally, while the DSM and EPMC are paired in the illustrated embodiment, in other embodiments, the DSM, EPMC, or both appear separately.

[0026] In some cases, multiple time-sharing sequences occur in the processing system 500. For example, in some cases, a sequence may include a software process, a software thread, a system-level transaction, or a power performance state (p-state). A sequence may include one or more instructions executed on the IC under test that are scheduled by the OS or on-die hardware. A sequence identifier (ID) is used to distinguish the 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 may share hardware resources (e.g., execution units, queues, schedulers, process states, or memory space) in the IC with other sequences.

[0027] In some embodiments, one or more processor cores (e.g., multithreaded processor cores 532-1-532-2 or graphics processor core 542) of processing system 500 execute multithreaded applications. Additionally, in some cases, processing system 500 operates under any of a number of power performance states. Additionally, in some cases, multiple independent system level transaction levels operate on processing system 500. Each of the processes, threads, and p-states is an example of a sequence.

[0028] In some embodiments, one or more of the DSMs 520, 534 (DSMs 534-1-534-2), or 544 of the processing system 500 track statistics and operational behavior including on-die interconnect state and I / O device interconnect state. The DSMs 520, 534, 544, or any combination thereof, provide state information, stored parameters, and combinatorial control logic for testing the on-die hardware during processing of independent sequences. Rather than duplicating a full instantiation 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 event lists that can be modified after manufacturing of the processing system 500. As a result, in some cases, various tests and parameters tracked by the DSMs 520, 534, and 544 are modified after manufacturing of the processing system 500.

[0029] As described above, one or more of EPMCs 522, 536 (EPMCs 536-1 through 536-2) or 546 similarly track and provide status information for debugging, profiling and refining code, and operating system operation. 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. Additionally, in some cases, EPMCs 522, 536, and 546 combine the received DSM indications with received event-based interrupt data to generate event data.

[0030] As shown, processing system 500 includes various units 508 (general purpose processing units 508-1-508-2) and units 510 (e.g., graphics processing units). Units 508 include respective general purpose multi-threaded processor cores 532 and corresponding cache memory subsystems 530 (e.g., cache memory subsystems 530-1-530-2). Similarly, units 510 include graphics processor cores 542 and buffers 540.

[0031] In some embodiments, each multithreaded processor core 532 includes a superscalar microarchitecture with one or more multi-stage pipelines. In some cases, each software thread of a multithreaded software application is processed by a separate pipeline within each multithreaded processor core 532. Alternatively, a pipeline capable of processing multiple threads via control at a particular functional unit processes each thread. In yet other instances, each thread is processed by a pipeline with a combination of dedicated resources for each of the multiple threads and shared resources used by all of the multiple threads. In various embodiments, each multithreaded processor core 532 includes circuitry for processing instructions according to a predetermined general purpose instruction set.

[0032] Typically, each multi-threaded processor core 532 accesses a level 1 (L1) cache for data and instructions. In some cases, there are multiple on-die level (L2, L3, etc.) caches. In some embodiments, one or more of these levels of caches are external to the processor core and are within each cache memory subsystem 530. Additionally, in some cases, the processing system 500 includes one or more application-specific 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 including multiple pipeline stages, each stage having multiple arithmetic logic unit (ALU) components, and operates on multiple data values ​​in a data stream with a single instruction.

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

[0034] In some cases, memory controller 502 connects processing system 500 to off-die memory devices, such as dynamic random access memory (DRAM), disk memory, and offline archival memory. Thus, memory controller 502 includes control circuitry for interfacing to 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 DSM 520 and EPMC 522.

[0035] In the illustrated embodiment, the interface 512 includes integrated channel circuitry for directly linking signals to other processing nodes, such as another processor. Thus, in some cases, the interface 512 utilizes one or more coherence links for inter-node access of the processor's on-die cache and the off-die memory of another processing node. Examples of this technology include HyperTransport and QuickPath. The I / O interface 550 provides an interface to the shared cache memory subsystem 504 and units 508 and 510 for I / O devices outside the processing system 500. Additionally, in some cases, the I / O interface 550 provides an interface to one or more of the EPMCs 522, 536, and 546. In some cases, the I / O interface 550 further communicates with a platform and an I / O controller hub (not shown) for data control and access. In some cases, the hub generates control packets and response packets in response to information and commands received from the processing system 500 in response to control packets and messages received on each link. In some cases, the hub performs on-die operations that are typically performed off-die by a traditional southbridge chipset. In some embodiments, the hub includes a separate DSM, EPMC, or both.

[0036] Test interface 514 includes an interface for testing processing system 500 according to a predetermined 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, test interface 514 is used to program one or more of DSMs 520, 534, and 544 via DSM interface 560. In some embodiments, programming a DSM includes writing a particular value to a register corresponding to a given DSM, such as a register corresponding to an event list. In some cases, programming a DSM determines which triggers the DSM will respond to and the type of action performed in response.

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

[0038] 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 indicator in response to identifying the event, the DSM configured to identify the event based on programmable event information; and an extended performance monitor counter (EPMC) configured to indicate a plurality of detected events including the identified event, the EPMC configured to indicate the identified event in response to the DSM indicator. In one aspect, the EPMC is further configured to output the event data in response to receiving event-based interrupt data, the event-based interrupt data being 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.

[0039] 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 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 cycle count 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 transmitting data describing the event to a user interface.

[0040] In some embodiments, the method includes receiving, by a debug state machine (DSM), first debug data over a debug interconnect; 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 in the event list, sending a DSM indication to an extended performance monitor counter (EPMC) indicating that a first event has been detected. In one aspect, the method includes receiving, by the DSM prior to receiving the first debug data, second debug data matching a second portion of the first entry, the first entry corresponding to a multiple condition event, the first portion of the first entry corresponding to a last condition of the multiple condition event. In another aspect, the method includes receiving, by the DSM after sending the DSM indication, an update to the event list.

[0041] In one aspect, the method includes receiving, by the DSM, second debug data via the debug interconnect after receiving the update to the event list, comparing, by the DSM, the second debug data to the event list, and in response to the second debug data matching an updated first portion of the first entry in the event list, sending a second DSM indication to the EPMC indicating that a second event has been detected, where the second event is different from the first event and 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.

[0042] In some embodiments, the method includes a debug state machine (DSM) configured to, in response to receiving the debug data and the pipeline trigger data, identify an event based on an event list stored in the DSM and, in response to identifying the event, output a DSM indication; and an extended performance monitor counter (EPMC) configured to, in response to receiving the 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 phase change of a power state. In yet another aspect, the DSM indication includes a power state monitor count. In yet another aspect, the identified event includes a resynchronization failure event.

[0043] In some embodiments, a 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. Such storage media may 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, magnetic tape, magnetic hard drives), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or flash memory), or micro-electromechanical systems (MEMS) based storage media. The computer-readable storage medium (e.g., system RAM or ROM) may be internal to the computing system, the computer-readable storage medium (e.g., a magnetic hard drive) may be permanently attached to the computing system, the computer-readable storage medium (e.g., an optical disk or Universal Serial Bus (USB)-based flash memory) may be removably attached to the computing system, or the computer-readable storage medium (e.g., network-accessible storage (NAS)) may be coupled to the computer system via a wired or wireless network.

[0044] In some embodiments, some aspects of the above techniques may be implemented by one or more processors of a processing system executing software. The software includes one or more sets of executable instructions stored in or tangibly embodied on a non-transitory computer-readable storage medium. The software may include instructions and specific data that, when executed by one or more processors, operate the one or more processors to perform one or more aspects of the above techniques. The non-transitory computer-readable storage medium may include, for example, 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. The executable instructions stored on the non-transitory computer-readable storage medium may be source code, assembly language code, object code, or other instruction formats that can be interpreted or executed by one or more processors.

[0045] In addition to the above, it should be noted that not all activities or elements described in the summary description are required, some of the specific activities or devices may not be required, one or more additional activities may be performed, and one or more additional elements may be included. Furthermore, the order in which the activities are listed is not necessarily the order in which they are performed. Also, the concepts have been described with reference to specific embodiments. However, those skilled in the art will appreciate that various changes and modifications can be made without departing from the scope of the invention as set forth in the claims. Thus, the specification and drawings should be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the invention.

[0046] Benefits, other advantages, and solutions to problems have been described above with respect to specific embodiments. However, the benefits, advantages, solutions to problems, and features by which any benefit, advantage, or solution may occur or be manifested are not to be construed as critical, essential, or essential features of any or all claims. Moreover, the specific embodiments described above are illustrative only, as the disclosed invention may be modified and practiced in different but similar manners apparent to those skilled in the art having the benefit of the teachings herein. No limitations are intended to the details of construction or design herein shown, other than as set forth in the appended claims. It is therefore apparent that the specific embodiments described above may be altered or modified, and all such variations are considered to be within the scope of the disclosed invention. Accordingly, the protection sought herein is set forth in the appended claims.

[0047] Within the scope of this disclosure, in some cases, different entities (variously referred to as "components," "units," "devices," etc.) are described or claimed to be "configured" to perform one or more tasks or operations. The phrase "entity" 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 phrase is used to indicate that the structure is configured 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 operated. A "memory device configured to store data" is intended to include, for example, an integrated circuit having a circuit that stores data during operation, even if the integrated circuit is not currently in use (e.g., not connected to a power source). Thus, an entity described or illustrated as "configured" to perform a task refers to a physical thing, such as a device, a circuit, a memory that stores program instructions executable to perform a task. The phrase is not used herein to refer to intangible things. Moreover, the term "configured to" does not mean "configurable to". For example, an unprogrammed field programmable gate array is not considered to be "configured to" perform any particular function, even if it is "configurable" to perform that function after programming. Moreover, it is expressly intended that any recitation in the appended claims of a structure being "configured to" perform one or more tasks should not be construed as having a means-plus-function element.

Claims

1. a debug controller [102] configured to selectively output debug data [122] on a debug interconnect [110]; a debug state machine (DSM) [104] configured to identify an event based on the debug data and output a DSM indicator [124] in response to identifying the event, the DSM configured to identify the event based on programmable event information; an Extended Performance Monitor Counter (EPMC) [106] configured to indicate a number of detected events including the identified event, the EPMC configured to indicate the identified event in response to the DSM indicator; Integrated circuits (ICs) [100].

2. The EPMC is further configured to output event data [128] in response to receiving the event-based interrupt data [126]; the event-based interrupt data is different from the debug data; The IC of claim 1.

3. The DSM is further configured to identify the event based on at least one pipeline trigger [210].

3. An IC according to claim 1 or 2.

4. The DSM is configured to receive the programmable event information via a basic input / output system (BIOS) update or a secure firmware update. An IC according to any one of claims 1 to 3.

5. the DSM is configured to receive the programmable event information from a user; An IC according to any one of claims 1 to 4.

6. the identified event is a multi-condition event; The DSM is further configured to output the DSM indicator in response to determining that the debug data indicates a final condition of the identified event. An IC according to any one of claims 1 to 5.

7. the DSM index includes a count of cycles elapsed between a first condition of the identified event and the last condition of the identified event. The IC of claim 6.

8. and indicating the identified event includes storing data describing the identified event in an event log in a memory device. An IC according to any one of claims 1 to 7.

9. indicating the identified event includes transmitting data describing the event to a user interface. An IC according to any one of claims 1 to 8.

10. receiving, by a debug state machine (DSM) [104], first debug data [122] over a debug interconnect [110]; comparing, by the DSM, the first debug data with an event list [304] stored in the DSM; in response to the first debug data matching a first portion of a first entry in the event list, sending a DSM indication [124] to an extended performance monitor counter (EPMC) [126] indicating that a first event has been detected. method.

11. receiving, by the DSM prior to receiving the first debug data, second debug data that matches a second portion of the first entry; the first entry corresponds to a multi-condition event, and the first portion of the first entry corresponds to a last condition of the multi-condition event. The method of claim 10.

12. and receiving, by the DSM after transmitting the DSM indicator, an update to the event list.

12. The method of claim 10 or 11.

13. receiving, by the DSM after receiving the event list update, second debug data over the debug interconnect; comparing, by the DSM, the second debug data to the event list; and in response to the second debug data matching the updated first portion of the first entry in the event list, sending a second DSM indication to the EPMC indicating that a second event has been detected; the second event is different from the first event and the DSM index is the same as the second DSM index; 13. The method of claim 12.

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

15. receiving updates to the event list includes receiving the updates from a user; The method of any one of claims 12 to 14.

Images