Devices, methods, and computer programs for monitoring software performance

Abstract

The device has multiple event counters, each event counter maintaining its own count value based on monitoring events occurring during the execution of a sequence of instructions by the processing circuit. When at least a given condition exists, the selection circuit responds to a given instruction in a sequence in which the execution by the processing circuit causes several operations that depend on relevant instruction control information, one or more of which are associated with a given event monitored by a given event counter, by applying a selection algorithm to derive a selected update indicator from the instruction control information. The selection algorithm is such that the selected update indicator changes across multiple applications of the selection algorithm. The count control circuit is configured to adjust the count value of a given event counter by a default amount to consider the execution of a given instruction by the processing circuit when the value of the selected update indicator is a first value, or to adjust the count value of a given event counter by a non-default amount to consider the execution of a given instruction by the processing circuit when the value of the selected update indicator is a second value.

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, and stalls in instruction execution. 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] One or more of the event counters may be used to maintain counts related to the work done in response to the execution of a particular instruction, and the counts may depend, for example, on the number of operations executed as a result of executing such an instruction. However, in some instances, it may be impractical and / or prohibitively expensive to provide logic that can track the exact number of operations executed and update the relevant event counters accordingly.

Summary of the Invention

[0004] In one exemplary configuration, a device is provided comprising: a plurality of event counters, each maintaining its own count value based on monitoring events occurring during the execution of a sequence of instructions by a processing circuit; a selection circuit, configured such that, given at least one of the operations is associated with a given event monitored by a given event counter and in response to a given instruction in a sequence causing the execution by the processing circuit to perform several operations dependent on relevant instruction control information, wherein one or more of the operations are associated with a given event monitored by a given event counter and the selection circuit applies a selection algorithm to derive a selected update indicator from the instruction control information, wherein the selection algorithm is configured such that the selected update indicator changes across multiple applications of the selection algorithm; and a count control circuit, configured such that, given at least one of the operations is associated with a given event monitored by a given event counter and in response to a given instruction, adjusts the count value of a given event counter by a default amount to consider the execution of a given instruction by the processing circuit if the value of the selected update indicator is a first value, and adjusts the count value of a given event counter by a non-default amount to consider the execution of a given instruction by the processing circuit if the value of the selected update indicator is a second value.

[0005] In another exemplary configuration, a computer-readable medium is provided for storing computer-readable code for manufacturing the aforementioned device.

[0006] A further exemplary configuration provides a method for monitoring the performance of software executed by a processing circuit, the method comprising: using a plurality of event counters to maintain a count value for each based on monitoring events occurring during the execution of a sequence of instructions of the software by the processing circuit; and, given that, at least a given condition exists, the execution by the processing circuit causes a given instruction in a sequence to perform several operations that depend on relevant instruction control information, wherein one or more of the operations are associated with a given event monitored by a given event counter, and the method applies a selection algorithm to derive a selected update indicator from the instruction control information, wherein the selected update indicator changes across multiple applications of the selection algorithm; and, when the value of the selected update indicator is a first value, adjusting the count value of a given event counter by a default amount to take into account the execution of a given instruction by the processing circuit; and when the value of the selected update indicator is a second value, adjusting the count value of a given event counter by a non-default amount to take into account the execution of a given instruction by the processing circuit.

[0007] In yet another exemplary configuration, a computer program is provided which, when executed by a host data processing device, includes instructions that control the host data processing device to provide an instruction execution environment for executing target program code, the computer program includes event counting program logic that emulates several event counters, each event counter maintaining its respective count value based on monitoring events occurring during the simulated execution of a sequence of instructions of the target program code by the processing program logic, and, when at least a given condition exists, the execution by the processing program logic, in response to a given instruction in a sequence causing it to perform several operations that depend on relevant instruction control information, one or more of which are events The computer program comprises: a selection program logic that applies a selection algorithm to derive a selected update indicator from instruction control information associated with a given event monitored by a counter, wherein the selection algorithm is configured such that the selected update indicator changes across multiple applications of the selection algorithm; and a count control program logic configured, under at least given conditions, to adjust the count value of a given event counter by a default amount to consider the execution of a given instruction by the processing program logic if the value of the selected update indicator is a first value, and to adjust the count value of a given event counter by a non-default amount to consider the execution of a given instruction by the processing program logic if the value of the selected update indicator is a second value. Such a computer program can 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. [Brief explanation of the drawing]

[0008] This technology will be further described with reference only to the embodiments of this technology shown in 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 is shown. [Figure 3] The following outlines how one or more counters may be updated according to the first exemplary implementation. [Figure 4] The following outlines how one or more counters may be updated according to the second exemplary implementation. [Figure 5] This is a flowchart illustrating how event counters can be updated in one exemplary implementation. [Figure 6A] Here are two examples of instruction types that may involve a variable number of operations. [Figure 6B] Here are two examples of instruction types that may involve a variable number of operations. [Figure 7A] Two exemplary configurations that can be used by a count control circuit to determine whether a given condition exists are shown. [Figure 7B] Two exemplary configurations that can be used by a count control circuit to determine whether a given condition exists are shown. [Figure 8] This flowchart illustrates a merge process that can be performed in one exemplary implementation. [Figure 9] This figure shows a simulation example. [Modes for carrying out the invention]

[0009] As provided herein, there is a device having a plurality of event counters, each used to maintain its own count value based on monitoring events occurring during the execution of a sequence of instructions by a processing circuit. Given at least a given condition, the device takes several actions in response to a given instruction in a sequence causing the execution by the processing circuit to perform several operations that depend on relevant instruction control information, one or more of which operations may be associated with a given event monitored by a given event counter. The actions taken are used to determine how to update the given event counter.

[0010] In particular, the selection circuit can be configured to apply a selection algorithm to derive a selected update indicator from the instruction control information. The selection algorithm can take various forms, such that the selected update indicator changes across multiple applications of the selection algorithm. Therefore, over a period in which the selection algorithm is applied multiple times, the selected update indicator determined during one application of the selection algorithm is expected to differ from the selected update indicator determined during another application of the selection algorithm. Examples of suitable selection algorithms that may be used include a round-robin algorithm that cycles through multiple different possible parts of the instruction control information that can be selected as the update indicator, or a random or pseudo-random number generation algorithm that randomly or pseudo-randomly determines the part of the instruction control information to be selected as the update indicator. In other implementations, the selected update indicator may not directly correspond to a specific selected part of the instruction control information, but may be derived from the instruction control information in some other way. For example, the instruction control information may take the form of a specified value that can take one of several N different possible values, and a random or pseudo-random generator can be used to generate a comparison value from the N different possible values, and the value of the selected update indicator is set based on comparing the specified value with the comparison value. As a purely specific example, if the comparison value is the same as or less than the value specified by the instruction control information, the selected update indicator may be set to the first value; otherwise, it may be set to a different second value.

