Performance monitoring circuit, method, and computer program

Abstract

The performance monitoring circuit (40) has event counters (42) each maintaining an event count value based on monitoring of events during software processing by the processing circuit. The control circuit (44) configures the event counters based on counter configuration information. For at least a subset of the event counters, a given event counter (42) in the subset supports chain counter operation, which includes incrementing a given event count value by an increment value determined based on a logical combination of a first event status indicator indicating the status of a first event type assigned by counter configuration information to be monitored by a given event counter, and a second event status indicator indicating the status of a second event type assigned by counter configuration information to be monitored by a further event counter.

Description

Technical Field

[0001] This technique relates to the field of data processing. More particularly, it relates to performance monitoring.

[0002] A data processing system may have a performance monitoring circuit for monitoring the performance of software executed on a processing circuit. The performance monitoring circuit includes event counters for counting the occurrence of various events such as the execution of instructions, misses in a cache or translation lookaside buffer, buffer full conditions, stalls in instruction execution, etc. The event count values maintained by the counters are read by debug software and may be used for analysis of software performance to help identify possible reasons for any performance problems when the software is executing on the data processing system.

[0003] At least some embodiments provide a performance monitoring circuit for monitoring the performance of software running on a processing circuit, comprising: a plurality of event counters, each maintaining its own event count value based on monitoring events during software processing by the processing circuit; and a control circuit for configuring the event counters based on counter configuration information, wherein the counter configuration information includes event type assignment information indicating which types of events are assigned to be monitored by the event counters, wherein for at least a subset of the event counters, a given event counter in the subset is configured to support chain counter operation for at least one setting of the counter configuration information, a given event counter is configured to maintain a given event count value, and the chain counter operation includes incrementing a given event count value by an increment value determined based on a logical combination of a first event status indicator indicating the status of a first event type assigned by counter configuration information to be monitored by a given event counter, and a second event status indicator indicating the status of a second event type assigned by counter configuration information to be monitored by further event counters.

[0004] At least some embodiments provide an apparatus comprising the performance monitoring circuit and processing circuit described above.

[0005] At least some embodiments provide a computer-readable medium for storing computer-readable code for the fabrication of a performance monitoring circuit or the aforementioned device. The computer-readable medium may be a non-temporary storage medium.

[0006] At least some embodiments provide a method for monitoring the performance of software running on a processing circuit, the method comprising: configuring a plurality of event counters based on counter configuration information, wherein the counter configuration information includes event type assignment information indicating which types of events are assigned to be monitored by the event counters; using the plurality of event counters, maintaining each event count value based on monitoring events in the processing of the software by the processing circuit; and performing a chain counter operation for at least one setting of the counter configuration information for a given event counter in at least a subset of the event counters, wherein the given event counter maintains a given event count value, the chain counter operation comprising incrementing a given event count value by an increment value determined based on a logical combination of a first event status indicator indicating the status of a first event type assigned by counter configuration information to be monitored by a given event counter, and a second event status indicator indicating the status of a second event type assigned by counter configuration information to be monitored by further event counters.

[0007] At least some embodiments provide a computer program that includes instructions for controlling a host data processing device to provide an instruction execution environment for executing target program code when executed by the host data processing device, the computer program includes event count program logic for maintaining a plurality of event count values ​​based on monitoring of events during simulated processing of target program code by a target processing circuit, and control program logic that constitutes the event count program logic based on counter configuration information, the control program logic including event type assignment information indicating which types of events are assigned so that the event count program logic monitors using a plurality of event count values, the event count program logic is configured to support chain counter operation for maintaining a given event count value in the subset for at least a subset of event count values ​​and for at least one setting of the counter configuration information, the chain counter operation includes incrementing a given event count value by an increment value determined based on a logical combination of a first event status indicator indicating the status of a first event type assigned by counter configuration information to be monitored using a given event count value and a second event status indicator indicating the status of a second event type assigned by counter configuration information to be monitored by further event counters.

[0008] At least some embodiments provide a computer-readable storage medium for storing the aforementioned computer programs. The storage medium may be a non-temporary storage medium. [Brief explanation of the drawing]

[0009] Further aspects, features, and advantages of this technique will become apparent from the following example description, which should be read in conjunction with the attached drawings. [Figure 1]An example of a data processing system including a performance monitoring circuit will be illustrated. [Figure 2] An example of a performance monitoring circuit will be illustrated. [Figure 3] This example illustrates an event counter that is incremented based on an increment value selected as a function for indicating the event status. [Figure 4] For comparison, we illustrate an approach in which a third event counter is configured to increment its count value based on a logical combination of the outputs of two other counters, which depend on an event status indicator that shows the status of an event assigned to the other two counters by the counter configuration information. [Figure 5] An alternative technique is illustrated for controlling a given counter to increment a given count value by an increment value selected based on a logical combination of a first event status indicator indicating the status of a first event type assigned to be monitored by the given counter itself, and a second event status indicator indicating the status of a second event type assigned to be monitored by a further event counter. [Figure 6] An alternative technique is illustrated for controlling a given counter to increment a given count value by an increment value selected based on a logical combination of a first event status indicator indicating the status of a first event type assigned to be monitored by the given counter itself, and a second event status indicator indicating the status of a second event type assigned to be monitored by a further event counter. [Figure 7]An alternative technique is illustrated for controlling a given counter to increment a given count value by an increment value selected based on a logical combination of a first event status indicator indicating the status of a first event type assigned to be monitored by the given counter itself, and a second event status indicator indicating the status of a second event type assigned to be monitored by a further event counter. [Figure 8] This flowchart illustrates performance monitoring using event counters. [Figure 9] This flowchart illustrates the process of implementing a chain counter. [Figure 10] This flowchart illustrates a specific embodiment in which the second event status indicator is one of the candidate increment values ​​available for selection, depending on the result value of the first event status function. [Figure 11] An example of a simulation will be provided.

[0010] A performance monitoring circuit is provided for monitoring the performance of software running on a processing circuit. The performance monitoring circuit comprises two or more event counters, each maintaining its own event count value based on monitoring events during software processing by the processing circuit, and a control circuit that configures the event counters based on counter configuration information. The counter configuration information includes event type assignment information indicating which types of events are assigned to be monitored by the event counters. Such a performance monitoring circuit can be useful in investigating possible causes of insufficient performance when software is running on the processing circuit, because the event count values ​​can reveal information about internal events occurring within the processing circuit while the software is running (such as cache misses, branch prediction misses, instruction stalls, buffer fullness, etc.).

[0011] In the following embodiments, for at least a subset of event counters, a given event counter within the subset is configured to support chain counter operation for at least one setting of counter configuration information. Hereinafter, the event count value maintained by a given event counter is referred to as the "given event count value". The chain counter operation includes incrementing the given event count value by an increment value determined based on a logical combination of a first event status indicator indicating the status of a first event type assigned by counter configuration information to be monitored by a given event counter, and a second event status indicator indicating the status of a second event type assigned by counter configuration information to be monitored by a further event counter.

[0012] Such chain counter operations are useful for providing information about combinations of occurrences of multiple different event types that would normally be counted by different counters. For example, a logical combination may implement a function such as AND so that a given event count value can indicate the number of times an event of a first event type and an event of a second event type occurred simultaneously, or it may implement a function such as OR so that a given event count value can indicate the total number of cycles in which one or both of the two types of events occurred. Combining such functions may provide more useful diagnostic information than counting each event type individually.

[0013] The chain counter operation involves incrementing a given event count value (maintained by a given event counter) based on a logical combination of a first event status indicator corresponding to a first event type assigned to be monitored by a given event counter, and a second event status indicator corresponding to a second event type assigned to be monitored by a further event counter. This can be a particularly efficient approach for generating an event count value as the combined status of two different events.

[0014] Firstly, this approach can help save on the hardware costs of implementing event counters and associated control hardware. To enable a configurable selection of event types counted by the event counters (selected based on counter configuration information that may be programmable by the user), each event counter may be associated with event selection hardware logic (e.g., a multiplexer) to select which of several different event status signals is provided to the event counter logic to control the increment of the corresponding event count value. For approaches that do not support chain counter operation, such event selection hardware logic may be implemented so that the event selection hardware logic for each event counter can select a single event signal at a time. In chain counter operation, by using a second event type assigned to a further event counter as an additional input to a given event counter (rather than allowing the arbitrary definition of a second type of event for a given event counter independently of any events assigned to other counters), this means that chain operation for a given event counter can leverage the event selection hardware logic provided for further event counters, rather than needing to increase the complexity of the event selection hardware logic associated with a given event counter to support the selection of two or more event types per counter. Therefore, this can save on the hardware costs associated with implementing a chain counter configuration.