[0011] Furthermore, the count control circuit is configured to update the count value of a given event counter in response to a given instruction, according to the value of a selected update indicator. In particular, when the value of the selected update indicator is a first value, the count control circuit is configured to adjust the count value of a given event counter by a default amount to accommodate the execution of a given instruction by the processing circuit. However, when the value of the selected update indicator is a second value, the count control circuit instead adjusts the count value of a given event counter by a non-default amount to accommodate the execution of a given instruction by the processing circuit.

[0012] Such techniques have been shown to provide a statistical approach that allows for the maintenance of a reliable count value by a given event counter when considering a sufficiently large sample of occurrences of events that update the event counter. In particular, such an approach can avoid overcounting, which can occur when the count value of a given event counter is updated by a fixed amount (e.g., an amount indicating the maximum number of operations that can be performed) each time a given instruction is encountered, and thus can provide a much more reliable count value. Furthermore, such an approach avoids the need to provide logic for actively determining the number of operations to be performed each time a given instruction is executed, which is prohibitively expensive in many situations (e.g., in terms of the cost and complexity of such additional logic, the power consumed by such logic, etc.).

[0013] The selection circuit and counting control circuit can be located at various positions within the device. For example, one or both of the selection circuit and the counting control circuit may be located within the processing circuit, or within a performance monitoring circuit used to monitor the performance of software running on the processing circuit.

[0014] The non-default quantity to which the count value is adjusted when the value of the selected update indicator is a second value can take various forms. However, in one exemplary implementation, the non-default quantity is zero, and as a result, when the value of the selected update indicator is a second value, updating the count value of a given event counter is prohibited, and therefore no adjustment is made in that case to consider the execution of a given instruction by the processing circuit. In such applications, the default quantity to which the count value of a given event counter is adjusted when the value of the selected update indicator is a first value can also take various forms. For example, the default quantity may be chosen to indicate the maximum number of operations that can be performed, and therefore, based on the selected update indicator determined for any particular instance of a given instruction, the count value is either updated by its default, maximum, quantity, or not updated at all. This has been shown to provide a particularly effective mechanism for maintaining a reliable count value when updating a given event counter and considering a sufficiently large sample of instruction occurrences where the number of operations performed at the time of execution of any particular occurrence can vary.

[0015] It should also be noted that the number of bits contained within the selected update indicator may vary depending on the implementation. For example, in some exemplary implementations, more than one bit may form the selected update indicator, and therefore there may be more than two possible values ​​for the selected update indicator. In such cases, one value of the selected update indicator may update the count value by the default amount, another value of the selected update indicator may update the count value by a non-default amount (e.g., zero as described above), but one or more additional values ​​of the selected update indicator may update the count value by one or more different non-zero amounts up to the default amount (e.g., half of the default amount).

[0016] A given instruction can take various forms, but in one exemplary implementation, it is an instruction that defines at least one operation that is executed multiple times, the number of times depending on the instruction control information, and each instance of the operation is configured to perform the operation on a data element identified for that instance.

[0017] Instruction control information can take various forms depending on the form of a given instruction, but in one exemplary implementation, it is information used by the processing circuit to control how many operations are performed when the instruction is executed. For example, such instruction control information may be provided for certain types of scalar instructions, such as load-multiplex or store-multiplex instructions, where the load or store operation is repeated multiple times for several different memory addresses / associated data values. The instruction control information for such an instruction can take the form of information used to identify the load or store operations to be performed (for example, a field / mask value can encode which registers should be accessed when executing a load-multiplex or store-multiplex instruction, and thus effectively identify how many load or store operations should be performed). According to the techniques described herein, a selected update indicator may be determined using a selection circuit, and then the value of that update indicator may be determined to determine how to update the count value. As mentioned above, the way in which the selected update indicator is determined from such instruction control information can vary depending on the implementation. For example, the selected update indicator may take the form of a selected portion (e.g., bits) of a field / mask value. However, in an alternative embodiment, a specified value (e.g., a specified number of registers accessed when executing a load-multiplex or store-multiplex instruction) from among N different possible values ​​(e.g., the total number of registers) may be set as instruction control information, and the selected update indicator may be set based on a comparison between the specified value and a generated comparison value.

[0018] In another example, a processing circuit may be configured to perform vector processing in response to vector instructions, one or more of which vector instructions may identify one or more predicate operands used to identify which data elements in one or more source vectors should undergo the processing defined by the vector instruction. Thus, the number of operations performed in response to any particular instance of an instruction depends on the form of the predicate operand(s). The predicate operand(s) can take various forms. For example, a predicate operand may identify predicate information in the form of a number (also referred herein to a specified value) that can be used to identify which data elements of a vector to process, or alternatively, the predicate information identified by the predicate operand may include a plurality of predicate bits, each predicate bit associated with a corresponding data element in a given source vector identified by a given instruction, and the value of each predicate bit is used to determine whether the corresponding data element should undergo the processing operation. Regardless of how the predicate information is specified, according to the techniques described herein, a selected update indicator may be determined by a selection circuit from the predicate information, and the value of the selected update indicator may then be used to determine how to update the count value. For example, if the predicate information takes the form of multiple predicate bits, one or more of those predicate bits may be selected to form a selected update indicator. Alternatively, if the predicate information takes the form of a specified value (e.g., a specified number of data elements in a given source vector) from among N different possible values ​​(e.g., the total number of data elements in a given source vector), the selected update indicator may be set based on a comparison between the specified value and a generated comparison value.

[0019] The aforementioned default amount can be specified in various ways. In one exemplary implementation, it can be specified for each event. In one exemplary implementation, the count control circuit may be configured to receive event indications generated by the processing circuit during the execution of a sequence of instructions, and the event indication associated with the execution of a given instruction may be configured to identify a given event and an indication of the default amount. The manner in which any given event is identified to the count control circuit can take various forms. For example, an event identifier value may be provided as part of the event indication in one exemplary implementation. However, in another exemplary implementation, event indications associated with different events are input to the count control circuit via different input connections, and thus, the identification of the event is implicit from the input connection (e.g., one or more wires) through which the event indication is received.

[0020] Event indications can be generated at various points within a processing circuit. For example, the processing circuit may be organized in a pipeline configuration, and event indications may be generated at an appropriate pipeline stage. For example, in one exemplary implementation, event indications may be generated at the instruction decoding stage, before the instruction is executed by the processing circuit. This makes it possible to generate event indications relatively early in the processing pipeline. However, the relevant determination of the selected update indicator and the evaluation of the value of that selected update indicator can be performed at a later stage than the decoding stage. In such cases, the count control circuit may be further configured to receive the value of the selected update indicator for a given instruction in a manner that enables correlation with the event indication associated with the execution of a given instruction. This may be useful, for example, when the count control circuit is located outside the processing circuit, for example, as part of a performance monitoring unit provided in relation to the processing circuit. There are various ways in which such correlations can be achieved. For example, if different events are signaled over different input connections (e.g., different sets of wires), the value of the selected update indicator may also be provided through the appropriate input connection for the relevant event. In another exemplary implementation, some other identifier (ID) information may be associated with both the event indication and the value of the selected update indicator, or the issuance of the event indication to the count control circuit may be deferred until the value of the selected update indicator is determined, allowing all the necessary information to be provided to the count control circuit together.

[0021] It should also be noted that in some exemplary implementations, the value of the selected update indicator may be shared by multiple events in order to influence how the associated counter is updated in response to those events.

[0022] In an alternative exemplary configuration, the count control circuit can incorporate a selection circuit, determine a selected update indicator, and be configured to evaluate the value of the selected update indicator. Such an approach can be employed, for example, in an implementation where the count control circuit is provided as part of a processing circuit. In such a case, the count control circuit may thus be disposed separately from a performance monitoring unit that provides various event counters, and in such a case, the update control signal can be issued from the count control circuit to the performance monitoring unit to identify how various counters should be updated in response to event indications received by the count control circuit. Indeed, in situations where it is determined that an update should not be performed (e.g., in the aforementioned case where the non-default amount used when the value of the selected update indicator is a second value is actually a zero amount), the count control circuit can simply be configured to suppress the generation of any update control signal to the performance monitoring unit in situations where it is determined that a counter update should not be performed in consideration of the execution of a given instruction.

[0023] As described above, in some exemplary implementations, the above-described function of updating the count value of a given event counter by only a default amount or a non-default amount can be implemented only in situations where it is determined that a given condition exists. There are various ways to determine the existence of a given condition. For example, in one exemplary implementation, the device can further include a configuration storage that is referenced by the count control circuit to determine whether a given condition exists.

[0024] Configuration storage can be organized in various ways. For example, configuration storage may provide a global condition indicator that identifies whether a given condition exists or does not exist, regardless of which events are considered by the count control circuit. This allows the above functionality to be turned on or off as needed as a global parameter affecting all relevant events (i.e., events whose associated count values ​​are updated according to the number of operations performed when one or more instructions are executed, and whose operations are operations on which the techniques described herein are used). In an alternative implementation, configuration storage may provide multiple individual condition indicators, each associated with one of the event counters and configured to identify whether a given condition exists or does not exist for the associated event counter. This allows for finer granularity in setting a given condition for one or more event counters. In one example, a separate condition indicator may be provided for each relevant event counter, but in an alternative implementation, a condition indicator can be shared by multiple event counters, depending on the desired level of granularity for specifying the presence or absence of a given condition.

[0025] As an alternative to using configuration storage as described above, in alternative implementations, the presence or absence of a given condition may be predetermined based on the events considered by the count control circuit. Therefore, in such scenarios, the presence or absence of a given condition is an implicit property of the specific event, rather than needing to be determined by referring to configuration storage. In some implementations, this can provide a low-cost mechanism for implementing the above functionality when it is known that a given condition should always be determined to be present for one or more events, and not present for certain other events.

[0026] In yet another exemplary implementation, the device may adopt a fixed behavior for each relevant event, and therefore, the aforementioned technique can always be used for such events without needing to evaluate whether a given condition exists or not.

[0027] In one exemplary implementation, the count control circuit is configured to adjust the count value of a given counter by a default amount to allow the processing circuit to execute a given instruction if no given conditions for a given event are present. Therefore, if the given conditions are not detected, a standard update mechanism can be employed.

[0028] There are various ways in which a default amount can be determined. For example, in situations where vector processing is being performed, in some implementations a fixed vector length may be used, and the default amount may be determined according to the number of data elements in that vector length. For example, when decoding an instruction, the data element size may be known, and therefore the number of data elements in the fixed vector length can be determined, and this value can be used when determining the default amount by which the count value should be updated.

[0029] In other contexts, the vector length can be configurable within the instruction set architecture, and any particular implementation may have a vector length selected from several different acceptable vector lengths, while the instructions themselves are organized independently of the vector length. This approach is employed by the Arm Scalable Vector Extension (SVE), developed by Arm Limited in Cambridge, UK. In such implementations, a default quantity may be determined, for example, by the number of data elements in a given vector length. Thus, a given vector length can be a fixed vector length, regardless of the actual vector length selected in any particular implementation (typically a multiple of its fixed vector length). Since the count values ​​are updated by an update quantity based on the given vector length, software running in any particular implementation can scale those count values ​​as needed, taking into account the actual vector lengths used in that particular implementation.

[0030] In addition to, or alternatively to, the number of data elements within a particular vector length that affects the default amount, the default amount may be determined by the number of operations that form at least one operation defined by a given instruction. A particular instruction may require more than one operation to be performed in order to implement the processing required by that instruction. As a mere specific example, a multiply-accumulate instruction may be thought to involve two operations, namely multiplication and accumulation.

[0031] In one particular exemplary implementation, the default quantity is selected based on both the number of operations defined by a given instruction and the number of data elements in a given vector length. Therefore, as a purely specific example, if an instruction defines two operations to be performed per data element, and it is determined that the number of data elements in a given vector length is 8, the default quantity may be selected to be 16. Note that for some events, the default quantity may be selected considering only a subset of the operations defined by a given instruction. As a purely specific example, for a particular event, it may be determined that when executing a multiply-accumulate instruction, only the number of multiplications, and not the number of additions, should be counted.