[0015] Furthermore, by incrementing a given event count value based on a logical combination of a first event status indicator corresponding to a first event type assigned to be monitored by a given event counter itself, and a second event status indicator corresponding to a second event type assigned to be monitored by a further event counter, this means that the third counter does not need to be used to obtain the count value based on the combined status of the first and second event types (as opposed to an alternative approach in which the third counter increments its counter based on a logical combination of the statuses of the first and second event types assigned to two other counters by counter configuration information). Since the number of event counters supported by hardware may be limited, freeing up counters for other purposes may be useful to allow additional items of performance monitoring information to be collected (e.g., for events unrelated to the first and second event types) in scenarios where the user does not think it is necessary to maintain individual counts of the occurrences of both the first and second events, as well as a combined count based on a logical combination of the status signals corresponding to those events.

[0016] The first and second event status indicators can be arbitrary signals indicating the status of something occurring in a given part of the processing circuit. For some event types, the event status indicator can be a two-state indicator indicating whether a particular event occurred in a given cycle. For example, the event status indicator may indicate whether a cache miss occurred in the current cycle, or whether a load instruction was executed in the current cycle. Alternatively, in some implementations, event signals may be communicated to a performance monitoring circuit at intervals less frequent than all cycles (or some types of events may occur more than once in the same cycle), and therefore, the event status indicator may indicate the number of occurrences of the corresponding event type since the update prior to the event status indicator. For example, the event signal may indicate the number of cache misses that have occurred since the last update. Also, in some cases, the event status indicator may not be a simple yes / no indicator of whether an event occurred, but rather a quantitative parameter representing the current state of a component of the processing circuit. For example, for one event type, the event status indicator may indicate the current occupancy rate of a buffer (e.g., the number of pending loads in the load buffer). Therefore, it will be understood that event status indicators can be represented in many different ways, depending on the type of event being tracked.

[0017] The counter configuration information may include information specifying which logical combination should be used to combine the first and second event status indicators. For example, the chain count operation may support several different logical combinations, and the counter configuration information may select which logical combination to use. For example, the information identifying the logical combination may specify a Boolean function (such as AND or OR) to be applied to combine the first and second event status indicators. Alternatively, the information identifying the logical combination may specify how an increment value should be selected to increment a given event count value based on the first / second event status indicators (as will be further discussed below, in some implementations, the first / second event status indicators can be processed individually and then the result can be used to adjust the selection of the increment value to produce a result equivalent to a Boolean combination such as AND or OR, and therefore it is not necessary to include circuit logic for directly combining the first / second event status indicators with a Boolean function).

[0018] In some embodiments, the chain counter operation includes determining a first event function result value for a given event counter as a function of at least a first event status indicator, and, depending on at least the first event function result value, selecting one of several candidate increment values ​​as an increment value for incrementing a given event count value based on selection control information. For example, the function may include a threshold function and / or an edge function, as further mentioned below. At least one of the first event function result value, selection control information, and candidate increment values ​​depends on a second event status indicator.

[0019] Therefore, the second event status indicator can affect the chain counter operation in different ways, depending on the selected implementation.

[0020] In some embodiments, one or more of the selection control information and / or candidate increment values ​​may depend on a value dependent on a second event status indicator. For example, the value dependent on the second event status indicator may be an input to an increment selection multiplexer that selects from candidate increment values ​​based on the selection control information. Introducing the dependency on the second event status indicator in the increment selection multiplexer, rather than in the circuit for evaluating the first event function result value, may help reduce hardware costs by avoiding any need to arbitrarily complicate the function calculation circuit for calculating the function of the first event status indicator, rather than being provided to support non-chain counter operation in which a given event counter is incremented based on a function of the first event status indicator independently of the second event status indicator. Adapting the circuit for selecting the increment to support consideration of the second event status indicator may be more efficient. Furthermore, introducing a value that depends on a second event status indicator in an increment selection multiplexer may make it easier to meet the circuit's timing requirements, as it eliminates the need to delay the calculation of the first event function result value while waiting for further event counters to provide a value that depends on the second event status indicator.

[0021] In some embodiments, the plurality of candidate increment values include a value that depends on the second event status indication and at least one additional increment value. The inventors have provided a value that depends on the second event status indication as an option for selecting, as an increment value in a given event counter, a result equivalent to a logical combination (such as a Boolean AND or OR) of the first / second event statuses, and recognized that it can be simulated by selecting between a value that depends on the second event status indication and at least one additional increment value based on a first event function result value (derived from the first event status indication). This eliminates the need to include circuitry for actually combining the first / second event function results in a Boolean conjunction. Thus, this approach can be particularly efficient in supporting chain counter operation with reduced additional complexity in hardware circuit logic compared to an approach where each counter can only increment its count value based on a function of the event status indication of a single event type.

[0022] (Provided as an alternative to selecting a value that depends on the second event status indication as an increment value) The at least one additional increment value can include at least one of 0, 1, and the first event status indication. In implementations that support two or more of these options for the additional increment value, the counter configuration information can specify which option should be used for the additional increment value for a given instance performing chain counter operation.

[0023] In some embodiments, the selection control information depends on a value that depends on the second event status indication (and depends on the first event function result value). In this case, the value that depends on the second event status indication is used as a control input to an increment selection multiplexer that controls which increment value is selected. The value that depends on the second event status indication may also be provided as one of the candidate increment values available for selection.

[0024] In other embodiments, the first event function result value may depend on a value that depends on the second event status indication. In this case, the first event function result value may be calculated as a function of both the first event status indication and the value that depends on the second event status indication, and then the first event function result value can be used to select the increment value to be used to increment a given event count value (in this case, the increment selection need not have an additional dependency on the second event status indication other than that the first event function result value depends on the second event status indication). This approach can increase the flexibility of the range of logical combinations that can be used to combine the first / second event statuses. For example, this approach may support a combining function that determines the minimum or maximum value of the numerical values indicated by the first / second event statuses.

[0025] The selection of an increment value may also depend on other information (independent of the first / second event status indicator). For example, the selection of an increment value may also depend on the counter configuration information of a given event counter. In one embodiment, the first event function result value is used to select between two alternative candidate increment values, and the counter configuration may specify information for selecting which of the two alternative candidate increment values, selected based on the first event function result value, is from a wider set of three or more hardware-supported candidate increment values. In some implementations (for example, when a value dependent on the second event status indicator is used as one of the two alternative candidate increment values), the information defining the two alternative candidate increment values ​​may also define whether chain counter operation should be performed at all (for example, in a setting of counter configuration information where the second event status indicator is not one of the two alternative candidate increment values, the increment value may be independent of the second event status indicator, and therefore the given event counter may instead perform non-chain counter operation).

[0026] The value that depends on the second event status indicator (used as a candidate increment value for a given event counter, a control input to a selection circuit that selects the increment value for a given event counter, or an input to a function used to determine the result value of the first event function) can be implemented in different ways. For example, depending on the choice of implementation, the value that depends on the second event status indicator may be: • Second event status indication (for example, for event types where the second event status indication is a two-state indication of whether the event occurred or not, it may not be necessary to further modify it before using it in chain counter operation), • At least as a function of the second event status indicator, a second event function result value determined for further event counters (for example, for quantitative status indicators, it may be useful to generate a two-state indicator that shows whether the number indicated by the second event status indicator meets a certain criterion (e.g., whether it is greater than a threshold)), and Based on at least the result value of the second event function, a second increment value may be selected to increment a further event counter (in some cases, the increment value selected by the further event counter may help enable the increment value of a given event counter to represent a logical combination of the first / second event status indications).

[0027] The function used to calculate the result value of the first event function may vary.

[0028] In some embodiments, for at least one setting of counter configuration information, the first event function result value comprises a first event status indicator and a threshold function result value indicating whether the threshold condition is met. Such a threshold function is useful because there may be types of events for which the event is counted only if the event status indicator exceeds the threshold, and this is significant enough. For example, some performance effects may be caused by a particular buffer or queue becoming full or nearly full, and as a result, it may be useful to count the number of times the occupancy rate of a particular buffer or queue exceeds a threshold. Similarly, underutilization of some components can be examined based on whether the occupancy rate of a queue is below a threshold.

[0029] The threshold of the threshold function may be specified by the counter configuration information, and as a result, the user can program the counter configuration information to set the threshold to a desired level. Therefore, the threshold may be a pre-configured value defined solely by the counter configuration information set by the user, regardless of the status of any events being monitored by the performance monitoring circuit.

[0030] Furthermore, it is possible to variably control the specific threshold conditions applied based on the counter configuration information. For example, the threshold condition could be one of the following: whether the first event status indicator is equal to a threshold, whether the first event status indicator is not equal to a threshold, whether the first event status indicator is greater than or equal to a threshold, or whether the first event status indicator is less than a threshold (other options are also possible). The counter configuration information can specify which particular type of threshold condition should be applied to a particular event counter.