[0032] In one exemplary implementation, a count control circuit may be configured to create merged update information for a given event counter when multiple events associated with that event counter are detected, provided at least a given condition exists, based on the default amount of each of the events and the value of a selected update indicator associated with each of the events. This can be useful in a variety of situations to reduce the number of updates required for the counter and / or to postpone counter updates until certain conditions are met. For example, when an instruction is executed speculatively, such an approach may be used to postpone counter updates for such speculatively executed instructions until a commit point is reached, by maintaining merged update information that can be used to update the counter when a commit point is reached. As another example, when multiple instructions are executed in parallel by different execution units within a processor, and each instruction performs superscalar processing with different instruction control information, it may be possible to create merged update information used to update the associated event counters. Such merging may be implemented at various locations within the system, for example, within a processing unit, or within a unit shared among several processing units, each used to execute instructions.

[0033] Next, we will consider specific exemplary implementation forms by referring to the attached diagram.

[0034] Figure 1 schematically illustrates an example of a data processing device 2. The data processing device has a processing pipeline 4 that includes several pipeline stages. In this embodiment, the pipeline stages include a fetch stage 6 for fetching instructions from the instruction cache 8, a decryption stage 10 for decrypting the fetched program instructions to generate microoperations (decrypted instructions) to be processed by the remaining stages of the pipeline, an issue stage 12 for checking whether the operands required for a given microoperation are available in the register file 14 and issuing a microoperation for execution when the operands required for a given microoperation are available, an execution stage 16 for executing data processing operations corresponding to the microoperation by processing the operands read from the register file 14 to generate result values, and a writeback stage 18 for writing the results of the processing back to the register file 14. This is just one example of a possible pipeline configuration, and it will be understood that other systems may have additional stages or different configurations of stages. For example, an out-of-order processor may include a register rename stage for mapping architectural registers specified by program instructions or microoperations to physical register specifiers that identify physical registers in the register file 14. In some examples, a one-to-one relationship may exist between a program instruction decoded by the decoding stage 10 and a corresponding microoperation processed by the execution stage. Alternatively, a one-to-many or many-to-one relationship may exist 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.

[0035] The execution stage 16 includes several processing units for performing different classes of processing operations. For example, the execution unit includes a scalar processing unit 20 (for example, equipped with a scalar arithmetic / logic unit (ALU) 20 for performing arithmetic or logical operations on scalar operands read from register 14), a vector processing unit 22 for performing vector operations on vectors containing multiple data elements, and a load / store unit 28 for performing load / store operations to access data in memory systems 8, 30, 32, and 34. Other examples of processing units that can be provided in the execution stage include a floating-point unit for performing operations involving values ​​expressed in floating-point format, or a branch unit for processing branch instructions.

[0036] Register 14 includes a scalar register 25 for storing scalar values, a vector register 26 for storing vector values, and a predicate register 27 for storing predicate values. The predicate value 27 may be used by the vector processing unit 22 when processing vector instructions, and the predicate value in a given predicate register indicates which vector elements of the corresponding vector operand stored in vector register 26 are active vector elements or inactive vector elements (operations corresponding to inactive data elements may be suppressed or may not affect the result value generated by the vector processing unit 22 in response to a vector instruction).

[0037] The memory management unit (MMU) 36 controls address translation between virtual addresses (specified by instruction fetches from the fetch circuit 6 or load / store requests from the load / store unit 28) and physical addresses that identify locations within the memory system, based on address mappings defined in a page table structure stored within the memory system. The page table structure can also define memory attributes that can specify access permissions for corresponding pages in the address space, for example, specifying whether a region of the address space is read-only or read / write, specifying which privilege levels are permitted to access the region, and / or specifying other properties that govern how the corresponding region of the address space can be accessed. Entries from the page table structure may be cached in a translation lookaside buffer (TLB) 38, which is a cache maintained by the MMU 36 to cache page table entries or other information in order to speed up access to page table entries from the page table structure shown in memory.

[0038] In this example, 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 cache arrangements are possible. The specific types of processing units 20-28 shown in execution stage 16 are merely examples, 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 configuration, and it will be understood that the processor may include many other elements not shown for brevity.

[0039] 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, 34, or may be stored within the memory systems 30, 32, 34 themselves (if memory-mapped registers or data structures within the memory itself are 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, 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 may be configured to collect various types of performance monitoring information of interest 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 may then be executed. During the execution of the target program, the performance monitoring circuit 40 operates according to the pre-configured counter configuration information.

[0040] 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 logical 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 monitored by the corresponding event counter.

[0041] 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.

[0042] 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 an instruction (either any general instruction or one or more specific types of instructions) • The number of operations performed by the instruction, or a value indicating that (either any general operation or one or more specific types of operations), • A memory access request is made (either a general, arbitrary memory access, or a specific type of memory access, such as load or store). • Cache access, cache line fill, or cache miss occurs (which may be specific to a particular level or type of cache). • TLB access, TLB line fill, or TLB miss occurs (this can also be an event that is tracked for any TLB in general, or it can 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)). • Occurrence of branch prediction errors, • The queue or buffer becomes full (variations of which may be provided to specific buffers such as the instruction issue queue, load buffer, or store buffer), or This may include any of the following: a pipeline stall caused by a specific reason (e.g., a cache miss, a TLB miss, or the load or store buffer becoming full).

[0043] Other event signals are quantitative status values ​​that indicate the characteristics of the event that occurred, i.e., • 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 This may include either an indication of the current occupancy rate of a specific instance of a queue or buffer located within the hardware.

[0044] 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.

[0045] 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, which has coding to select which 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 indication 47 representing the status of the event assigned to that event counter 42 by the counter configuration information 46.

[0046] 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 counter update logic circuit (implemented in hardware) for updating the event count value as a function of the event status indication 47 provided to the counter 42 by the event selection circuit 48. For example, the increment value may be selected as a function of the event status indication 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 indication 47, and how the increment value should be selected based on the result of applying the function to the event status indication 47.

[0047] 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 the respective event count value 43. In either case, debugging software can read the current value of each event count value to determine information about 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.

[0048] As mentioned above, one or more event counters may be used to maintain a count value related to the work performed in response to the execution of a particular instruction, the count value may depend, for example, on the number of operations performed as a result of executing such an instruction. Figure 3 schematically shows how such counters may be updated according to a first exemplary implementation. Processing circuit 100 is provided to execute a sequence of instructions including instructions of the type described above. The instructions may be decoded by the decoding stage 105 in the processing pipeline of processing circuit 100 and subsequently executed in the execution stage 110 in the processing pipeline.

[0049] A performance monitoring unit 115 is provided, which can take the form of the aforementioned performance monitoring circuit 40. Storage 120 is provided to maintain a plurality of event counters 122, 124, and 126, each of which may be used to maintain its respective count value based on monitoring of events occurring during the execution of instructions by the processing circuit 100. Thus, event counters 122, 124, and 126 correspond to the event counter 42 described above, with reference to Figure 2.

[0050] As previously explained with reference to Figure 2, a set of hardware circuit logic may be provided for various counters, which may include a count control circuit 130 and an update circuit 135 shown in Figure 3. In Figure 3, each of the count control circuit 130 and the update circuit 135 is shown as a single logic block, but in alternative implementations, they may each have separate count control and update circuits for each event counter.

[0051] During the execution of an instruction by the processing circuit 100, an event indication may be output to the PMU 115 that identifies an event requiring the update of one or more of the counters 122, 124, and 126. For simplicity, the following description will refer to the update of a single counter, but it should be understood that a particular event may update multiple counters. The format of the event indication may vary depending on the type of event displayed, but considering events related to the execution of the aforementioned types of instructions, the execution of such an instruction may cause several operations to be performed depending on the relevant instruction control information, and the event indication for such an instruction may be generated in the decoding stage 105 when the instruction is decoded, in one exemplary implementation. The event indication may include an event identifier 145 and a default amount indication 150, the default amount indication indicating the default amount by which the relevant counter in the counter storage 120 should be updated in consideration of the instruction execution. The event identifier 145 may be an explicit identifier value in one exemplary implementation, but in another exemplary implementation, event indications associated with different events are provided to the PMU 115 via different input connections, and therefore the identification of the event is implicit from the input connection (e.g., a wire or multiple wires) from which the event indication is received.

[0052] As mentioned above, according to the statistical approach employed when using this technique, whether the relevant counter is updated by a default amount or by some other amount (e.g., a zero amount that prohibits updating the relevant counter) depends on the value of a selected update indicator derived from the instruction control information, which in one exemplary implementation may be determined by the selection circuit 140 shown in Figure 3. This may be provided at various locations in the system, but in the example shown in Figure 3, it is shown as being associated with the execution stage of the processing circuit 100. In particular, the instruction control information is made available to the execution stage 110 and therefore available for analysis by the selection circuit 140 at that stage.

[0053] The selection circuit is configured to apply a selection algorithm to determine the selected update indicator from the instruction control information. For the purposes of the following description, we assume that the selection algorithm is configured to determine the selected portion of the instruction control information to form the selected update indicator. However, in alternative implementations, the selected update indicator may be derived from the instruction control information in any suitable way.

[0054] The selection algorithm can take various forms, such that the selected portion to be determined changes across multiple applications of the selection algorithm. Examples of suitable selection algorithms that may be used include a round-robin algorithm that cycles through several different possible portions to be selected, or a random or pseudo-random number generation algorithm that randomly or pseudo-randomly determines the portion of the instruction control information to be selected. It is assumed that a random or pseudo-random number algorithm is applied according to the approach shown in Figure 3, and therefore a randomly selected portion of the instruction control information is determined by the selection circuit, and the value of that randomly selected portion is evaluated. This value can then be provided to the count control circuit 130 via path 155 in a manner that allows it to be correlated with event indications 145, 150.

[0055] There are various ways in which such correlation can be achieved. For example, if different events are signaled over different input connections (e.g., different sets of wires), the value of a randomly selected portion of the instruction control information can be provided via the appropriate input connection for the event to which the information relates. In another exemplary implementation, some other identifier (ID) information can be associated with both the event indication and the value of the selected portion of the instruction control information, or the issuance of the event indication to the PMU 115 can be delayed until the value of the selected portion of the instruction control information is determined, thereby allowing all the necessary information to be provided together to the count control circuit.

[0056] The count control circuit 130 is configured to update the count value of an associated event counter in response to a received event indication and a corresponding value of a randomly selected portion of the instruction control information, according to the value of that selected portion of the instruction control information. In particular, when the value of the selected portion of the instruction control information is a first value, the count control circuit is configured to adjust the count value of the associated event counter by a default amount to account for the execution of the associated instruction by the processing circuit. However, when the value of the selected portion of the instruction control information is a second value, the count control circuit instead adjusts the count value of a given event counter by a non-default amount (zero in one exemplary implementation) to account for the execution of the associated instruction by the processing circuit. Therefore, based on the evaluation performed by the count control circuit 130, a control signal can be sent to the update circuit 135 to update the appropriate counter as needed.

[0057] The default amount by which the count value is adjusted when the value of a selected portion of the instruction control information is a first value can take various forms. For example, the default amount may be chosen to indicate the maximum number of operations that can be performed when the instruction that caused the event indication is executed, and therefore, based on the selected portion of the instruction control information, the count value may be updated by its default, maximum, amount, or (as previously stated, the non-default amount is zero) not updated at all. This has been shown to provide a particularly effective mechanism for updating the event counter and maintaining a reliable count value when considering a sufficiently large sample of instruction occurrences where the number of operations performed when any particular occurrence is executed can vary.

[0058] In one exemplary implementation, the above function that determines how one or more counters are updated in accordance with a randomly selected portion of instruction control information may be configurable. In particular, in one exemplary implementation, such a function may be implemented only if it is determined that a given condition exists; otherwise, a default update mechanism may be implemented, for example, by updating the relevant counters by a default amount regardless of the instruction control information. Various methods for determining whether a given condition exists will be described in more detail later.

[0059] The randomly selected portion determined by the selection circuit 140 may, as necessary, contain one or more bits of instruction control information. If the randomly selected portion contains more than one bit, it will be understood that there are more than two possible values ​​for the randomly selected portion. In one exemplary implementation, if more than two possible values ​​are available, several different update amounts may be determined based on the value of the randomly selected portion. For example, a first value may cause the associated counter to be updated by a default amount, a second value may not update the counter at all, and one or more other values ​​may cause the associated counter to be updated by a different amount than the default amount (e.g., half the default amount). In one particular exemplary embodiment, the processing circuit is executing a vector instruction, and the instruction control information takes the form of predicate information specified by the predicate operand of the vector instruction. Such predicate information can take various forms, but in one particular exemplary implementation, it comprises multiple predicate bits, each predicate bit associated with a corresponding data element in a given source vector identified by the instruction. In such cases, the selected portion of the instruction control information may, in one exemplary implementation, take the form of a single predicate bit among those predicate bits, where if the selected predicate bit has a first value, the associated counter is updated by a default amount; if the predicate bit has a second value, the counter is not updated.