[0031] In some embodiments, for at least one setting of counter configuration information, the first event function result value includes an edge function result value indicating whether there has been a change between the previous cycle and the current cycle in whether the first event status indicator satisfies a predetermined condition. In some cases, the predetermined condition may be a threshold condition used to evaluate a threshold function based on the first event status indicator and a threshold, as discussed above, but it is also possible that the edge function depends on the evaluation of other functions of the first event status indicator that are not based on a threshold. Edge functions can be useful for performance monitoring when it is desirable to obtain a count of the number of different cases in which a condition is met (rather than the total number of cycles in which the condition is met). For example, an edge function can be used to count the number of different cases in which a buffer is full (as opposed to counting the duration (number of cycles) in which the buffer remains full, which can be done with a non-edge function).

[0032] Therefore, the chain counter operation can select an increment for a given event counter based on a logical combination of the result of applying a threshold and / or edge function to a first event status indicator and a value dependent on a second event status indicator indicating the status of the event assigned to a further event counter. This value dependent on the second event status indicator may itself depend on a threshold and / or edge function calculated by the further event counter based on the second event status indicator. This provides a flexible infrastructure for calculating a range of useful information about the co-occurrence of two events.

[0033] There may be different approaches to selecting which other counters are further event counters used to derive information for chain counter information in which a second event status indication is performed by a given event counter.

[0034] In some embodiments, the selection of which other event counter is a further event counter for a chain counter operation performed by a given event counter is fixed, independent of the counter configuration information. In this case, each event counter in the subset capable of performing a chain counter operation may be limited to using only one other counter as a further event counter. It may not be possible to change which other counter is the further event counter corresponding to a given event counter. For example, given a given set of counters assigned counter numbers within a range (e.g., 0 to X-1), one approach is to restrict that for any given event counter having counter number N, if a chain counter operation is performed by the given event counter, the further event counter used for the chain counter operation is, for example, the counter having counter number N-1. Other embodiments may take a different approach to define which counter is the further event counter corresponding to any given event counter. By restricting the combination of event counters so that each counter can only take a value that depends on a second event status indication from another counter, the number of inter-counter wiring connections required is reduced compared to implementations that allow for more flexible selection of which counters are further event counters, thus significantly reducing the hardware complexity of implementing chain counter operation for several counters. In practice, the user can choose which events to assign to each counter, and as a result, the event types that should be combined in a logical combination support being further event counters for the other event counter in a pair of counters, when one event counter in the pair is a given event counter that performs chain counter operation. Therefore, the restriction on the combination of event counters should not limit the options available to the user.

[0035] On the other hand, in other embodiments, the counter configuration information may support variably specifying which other event counters are further event counters for chain counter operations performed by a given event counter. This may increase flexibility in varying combinations of event types, but it may also increase hardware complexity.

[0036] In some embodiments, all event counters may be within a subset of event counters that support chain counter operation.

[0037] In other embodiments, chain counter operation may be supported only for a suitable subset of event counters, and there may be at least one event counter that does not support chain counter operation. For example, in an approach where a given event counter with counter number N is restricted to using a counter with event counter N-1 as a further event counter, event counter 0 may not support chain counter operation because there are no other counters with event counter N-1 (alternatively, counter 0 can use a counter with the highest counter number as a further event counter). In other embodiments, the subset of event counters that support chain counter operation may be further restricted, and there may be two or more event counters that do not support chain counter operation because they are outside the subset. In practice, since several counts of a single event type may also be desired, it is unlikely that all counters need to perform chain counter operation simultaneously, and therefore it may be useful to limit hardware costs by reducing the number of event counters in the subset that support chain counter operation.

[0038] The device may include the aforementioned performance monitoring circuit, as well as a processing circuit whose operation is monitored by the performance monitoring circuit.

[0039] A computer-readable medium may store computer-readable code for the fabrication of a performance monitoring circuit or the aforementioned device. As will be further described below, this can provide an electronic representation of the circuit design, which can then be disseminated to other parties (or yet another party further down the manufacturing chain) to fabricate the performance monitoring circuit or device.

[0040] The techniques discussed above may be implemented using the hardware circuits provided for implementing the event counter and control circuit discussed above.

[0041] However, the same technique may also be implemented within a computer program that runs on a host data processing unit to provide an instruction execution environment for the execution of target program code. Such a computer program may control the host data processing unit to simulate an architectural environment provided on a hardware device that actually supports the target code according to a particular instruction set architecture, even if the host data processing unit itself does not support that architecture. The computer program may have event counting program logic and control program logic that emulates the functions of the event counter and control circuit discussed above, including support for chain counter operation. Such simulation can enable software development of the target program code (e.g., debugging software targeting a device with the performance monitoring circuit discussed above) to begin before the hardware with the performance monitoring circuit is actually ready. By executing the target program code on the simulated execution environment, this can enable testing of the target code in parallel with the ongoing development of a hardware device that supports new features of the performance monitoring circuit. The simulation program may be stored in a storage medium, which may be a non-temporary storage medium.

[0042] Figure 1 schematically illustrates an example of a data processing device 2. The data processing device has a processing pipeline 4 (for example, one embodiment of a processing circuit that may form part of a CPU (Central Processing Unit)). The processing circuit 4 is for executing instructions defined in an instruction set architecture (ISA) in order to perform data processing operations represented by instructions. The processing pipeline 4 includes several pipeline stages. In this embodiment, the pipeline stages include a fetch stage 6 for fetching instructions from an instruction cache 8 (for example, the selection of which instructions to fetch may be controlled based on the prediction of branch results made by a branch predictor 7). The pipeline includes a decryption stage 10 for decrypting a fetched program instruction to generate a microoperation (decryption instruction) to be processed by the remaining stages of the pipeline; an issue stage 12 for issuing a microoperation for execution, which checks whether the operands required for the microoperation are available in the register file 14 and, if the operands required for a given microoperation are available; an execution stage 16 for performing data processing operations corresponding to the microoperation by processing the operands read from the register file 14 to generate result values; and a write-back stage 18 for writing the results of the processing back to the register file 14. This is merely one example of a possible pipeline architecture, and it will be understood that other systems may have additional stages or stages with different configurations. For example, an out-of-order processor may include a register rename stage for mapping architecture registers specified by a program instruction or microoperation to physical register specifiers that identify physical registers in the register file 14. In some embodiments, there may be a one-to-one relationship between a program instruction defined in the ISA decrypted by the decryption stage 10 and the corresponding microoperation processed by the execution stage.Furthermore, there can be a one-to-many or many-to-one relationship between program instructions and microoperations. For example, a single program instruction may be split into two or more microoperations, or two or more program instructions may be merged so that they are processed as a single microoperation.

[0043] Execution stage 16 includes several processing units for performing different classes of processing operations. For example, the execution units may include a scalar arithmetic / logic unit (ALU) 20 for performing arithmetic or logical operations on scalar operands read from register 14, a floating-point unit 22 for performing operations on floating-point values, a branch unit 24 for evaluating the results of branch operations and adjusting the program counter representing the current execution point accordingly, and a load / store unit 26 for performing load / store operations that access data in memory systems 8, 30, 32, and 34.

[0044] A memory management unit (MMU) 28 is provided to control memory access permission checks and perform address translation between a virtual address specified by the load / store unit 26 based on the operand of a data access instruction and a physical address that identifies the storage location of the data in the memory system. The MMU has a translation lookaside buffer (TLB) 29 for caching address translation data from a page table stored in the memory system, where page table entries define address translation mappings and may specify permissions that govern whether a given process running on the pipeline can read, write, or execute instructions from a given memory region. Although the MMU 28 is shown as being associated with the load / store unit 26, the MMU 28 may also be looked up during instruction fetches triggered by the fetch stage 6 (or a separate instruction-side MMU may be implemented to handle instruction fetches, separate from the data-side MMU used by the load / store unit 26 for data access, in which case both MMUs may cache information from a shared set of page tables in the TLB 29).

[0045] In this embodiment, the memory system includes a Level 1 data cache 30, a Level 1 instruction cache 8, a shared Level 2 cache 32, and main system memory 34. This is merely one example of a possible memory hierarchy, and it will be understood that other arrangements of caches are possible. The specific types of processing units 20-26 shown in execution stage 16 are merely one embodiment, and other implementations may have different sets of processing units or include multiple instances of the same type of processing unit to handle multiple microoperations of the same type in parallel. Figure 1 is merely a simplified representation of some components of a possible processor pipeline implementation, and it will be understood that the processor may include many other elements not illustrated for brevity.