[0060] Figure 4 schematically illustrates a modification of the technique shown in Figure 3, where the count control circuit 130' is located within the processing pipeline 100 and communicates with the update circuit 135' located within the PMU 115 via one or more event indication paths 145', 150'. In such an implementation, event information, such as that which may have been generated by the decoding stage 105, is forwarded to the count control circuit 130' for evaluation. The count control circuit can be located at various points within the processing pipeline, but in the example of Figure 4, it is assumed to be associated with the execution stage 110. Furthermore, in this example, the selection circuit 140' may be provided as part of the count control circuit 130'.

[0061] Based on the selected portion of the instruction control information determined by the selection circuit 140', the count control circuit 130' can then determine whether the associated counter corresponding to the received event information should be updated by a specified default amount (which may be provided as part of the event information) or by some other amount (e.g., zero). Based on this determination, the count control circuit can then issue an event indication to the update circuit 135' to identify the event (and therefore the associated event counter) and the update amount to be applied to that event counter, and the update circuit can then apply the update accordingly. In one particular exemplary implementation, the associated event counter is either updated by a default amount or no update is performed on the associated event counter, depending on the value of the selected portion of the instruction control information. In one exemplary implementation, if the count control circuit 130' determines that no update should be performed, no event indication is required to be issued to the PMU. Conversely, if an update is performed, the update amount indication provided via the path 150' is the default update amount provided in the event information analyzed by the count control circuit 130'.

[0062] Figure 5 is a flowchart illustrating how an event counter can be updated in one exemplary implementation. In step 200, it is determined whether an event has been detected by encountering an instruction that requires a variable number of operations to be executed, depending on the instruction control information. If not, in step 205, it is determined whether another type of event has been detected, and if so, in step 210, the other type of event is processed in the usual manner. Processing returns to step 200 after the execution of step 205, or directly to step 200 if no other type of event is detected in step 210.

[0063] If an event is detected in step 200 by encountering an instruction that requires a variable number of operations to be performed, in step 215 the aforementioned selection circuit is used to randomly select a bit of the instruction control information. Note that if the event is of a type that requires updating multiple counters, in one exemplary implementation, the same randomly selected bit of the instruction control information is used to control the update of each of those counters. Next, in step 220, it is determined whether the selected bit has a first value. If so, in step 225, the associated event counter associated with the event detected in step 200 is adjusted by a default amount. However, if the selected bit has a second value, in step 230, the update of the associated event counter is prohibited. Following either step 225 or step 230, the process returns to step 200.

[0064] Figures 6A and 6B show two examples of instruction types that may result in a variable number of operations being performed, and thus the techniques described herein may be performed. Figure 6A shows a vector instruction 250 having multiple fields. One field 255 is used to define an operation code, and thus defines one or more operations that must be performed in response to the execution of that instruction. The source operand field 270 is used to identify one or more source vector operands by identifying one or more vector registers 26 whose contents are provided by one or more source vectors, each containing a plurality of data elements to which the defined operations (one or more) should be applied.

[0065] Furthermore, the destination operand field 265 may be used to specify a destination vector operand, for example, by identifying one of the vector registers 26 in which the results generated as a result of executing an instruction should be stored. In an alternative implementation, the destination operand may also be one of the source operands, and as a result, once the calculations necessary to produce the result are performed, those results are written back to one of the source vector operands, overwriting the previous contents. As shown in Figure 6A, a predicate operand field 260 may also be provided that identifies one or more predicate operands that form instruction control information. In one example, a predicate operand may take the form of a plurality of predicate bits, each predicate bit associated with one of the data elements in the associated source vector operand, and the value of the predicate bit identifies whether the associated data element should undergo one or more operations defined by the instruction. In one exemplary implementation, a selection circuit is used to select a random bit of predicate information specified by a predicate operand, the value of which is then used to determine whether to adjust the associated event counter (by a default amount) when a vector instruction is encountered in the sequence of instructions being executed by the processing circuit.

[0066] In implementations where the data element size can vary, and therefore the number of data elements within a given vector length can change, the predicate register used to define the predicate information may have enough bits to account for the smallest data element size, and the actual predicate bits used to form the predicate information in any particular instance will depend on the data element size in question.

[0067] However, the techniques described herein are not applicable only to vector instructions. Figure 6B shows an example of a scalar instruction that defines an operation to be performed multiple times, the number of times depending on the instruction control information. In particular, a load-multiplex or store-multiplex instruction 280 is shown, and the operation code field 285 identifies the operation to be performed and thus distinguishes between load-multiplex and store-multiplex instructions. The base address indicator field 290 may be used to identify the base address to which the first data value should be loaded or stored, depending on whether the instruction is a load-multiplex or store-multiplex instruction. One or more other fields 295 may also be used to specify other information related to the execution of the instruction, for example, to identify the address increment mode, which identifies how much the base address is adjusted between each consecutive load or store operation. Furthermore, field 287 can be used to identify each of the registers being accessed (and thus each of the registers to which the data value should be loaded in the case of a load-multiplex instruction, or each of the registers to which the data value should be stored in memory in the case of a store-multiplex instruction). This identifier information in field 287 can take various forms, but one example is a mask that identifies which registers should be accessed. This identifier information can be used to control the number of load (or store) operations performed and can therefore be considered instruction control information. In one exemplary implementation, a random bit of the information in field 287 can be selected, and the value of that bit can be used to determine whether to adjust the associated event counter (by a default amount) when the processing circuit encounters an instruction in the sequence of instructions being executed. This default amount can take various forms, but for example, it could indicate the maximum number of registers that can be accessed by a load-multiplex or store-multiplex instruction, and therefore the maximum number of load or store operations performed when executing an instruction.In alternative implementations, the default amount can take into account other factors such as the access size of the data being accessed (bytes, words, etc.) and a predetermined vector length in the SVE implementation.

[0068] In implementations where the application of the techniques described above depends on whether a given condition is determined to exist, in one exemplary implementation, configuration storage can be used to store condition indicator information that is referenced to determine whether a given condition exists. Figure 7A shows one such form of configuration storage 300, in which a global condition indicator 310 is provided. The global condition indicator 310 is referenced by the count control circuit 305 when considering received events to determine whether a given condition exists. In one exemplary implementation, this information may also be referenced by the selection circuit 140. Thus, this approach makes it possible to turn the above functionality on or off as needed, as a global parameter that affects all relevant events (i.e., events in which the relevant count value is updated depending on the number of operations performed when one or more instructions are executed).