[0046] Device 2 also has a performance monitoring circuit 40 for monitoring the performance of software running on the processing circuit 4. The performance monitoring circuit 40 is shown in more detail in Figure 2. As shown in Figure 2, the performance monitoring circuit 40 includes several event counters 42, each maintaining a corresponding event count value 43. The performance monitoring circuit also includes a control circuit 44 that configures how the event counters behave based on counter configuration information 46 set by the user. For example, the counter configuration information 46 may be state information stored in the processor's registers 14 (e.g., system registers), which may be stored in memory-mapped registers implemented as separate hardware from the memory systems 30, 32, or may be stored within the memory systems 30, 32, 34 themselves (if a data structure within a memory-mapped register or the memory itself is used to provide the counter configuration information, the control circuit 44 may access those registers / structures based on a user-programmable base address). Therefore, generally speaking, a programming interface is provided that allows a user (e.g., a software developer performing debugging) to program counter configuration information 46, and as a result, the event counter 42 can be configured to collect various types of target performance monitoring information when debugging a particular program running on the processing circuit 4. For example, debugging software may be executed to set the counter configuration information. The target program being debugged can then be executed. While the target program is running, the performance monitoring circuit 40 operates according to the pre-configured counter configuration information.

[0047] The performance monitoring circuit 40 includes an event selection circuit 48 that receives several event signals 45 indicating the status of corresponding types of events from the processing circuit 4 and other parts of the data processing system 2. Although shown as a single logic block in Figure 2, the event selection circuit may have a separate event selector for each event counter, which independently selects the event signals 45 to be monitored by the corresponding event counter.

[0048] For example, event signals may be generated to indicate a wide variety of types of information about various components of the data processing device 2.

[0049] Some event signals may indicate the occurrence of a specific action (or a count of how many times that action has occurred). For example, such an action might be: • Clock cycle elapsed, • Execution of instructions (any general instruction, or a specific type of instruction) • A memory access request (general, arbitrary memory access, or specific types of memory access such as load or store) is made. • Cache access, cache line fill, and cache miss may occur (in some cases, this may be specific to a particular level or type of cache). • TLB access, TLB line fill, or TLB miss may occur (these may also generally be events trackable for any TLB, or they may be specific to a particular TLB instance (e.g., data-side TLB or instruction-side TLB) or a particular TLB level (e.g., level 1 or level 2)). • Branch prediction errors may occur. - The queue or buffer becomes full (a variation of which can be provided to a specific buffer, such as an instruction issue queue, load buffer, or store buffer), or This may include any of the following pipeline stalls caused by specific reasons (e.g., cache misses, TLB misses, or full load or store buffers).

[0050] Other event signals are, • The number of page table walk operations (requests to fill the TLB with page table entries loaded from memory) currently in progress in a given cycle. The number of pending cache line fill requests (requests to put data back into the cache following a cache miss) in a given cycle, or It may specify quantitative information that provides quantitative status values ​​indicating the nature of an event that has occurred, such as an indication of the current occupancy rate of a particular instance of a queue or buffer located within the hardware.

[0051] The above list of event types is not exhaustive, and it should be understood that a wide variety of different event types can be monitored.

[0052] Furthermore, in some cases, the event type assigned to a given event counter 42 may be an overflow of another event counter 42, thereby extending the numerical range in which a particular event is counted beyond the numerical range supported by a single counter. In this case, the two counters are "chained" together in the sense that they effectively represent a larger counter that counts a single event type, but it should be noted that the resulting count value tracked by the second event type in the chain (which is incremented based on the overflow of the first event counter) is not a function of a logical combination of two different event types assigned by the counter configuration information, as in the embodiment considered below. The second counter is incremented based solely on the occurrence of the overflow of the first counter, and not on a logical combination of the overflow of the first counter and the status of the event signal that increments the first counter.

[0053] The counter configuration information 46 includes event type assignment information that specifies the event types monitored by each event counter 42. For example, each event counter 42 may have a corresponding event type field in the counter configuration information that has coding for selecting the event signal 45 to use for a particular event counter 42. For each event counter, the event selection circuit 48 selects one of the event signals 45 based on the event type assignment information of that counter, and that event signal 45 is passed to the corresponding event counter 42 as an event status indicator 47 representing the status of the event assigned to that event counter 42 by the counter configuration information 46.

[0054] For each event counter 42, a set of hardware circuit logic is provided, including a storage circuit for storing a corresponding event count value 43, and a (hardware-implemented) counter control logic circuit for updating the event count value as a function of an event status indicator 47 provided to the counter 42 by an event selection circuit 48. For example, the increment value may be selected as a function of the event status indicator 47, and the new value of the event counter value 43 may be calculated by adding the increment value to the previous value of the event counter value 43. Control signals 49 may be provided to each event counter 42 by the control circuit 44 based on counter configuration information 46. These control signals 49 may constitute how a given counter selects a function to be applied to the event status indicator 47, and how the increment value should be selected based on the result of applying the function to the event status indicator 47.

[0055] The performance monitoring circuit 40 provides an event counter read interface 50 that allows software to read the event count value of each counter 42. For example, the read interface 50 may be provided by exposing each event count value 43 to the software as a system register that can be read by a system register read instruction executed by the processing circuit 4. Alternatively, the event count value 43 of each event counter 42 may be exposed via a memory-mapped interface so that it can be read by software executing a load instruction that specifies a memory address mapped to a storage location that stores each event count value 43. In either case, debugging software can retrieve the current value of each event count value to determine what happened when the target software was being processed by the processing circuit. During use, for example, debugging software may use breakpoints or watchpoints to trigger an exception when the target software reaches a desired point that needs investigation (e.g., a desired instruction address reached in the program flow, or a desired data address accessed by a memory access instruction). When an exception is triggered, an exception handler provided by the debugging software can read the event count value 43 and analyze the information provided by each event count value 43 to determine what happened. This is useful for diagnosing potential performance inefficiencies in the program code and can help identify possible improvements that can be made to the program code being executed to enable it to run more efficiently.

[0056] Figure 3 shows a more detailed embodiment of the counter control logic circuit of a given event counter 42. The event counter 42 receives its event status indicator 47 (indicated as Vb), which is selected by the event selection circuit 48 based on event type assignment information in the counter configuration information 46. The event counter 42 includes a comparison circuit 52 that compares the event status indicator Vb with a threshold TH and generates a function result value fn[Vb,TH] based on whether the event status indicator and the threshold satisfy predetermined conditions. Both the threshold TH and the specific conditions tested by the comparison circuit 52 can be modified by a user who programs the counter configuration information 46. The increment selection circuit 54 selects from several candidate increment values ​​based on at least the function result value fn[Vb,TH]. Three or more candidate increment values ​​(for example, including 0, 1, and the event status indicator Vb itself) may be supported, and the counter configuration information 46 may include increment configuration information specifying which of those candidate increment values ​​are two candidate increment values ​​from which the increment is selected based on the function result value fn[Vb,TH]. The selected increment value V is used to increment the corresponding event count value 43.

[0057] The function used to calculate fn[Vb,TH] can be implemented in several different ways. In one embodiment, the counter configuration information 46, for a given counter, • Threshold TH, • Function selection information specifying the comparison function to be applied to the event status indicator Vb and threshold (for example, selecting from a set of alternative functions such as "Vb and TH are not equal", "Vb is equal to TH", "Vb is greater than or equal to TH", and "Vb is less than TH"), and • Increment configuration information can be specified to control the selection of the increment.

[0058] In one embodiment, if the function evaluated by the comparison circuit 52 is not satisfied, an increment value of 0 may be selected by default. However, if the function is satisfied by Vb and TH, an increment value of 1 or Vb itself may be selected, and the increment configuration information may specify which of the alternative increment values, 1 and Vb, should be selected if the function is satisfied. As described below, for counters that support chain counter operation, a value that depends on an event status indicator tracked by another counter may also be provided as one of the candidate increment values ​​available for selection by the increment selection circuit 54.

[0059] In another embodiment (supporting both threshold comparison functions and edge functions), the function result may depend not only on whether the threshold comparison function is satisfied in the current cycle, but also on whether it was satisfied in the preceding cycle. Thus, an edge function may be applied to give an edge function result value indicating whether there has been a change between the previous cycle and the current cycle in whether the first event status indicator satisfies a predetermined condition. That predetermined condition may be the threshold condition mentioned for the threshold function above. Thus, the edge function result may be the result of calculating whether th-fn[Vb_t,TH] and th-fn[Vb_t-1,TH] satisfy the edge condition, where th-fn is the threshold function described above, and Vb_t and Vb_t-1 represent the values ​​of the event status indicator Vb in the current cycle and the preceding cycle, respectively. An edge condition may be satisfied if there is a change in value between th_fn[Vb_t,TH] and th_fn[Vb_t-1,TH], but may not be satisfied if th_fn[Vb_t,TH] = th_fn[Vb_t-1,TH]. In some cases, an edge condition may be specific to either a rising edge (e.g., th-fn[Vb_t-1,TH] = false and th-fn[Vb_t,TH] = true) or a falling edge (th-fn[Vb_t-1,TH] = true and th-fn[Vb_t,TH] = false), and may be satisfied for only one of the changes in the rising or falling edges in the result of the threshold function. In other cases, an edge condition may be considered satisfied for both the rising and falling edges. Part of the counter configuration information 46 may specify a particular edge condition to be satisfied.

[0060] In other embodiments, instead of applying the edge condition to the previous / current value of the function result fn[Vb,TH], the edge condition can be applied directly to the event status indicator Vb, rather than to the comparison function result fn[Vb,TH], and as a result, the increment V in the current cycle is selected based on the result of edge -fn[Vb_t-1,Vb_t], independently of any comparison with the threshold TH. This can be used in implementations that do not support threshold-based comparisons at all, or in implementations that support threshold functions but provide configuration options for applying only edge functions without relying on threshold comparisons. However, in practice, if threshold functions are supported and it is desirable to support applying the edge function directly to Vb, this can be implemented by applying the threshold function fn[Vb,TH] anyway, but setting TH=0 and the threshold comparison function to "Vb and TH are not equal", and then applying the edge condition to the change in status in the function result between one cycle and another. Thus, it may not be necessary to support specific control settings that avoid performing a threshold comparison with TH.

[0061] Regardless of the specific form of edge function used, using an edge function can be useful for some types of events, as it can provide more useful diagnostic information if the event count value tracks the different number of times a given event signal has changed whether a condition is met, rather than counting each cycle when the condition is met. For example, this could be used to count the different number of times a pipeline stalled.

[0062] Therefore, it should be understood that there are various ways to compute the function result as a function of the event status indicator Vb, and which particular function computation option is supported may depend on the implementation style chosen by the system designer.

[0063] In many cases, it may be sufficient to apply the aforementioned threshold / edge function to an event status indicator representing a single event type in order to provide useful performance monitoring information.

[0064] However, the performance effects encountered when running software may depend not only on the occurrence of one type of event, but also on the interaction between two or more types of events. For example, it may be desirable to examine the interaction between pending loads in a load buffer and cache misses occurring in a given cache, and therefore it may be useful to count the number of cache misses when the number of pending loads also satisfies certain conditions. In this case, it may be useful to increment a counter by a threshold that depends on a Boolean AND of the function result indicating that "a cache miss occurred" and "the number of pending loads is greater than the threshold."

[0065] Furthermore, in some cases, there may be two different types of events, each causing a delay in software processing, and the total performance cost may correspond to the number of cycles in which either of these two types of events occurs. If two different event counters are set up separately to count the number of cycles in which each type of event occurs individually, the sum of these counts may overestimate the performance cost of those events, since cycles in which both events occur simultaneously may be counted twice. Therefore, in some use cases, it may be more useful to increment the counters based on a Boolean OR of function results that represent a function for the first event type and a function for the second event type, respectively.

[0066] Therefore, it may be desirable to adapt the counter increment logic so that it can support incrementing a given counter based on a logical combination of the statuses of two different types of events represented by different event signals 45.

[0067] One approach would be to extend each counter 42 so that it can take event status indicators 47 corresponding to two or more of the event signals 45 from the processing circuit as input. However, allowing each event counter 42 to select two or more different event signals can significantly increase the complexity of the event selection circuit 48 (if there are many types of event signals supported in a given processor implementation, complex multiplexing logic tends to be required even to select a single event signal for each event counter). In practice, this is not necessary to allow one of the event count values ​​43 to be incremented by only an increment value selected as two or more logical combinations of event types.

[0068] Figure 4 shows, for comparison, another possible approach with three different event counters 42, each having a comparison circuit 52 and an increment selection circuit 54 similar to those shown in Figure 3. Note that the event selection circuit 48, shown as a single block in Figure 2, can also be implemented as a number of different multiplexers 48, each associated with a corresponding counter 42, as shown in Figure 4. In the embodiment of Figure 4, counters 1 and 2 function as shown in Figure 3, incrementing their respective count values ​​43(1) and 43(2) by increment values ​​V(1) and V(2), respectively, calculated as functions of the corresponding event status indicators Vb1 and Vb2 and the corresponding thresholds TH(1), TH(2), and TH(3). The third counter is provided with the increment values ​​V(1) and V(2) of counters 1 and 2, and its comparison circuit 52(3) is provided with additional circuitry capable of calculating the logic functions of V(1) and V(2) (for example, the functions may be AND, OR, minimum, maximum, etc.). The increment selection circuit 54(3) of the third counter then selects an increment value V(3) for incrementing the count value 43(3) of the third counter, and the increment value V(3) is selected based on the logic functions of V(1) and V(2) calculated by the comparison circuit 52(3) of the third counter. Thus, the event type assigned to the third counter can be considered as the event corresponding to the logic functions (for example, AND) of event types (1) and (2) assigned to counters 1 and 2. In this case, the third counter cannot be considered to increment itself based on the logical combination of event statuses of each type of event assigned to itself and other counters by the counter configuration information. Rather, counter 3 is considered to count the logical combination of event types assigned to the two other counters (not itself), or to count its own event type, but note that its event type (e.g., an AND result) is not logically combined with the event types of further counters.The drawback of the approach shown in Figure 4 is that it requires the use of three separate counters to generate an event count value that is incremented based on a logical combination of status indicators corresponding to two different event types, which in some implementations could represent a significant portion of the total number of event counters supported by the hardware. Furthermore, this approach requires more complex wiring when transferring signals from the two other counters to the third counter. Additionally, the V(1) and V(2) values ​​are inputs to the comparator circuit 52(3), meaning that the result of this selector cannot be calculated until the results of the previous two selectors have been calculated, which can complicate circuit timing and necessitate additional logic.

[0069] In contrast, the embodiments shown in Figures 5, 6, and 7 implement a chain counter operation in which a given event counter 42 increments its event count value 43 based on a logical combination of event status indicators corresponding to the event type assigned to the given event counter itself and one other event counter. This can be more efficient as it reduces the amount of wiring between counters and avoids the need to occupy three separate counters to track the combination of the first and second events. If the user determines that it is not necessary to count each of the first and second events separately, only two counters are occupied (one to count the second event and the other to count the logical combination of the first and second events), and the third counter shown in Figure 4 can be freed up for use when monitoring unrelated events separate from the first / second events. Thus, counter utilization can be improved and hardware complexity can be reduced.

[0070] For example, as shown in Figure 5, a given event counter 42(N) is assigned as a counter that increments its event count signal 43(N) based on a logical combination of event types assigned to be monitored by the given event counter 42(N) itself and further event counters 42(N-1). The increment of the event count value 43(N-1) of the further event counter is performed in the same manner as considered for Figure 3, based on the event status indicator Vb(N-1) selected by the event selection circuit 48 of that counter based on the counter configuration information 46, for example, by applying a threshold and / or edge function using a comparison circuit 52(N-1). However, the value dependent on the event status indicator Vb(N-1) is provided to the given event counter 42(N) by the further event counters 42(N-1) for use in chain counter operation. In this embodiment, the value provided to a given event counter 42(N) is an increment value V(N-1) selected by an increment selection circuit 54(N-1) of a further event counter 42(N-1).

[0071] A comparison circuit 52(N) of a given event counter 42(N) generates a function result fn(N) based on its event status indicator Vb(N) and threshold TH(N) in the same manner as described above for Figure 3. Both the function fn(N) applied by the comparison circuit 52(N) and the threshold TH(N) of the counter 42(N) can be set by counter configuration information 46, independently of the selection of the corresponding function fn(N-1) and threshold TH(N-1) used for counter 42(N-1). Thus, the two counters may apply different functions and / or use different thresholds. In the embodiment of Figure 5, the function result fn(N)[Vb(N),TH(N)] generated by the comparison circuit 52(N) depends on a first event status signal Vb(N) corresponding to an event type assigned to be monitored by counter 42(N), but is independent of a second event status signal Vb(N-1) corresponding to an event type assigned to be monitored by counter 42(N-1). In this embodiment, the function applied is the threshold function discussed above, and therefore the function result is fn(N)[Vb(N),TH(N)]. However, it will be understood that edge functions or other functions can also be applied to the first event status indicator Vb(N).

[0072] The value V(N-1) from counter 42(N-1) is provided to the increment selection circuit 54(N) as an additional candidate increment value available for selection as V(N), and the event count value 43(N) of counter 42(N) is incremented by that value. Thus, V(N) can be selected from the set {0,1,Vb(N),V(N-1)} based on the increment configuration information defined by the counter configuration information 46 for counter 42(N) and the function result fn(N) calculated by the comparison circuit 52(N) for counter 42(N).

[0073] For example, one approach is to provide encoding for counter configuration information so that the following increment control settings are applied to specific event counters 42(i) that support chain counter operation.