[0069] In an alternative implementation as shown in Figure 7B, the configuration storage 300 may provide a plurality of individual condition indicators, each of which is associated with one of the event counters and configured to identify whether a given condition exists or does not exist for the associated event counter. In particular, as shown in Figure 7B, a table 320 having a plurality of entries 322 may be maintained. Each entry may be used to identify an event counter 325 and an associated condition indicator value 330 that identifies when a given condition should be considered to exist or not exist for that event counter.

[0070] Therefore, this allows for finer granularity in setting a given condition for one or more event counters. For example, a separate condition indicator can be provided for each related event counter, but in an alternative implementation, the condition indicator can be shared by multiple event counters, depending on the desired level of granularity at which the presence or absence of a given condition can be specified.

[0071] As shown with reference to the flowchart in Figure 8, in one exemplary implementation, the count control circuit may be configured to create merged update information for a given event counter when multiple events associated with a given event counter are detected (for example, due to multiple instructions each triggering the same event, and therefore each requiring an update to the corresponding counter for that event), based on the default amount for each of the multiple events and the value of a selected portion of the instruction control information associated with each of the multiple events. As shown in step 400, it is determined whether multiple events associated with the same event counter have been detected, and if such a situation has been detected, in step 405, it is determined whether a merge condition exists. The merge condition can take various forms. For example, it may be decided to always merge the events when multiple events associated with the same event counter are detected. However, in an alternative implementation, it may be determined that the merge condition exists only in specific situations, for example, when an instruction is executed speculatively.

[0072] If it is determined that no merge conditions exist, in step 410 each event is processed separately, the event counter is updated as appropriate using the techniques described above, and then the process returns to step 400. However, assuming that it is determined in step 405 that merge conditions exist, in step 415 a default amount associated with each of those events is determined, as well as a randomly selected predicate bit value for each of those events. Next, in step 420, an updated amount to be applied after the merge is created, which is based on the default amount and the randomly selected predicate bit value determined in step 415. There are various ways in which the updated amount to be applied after the merge can be created from the configuration information determined in step 415. However, as a purely illustrative example, if in step 400 an event is detected for each of instructions A, B, and C, and the event associated with instruction A has a default amount of 4, the event associated with instruction B has a default amount of 4, and the event associated with instruction C has a default amount of 8, and randomly selected predicate bits for those three events are 1, 0, and 1 respectively (a value of 1 indicates that the default amount should be applied, and a value of 0 indicates that the update should not be applied), then the update amount created in step 420 could be an update amount of 12 in this particular example.

[0073] In step 425, the merged update information is output to update the relevant event counters. In the example in Figure 8, it is assumed that the merging process is performed within the processing circuit or within some other element outside the PMU, and therefore the merged update information is output to the PMU. However, in alternative implementations, the merging process may be performed by circuitry within the PMU.

[0074] In one exemplary implementation, after the update amount is created in step 420, the output of the merged update information may be deferred until some trigger event occurs. The trigger event can take various forms, but as an example, the trigger event may be reaching a commit point associated with the speculative execution path containing the instructions that generated the multiple events detected in step 400, and as a result, the actual update of the associated counters occurs only after the commit point is reached.

[0075] The merge technique described above can be useful in various situations to reduce the number of updates required for a counter and / or to postpone counter updates until certain conditions are met. For example, when an instruction is executed speculatively, it may be possible to postpone counter updates for such speculatively executed instructions until the commit point is reached by maintaining merged update information that can be used to update the counter when the commit point is reached, as described above. As another example, when multiple instructions are executed in parallel by different execution units within a processor, and each instruction performs superscalar processing with different instruction control information, it may be possible to create merged update information that can be used to update the associated event counter.

[0076] 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 can 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.

[0077] 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 register-transfer-level (RTL) abstractions of one or more logic circuits for defining a device embodying the concept. The code may define HDL representations 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 definitions that embody the concept using system-level modeling languages ​​such as SystemC and SystemVerilog, or other behavioral representations of the concept that may be interpreted by a computer to enable simulation, functional and / or formal verification, and testing of the concept.

[0078] 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 can 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.

[0079] 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.

[0080] 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. Integrated circuits 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.

[0081] Figure 9 also illustrates possible simulator implementations. While the embodiments described above implement the 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 by the use of 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 530, optionally running a host operating system 520 and supporting a simulator program 510. 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 techniques 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, Winter 1990 USENIX Conference, pages 53-63.

[0082] 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 configurations where one or more of the hardware elements referenced in the examples described above reside on host hardware (e.g., host processor 530), some simulated embodiments may, if preferred, utilize the host hardware.

[0083] The simulator program 510 can be stored on 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 500 (which may include applications, operating systems, and hypervisors), which is the same as the interface of the hardware architecture modeled by the simulator program 510. Therefore, program instructions in the target code 500, including the previously described types of instructions that perform several operations dependent on relevant instruction control information, may be executed from within the instruction execution environment using the simulator program 510. As a result, the host computer 530, which does not actually possess the hardware functions of the device 2 described above, can emulate these functions. 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.

[0084] Therefore, the simulator program 510 may have processing program logic 512 that simulates the state of the processing circuit 4 described above. The instruction decoding program logic 514 decodes the instructions of the target code 500 and maps them to the corresponding instruction set in the native instruction set of the host device 530. The register simulation program logic 513 maps the register access requested by the target code to access the corresponding register emulated data structure 533 maintained by the host hardware of the host device 530, such as by accessing the registers of the host device 530 or data in memory 532. The memory management program logic 515 performs address translation, page table walk, and access control checks in a manner corresponding to the MMU 36 described in the hardware implementation embodiment above, but also has the additional function of mapping the simulated physical address obtained by the simulated MMU 36 to the host virtual address used to access the host memory 532. 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 510). Thus, the simulated physical address space accessed by the target code 500 can be mapped to region 534 of host memory 532, which represents the simulated target memories 30, 32, and 34 of the target processing unit 2 simulated by the simulator program 510.

[0085] The simulator program 510 has a performance monitoring program logic 516 that simulates the behavior of the performance monitoring circuit 40, and may include an event count program logic 517 that maintains an event count value 535 in the host memory 532 corresponding to a count value maintained in the event counter 42 of the hardware embodiment. The performance monitoring program logic 516 also includes a count control program logic 518 that implements the functions of the count control circuits 130, 130' of the hardware embodiment described above, in order to make updates performed on one or more count values ​​dependent on a selected portion of the instruction control information, and a selection program logic 519 that implements the functions of the selection circuits 140, 140' of the hardware embodiment to determine a selected portion of the instruction control information.