[0074] [Table 1] Here, Vb(i) is the event status indicator 47 selected by the event selection circuit 48 for counter 42(i), and V(i-1) is the increment value selected by the increment selection circuit 54(N-1) associated with counter 42(i-1) based on Vb(i-1), which is the event status indicator 47 selected for counter 42(i-1).

[0075] It will be understood that not all of the above settings must be supported in a given implementation. Some implementations may support additional settings (for example, settings that reverse the selection so that an increment shown as selected for a "true" function result is instead selected for a "false" function result, and vice versa). In the embodiment of Figure 5, at least counter 42(N) implements at least one of settings C, D, and E. Counter 42(N-1) in Figure 5 does not need to implement any of settings C, D, or E, but can, if desired, allow for a chain of three or more counters.

[0076] By providing counter 42(N) with at least one setting (e.g., C, D, or E), V(N-1) can be selected as an increment applied to the event current value 43(N) of counter 42(N), which can support logical combinations between first and second event types, such as Boolean AND or join. Thus, settings C, D, and E of counter 42(N) correspond to settings of counter configuration information that cause counter 42(N) to perform chain counter operation, while settings A and B correspond to non-chain counter operation, in which case the increment selected by counter 42(N) is independent of Vb(N-1).

[0077] For example, if the first event status indicator Vb(N) and the second event status indicator Vb(N-1) are both positive multi-bit integers, the AND / OR combination of the first and second event types can be simulated using threshold functions for counters 42(N) and 42(N-1) as follows:

[0078] AND(Test whether both Vb(N) and Vb(N-1) are non-zero) The settings for counter 42(N-1) are as follows: • Threshold function: Vb(N-1)!=0 or Vb(N-1)>=1, • Increment control setting - Setting A. (This is an identity function whose output is reduced to either 0 or 1.)

[0079] The settings for counter 42(N) are as follows: • Threshold function: Vb(N) == 0 or Vb(N) < 1, • Increment control setting - setting C or E.

[0080] As a result, V(N) takes the following values:

[0081] [Table 2] Therefore, it can be seen that V(N) is equivalent to the logical AND of Vb(N-1) and Vb(N).

[0082] OR (Tests whether either Vb(N) or Vb(N-1) is non-zero) The settings for counter 42(N-1) are as follows: • Threshold function: Vb(N-1)!=0 or Vb(N-1)>=1, • Increment control setting - Setting A.

[0083] The settings for counter 42(N) are as follows: • Threshold function: Vb(N) != 0 or Vb(N) >= 1, • Increment control setting - Setting E (when it is desired that the result of Vb(N) be equal to Vb(N) when the OR result is satisfied) or Setting D (when the result of Vb(N) is 0 or 1).

[0084] Assuming that D is set for counter 42(N), then V(N) will take the following values.

[0085] [Table 3] Therefore, it can be seen that V(N) corresponds to the logical OR of Vb(N-1) and Vb(N).

[0086] Other functions include NAND (inverted AND result) and AND NOT (AND of the inverted version of one input value and the inverted version of the other input value). NOR (inverted OR result) and OR NOT (OR of the inverted version of one input value and the inverted version of the other input value) can be constructed in a similar manner.

[0087] Therefore, with a relatively simple modification to the counter logic (extending the increment selection multiplexer to take an additional input corresponding to V(N-1) from a further counter), a counter increment can be generated using only two counters that need to be occupied, using a logical combination between two event types and hardware circuitry that is far less complex than that shown in Figure 4.

[0088] This could be useful, for example, to count each occurrence of a second event when the first event exceeds (or falls below) a threshold. The first event assigned to counter 42(N-1) could be the occurrence of an event of interest, such as a cache miss. The second event assigned to counter 42(N) could be the number of unprocessed loads in each cycle.

[0089] Therefore, chain counter operation can be used to count the occurrence of cache misses within a cycle by configuring the following when the number of unprocessed loads is greater than or equal to a threshold TH(N): The counter 42(N-1) does not perform a threshold test, for example, by directly calculating fn(N-1) from Vb(N-1), or by applying a threshold function but using a threshold of 0 TH(N-1) and a comparison function Vb(N-1)>=TH(N-1). Counter 42(N) uses a threshold test Vb(N)>=TH(N) to control the setting C of the increment control logic.

[0090] This is just one example, and many other examples can be implemented to investigate the co-occurrence of specific event pairs. In Figure 5, the selected increment V(N) may depend on the value V(N-1) being calculated, but V(N-1) can enter the logic for calculating V(N) much later than in Figure 4, which is better timing as it means the function comparison of 52(N) does not need to wait for V(N-1) to be calculated. In terms of timing, the multiplexer 54 has much shallower logic than the selector 52, especially since the selector can compare magnitudes (an adder may be used to subtract one of the comparison inputs from the other, and an adder may require deeper circuit logic than a multiplexer). Therefore, there may be performance advantages in avoiding V(N-1) being an input to the comparator circuit 52(N).

[0091] Furthermore, while Figure 5 shows an embodiment in which two counters are chained together to provide a logical combination of a first event and a second event, if counter 42(N-1) itself also performs chain counter operation and can therefore receive a value V(N-2) obtained by another counter as input based on its event status indicator Vb(N-2), this can enable the combination of three or more different event types and their AND or base logical combinations to be used to select the increment of counter 42(N). Thus, although chain count operation is shown for two counters, it is also possible that the increment value V(N-1) selected by counter 42(N-1) itself depends on the event status indicator Vb(N-2) of another counter 42(N-2), as well as the event status indicators Vb(N) and Vb(N-1) shown in Figure 5.

[0092] Figure 6 shows an alternative approach to implementing chain counter operation (for example, to perform the same behavior as for counting co-occurring events such as unprocessed loads and cache misses as described above for Figure 5). In this embodiment, the calculation of the comparison function results fn(N-1) and fn(N) for counters 42(N-1) and 42(N) is the same as in Figure 5. However, instead of providing the increment value V(N-1) selected by counter 42(N-1) to the increment selection multiplexer 54(N) as an additional input to the increment selection multiplexer 54(N), a second event status indicator Vb(N-1) selected by the event selection circuit 48 for event counter 42(N-1) is provided as a candidate increment value available for selection by the increment selection multiplexer 54(N) within event counter 42(N). Furthermore, the function result fn(N-1) from the comparator circuit 52(N-1) in the counter 42(N) is provided as an additional control input to the increment selection circuit 54(N) in the event counter 42(N). As a result, the increment value V(N) for incrementing the count value 43(N) is selected from the set {0,1,Vb(N),Vb(N-1)} based on the increment control setting of the counter 42(N) (in some embodiments, the increment control setting of the counter 42(N-1) may also be considered), the function result fn(N) calculated by the comparator circuit 52(N) based on Vb(N), and the increment configuration information that defines the function result fn(N-1) calculated by the comparator circuit 52(N-1) based on Vb(N-1). This approach eliminates one multiplexer from the path between Vb(N-1) and the increment selector multiplexer 54(N) for the event counter 42(N), and therefore may help improve circuit timing in some implementations. Thus, in this case, the values ​​dependent on Vb(N-1) considered by the counter 42(N) could be Vb(N-1) itself, used as a candidate increment value for selection by the increment selector 54(N), and the function result fn(N-1), used as a control input for the increment selector 54(N).

[0093] Figure 7 shows another alternative example. In this case, as in Figure 5, the increment value V(N-1) selected by the counter 42(N-1) based on Vb(N-1) is provided as a candidate increment available for selection by the increment selector 54(N) in the counter 42(N). However, in Figure 7, the function result fn(N) used by the increment selector 54(N) to select between candidate increments {0, 1, V(N-1), Vb(N)} depends not only on Vb(N) but also on V(N-1). For example, the selector 52(N) can take three inputs Vb(N), V(N-1), and TH(N), and the configuration information may specify which of the three inputs should be compared according to the comparison function. The result of that function can then be used to control which increment value is selected as V(N) by the increment selector 54(N). This approach allows for a direct comparison of the first / second event status indicators of counters 42(N) and 42(N-1), and therefore may be more flexible in supporting additional logical combinations of first / second event status indicators (e.g., maximum and minimum) that are not supported in implementations where the second event status of counter 42(N-1) affects the increment selection but not the event comparison function of counter 42(N), as shown in Figures 5 and 6.

[0094] Note that, compared to Figure 4, Figures 5, 6, and 7 differ in that counter 42(N) counts logical combinations of events programmed for counter 42(N) to count and events programmed for another counter 42(N-1) to count (it counts logical combinations of events assigned to the other two counters, rather than itself). Also, in the approaches shown in Figures 5 and 6, there is no need to directly compare the event status indicators Vb(N) and Vb(N-1); instead, each is compared to a fixed threshold TH(N) or TH(N-1), which is then used to select which of the increment values ​​(including a value derived from event counter 42(N-1)) to use to increment the count value 43(N) of event counter 42(N).