[0086] 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.

[0087] 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.

[0088] 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. It is a device, Based on monitoring events that occur during the execution of a sequence of instructions by the processing circuit, multiple event counters each maintain their own event count value, When at least a given condition exists, the execution by the processing circuit responds to a given instruction in a sequence that causes several operations to be performed depending on relevant instruction control information, one or more of the operations to be associated with a given event monitored by a given event counter, and a selection algorithm is applied to derive an update indicator selected from the instruction control information, the selection algorithm is configured such that the selected update indicator changes over multiple applications of the selection algorithm, When at least the above given conditions exist, in response to the above given command, When the value of the selected update indicator is a first value, the count value of the given event counter is adjusted by a default amount in order to consider the execution of the given instruction by the processing circuit. A device comprising: a count control circuit configured to adjust the count value of a given event counter by a non-default amount in order to consider the execution of a given instruction by the processing circuit when the value of the selected update indicator is a second value.

2. The apparatus according to claim 1, wherein the non-default amount is zero in order to prevent the updating of the count value of the given event counter for consideration of the execution of the given instruction by the processing circuit when the value of the selected update indicator is the second value.

3. The apparatus according to claim 1 or 2, wherein the given instruction is an instruction that defines at least one operation that is executed multiple times, the multiple times depending on the instruction control information, and each instance of the operation is configured to perform the operation on a data element identified for that instance.

4. The apparatus according to claim 3, wherein the given instruction is a vector instruction that identifies at least one source vector including a plurality of data elements, and the instruction control information includes predicate information that identifies which data elements in the at least one source vector should undergo the at least one operation defined by the given instruction.

5. The apparatus according to claim 4, wherein the pre-descriptive word information includes a plurality of predicate bits, each predicate bit associated with a corresponding data element in a given source vector identified by the given instruction, and the selected update indicator is one of the pre-descriptive word bits.

6. The apparatus according to claim 4, wherein the pre-descriptive word information includes a specified value used to identify which data element in a given source vector should undergo the at least one operation defined by the given instruction.

7. The count control circuit is configured to receive event indications generated by the processing circuit during the execution of the sequence of instructions, and the event indication associated with the execution of a given instruction identifies the given event and the default amount indication. The apparatus according to any one of claims 1 to 6.

8. The count control circuit is further configured to receive the value of the selected update indicator for the given instruction in a manner that enables correlation of the event indication associated with the execution of the given instruction. The apparatus according to claim 7.

9. The apparatus according to claim 7, wherein the count control circuit is configured to incorporate the selection circuit, determine the selected update indicator, and evaluate the value of the selected update indicator.

10. Configuration storage referenced by the count control circuit to determine whether the given conditions exist, The apparatus according to any one of claims 1 to 9, further comprising:

11. The apparatus according to claim 10, wherein the configuration storage provides a global condition indicator that identifies whether the given condition exists or does not exist, and the global condition indicator is applied regardless of which event is considered by the count control circuit.

12. The apparatus according to claim 10, wherein the configuration storage provides a plurality of individual condition indicators, each individual condition indicator being associated with one of the event counters and configured to identify whether a given condition exists or does not exist for the associated event counter.

13. The apparatus according to any one of claims 1 to 9, wherein the presence or absence of the aforementioned given condition is predetermined based on the event considered by the count control circuit.

14. The apparatus according to any one of claims 1 to 13, wherein the count control circuit is configured to adjust the count value of a given counter by the default amount in order to consider the execution of a given instruction by the processing circuit when there are no given conditions for a given event.

15. The apparatus according to any one of claims 1 to 14, as dependent on claim 4, wherein the default amount is determined depending on the number of data elements in a predetermined vector length.

16. The apparatus according to any one of claims 1 to 15, as dependent on claim 3, wherein the default amount is determined depending on the number of operations that form the at least one operation defined by the given instruction.

17. The apparatus according to any one of claims 1 to 16, wherein the count control circuit is configured to create merged update information for the given event counter based on the default amount for each of the events and the value of the selected update indicator associated with each of the events when a plurality of events associated with the given event counter are detected, provided that at least the given conditions are met.

18. The aforementioned selection algorithm is: Round Robin algorithm and Random number generation algorithms, A pseudorandom number generation algorithm, and an apparatus according to any one of claims 1 to 17.

19. A computer-readable medium for storing computer-readable codes, for the manufacture of the apparatus according to any one of claims 1 to 18.

20. A method for monitoring the performance of software running on a processing circuit, Based on monitoring events that occur during the execution of the software instruction sequence by the processing circuit, multiple event counters are used to maintain their respective count values. When at least a given condition exists, the execution of a given instruction by the processing circuit in response to a given instruction in the sequence causes it to perform several operations that depend on the relevant instruction control information, and one or more of these operations are associated with a given event monitored by a given event counter. Applying a selection algorithm to derive an update indicator selected from the command control information, wherein the selected update indicator changes across multiple applications of the selection algorithm. When the value of the selected update indicator is a first value, the count value of the given event counter is adjusted by a default amount in order to consider the execution of the given instruction by the processing circuit. A method comprising, when the value of the selected update indicator is a second value, adjusting the count value of the given event counter by a non-default amount in order to consider the execution of the given instruction by the processing circuit.

21. A computer program that includes instructions to control the host data processing device to provide an instruction execution environment for executing target program code when executed by the host data processing device, wherein the computer program Event counting program logic for emulating multiple event counters, wherein each event counter maintains its own count value based on monitoring of events occurring during the simulated execution of a sequence of instructions of the target program code by the processing program logic, When at least a given condition exists, the execution by the processing program logic, in response to a given instruction in the sequence causing several operations that depend on relevant instruction control information, one or more of the operations are associated with a given event monitored by a given event counter, and a selection algorithm is applied to derive an update indicator selected from the instruction control information, wherein the selection algorithm is configured such that the selected update indicator changes across multiple applications of the selection algorithm, When at least the above given conditions exist, in response to the above given command, When the value of the selected update indicator is a first value, the count value of the given event counter is adjusted by a default amount in order to consider the execution of the given instruction by the processing program logic. A computer program comprising: a count control program logic configured to adjust the count value of a given event counter by a non-default amount in order to consider the execution of a given instruction by the processing program logic when the value of the selected update indicator is a second value.

Images