[0095] Figures 5 to 7 show an embodiment in which, for a given counter supporting chain counter operation, the selection of which counter is the further event counter is fixed in hardware and restricted to the counter having the next lowest counter number N-1 after the counter number N of the given counter itself. However, other embodiments may be more flexible in changing which counter is the further event counter based on counter configuration information 46.

[0096] As shown in Figures 5 to 7, it is not mandatory for all event counters 42 to support chain counter operation. In some cases, the ability to support chain counter operation may be limited to a subset of counters 42, and other counters may behave as shown in Figure 3, without considering any information about the status of event types assigned to be monitored by other event counters.

[0097] It will also be understood that a counter that supports chain counter operation can be configured to perform non-chain counter operation (for example, by selecting one of the control settings A and B described above, which does not select an increment value V(N) based on a value that depends on a second event status indicator Vb(N-1) of another counter).

[0098] Figure 8 is a flowchart illustrating a method of performance monitoring using event counters. In step 100, the event counter is configured by the user setting counter configuration information 46. The counter configuration information includes event assignment information indicating the type of events assigned to be monitored by the given counter, and may include function configuration information and increment configuration information for configuring a function applied by the comparator circuit 52 for the given counter (e.g., specifying whether a threshold / edge function is applied, specifying specific comparison conditions applied by the threshold / edge function, and / or specifying the threshold TH of the threshold function) (e.g., information for selecting one of the settings A to E discussed above). The counter configuration information defines rules for selecting between candidate increment values, depending on the result of the function calculated by the comparator circuit 52 for the given counter. This information may be defined separately for each event counter 42.

[0099] In step 102, the software is executed on the processing circuit 4. Meanwhile, the event counters 42 maintain their respective event count values ​​43 based on monitoring of their configured event types. Since the event counters 42 operate in hardware in the background of the software processing, there is no need to execute specific software instructions to update each event count value 43.

[0100] In step 104, the event count value 43 from the event counter 42 is read via the read interface 50. For example, this may occur when the software executed in step 102 encounters a breakpoint (when the program flow reaches a specific program counter address or when a breakpoint instruction is executed) or a watchpoint (when data access is made to a specific data address), which may trigger an exception that causes debugging software to run, read the event counter, and then analyze the count value.

[0101] Figure 9 is a flowchart illustrating how to perform performance monitoring in an implementation that supports chain counter operation. In step 110, the control circuit 44 determines whether the counter configuration information 46 is configured to specify that a given event counter 42(N) should perform chain counter operation. If not, in step 112, the given event counter 42(N) maintains its given event count value 43(N) based on non-chain counter operation, for example, using the approach considered with respect to Figure 3.

[0102] If a given event counter 42(N) is configured to perform chain counter operation, then in step 114, the counter 42(N) increments the given event count value by an increment value determined based on a logical combination of a first event status indicator Vb(N) and a second event status indicator Vb(N-1). The first event status indicator Vb(N) indicates the status of a first event type assigned by counter configuration information 46 monitored by the given event counter 42(N) itself, and the second event status indicator Vb(N-1) indicates the status of a second event type assigned by counter configuration information 46 monitored by further event counters 42(N-1).

[0103] Figure 10 is a flowchart illustrating the chain counter operation in more detail. In step 120, a given event counter 42(N) configured to perform the chain counter operation determines a first event status function result value fn(N) as a function of at least a first event status indicator Vb(N). The first event status function result value fn(N) may depend on some of the counter configuration information 46 and / or other information such as information derived from further counters 42(N-1), such as an increment value V(N-1) selected by counter 42(N-1) in the embodiment of Figure 7.

[0104] In step 122, a given event counter 42(N) selects an increment value V(N) from a group of candidate increment values, depending on (at least) a first event status function result value fn(N). The candidate increment value includes a value that depends on a second event status indicator (e.g., an increment V(N-1) selected by a further event counter 42(N-1), or a second event status indicator Vb(N-1)) and at least one further increment value (e.g., 0, 1, and / or the first event status indicator Vb(N)). The increment selection in a given event counter 42(N) may also depend on increment configuration information that, depending on the first event status function result value fn(N), can specify which setting should be used to select among the candidate increment values. As shown in Figure 6, the increment selection may also depend on information from further event counters 42(N-1), such as the function result fn(N-1) calculated by counter 42(N-1) based on a second event status indicator Vb(N-1).

[0105] In step 124, the given event counter 42(N) increments the given event count value 43(N) based on the increment value V(N) selected in step 122.

[0106] The concepts described herein may be embodied in computer-readable code for the fabrication of devices that embody the described concepts. For example, computer-readable code may be used in one or more stages of a semiconductor design and fabrication process, including an electronic design automation (EDA) stage, to fabricate an integrated circuit comprising a device that embodies the concepts. The computer-readable code described herein may additionally or alternatively enable the definition, modeling, simulation, verification, and / or testing of devices that embody the concepts described herein.

[0107] For example, computer-readable code for fabricating a device embodying a concept described herein may be embodyed by code that defines a Hardware Description Language (HDL) representation of the concept. For example, the code may define a Register-Transfer-Level (RTL) abstraction of one or more logic circuits for defining a device embodying the concept. The code may define the HDL representation of one or more logic circuits embodying the device in Verilog, SystemVerilog, Chisel, or an intermediate representation such as Very High-Speed ​​Integrated Circuit Hardware Description Language (VHDL) and FIRRTL. The computer-readable code may provide a definition that embodies the concept using a system-level modeling language such as SystemC and SystemVerilog, or other behavioral representations of the concept that can be interpreted by a computer to enable simulation, functional and / or formal verification, and testing of the concept.

[0108] Additionally or alternatively, computer-readable code may define low-level descriptions of integrated circuit components that embody the concepts described herein, such as one or more netlists or integrated circuit layout definitions, including representations such as GDSII. One or more netlists or other computer-readable representations of integrated circuit components may be generated by applying one or more logic synthesis processes to the RTL representations to generate definitions used for fabricating devices that embody the invention. Alternatively or additionally, one or more logic synthesis processes may generate bitstreams from computer-readable code that are loaded into a Field Programmable Gate Array (FPGA) to configure the FPGA to embody the concepts described herein. The FPGA may be deployed for the purpose of verifying and testing the concept before fabrication in an integrated circuit, or the FPGA may be deployed directly into a product.

[0109] Computer-readable code may include a mixture of code representations for the fabrication of a device, for example, a mixture of one or more RTL representations, netlist representations, or other computer-readable definitions used in semiconductor design and fabrication processes for fabricating a device embodying the present invention. Alternatively or additionally, the concept may be defined as a combination of computer-readable definitions used in semiconductor design and fabrication processes for fabricating a device and computer-readable code that defines instructions to be executed by the device once it is fabricated.

[0110] Such computer-readable code may be placed on any known temporary computer-readable medium (such as wired or wireless transmission of code over a network) or on a non-temporary computer-readable medium such as a semiconductor, magnetic disk, or optical disk. An integrated circuit fabricated using computer-readable code may include components such as a central processing unit, a graphics processing unit, a neural processing unit, a digital signal processor, or one or more other components that individually or collectively embody a concept.

[0111] Figure 11 illustrates possible implementations of a simulator. While the above embodiments implement the present invention in terms of devices and methods for operating specific hardware that supports the technique, it is also possible to provide an instruction execution environment according to the embodiments described herein, which are implemented using a computer program. Such a computer program is often referred to as a simulator, insofar as it provides a software-based implementation of a hardware architecture. Various simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, a simulator implementation may run on a host processor 230, optionally running a host operating system 220 and supporting a simulator program 210. In some configurations, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or multiple different instruction execution environments may be provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations that run at reasonable speeds, but such an approach may be justified in certain circumstances, such as when it is desirable to run native code on a different processor for reasons of compatibility or reuse. For example, a simulator implementation may provide an instruction execution environment with additional functionality not supported by the host processor hardware, or it may provide an instruction execution environment typically associated with a different hardware architecture. An overview of the simulation is provided in "Some Efficient Architecture Simulation Techniques," Robert Bedichek, 1990 Winter USENIX Conference, pp. 53-63.

[0112] While embodiments have been described so far with reference to specific hardware components or features, in simulated embodiments, equivalent functionality may be provided by suitable software components or features. For example, certain circuits may be implemented as computer program logic in simulated embodiments. Similarly, memory hardware such as registers or caches may be implemented as software data structures in simulated embodiments. In arrangements where one or more of the hardware elements referenced in the embodiments described above reside on host hardware (e.g., host processor 230), some simulated embodiments may, if preferred, utilize the host hardware.

[0113] The simulator program 210 may be stored in a computer-readable storage medium (which may be a non-temporary medium) and provides a program interface (instruction execution environment) to the target program code 200 (which may include applications, operating systems, and hypervisors), which is the same as the interface of the hardware architecture modeled by the simulator program 210. Therefore, program instructions of the target code 200, including instructions for setting counter configuration information 46 and instructions for reading event count values ​​43, may be executed from within the instruction execution environment using the simulator program 210, thereby enabling a host computer 230, which does not actually possess the hardware features of the device 2 discussed above, to emulate these features. The functions of the performance monitoring circuit 40 can be emulated by the corresponding program logic. By providing a simulation of the device shown in Figure 1 in software form, it is possible to develop debugging software to interact with the performance monitoring circuit 40 before the hardware is actually available.

[0114] Therefore, the simulator program 210 may have a processing program logic 212 that simulates the state of the processing circuit 4 described above. For example, the processing program logic 212 may control transitions in the execution state (e.g., exception level, operating mode) in response to events occurring during the simulated execution of the target code 200. The instruction decoding program logic 214 decodes the instructions of the target code 200 and maps them to the corresponding instruction set in the native instruction set of the host device 230. The register emulation program logic 213 maps the register access requested by the target code to access the corresponding register emulation data structure 233 maintained by the host hardware of the host device 230, such as by accessing the registers of the host device 230 or data in memory 232. The memory management program logic 215 performs address translation, page table walk, and access control checks in a manner corresponding to the MMU 28 described in the hardware implementation embodiment above, but also has the additional function of mapping the simulated physical address obtained by the simulated MMU 28 to the host virtual address used to access the host memory 232. These host virtual addresses can themselves be translated to host physical addresses using the standard address translation mechanism supported by the host (the translation of host virtual addresses to host physical addresses is outside the scope of what is controlled by the simulator program 210). Thus, the simulated physical address space accessed by the target code 200 can be mapped to region 234 of host memory 232, which represents the simulated target memories 30, 32, and 34 of the target processing unit 2 simulated by the simulation program 210.

[0115] The simulator program 210 includes a performance monitoring program logic 216 that simulates the behavior of the performance monitoring circuit 40, and includes an event counter program logic 217 that increments the event count value 235 maintained in the host memory 232 based on the event increment function described above for the event counter 42 in the hardware embodiment. The performance monitoring program logic 216 also includes a control program logic 218 that accesses counter configuration information 236 specified in the host memory 232 and adapts how the event count program logic 217 increments the event counter value 235 depending on the counter configuration information 236. The performance monitoring program logic 216 may support chain counter operation in a similar manner to that described above for the hardware event counter.

[0116] In this application, the phrase "configured to..." is used to mean that an element of the device has a configuration that enables it to perform a defined operation. In this context, "configuration" means the arrangement or interconnection of hardware or software. For example, the device may have dedicated hardware to provide the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured to" does not mean that an element of the device must be modified in any way to provide the defined operation.

[0117] In this application, the enumeration of features preceded by the phrase "at least one of ~" means that any one or more of those features can be provided individually or in combination. For example, "[A], [B], and [C]" () includes any of the following options: A alone (without B or C), B alone (without A or C), C alone (without A or B), a combination of A and B (without C), a combination of A and C (without B), a combination of B and C (without A), or a combination of A, B, and C.

[0118] While illustrative embodiments of the present invention are described in detail herein with reference to the accompanying drawings, it will be understood that the present invention is not limited to those exact embodiments, and that various changes and modifications can be made to the embodiments without departing from the scope of the present invention as defined by the appended claims.

Claims

1. A performance monitoring circuit for monitoring the performance of software running on a processing circuit, Based on the monitoring of events during the processing of the software by the processing circuit, a plurality of event counters each maintain their respective event count values, The system comprises a control circuit that configures the event counter based on counter configuration information, wherein the counter configuration information includes event type assignment information indicating which types of events are assigned to be monitored by the event counter, For at least a subset of the event counters, a given event counter within the subset is configured to support chain counter operation for at least one setting of the counter configuration information, and the given event counter is configured to maintain a given event count value. A performance monitoring circuit in which the chain counter operation includes incrementing the given event count value by an increment value determined based on a logical combination of a first event status indicator indicating the status of a first event type assigned by the counter configuration information to be monitored by the given event counter, and a second event status indicator indicating the status of a second event type assigned by the counter configuration information to be monitored by a further event counter.

2. The performance monitoring circuit according to claim 1, wherein the counter configuration information includes information for specifying which logical combination should be used to combine the first event status instruction and the second event status instruction.

3. The chain counter operation described above is At least as a function of the first event status indicator, the first event function result value of the given event counter is determined, This includes, at least depending on the result value of the first event function, selecting one of a plurality of candidate increment values ​​as the increment value for incrementing the given event count value based on selection control information, The performance monitoring circuit according to claim 1 or 2, wherein at least one of the first event function result value, the selection control information, and the candidate increment value depends on a value that depends on the second event status instruction.

4. The performance monitoring circuit according to claim 3, wherein at least one of the selection control information and the candidate increment value depends on the value that depends on the second event status instruction.

5. The performance monitoring circuit according to claim 3 or 4, wherein the plurality of candidate increment values ​​include the value that depends on the second event status instruction and at least one further increment value.

6. The at least one further increment value is ０、 1, and The performance monitoring circuit according to claim 5, comprising at least one of the first event status indicators.

7. The performance monitoring circuit according to claim 3 or 4, wherein the selection control information depends on the value that depends on the second event status instruction.

8. The performance monitoring circuit according to claim 3, wherein the result value of the first event function depends on the value that depends on the second event status instruction.

9. The performance monitoring circuit according to any one of claims 3 to 8, wherein the selection of the increment value also depends on the counter configuration information of the given event counter.

10. The value that depends on the second event status instruction is, The second event status indication mentioned above, At least as a function of the second event status indicator, the second event function result value determined for the further event counter, and A performance monitoring circuit according to any one of claims 3 to 9, comprising one of a second increment value selected to increment the further event counter based on at least the second event function result value.

11. The performance monitoring circuit according to any one of claims 3 to 10, wherein, for at least one setting of the counter configuration information, the first event function result value includes a threshold function result value indicating whether the first event status indication and threshold satisfy the threshold condition.

12. The performance monitoring circuit according to claim 11, wherein the threshold is specified by the counter configuration information.

13. The performance monitoring circuit according to any one of claims 3 to 11, wherein, for at least one setting of the counter configuration information, the first event function result value includes an edge function result value indicating whether there has been a change between the previous cycle and the current cycle in whether the first event status indication satisfies a predetermined condition.

14. The performance monitoring circuit according to any one of claims 1 to 13, wherein, with respect to the chain counter operation performed by the given event counter, the selection of which other event counter is the further event counter is fixed independently of the counter configuration information.

15. The performance monitoring circuit according to any one of claims 1 to 13, wherein the counter configuration information variably specifies which other event counters are the further event counters for the chain counter operation performed by the given event counter.

16. It is a device, A performance monitoring circuit according to any one of claims 1 to 15, A device comprising a processing circuit.

17. A computer-readable medium for storing computer-readable code, for manufacturing a performance monitoring circuit according to any one of claims 1 to 15 or an apparatus according to claim 16.

18. A method for monitoring the performance of software running on a processing circuit, wherein the method is Multiple event counters are configured based on counter configuration information that includes event type assignment information indicating which types of events are assigned to be monitored by the event counters. Using the aforementioned multiple event counters, the system maintains the respective event count values ​​based on monitoring of events during processing by the processing circuit of the software. The process includes performing a chain counter operation for at least one setting of the counter configuration information for a given event counter within at least a subset of the event counters, wherein the given event counter maintains a given event count value. A method wherein the chain counter operation includes incrementing the given event count value by an increment value determined based on a logical combination of a first event status indicator indicating the status of a first event type assigned by counter configuration information to be monitored by the given event counter, and a second event status indicator indicating the status of a second event type assigned by counter configuration information to be monitored by a further event counter.

19. A computer program that, when executed by a host data processing device, includes instructions for controlling the host data processing device to provide an instruction execution environment for executing target program code, wherein the computer program Based on monitoring of events during the simulated processing of the target program code by the target processing circuit, an event count program logic maintains multiple event count values, The system comprises: control program logic that constitutes the event count program logic based on counter configuration information, wherein the counter configuration information includes event type assignment information indicating which types of events are assigned to be monitored by the event count program logic using the plurality of event count values; For at least a subset of the event count values, and for at least one setting of the counter configuration information, the event count program logic is configured to support chain counter operation to maintain a given event count value within the subset. A computer program in which the chain counter operation includes incrementing the given event count value by an increment value determined based on a logical combination of a first event status indicator indicating the status of a first event type assigned by counter configuration information to be monitored using the given event count value, and a second event status indicator indicating the status of a second event type assigned by counter configuration information to be monitored by further event counters.

20. A computer-readable storage medium for storing the computer program described in claim 19.

Images