Performance monitoring counting method and device, electronic equipment and storage medium

Abstract

The invention provides a performance monitoring counting method and device, electronic equipment and a storage medium, and relates to the technical field of processor design. According to the device, a plurality of performance monitoring slave units are respectively configured in different chip partitions of a processor and are used for independently counting performance events generated by calculation modules to be subjected to performance analysis and generating counting results; the counting result output requests of the plurality of performance monitoring slave units are uniformly managed through the performance monitoring master unit, and counting results of all sources are distinguished and stored in a target cache unit through a system bus according to a preset address mapping mode. According to the scheme, accurate distinguishing of performance event sources can be realized in a multi-module parallel operation scene, so that the monitoring data has clear spatial boundary and source relevance, meanwhile, writing conflicts are reduced, and the stability of data management is improved; therefore, the reliability, the expandability and the monitoring precision of a performance monitoring system under a complex parallel architecture are improved.

Description

Technical Field

[0001] This disclosure relates to the field of processor design technology, and more specifically, to a performance monitoring and counting method and apparatus, electronic device, and storage medium. Background Technology

[0002] In scenarios where graphics processing units (GPUs) run in parallel with multiple tasks, it is usually necessary to statistically analyze various performance events generated during processing in order to assess the utilization of chip resources. This helps the software identify performance bottlenecks and optimize scheduling strategies.

[0003] Currently, a shared performance counting mechanism is commonly used in related technologies. This mechanism uses a set of global counters to accumulate and statistically analyze performance events generated by multiple modules within the processor. However, with the increasing parallelism of processors and the diversification of task types, the shared performance counter scheme has gradually exposed the problem of mixed data sources. When multiple tasks or multiple computing modules run simultaneously, the global counter cannot distinguish between performance events from different sources, making it difficult to clearly attribute performance data and failing to reflect the true operating behavior of each independent task or chip partition. Furthermore, in application scenarios that require performance data collection at higher frequencies or with finer granularity, the relevant schemes also struggle to balance system overhead and monitoring accuracy in terms of real-time counting, result management methods, and data writing mechanisms.

[0004] Therefore, how to accurately distinguish performance events from different sources and reasonably manage statistical results under a multi-task parallel architecture has become a technical problem that urgently needs to be solved in this field.

[0005] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] The purpose of this disclosure is to provide a performance monitoring and counting method, a performance monitoring and counting device, an electronic device, and a computer-readable storage medium, which can reduce write conflicts and improve the stability of data management, thereby improving the reliability, scalability, and monitoring accuracy of the performance monitoring system under complex parallel architectures.

[0007] Other features and advantages of this disclosure will become apparent from the following detailed description, or may be learned in part from practice of this disclosure.

[0008] According to a first aspect of the present disclosure, a performance monitoring and counting device is provided, applied in a processor supporting multi-task parallel processing, the device comprising: At least two performance monitoring slave units are provided, each of which is associated with a computing module to be analyzed in each chip partition of the processor. Each performance monitoring slave unit is used to independently count the performance events generated by its associated computing module and generate corresponding count results. The performance monitoring master unit is communicatively connected to the at least two performance monitoring slave units, and is used to receive and manage the counting result output requests from the at least two performance monitoring slave units, and to distinguish and store the counting results in the target cache unit through the system bus based on the counting result output requests.

[0009] In some example embodiments of this disclosure, based on the foregoing scheme, each of the performance monitoring slave units includes: At least one performance event accumulator is used to count at least one input performance event signal in parallel, with one performance event accumulator corresponding to each performance event; A control signal processor is used to generate start counting, stop counting, and dump commands based on received control signals. An output buffer is used to cache the current count result of the at least one performance event accumulator when the dump command is triggered.

[0010] In some example embodiments of this disclosure, based on the foregoing scheme, the performance monitoring and counting device further includes: A central control signal generator, which is communicatively connected to the control signal processor, is used to generate and broadcast a unified global control signal. The control signals received by the control signal processor include global control signals from the central control signal generator and / or control information generated based on local register configuration.

[0011] In some exemplary embodiments of this disclosure, based on the foregoing scheme, the central control signal generator outputs at least two global control signals, the at least two global control signals including an enable signal and a command signal; The control signal processor generates a start or stop counting command by detecting the edge of the enable signal, and generates a dump command by detecting the edge of the command signal.

[0012] In some example embodiments of this disclosure, based on the foregoing scheme, the operating modes of the control signal processor include an event-triggered mode and an interval-triggered mode; In the event-triggered mode, the dump command is triggered by local register configuration; In the interval-triggered mode, the dump command is automatically triggered according to the configured interval period.

[0013] In some example embodiments of this disclosure, based on the foregoing scheme, when the control signal processor receives a global control signal from the central control signal generator, it ignores the trigger mode configured in the local register and directly generates a command based on the global control signal.

[0014] In some example embodiments of this disclosure, based on the foregoing scheme, the performance monitoring master unit includes an arbitrator, which is used to poll and arbitrate write requests from the at least two performance monitoring slave units to obtain an arbitration result that includes the writing order of the calculation results, and write the counting result to the target cache unit through the system bus based on the arbitration result.

[0015] In some example embodiments of this disclosure, based on the foregoing scheme, the performance monitoring master unit is configured to write the counting results of different performance monitoring slave units into non-overlapping address regions in the target cache unit according to a predetermined address mapping method, so as to achieve the differentiated storage.

[0016] In some example embodiments of this disclosure, based on the aforementioned scheme, for the same performance monitoring slave unit, the performance monitoring master unit writes the count results dumped at different times into the target cache unit in a continuous or fixed-step interval address region according to a predetermined address increment rule, so as to achieve differentiated storage of different batches of data in the same unit.

[0017] In some example embodiments of this disclosure, based on the foregoing scheme, each of the performance monitoring slave units further includes: The dump address calculator is used to dynamically calculate the target memory address for each dump operation based on the configured base address, starting address offset, and dump step size.

[0018] In some example embodiments of this disclosure, based on the foregoing scheme, the dump address calculator is further configured to execute a wraparound mode or a stop mode when the calculated target memory address exceeds the configured memory space range. In the wraparound mode, the target memory address wraps back to the configured base address and continues to be dumped; In the stop mode, the counting stops and an address overflow error is reported.

[0019] In some example embodiments of this disclosure, based on the foregoing scheme, the counting mode of the performance event accumulator includes a relative counting mode or an absolute counting mode; In the relative counting mode, after each dump operation is completed, the count result of the corresponding performance event accumulator is cleared to zero; In the absolute counting mode, the count result of the performance event accumulator remains unchanged after dumping until it is cleared to zero upon receiving a stop counting command.

[0020] In some example embodiments of this disclosure, based on the foregoing scheme, the performance monitoring slave unit is further configured to generate dump pointer information, the dump pointer information including the number of dumps and a last dump completion flag; The performance monitoring master unit writes the dump pointer information and the counting result together or separately into the target cache unit.

[0021] In some example embodiments of this disclosure, based on the foregoing scheme, the performance monitoring slave unit triggers a write of the dump pointer information after completing a specified number of dump operations, according to the configured pointer update frequency; and / or After receiving the stop counting command and completing the last dump operation, the dump pointer information is written once.

[0022] In some example embodiments of this disclosure, based on the foregoing scheme, the performance monitoring slave unit further includes: The status reporting module is used to write the running status and error status into the status register; The running status and error status include one or more of the following: last dump completion flag, dump command overlap flag, counter overflow flag, and address space overflow flag.

[0023] In some example embodiments of this disclosure, based on the foregoing scheme, the performance monitoring slave unit receives configuration information through a configuration register; The configuration information includes one or more combinations of enable bit, counter mode bit, address overflow handling mode bit, interval trigger period, pointer update frequency, memory base address, memory space size, starting address offset, and dump step size.

[0024] According to a second aspect of the present disclosure, a performance monitoring and counting method is provided, applied in a processor supporting multi-task parallel processing, the processor including independent performance monitoring slave units configured in at least two different computing modules to be performed analyzed, and a performance monitoring master unit for uniformly managing all the performance monitoring slave units; the method includes: Each performance monitoring unit independently counts the performance events generated during the runtime of the associated computing module to be analyzed, and generates corresponding counting results. In response to the count result output requests from each of the performance monitoring slave units, the performance monitoring master unit performs unified management and, based on a predetermined address mapping method, stores the count results from different performance monitoring slave units separately in the target cache unit via the system bus according to the count result output requests.

[0025] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a processor; and a memory storing computer-readable instructions that, when executed by the processor, implement the performance monitoring and counting method of the second aspect.

[0026] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the performance monitoring and counting method of the second aspect.

[0027] The technical solutions provided in this disclosure may have the following beneficial effects: The performance monitoring and counting method in the example embodiments of this disclosure, on the one hand, configures performance monitoring slave units separately in different chip partitions of the processor, and allows each performance monitoring slave unit to independently count the performance events generated by its associated computing modules. This makes the collection of performance events no longer dependent on the accumulation method of a shared global counter, but rather recorded in a source-isolated manner. This allows performance events generated during the operation of parallel tasks to be clearly distinguished according to module affiliation, avoiding the problem of unclear mixed data sources caused by shared performance counting in related technologies. Thus, when analyzing processor load distribution and locating performance bottlenecks, judgments can be made based on clear structured source information, improving the mapping accuracy of performance monitoring data to actual operating behavior. On the other hand, the performance monitoring master unit uniformly manages the output requests of counting results from multiple performance monitoring slave units and maps them according to a predetermined address method. This method writes statistical results from different sources to the target cache unit via the system bus, enabling multi-source statistical data to present an ordered and partitioned organizational structure during the write process. This reduces data conflicts and overwrite risks during parallel writing, ensuring the traceability of statistical results in both time and space dimensions. This improves data consistency and real-time performance in high-frequency or fine-grained acquisition scenarios. Furthermore, by decoupling the counting and writing behaviors in the architecture, the statistical needs of a single module will not interfere with the operation of other modules, nor will the monitoring structure itself introduce additional scheduling burdens. This reduces resource contention caused by performance monitoring activities on the normal task scheduling of the processor, allowing the monitoring system to maintain stable operating overhead and monitoring capabilities under multi-task parallel conditions. This enhances the availability and adaptability of the overall system in high-parallelism, large-scale task scenarios.

[0028] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0029] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0030] Figure 1 A schematic diagram illustrating the composition of a performance monitoring and counting device according to some embodiments of the present disclosure is shown.

[0031] Figure 2 The diagram illustrates the composition of a performance monitoring slave unit according to some embodiments of the present disclosure.

[0032] Figure 3 The diagram illustrates the composition of a performance monitoring main unit according to some embodiments of the present disclosure.

[0033] Figure 4 A schematic flowchart of a performance monitoring and counting method according to some embodiments of the present disclosure is shown.

[0034] Figure 5 The schematic diagram illustrates the structural schematic of a computer system of an electronic device according to some embodiments of the present disclosure.

[0035] Figure 6 A schematic diagram of a computer-readable storage medium according to some embodiments of the present disclosure is shown.

[0036] In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts. Detailed Implementation

[0037] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this specification as detailed in the appended claims.

[0038] The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of this specification. The singular forms “a,” “the,” and “the” as used in this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0039] It should be understood that although the terms first, second, third, etc., may be used in this specification to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this specification, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0040] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this disclosure. However, those skilled in the art will recognize that the technical solutions of this disclosure can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this disclosure.

[0041] Furthermore, the accompanying drawings are for illustrative purposes only and are not necessarily drawn to scale. The block diagrams shown in the drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0042] In this example embodiment, a performance monitoring and counting device is first provided. This performance monitoring and counting device can be applied to a processor that supports multi-task parallel processing, such as a graphics processor or a central processing unit. This embodiment does not make any special limitations on this. Figure 1 A schematic diagram illustrating the composition of a performance monitoring and counting device according to some embodiments of the present disclosure is shown. Reference Figure 1 As shown, the performance monitoring and counting device 100 may include at least two performance monitoring slave units 110 and a performance monitoring master unit 120, wherein: At least two performance monitoring slave units 110 are associated with the computing modules to be analyzed in each chip partition of the processor. Each performance monitoring slave unit 110 is used to independently count the performance events generated by its associated computing modules and generate corresponding count results.

[0043] Among them, the performance monitoring slave unit refers to an independent monitoring circuit unit distributed across multiple chip partitions within the processor, each used to monitor the computing modules within that chip partition that require performance analysis. The performance monitoring slave unit is a local monitoring function block instantiated for a specific computing module, with each chip partition as the unit. The configuration of the performance monitoring slave unit is based on the concept of distributed acquisition, placing the monitoring function close to the computing module itself, enabling it to directly receive performance event signals output by the computing module.

[0044] Each performance monitoring slave unit can receive a set of performance event indicator bits using digital circuitry. When any performance event bit is valid, the corresponding counting mechanism within the performance monitoring slave unit can incrementally update the performance event count. To adapt to the performance monitoring needs of different chip partitions, the internal structure of the performance monitoring slave unit can be configurable based on the number of events. For example, different widths of event input line groups (N bits) can be selected based on the number of events in the computing module to be analyzed, and a corresponding number of event processing paths can be arranged internally to ensure that each performance event can be recorded independently. Through a distributed arrangement, each performance monitoring slave unit can physically isolate performance events at the hardware level, preventing signal interference between the statistical behaviors of different chip partitions, thereby enhancing the independence and clarity of the statistical data.

[0045] The performance monitoring slave unit can employ a clock-edge triggered synchronous counter to sample and accumulate input performance event signals cycle by cycle; alternatively, it can use an asynchronous counting structure to handle asynchronously arriving event pulses. Once the performance monitoring slave unit has completed the accumulation of performance events, it generates a count result output request when its internal triggering conditions are met. The generation of the count result output request can be based on the coordinated operation of monitoring the internal counting state, identifying the triggering conditions, and controlling the output timing. For example, the performance monitoring slave unit can generate a data write request signal by monitoring the internal counter reaching a certain threshold or detecting a valid control edge from an external trigger signal. The count result output request can be represented by a standard interface signal, such as a valid level signal, a handshake protocol signal, or a register-based write flag. The choice of which depends on the processor's internal interconnect structure, and this embodiment does not impose any special limitations on this.

[0046] The performance monitoring master unit 120 is communicatively connected to at least two performance monitoring slave units 110. It is used to receive and manage counting result output requests from at least two performance monitoring slave units 110, and to distinguish and store the counting results in the target cache unit through the system bus based on the counting result output requests.

[0047] The performance monitoring master unit, acting as a centralized data flow control module for managing multiple performance monitoring slave units, receives and manages count result output requests from at least two slave units. As the data aggregation point for these slave units, the master unit is responsible for scheduling output requests, organizing write operations, and managing the spatial layout of write results. The master unit operates based on centralized arbitration and unified storage management. By listening to output requests from all slave units, it sorts the count result data from different sources to determine which data is ready for the write phase.

[0048] In some optional implementations, the performance monitoring master unit may integrate a request buffer queue, an arbitrator, address mapping logic, and a write controller; this embodiment does not impose any special limitations on this. The request buffer queue is used to temporarily store data signals simultaneously reported by multiple slave units, while the arbitrator can select the specific write order based on arbitration strategies such as polling, fixed priority, and dynamic priority to ensure that data write operations do not block during multi-task concurrency. The address mapping logic is used to plan the write addresses of the target cache space according to a preset storage layout, and the write controller is responsible for generating legitimate write transactions through the system bus to ensure that the counting results are correctly written to the target cache unit. Through centralized management by the performance monitoring master unit, it can be ensured that statistical results from various sources are written in a structured manner, and data conflicts caused by simultaneous writes from multiple performance monitoring slave units can be avoided, maintaining the continuity and traceability of the data storage structure.

[0049] After the performance monitoring master unit completes arbitration and write scheduling, the counting results from different performance monitoring slave units can be stored separately in the target cache unit via the system bus according to a predetermined address mapping method. Separate storage means that the data from each performance monitoring slave unit occupies non-overlapping areas in the storage space, making its storage boundaries clear and its source identifiable. Address mapping can be based on a statically or dynamically configured storage layout. By reserving specific address ranges for each performance monitoring slave unit, writes do not need to share the same storage location with other sources. In practical implementation, a linear mapping method can be used to allocate continuous areas to each performance monitoring slave unit, or a straddle layout method can be used to provide balanced bandwidth usage for concurrent writes. Alternatively, a multi-level address generation logic can be used to dynamically calculate the target address based on the performance monitoring slave unit number and write batch; this embodiment does not impose any special limitations on this approach. This separate storage structure allows the subsequent system to directly locate the corresponding source area when reading statistical results, reducing the inference steps during data parsing and improving data access efficiency. Simultaneously, it enhances the scalability of the performance analysis system under large-scale parallel task conditions.

[0050] After differentiating and storing data from different performance monitoring slave units, the performance monitoring master unit can transmit the counting results to the target cache unit via the system bus in a standard data transaction format, thus ensuring that the statistical data is ultimately physically stored in a readable cache space. In a specific implementation, the performance monitoring master unit can update the target cache unit by sending a write transaction containing the target address information and the counting results to the system bus. Alternatively, the performance monitoring master unit can also support burst writes or multi-phase writes to improve write bandwidth utilization efficiency when the output data scale of the performance monitoring slave units is large or there are many monitoring dimensions. Since the write operation is uniformly initiated by the performance monitoring master unit and scheduled via the system bus, the entire data write process maintains sequential consistency across different sources and reduces contention for bus bandwidth from multiple sources writing simultaneously, ensuring stable transmission performance even in high-parallelism scenarios.

[0051] The target cache unit refers to the storage area used to store the counting results written by the performance monitoring master unit. For example, the target cache unit can be implemented as an on-chip cache, off-chip memory, or a dedicated statistical buffer inside the processor. This embodiment does not specifically limit the type of the target cache unit. The storage principle of the target cache unit is based on address range partitioning. The performance monitoring master unit writes data according to a preset address mapping method, ensuring that the data of each performance monitoring slave unit is written to non-overlapping address areas. The target cache unit can adopt a row-based, page-based, or block-based storage method to adapt to different granularity data organization requirements. This embodiment does not specifically limit the data organization method within the target cache unit. For example, in one optional implementation, the target cache unit can use fixed-length storage blocks, with the data of each performance monitoring slave unit arranged continuously at fixed-length intervals; in another implementation, a variable-length storage area can be set for each slave unit to adapt to the data scale of different monitoring tasks. By working in conjunction with the main unit, the target cache unit can ensure that data from different sources remains clearly separated at the physical level, thereby avoiding write overwriting or data mixing issues in the shared counting structure, and making the monitoring results more readable and interpretable.

[0052] According to the performance monitoring and counting method in this example embodiment, on the one hand, by configuring performance monitoring slave units separately in different chip partitions of the processor, and enabling each performance monitoring slave unit to independently count the performance events generated by its associated computing modules, the collection of performance events no longer relies on the accumulation method of a shared global counter, but is recorded in a source-isolated form. This allows performance events generated during the operation of parallel tasks to be clearly distinguished according to module affiliation, avoiding the problem of unclear mixed data sources caused by shared performance counting in related technologies. Thus, when analyzing processor load distribution and locating performance bottlenecks, judgments can be made based on clear structured source information, improving the mapping accuracy of performance monitoring data to actual operating behavior. On the other hand, the performance monitoring master unit uniformly manages the output requests of counting results from multiple performance monitoring slave units and maps them according to a predetermined address method. This method writes statistical results from different sources to the target cache unit via the system bus, enabling multi-source statistical data to present an ordered and partitioned organizational structure during the write process. This reduces data conflicts and overwrite risks during parallel writing, ensuring the traceability of statistical results in both time and space dimensions. This improves data consistency and real-time performance in high-frequency or fine-grained acquisition scenarios. Furthermore, by decoupling the counting and writing behaviors in the architecture, the statistical needs of a single module will not interfere with the operation of other modules, nor will the monitoring structure itself introduce additional scheduling burdens. This reduces resource contention caused by performance monitoring activities on the normal task scheduling of the processor, allowing the monitoring system to maintain stable operating overhead and monitoring capabilities under multi-task parallel conditions. This enhances the availability and adaptability of the overall system in high-parallelism, large-scale task scenarios.

[0053] The performance monitoring and counting device in this example embodiment will now be further described.

[0054] In an example embodiment of this disclosure, reference is made to Figure 2 As shown, each performance monitoring slave unit 110 may include at least one performance event accumulator 111, a control signal processor 112, and an output buffer 113, wherein: At least one performance event accumulator 111 is provided for parallel counting of at least one input performance event signal, with each performance event accumulator 111 corresponding to one performance event. A performance event accumulator is a counting circuit used to perform parallel counting of at least one input performance event signal. The performance event accumulator can provide corresponding counting paths for different performance events, enabling the performance monitoring slave unit to perform simultaneous, independent, and non-interfering statistical operations on multiple performance events at the hardware level.

[0055] The performance event accumulator can employ an accumulation structure composed of digital adders and sample performance event signals from the computing module via a clock drive. When the performance event signal is active, the accumulator increments the count value corresponding to that performance event; when the signal is inactive, the count remains unchanged. To ensure counting accuracy, the accumulator can use synchronous counting, triggering accumulation at the clock edge to maintain a consistent statistical rhythm across different performance events. In some applications, performance events may be in pulse form; in this case, the accumulator can also support pulse edge detection to correctly record events even with extremely short pulse durations. Furthermore, to enhance counting stability and handle high-frequency event input, an optional approach is to use a two-level buffer structure: the first level detects the event signal, and the second level performs addition accumulation to avoid the impact of combinational logic delays on counting accuracy. The performance event accumulator enables the performance monitoring unit to independently count multiple types of performance events, thereby increasing the dimensionality of performance data and ensuring that statistical results accurately reflect the frequency of different performance behaviors.

[0056] The control signal processor 112 is used to generate start counting, stop counting, and dump commands based on received control signals. The control signal processor can parse external control sources and internally generate control logic signals that directly affect the performance event accumulator and output buffer. Based on edge detection, pattern judgment, and instruction generation of input control signals, the control signal processor can convert external commands into internally recognizable control sequences, enabling the performance monitoring slave unit to execute corresponding counting or dumping behaviors at different operating stages.

[0057] The control signal processor (CSP) can be driven by a combination of combinational and sequential logic. For example, configurable registers can store the current operating mode, edge detectors can identify valid transitions in control signals, and adders or state machines can generate complete control command sequences. In a specific implementation, the CSP can put the performance event accumulator into a running state after detecting a start counting command; stop the accumulator upon receiving a stop counting command; and trigger the output buffer to read the current accumulation result upon receiving a dump command. To adapt to different system architectures with varying control signal input methods, the CSP can support multi-source control signals and determine the final command to be executed based on priority rules. In another optional implementation, the CSP can support asynchronous control signal input, eliminating input jitter across clock domains through a synchronous circuit module, thus stabilizing the control command generation process. By coordinating the performance event accumulator and output buffer through the CSP, the performance monitoring unit can start counting, dump data, and stop counting as needed, thereby improving the timing controllability of the counting chain.

[0058] Output buffer 113 is used to cache the current count result of at least one performance event accumulator 111 when a dump command is triggered. The output buffer provides a transitional data storage space for the performance monitoring slave unit, isolating the counting behavior of the performance event accumulator from subsequent data write behavior, thereby preventing the counting behavior from being affected by write delays. The current count value in the performance event accumulator can be read and stored in the output buffer when the dump command is valid, allowing the performance event accumulator to continue counting without being limited by the bandwidth of the output phase.

[0059] The output buffer can be a register array, static random access memory (SRAM), or other memory structures capable of fast write and read operations. In specific implementations, the output buffer can have data areas arranged in performance event index order, allowing performance event counting results to be written to the corresponding locations in a fixed format; it can also have a queue structure to support fast caching for multiple dumps. In another optional implementation, the output buffer can complete data transmission with the performance monitoring master unit through a handshake mechanism. That is, the output buffer sends a data preparation signal to the performance monitoring master unit when data preparation is complete, and the performance monitoring master unit sends back a receive signal when ready to receive data, thus ensuring a stable transmission rhythm during the data writing process. By configuring the output buffer, the performance monitoring slave unit can complete the output of counting results without interrupting the performance event accumulator's statistical behavior, thereby enhancing the continuity and stability of the monitoring link.

[0060] Within the performance monitoring slave unit, a clear data flow relationship is established between at least one performance event accumulator, a control signal processor, and an output buffer. This ensures that the reception, counting, triggering control, and temporary storage of performance events form a complete and controllable statistical chain. The performance event accumulator is responsible for continuously accumulating performance events from the calculation modules to be analyzed. The control signal processor is responsible for applying control actions to the performance event accumulator and the output buffer at different operating stages. The output buffer, after the control signal processor issues a dump command, temporarily stores the counting results and prepares them for subsequent writing. Through the close cooperation of these three sub-modules, the performance monitoring slave unit can capture performance events in a single cycle, achieve stable accumulation over multiple consecutive cycles, and completely dump the current statistical value when necessary, providing the performance monitoring system with accurate and clearly sourced counting result data.

[0061] By setting at least one performance event accumulator, control signal processor, and output buffer in the performance monitoring slave unit, the performance monitoring slave unit can receive performance events, execute counting, manage control commands, and temporarily store counting results in a hardware-level parallel manner. This structurally separates the event acquisition path from the result output path, thereby improving the stability of performance event acquisition, reducing the probability of data loss in high event density scenarios, and ensuring consistency of counting behavior under different control sequences.

[0062] In an example embodiment of this disclosure, reference is made to Figure 2 As shown, the performance monitoring and counting device 100 also includes a central control signal generator 140 and a local register 150. The central control signal generator 140 and the local register 150 are communicatively connected to the control signal processor 112 and are used to generate and broadcast a unified global control signal. The control signals received by the control signal processor 112 include the global control signal from the central control signal generator 140 and / or control information generated based on the configuration of the local register 150.

[0063] The central control signal generator is a control circuit module deployed within the processor system, used to simultaneously issue control commands to multiple performance monitoring slave units. The central control signal generator provides a unified timing reference for the entire performance monitoring system, enabling multiple performance monitoring slave units to receive consistent control signals at the same time, without relying on individual software configuration of each slave unit. Based on a centralized configuration register and triggering logic, the central control signal generator generates control signals containing start counting, stop counting, and dump instructions by having the user or upper-level software write configuration content into the central register. In its implementation, the central control signal generator may include a configurable register array, an edge-triggered detector, a signal broadcast network, and clock generation logic. When the control field in the configuration register changes, the central control signal generator identifies the transition of the control bit through edge detection circuitry and generates a global control signal with strict time boundaries. This global control signal can be broadcast to all performance monitoring slave units via a control signal processor, ensuring a consistent control entry point for the entire monitoring system.

[0064] The global control signals generated by the central control signal generator can include multiple signal lines for initiating counting, ending counting, and triggering dump operations. Specifically, these can include enable signals and dump trigger signals. The enable signal determines whether the performance monitoring slave unit has entered the counting state, while the dump trigger signal instructs the performance monitoring slave unit to perform a dump operation on the current counting result. The global control signals can be generated based on control fields written by the user to the central register. The difference between the old and new values ​​is compared to detect the presence of rising or falling edges, thereby triggering the corresponding control signal transition. This method establishes a timing correspondence with the control signal processors within the performance monitoring slave units, enabling multiple performance monitoring slave units to synchronously perform counting state switching or data dump operations at the same time. This improves the synchronization and consistency of the monitoring system and reduces statistical deviations caused by different modules receiving control commands at different times.

[0065] Within the performance monitoring slave unit, the control signals received by the control signal processor can include global control signals from the central control signal generator and / or control information generated based on local register configuration. This multi-source control mode enables the performance monitoring slave unit to execute commands based on control information from both sources, thus forming a flexible cooperative relationship between global collaborative control and local personalized control. The control signal processor can identify the current control source through internal control logic and select the final control instruction to be executed according to priority rules. In specific implementations, the control signal processor can adopt a priority arbitration mechanism, that is, when a valid transition of the global control signal exists, it is executed as the highest priority signal; when no global control signal input exists, the control field configured in the local register is parsed and the corresponding command is executed. This approach ensures that in scenarios requiring globally consistent control, the global control signal can cover all monitoring instances, while the local register configuration can still play a role when individual modules need to be debugged separately, thereby enhancing the flexibility of the monitoring system.

[0066] The control information generated by the local register configuration can come from the configuration registers bound to the performance monitoring slave unit. These registers can be read and written by software through the control interface. The control information may include command fields for starting counting, stopping counting, triggering dumps, etc., and may also include operating mode configuration fields, enabling the performance monitoring slave unit to execute different statistical rhythms according to different experimental needs. This embodiment does not specifically limit the specific content of the control information. The mode parsing logic in the control signal processor can determine the time window and valid conditions for command generation based on the contents of the configuration registers. For example, when manual triggering of statistics is required, the control signal processor can output the corresponding command according to the timing of the software writing to the register; when multiple rapid triggering of dumps is required, dump commands can be frequently output according to the operating mode configured in the register. By establishing a coordination mechanism between the local registers and the global control signals, the performance monitoring slave unit can operate efficiently under different levels of control strategies.

[0067] After receiving the global control signal, the control signal processor (CSP) uses internal edge detection logic to identify whether a valid rising or falling edge exists in the global control signal. When a global control signal shows an edge change corresponding to the start of counting, the CSP generates an internal command to enable the performance event accumulator; when a global control signal shows an edge change corresponding to the stop of counting, it generates an internal command to disable the performance event accumulator; and when a global control signal shows an edge change corresponding to a dump operation, it outputs an internal command to trigger the output buffer to read the current count value of the performance event accumulator. By converting the transition characteristics of the global control signal into local control commands, the CSP ensures that all performance monitoring slave units perform counting behavior switching or dumping behavior at the same time, thereby improving the synchronization of the entire performance monitoring system and ensuring that statistical results across partitions have consistent timing boundaries.

[0068] By adding a central control signal generator and broadcasting global control signals to all performance monitoring slave units, the performance monitoring system can form a unified time base and control command source among multiple performance monitoring slave units. This enables the counting start, stop, and dump operations of different performance monitoring slave units to have consistent timing characteristics, thereby improving the synchronization of cross-chip partition monitoring tasks and reducing the deviation of monitoring results in time alignment.

[0069] In one example embodiment of this disclosure, the central control signal generator can output at least two global control signals, which may include an enable signal and a command signal; the control signal processor generates a start counting or stop counting command by detecting the edge of the enable signal, and generates a dump command by detecting the edge of the command signal.

[0070] The enable signal output by the central control signal generator is a control signal used to indicate whether the performance monitoring slave unit has entered the counting state. The enable signal can be represented as a single-bit level value, providing a global counting switch for the entire performance monitoring system. This allows each performance monitoring slave unit to synchronize its counting start / stop operation without requiring independent configuration, instead using a unified signal. The enable signal maps the user-configured control state to a stable 0 / 1 output, ensuring that multiple performance monitoring slave units receive completely consistent level values ​​in the on-chip interconnect structure. In specific implementations, the enable signal can be generated by the control bit of the configurable register CR_CSG_CTRL. When the control bit is 1, the central control signal generator drives a high level on its output pin, causing all performance monitoring slave units to recognize that counting has started; when the control bit is 0, it drives a low level, causing all performance monitoring slave units to recognize that counting has stopped. Optionally, to avoid false triggering caused by signal jitter, the enable signal can be stabilized using a Schmitt trigger, hysteresis circuit, or clock synchronization circuit to improve its anti-interference capability in large-scale broadcast environments.

[0071] The command signal output by the central control signal generator is a control signal used to trigger each performance monitoring slave unit to perform a count result dump operation. The command signal can be in the form of a single-bit pulse. Its principle is to issue a unified dump action instruction to all performance monitoring slave units by detecting level transitions. This command signal can be generated using an edge-triggered register. When the user writes a 1 to the command field, the central control signal generator generates a brief pulse signal through edge detection logic and automatically restores the initial value in the next clock cycle. This command signal generation method ensures that each register write operation corresponds to only one valid pulse, thereby enabling multiple performance monitoring slave units to perform consistent dump operations at the same time, avoiding the problem of repeated triggering due to a static command signal level. Alternatively, the command signal can be generated periodically using a hardware timer, allowing the performance monitoring slave units to perform dump operations at fixed periods, suitable for continuous monitoring scenarios.

[0072] By distinguishing global control signals into enable signals and command signals and using edge detection technology to differentiate between start counting, stop counting, and dumping behavior, global control signals can have clear trigger boundaries at the hardware level. This improves the anti-interference capability of the control path, reduces false triggering caused by excessive signal duration or signal jitter, and makes the monitoring process more controllable and easier to manage in a unified manner.

[0073] In one example embodiment of this disclosure, the operating modes of the control signal processor include an event-triggered mode and an interval-triggered mode; in the event-triggered mode, the dump command can be triggered by configuration of a local register; in the interval-triggered mode, the dump command is automatically triggered according to the configured interval period.

[0074] The operating mode refers to the specific method or approach adopted by the control signal processor when performing signal processing. Different operating modes are used to limit the conditions under which the control signal processor generates dump commands, as well as the triggering source and triggering rhythm of the dump commands. By configuring the operating mode, the performance monitoring unit can adopt different data dumping mechanisms in different monitoring scenarios. For example, the operating modes of the control signal processor can include at least event-triggered mode and interval-triggered mode. Of course, other types of operating modes can also be set according to the actual situation. This embodiment does not make any special limitations on this.

[0075] Event-triggered mode refers to a runtime mode where a trigger field configured in a local register serves as the trigger condition for a dump operation. This allows users to directly control the dump behavior by writing to the local register. Event-triggered mode can be based on edge detection generated by register write operations. When a user writes a trigger value to the corresponding register via software, the edge detection circuit inside the control signal processor detects the change in the register content and generates a valid dump command. In specific implementations, event-triggered mode can be implemented using a single-bit trigger field. For example, bit 0 in the register can be used as the dump trigger field; writing "1" indicates executing a dump command, and the field is automatically cleared in the next cycle to avoid repeated triggering. Alternatively, event-triggered mode can support writing any value as trigger; any write to the register is considered a trigger event, and the control signal processor performs internal logic parsing to generate a trigger command. Application scenarios for event-triggered mode can include debugging phases, discrete event monitoring phases, or scenarios where users need to manually request a dump operation without interrupting program execution. This embodiment is not limited to these scenarios.

[0076] Interval-triggered mode refers to the operating mode where the control signal processor (CSP) automatically triggers a dump command according to a configured interval period. This allows performance monitoring units to perform dump operations at a fixed time rhythm without external events or manual configuration intervention. Interval-triggered mode can be implemented based on internal counters or timer logic. Specifically, the CSP contains a time counter for accumulating clock cycles. When the accumulated number of cycles reaches the interval period configured in the local register, a dump command is automatically generated, and then the counter is cleared and restarted. In a specific implementation, this internal counter can be a synchronous counter with a width of N bits, the bit width of which is determined by the maximum configurable monitoring period. For example, when updating the counter with a 1MHz clock, if the interval period is configured to 1000, it means a dump operation is triggered every 1000 clock cycles. Alternatively, interval-triggered mode can be implemented using an on-chip timer module to reduce the resource consumption within the CSP and improve timing accuracy.

[0077] The coexistence of event-triggered and interval-triggered modes gives the control signal processor (SSP) high flexibility, enabling it to adapt to different monitoring granularities and control methods. To ensure no logical conflict between the two modes, the SSP can be configured with a mode selection field. Users can choose between event-triggered and interval-triggered modes via a local register, and the SSP determines the execution path of its internal logic based on this field. In complex scenarios, the SSP can also support a priority strategy: when both event-triggered and interval-triggered modes meet their triggering conditions, event-triggered mode takes precedence to ensure that user-initiated trigger commands are not delayed.

[0078] By introducing two types of triggering mechanisms—event-triggered mode and interval-triggered mode—into the control signal processor, the performance monitoring unit can adapt to the triggering requirements of different monitoring scenarios. This allows the system to perform accurate sampling based on event triggering in event-intensive scenarios and stable data collection based on interval periods in periodic sampling scenarios. This improves the flexibility of monitoring tasks and enhances the system's adaptability to different task types.

[0079] In one example embodiment of this disclosure, when the control signal processor receives a global control signal from the central control signal generator, it ignores the trigger mode configured in the local register and directly generates a command based on the global control signal.

[0080] The control signal processor (CSP) ignores the triggering mode configured in the local registers after recognizing a global control signal, and can do so based on a control priority arbitration mechanism. This arbitration mechanism can be implemented internally within the CSP, using a priority register or hard-wired priority logic to specify that the global control signal has a higher priority than the control information generated by the local register configuration. When a valid transition of the global control signal is detected, the arbitration logic within the CSP masks all triggering conditions from the local registers, including event-triggered and interval-triggered modes, thus ensuring that local triggering modes and global control signals do not occur concurrently.

[0081] After the control signal processor ignores the trigger mode configured in the local register, its internal command generation module directly generates the corresponding command signal based on the global control signal type. When the global enable signal generates a rising edge, the command generation module outputs a start counting command; when the global enable signal generates a falling edge, it outputs a stop counting command; and when the global command signal transitions, it outputs a dump command. In this mode, the control signal processor does not refer to the mode field, interval period field, or event trigger field in the local register, nor does it execute the internal period counter or trigger register detection logic. The command generation module's method of generating commands based on global signals ensures that all performance monitoring slave units perform consistent counting behavior switching and dumping behavior at the same time.

[0082] By ignoring the trigger mode of local register configuration when performance monitoring receives central control signals from the unit, global instructions are given priority. This ensures that critical monitoring tasks or system-level scheduling signals can be executed accurately under any local configuration, enabling the monitoring system to maintain a unified instruction chain under multi-source configuration conditions and reducing inconsistencies in monitoring behavior caused by configuration conflicts.

[0083] In an example embodiment of this disclosure, reference is made to Figure 3 As shown, the performance monitoring master unit 120 may include an arbitrator 121, which can be used to poll and arbitrate write requests from at least two performance monitoring slave units to obtain an arbitration result that includes the order in which the calculation results are written, and write the counting result to the target cache unit through the system bus based on the arbitration result.

[0084] In this system, when multiple performance monitoring slave units generate count result output requests within the same time window, the arbitrator determines the service order of write requests using a unified scheduling rule, ensuring that the system bus is not driven by multiple performance monitoring slave units simultaneously at the same time. The arbitrator's working principle can be based on a round-robin arbitration algorithm, which is essentially a sequential traversal method. That is, the arbitrator maintains an internal polling pointer, which points to different performance monitoring slave units in a fixed order and advances continuously during the clock cycle. Whenever a write request is found from a corresponding performance monitoring slave unit, the arbitrator selects that request as the current service object, thereby achieving fair scheduling of write requests.

[0085] For example, the arbitrator may internally include a request detection module, a polling pointer module, a priority management module, and a write control module. The request detection module monitors all performance monitoring slave units for valid write requests, and its input is connected to the write request signal of each performance monitoring slave unit. The polling pointer module cycles through the performance monitoring slave units in a clock-driven manner, prioritizing the write requests of the slave unit it points to. The priority management module assists in dynamically adjusting priorities in special scenarios; for example, after serving the same performance monitoring slave unit for several consecutive cycles, the polling pointer can be manually adjusted to prevent resources from being occupied by a single source for an extended period. The write control module is responsible for generating a system bus transaction containing the target address, write data, and write control signals after the arbitrator makes a scheduling decision, ensuring that the counting result can be successfully written to the target cache unit.

[0086] In its implementation, polling arbitration can be achieved through a hardware adder in conjunction with a register. The polling pointer register stores the current performance monitoring slave unit number. During polling, the register content is incremented, wrapping back to zero when the maximum number is reached, forming a circular traversal. When the performance monitoring slave unit pointed to by the polling pointer has a write request, the arbitrator immediately selects that request and triggers the write control module to execute the write transaction; when the pointed-to performance monitoring slave unit does not have a write request, the polling pointer continues to move forward until the next valid request is found.

[0087] In another optional approach, the arbitrator can implement weighted round-robin arbitration, assigning different service weights to different performance monitoring slave units. For example, the service weight of performance monitoring slave units with high-frequency monitoring tasks can be increased, increasing their frequency of appearance in the arbitration process; while the weight of performance monitoring slave units with less monitoring content can be reduced to ensure overall resource utilization efficiency. Weighted round-robin arbitration can achieve a proportional distribution of service frequency by inserting multiple identical pointers in the polling cycle, which is particularly suitable for scenarios where multiple performance monitoring slave units have significantly different output frequencies. In yet another optional approach, the arbitrator can support preemptive arbitration, whereby when a critical performance monitoring slave unit makes a high-priority write request, the arbitrator interrupts the current polling process to immediately serve the high-priority source, ensuring the timeliness of critical task monitoring.

[0088] After executing the write request scheduling, the arbitrator can write the counting result to the target cache unit via the system bus. The system bus can adopt an on-chip interconnect protocol, such as the Advanced Dextensible Interface (AXI) or the Advanced High-Performance Bus (AHB) protocol, and can complete the write transfer operation through address channels, data channels, and handshake signals. When constructing a write transaction, the counting result stored in the performance monitoring slave unit's output buffer can be used as the write data, the starting address of the storage area allocated to the performance monitoring slave unit in the target cache unit can be used as the write address, and a write enable signal and transaction attribute field can be attached to enable the system bus to recognize the transaction and execute the write in the target cache unit.

[0089] To avoid system bus access conflicts, the arbiter performs a bus idle check before the write control module generates a write transaction. This check determines whether the system bus is currently idle. If the system bus is occupied by another master device, the arbiter must postpone the write operation until the system bus becomes idle. To prevent write requests from being lost due to waiting, the arbiter can internally set up a queue or write request register to cache write requests that have not yet been served by the system bus, ensuring that the counting results are not lost due to bus congestion.

[0090] By setting an arbitrator in the performance monitoring master unit and polling and arbitrating write requests from multiple performance monitoring slave units, the sequentiality and fairness of write transactions can be ensured in high-parallelism scenarios, avoiding system bus congestion caused by write conflicts, making the writing process of counting results more stable, and enabling monitoring data to maintain predictable write timing even in highly competitive environments.

[0091] In one example embodiment of this disclosure, the performance monitoring master unit is configured to write the counting results of different performance monitoring slave units into non-overlapping address regions in the target cache unit according to a predetermined address mapping method, so as to achieve differentiated storage.

[0092] The predetermined address mapping method refers to the allocation strategy used to determine the storage area for the counting results of each performance monitoring slave unit within the target cache unit. The predetermined address mapping method, through a fixed or configurable storage layout, allows the counting results of each performance monitoring slave unit to be written to an independent and clearly defined address range, enabling subsequent software to directly locate the data based on the source index or partitioning rules.

[0093] The predetermined address mapping method can be implemented through the unique numbering of the performance monitoring slave units. For example, the performance monitoring master unit can maintain the numbers of each performance monitoring slave unit, such as consecutive numbers starting from 0. By multiplying the performance monitoring slave unit number by a fixed step size or a configurable step size, the starting address of the region of that performance monitoring slave unit in the target cache unit is obtained. To implement this address calculation process, the performance monitoring master unit can implement adders, multipliers, or shift logic in hardware so that the final generated target address can cover contiguous storage space without overlap. In one optional method, the predetermined address mapping method can adopt a static segmentation method, that is, reserving a fixed length of storage area for each performance monitoring slave unit; in another optional method, a dynamic segmentation method can be adopted, that is, the region length is dynamically configured by software or firmware according to the scale of the monitoring task. This embodiment does not impose any special limitations on this.

[0094] Non-overlapping address regions within the target cache unit refer to independent physical address ranges allocated to different performance monitoring slave units. These physical address ranges can be defined by a preset starting address and region length. Non-overlapping address regions ensure that data written to each performance monitoring slave unit will not overwrite or modify data belonging to other performance monitoring slave units, thus ensuring that differentiated storage exists not only in logical allocation but also in the physical storage structure. To ensure non-overlapping regions, the performance monitoring master unit must guarantee that the address range calculated for each performance monitoring slave unit does not intersect with the ranges of other performance monitoring slave units in the address mapping method.

[0095] In an optional implementation, the predetermined address mapping method can be a page-based mapping method, which divides the target cache unit into multiple fixed pages, each page being the same size. The performance monitoring master unit allocates a specific set of pages to the performance monitoring slave unit based on its performance monitoring slave unit number. The page-based mapping method has the advantages of fast location and flexible expansion, and can be applied to scenarios where the write frequencies of different performance monitoring slave units vary greatly.

[0096] By writing the counting results from different performance monitoring units into non-overlapping address regions based on a predetermined address mapping method, the performance monitoring master unit can ensure that the data from each source remains completely isolated in the storage space, thereby avoiding the risk of data overwriting. This allows the parsing software to clearly distinguish the monitoring results from different chip partitions or modules, making the monitoring data structure clearer and more scalable.

[0097] In one example embodiment of this disclosure, for the same performance monitoring slave unit, the performance monitoring master unit writes the count results dumped at different times into consecutive address regions or address regions with fixed step intervals in the target cache unit according to a predetermined address increment rule, so as to achieve differentiated storage of different batches of data in the same unit.

[0098] The predetermined address increment rule refers to the hardware logic rule used by the performance monitoring master unit to determine the next storage address when writing multiple batches of count results to the same performance monitoring slave unit. This can establish a storage layout similar to a "data timeline" for the same performance monitoring slave unit, ensuring that each count result dump corresponds to a unique address in the target cache unit. The address increment rule can be implemented based on recording the write position of the previous batch and calculating the new address using a fixed offset. For example, after a write transaction is completed, the performance monitoring master unit records the current write address in an internal address register. When the next write transaction is triggered, a preset step value is added to the contents of this register to generate the next write address, thus achieving sequential address increment.

[0099] When the address increment rule is set to continuous write mode, meaning the predetermined address increment rule uses a method of successively accumulating the actual length of the count result, the performance monitoring master unit will store each batch of count results adjacent to each other, so that all batches of data form a contiguous storage area in the target cache unit. In this mode, the storage efficiency of the count results is high, and it is suitable for count result structures with fixed format and fixed length. In the hardware implementation, the performance monitoring master unit must ensure that the contiguous address space does not exceed the address range reserved for the performance monitoring slave unit. To achieve this, a region boundary detector can be added to the increment logic to block the write operation or trigger a software processing flow when the range boundary is about to be exceeded.

[0100] When the address increment rule is set to fixed step interval mode, meaning each write position increments by a fixed offset, the performance monitoring master unit will arrange the count results in a fixed-interval structure. For example, when the fixed step is set to 8 bytes and the count result is 4 bytes, a 4-byte gap will be maintained between write positions. This mode can be used in scenarios where space needs to be reserved between data to store additional fields, such as timestamps, checksums, batch identifiers, or other metadata. In the specific implementation, the performance monitoring master unit can automatically maintain default values ​​(such as 0 padding) in the gap areas during write transactions to ensure clear boundaries during data reading.

[0101] The performance monitoring software arranges the count results from different batches within the same unit into a continuous or fixed-step storage structure in the target cache unit. This allows the software to directly locate any batch of data during reading by simply adding an offset. For example, in continuous write mode, the performance analysis software can directly locate the data based on the batch number multiplied by the count result length; in fixed-step mode, the performance analysis software can calculate the target address based on the batch number multiplied by the step size. This storage structure reduces parsing logic, improves data processing efficiency, and allows the monitoring results to present a clear time-series structure in subsequent analysis stages.

[0102] By using address increment rules to write different batches of counting results to the same performance monitoring unit at continuous or fixed step intervals, monitoring data from the same source can form a storage layout with a time-series structure. This allows software to locate any batch of monitoring data based on offset at low cost, improving the availability of monitoring data in time-series analysis, trend judgment, and batch aggregation analysis.

[0103] In an example embodiment of this disclosure, reference continues to be made to Figure 2 As shown, each performance monitoring slave unit 110 may also include a dump address calculator 114, which can be used to dynamically calculate the target memory address corresponding to each dump operation based on the configured base address, starting address offset and dump step size.

[0104] The base address in the dump address calculator refers to the starting physical address of the target cache unit address space allocated to the performance monitoring slave unit. It provides a fixed storage area entry point for the performance monitoring slave unit, ensuring that all target memory addresses generated by dump operations are offset based on this address. The base address can be written to the performance monitoring slave unit via a configuration register and initialized after the performance monitoring slave unit is reset or before a monitoring task switch. The base address can be set using direct register loading, where the performance analysis software writes the physical address to the base address register, and the performance monitoring slave unit reads the register contents for subsequent calculations. Alternatively, the base address can be generated collaboratively with the system bus address mapping module, automatically matching it to a fixed window in a complex address space, enhancing system consistency.

[0105] The starting address offset is an initial offset relative to the base address, used to define the starting position for writing the first batch of count results. The starting address offset allows performance monitoring slave units to adjust the position of the first batch of data within their allocated area, for example, to reserve a fixed length of space for other structured data, such as metadata, pointer fields, or check fields. In a specific implementation, the starting address offset can be stored in an offset register and added to the base address using an adder to obtain the starting target memory address for the first batch. The starting address offset can be configured by the performance analysis software, or in some application scenarios, it can be preset by hardware to a fixed value, thus avoiding the need for software to reinitialize the offset parameters at runtime.

[0106] The dump step size is used to calculate the increment value of the target memory address corresponding to consecutive dump operations. It can build the storage interval between batches for the performance monitoring slave unit, so that the count results of each batch have a clear and regular arrangement in the target cache unit. The dump step size can make the target memory address of each dump obtained by adding a fixed increment to the previous address, thereby building a batch serialized data structure. The dump step size can be pre-written into the configuration register, or it can be automatically set by the performance monitoring slave unit according to the type of count result. For example, when the count result is a fixed-length structure, the dump step size can be equal to the length of the structure. In another optional approach, the dump step size can be automatically adjusted according to external constraints, such as cache line alignment requirements, such as aligning to a 64-byte boundary, thereby improving the system's memory access efficiency.

[0107] The dump address calculator can calculate the target memory address based on the formula "base address + starting address offset + (dump count × dump step size)". For example, it can calculate the virtual address written for each performance calculation result. The performance monitoring main unit can calculate the actual target memory address written for each dump based on the configured base address, offset address, and the interval between each counter result dump. This can be achieved using the following formula: dump_address_nth = base_address + start_address_offset + dump_stride×n; Here, dump_address_nth can represent the target memory address corresponding to each dump operation, base_address can represent the base address of the memory to be written, start_address_offset can represent the offset address of the memory to be written, dump_stride can represent the interval of each counter result dump, i.e., the dump step size, and n can represent the number of dumps between the start of counting and the stop of counting.

[0108] The performance monitoring slave unit can internally include a dump counter register to record the number of dumps currently executed. The dump address calculator reads the value of this counter register, multiplies it by the dump step size or calculates the offset increment using a shift-address method, and then adds it to the base address and the starting address offset to obtain the target memory address for the current batch. In this way, the performance monitoring slave unit can generate the corresponding target memory address on the fly each time a dump operation is triggered, without the intervention of the performance monitoring master unit, thereby simplifying the performance monitoring slave unit logic and reducing system bus contention.

[0109] By using the base address, starting address offset, and dump step size to dynamically calculate the target memory address in the dump address calculator, the performance monitoring slave unit can independently complete the storage address planning. This reduces the addressing burden on the performance monitoring master unit, allows the monitoring system to be expanded in a modular manner, and enables different monitoring tasks to dynamically adjust the storage layout through configuration registers, thereby improving the flexibility and adjustability of the storage structure.

[0110] In one example embodiment of this disclosure, the dump address calculator is further configured to execute a wraparound mode or a stop mode when the calculated target memory address exceeds the configured memory space range; in the wraparound mode, the target memory address wraps back to the configured base address and continues dumping; in the stop mode, the counting stops and an address overflow error is reported.

[0111] In wrapback mode, the dump address calculator can wrap back the target memory address to the configured base address and continue dumping after detecting that the target memory address exceeds the configured memory space range. Wrapback mode can use the storage space allocated by the performance monitoring unit in a cyclic manner, allowing the counting results to be updated over an overlay within a limited address range. Wrapback mode can be based on modulo operation logic; that is, when the current address is detected to be greater than the maximum available address, the current address is set as the base address. This means the address register in the dump address calculator is reloaded with the contents of the base address register, causing the generated next target memory address to start again from the beginning of the address range.

[0112] In its implementation, the wraparound mode can be achieved by setting an address comparator and an address selector within the dump address calculator. The comparator compares the currently calculated target memory address with the upper bound of the configured memory space range. When the comparison result indicates that the address is out of bounds, the address selector selects the base address as the new write address and writes this address to the address register. When the next dump operation is triggered, the dump address calculator can continue to execute the address increment logic based on the wrapped address. In an optional approach, the wraparound mode can be used in conjunction with a counting result overwrite strategy. That is, when new data is written to the original area, the old data is overwritten, thereby constructing a sliding window monitoring structure so that the latest monitoring data is always retained in the storage range. To improve the flexibility of the wraparound mode, it is also possible to support configuring the wraparound trigger point. For example, the wraparound start point can be pre-set in the configuration register, which is not necessarily fixed to the base address, but rather to a certain offset address. In this case, the wrapped write address will be set to this offset address, thereby enabling the construction of more diverse cyclic write modes within the same storage range.

[0113] In stop mode, the dump address calculator stops counting and reports an address overflow error when it detects that the target memory address exceeds the configured memory space range. Stop mode ensures storage safety priority, preventing the overwriting of other performance monitoring units' storage areas or other critical data within the system due to address out-of-bounds errors in scenarios where strict retention of historical counting results for each batch is required.

[0114] In specific hardware implementations, the stop mode can send a stop signal to the counting control path via out-of-bounds detection logic, preventing the control signal processor inside the performance monitoring slave unit from generating new dump commands, or having them directly masked by the dump address calculator after generation. Simultaneously, the performance monitoring slave unit's status reporting module can write an address space overflow flag to the status register, allowing subsequent readings of the status to determine whether the current monitoring task needs to be terminated or reconfigured. Alternatively, the stop mode can be used in conjunction with an error recovery strategy. For example, by clearing the error flag in the status register and reconfiguring the base address, starting address offset, and dump step size, the system can restart the monitoring task after manual confirmation.

[0115] The performance monitoring unit includes an internal mode selection register for configuring the current address overflow handling mode. After calculating the target memory address, the dump address calculator reads the contents of this mode selection register to determine whether to perform a wraparound or stop action upon exceeding the limit. Through the mode selection register, the system can switch between different task requirements in a configurable manner; for example, selecting wraparound mode for long-running tasks and stop mode for critical monitoring tasks.

[0116] By executing either wraparound mode or stop mode when an address goes out of bounds, the dump address calculator gains boundary protection capabilities. Wraparound mode creates a stable circular buffer structure within a limited space, while stop mode ensures that critical monitoring data is not overwritten, thereby enhancing system storage security and enabling monitoring software to determine whether sampling integrity or space configuration needs adjustment based on the out-of-bounds behavior.

[0117] In one example embodiment of this disclosure, the counting mode of the performance event accumulator may include a relative counting mode or an absolute counting mode. In the relative counting mode, the counting result of the corresponding performance event accumulator is cleared to zero after each dump operation is completed. In the absolute counting mode, the counting result of the performance event accumulator remains unchanged after the dump until it is cleared to zero after a stop counting command is received.

[0118] The relative counting mode refers to the performance event accumulator automatically clearing its current count after each dump operation and restarting the accumulation in the next cycle. Relative counting mode allows each batch of counts to reflect only the performance event increment between two dumps, thus enabling the capture of short-cycle, high-frequency performance changes. The principle of relative counting mode is based on the linkage between dump and clear actions: when a dump command is triggered and the count result is written to the target cache unit, the performance event accumulator clears the contents of the accumulator register through an internal reset path, causing subsequent counting to start from zero. The performance event accumulator can be implemented in hardware through clearing logic; that is, when the dump completion signal is valid, the corresponding memory unit of the accumulator is written to zero and the event accumulation function is re-enabled.

[0119] In its implementation, the relative counting mode can be achieved by a control signal processor sending a clear control signal to the performance event accumulator. This control signal processor generates a clear pulse upon detecting a dump completion signal from the dump address calculator or output buffer, synchronously clearing the registers inside the performance event accumulator. To avoid count loss during high-frequency events, the clear pulse can be synchronized before and after the clock edge. For example, by setting a status latch in the performance event accumulator, the clear operation can be executed in the next clock cycle after the dump is completed, ensuring that the clear operation does not conflict with the event accumulation pulse.

[0120] Absolute counting mode means that the performance event accumulator maintains its count after a dump operation until a stop counting command is received, at which point it is reset to zero. Absolute counting mode allows the count to reflect the cumulative number of performance events from the start of monitoring to the dump time, making it suitable for long-term monitoring or trend analysis tasks. Absolute counting mode can switch the storage of count results from a short-term incremental mode to a long-term cumulative mode, enabling the monitoring system to extract trends in event density changes over a longer time window.

[0121] In hardware implementation, absolute counting mode can be achieved by disabling the clear control path in the control signal processor. For example, when the control signal processor detects that the current counting mode is absolute counting mode through the configuration register, it deactivates the clear pulse generation logic, ensuring that the performance event accumulator retains its original count value after performing a dump operation. Subsequently, upon receiving a stop counting command, the control signal processor re-enables the clear path, restoring the accumulator to its initial state after the monitoring cycle ends.

[0122] The relative counting mode and absolute counting mode can be flexibly switched according to actual monitoring needs. For example, in short-time-slice resource contention analysis scenarios, the relative counting mode can be used to record event increments between different time slices; in long-term performance trend monitoring or power consumption modeling scenarios, the absolute counting mode can be used to obtain cumulative statistical data. The performance monitoring slave unit can select the above two modes by configuring the counting mode bit in the configuration register, so that the performance event accumulator maintains consistent behavior in different task stages, thereby improving the configurability and adaptability of the monitoring system.

[0123] By providing both relative and absolute counting modes, the performance event accumulator can adapt to both short-cycle differential analysis and long-term cumulative monitoring scenarios. This enables the monitoring results to be interpretable under different application requirements, improves the generalization ability of the monitoring system under different task characteristics, and reduces the burden of additional data processing on the software side.

[0124] In one example embodiment of this disclosure, the performance monitoring slave unit is further configured to generate dump pointer information, which includes the number of dumps and a last dump completion flag; the performance monitoring master unit writes the dump pointer information together with or separately from the counting result into the target cache unit.

[0125] The dump count in the dump pointer information is a counter variable used internally by the performance monitoring slave unit to record the number of dump operations performed within the current monitoring period. An incrementing counter reflects the stage progress of the dump process, giving the dump actions sequence information for constructing a batch data structure. The dump count can be implemented based on a synchronously incrementing counter structure. Specifically, the dump count register inside the performance monitoring slave unit increments once whenever the output buffer inside the performance monitoring slave unit completes a dump of the count result, or when the dump address calculator generates a target memory address and sends a write request to the performance monitoring master unit.

[0126] In a specific implementation, the dump count register can be constructed using a synchronous adder structure. The dump completion signal is sampled and incremented by one at the rising edge of the system clock to achieve strict alignment of the dump batch. Alternatively, the dump count can be constructed using an asynchronous counting structure, which triggers the count increment immediately when the dump completion signal arrives to reduce clock synchronization delay and improve the timeliness of dump count recording.

[0127] The last dump completion flag in the dump pointer information indicates whether the most recent dump operation of the performance monitoring slave unit has been successfully completed. This flag is typically a single-bit status variable used to identify the availability of the latest batch count result in the target cache unit. The last dump completion flag is generated in the status register inside the performance monitoring slave unit when the output buffer successfully writes the count result to the performance monitoring master unit, or when the performance monitoring master unit confirms the completion of the write transaction. The last dump completion flag remains valid until the next dump begins, and is cleared or updated to a new state after the next dump command is triggered, ensuring that the completion status of each dump operation can be accurately identified.

[0128] In the specific implementation, the final dump completion flag can be implemented using a dedicated status trigger. This trigger receives a write completion handshake signal from the performance monitoring master unit during the write path and updates its status via the rising edge of this signal. Simultaneously, this trigger is automatically reset when the dump command is generated, ensuring it accurately reflects whether subsequent dumps were successfully executed.

[0129] The performance monitoring master unit writes the dump pointer information and the counting results together or separately to the target cache unit, thus forming a structured monitoring data layout. When the performance monitoring master unit receives a write request from the performance monitoring slave unit, it can integrate the dump count, the last dump completion flag, and the count results of this batch into a continuous data structure and write it to the target cache unit together in a single write transaction, making it uniform in storage physical format, which is convenient for subsequent batch parsing with a fixed step size. Optionally, the performance monitoring master unit can allocate an independent address area for the dump pointer information and write it separately through independent write transactions, so that the counting results and pointer information remain independent in storage structure but are associated through address relationship, allowing the two parts to be read separately during debugging and error analysis.

[0130] By generating dump pointer information and writing it into the target cache unit, each dump operation is equipped with a batch identifier and completion status, which makes the monitoring data form clear boundary markers in structure. This can improve the accuracy of batch location during data parsing and enable the system to judge situations such as missing monitoring data and abnormal interruptions, thereby improving the traceability and reliability of monitoring tasks.

[0131] In one optional embodiment, the performance monitoring slave unit triggers a write of dump pointer information after completing a specified number of dump operations, according to the configured pointer update frequency; and / or triggers a write of dump pointer information after receiving a stop counting command and completing the last dump operation.

[0132] The pointer update frequency is an integer parameter set in the configuration register, defining how many dump operations the performance monitoring slave unit generates a dump pointer information after each dump operation. The pointer update frequency can be parameterized and periodically controlled, allowing the dump pointer information to reflect the dynamic behavior of the monitoring process at a fixed time interval. This enables the software to obtain the staged monitoring status with low overhead when reading monitoring data. The pointer update frequency can be based on a modulo-counting structure, where the performance monitoring slave unit maintains a counter bound to the number of dumps. When "dump count mod pointer update frequency = 0", the system triggers a pointer information write operation.

[0133] Upon receiving a stop counting command and completing the final dump operation, the performance monitoring slave unit can trigger a write operation to the dump pointer. This ensures that the monitoring system can record the final dump count and the completion status of the last dump before termination, thus providing complete boundary information for the monitoring results. After capturing the stop counting command, the performance monitoring slave unit blocks subsequent event accumulation paths and performs a necessary dump operation before terminating the counting, allowing the accumulated value not yet written to the counter to be written to the target cache unit. Subsequently, after the final dump operation is completed, the performance monitoring slave unit immediately generates a pointer information write request to record this termination boundary.

[0134] The write operation of the dump pointer information can be carried out in the same channel as the count result, that is, the performance monitoring slave unit integrates the dump pointer information with the current batch count result and sends it to the performance monitoring master unit through the same write request; or an independent write channel can be used to write the dump pointer information to the target cache unit with high priority, so as to avoid the dump pointer information being delayed due to write delay when dumping frequently.

[0135] By periodically writing pointer information based on the pointer update frequency and forcibly writing the final pointer information when the stop counting command arrives, the monitoring system can form effective status records during both the running and ending processes. This enhances the observability of the monitoring progress, allows the software to clearly define the boundaries of the monitoring interval, and improves the ability to judge the integrity of the monitoring data.

[0136] In an optional embodiment of this disclosure, the performance monitoring slave unit may further include a status reporting module, which may be used to write the running status and error status into a status register; the running status and error status include one or more combinations of the last dump completion flag, dump command overlap flag, counter overflow flag and address space overflow flag.

[0137] The status reporting module is a hardware logic unit within the performance monitoring unit used to manage status information. It captures runtime events, boundary events, and error events that occur during the execution of monitoring tasks, converts them into structured information fields, and writes them to the status register. When a certain status condition is triggered during the monitoring process, the internal status detector of the status reporting module identifies the event and writes the corresponding flag bit into the status register, thereby enabling the status register to continuously reflect the current running status of the monitoring task.

[0138] A status register is a special register used to store running and error states. Its structure can contain multiple bit fields, each corresponding to a status flag. Status registers can express different state combinations through bit-level encoding, allowing different status information to appear independently or in combination. Status registers can be read-write registers; the current state can be determined by reading the register's contents, and certain status flags can be cleared by writing to the register when necessary, thereby restoring the monitoring task to its normal operating path.

[0139] The last dump complete flag indicates whether the most recent count result dump has been successfully completed; the dump command overlap flag indicates that a new dump command is triggered before the previous dump process has been fully completed; the counter overflow flag indicates that the value of the performance event accumulator exceeds the range that its register can represent; the address space overflow flag indicates that the target memory address generated by the dump address calculator exceeds the range of the allocated memory space.

[0140] By recording information such as the last dump completion status, dump command overlap, counter overflow, and address space overflow through the status reporting module, the performance monitoring unit can provide real-time status feedback during operation. This enables the system to identify potential anomalies in a timely manner at the software layer and take corrective measures, thereby improving the stability, security, and diagnosability of the monitoring task.

[0141] In an optional embodiment of this disclosure, the performance monitoring slave unit can receive configuration information through a configuration register; the configuration information may include one or more combinations of enable bit, counter mode bit, address overflow handling mode bit, interval trigger period, pointer update frequency, memory base address, memory space size, starting address offset, and dump step size.

[0142] The configuration register is a set of hardware registers within the performance monitoring slave unit used to store configuration information. It can store parameters required for monitoring task execution through a read-write register structure, enabling the performance monitoring slave unit to control its own behavior by reading the contents of these registers during runtime. The configuration register can be bound to a software programming interface via the system bus or internal control path, allowing performance analysis software to write parameter values ​​to the register during initialization or runtime and influence the behavior of the monitoring system.

[0143] The enable bit is a configuration field used to control whether the performance monitoring slave unit enters the working state; the counting mode bit is used to select the counting mode of the performance event accumulator; the address overflow handling mode bit is used to select whether the dump address calculator should execute wraparound mode or stop mode when encountering an address out of bounds; the interval trigger cycle is used to set the cycle of the control signal processor executing dump commands in interval trigger mode; the pointer update frequency is used to set the cycle of generating dump pointer information; the memory base address is used to set the starting address of the physical storage area allocated by this performance monitoring slave unit in the target cache unit; the memory space size is used to set the range of storage areas that can be written; the starting address offset is used to determine the position of the first dump write, providing an offset to the base address, making the initial write position flexible, and reserving space for metadata or other structures; the dump step size is used to set the address spacing between consecutive batches, so that the counting results of different batches have a regular layout.

[0144] By configuring registers to provide performance monitoring units with parameters such as enable control, counting behavior mode configuration, overflow handling strategy, triggering method, and storage planning, the monitoring behavior can be highly configurable at the hardware level. This can improve the system's adaptability to multi-task, multi-module heterogeneous monitoring scenarios and make the monitoring system more flexible in deployment, tuning, and expansion.

[0145] It should be noted that although several modules or units of the performance monitoring and counting device have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0146] Furthermore, in this example embodiment, a performance monitoring and counting method is also provided. This method can be applied to a processor that supports multi-task parallel processing. The processor may include at least two performance monitoring slave units and a performance monitoring master unit for unified management of all performance monitoring slave units. (Refer to...) Figure 4 As shown, this performance monitoring and counting method may include: Step S410: Each performance monitoring slave unit independently counts the performance events generated during the runtime of the associated computing module to be analyzed, and generates corresponding counting results. Step S420: In response to the count result output requests from each of the performance monitoring slave units, the performance monitoring master unit performs unified management and, based on a predetermined address mapping method, stores the count results from different performance monitoring slave units separately in the target cache unit via the system bus according to the count result output requests.

[0147] The specific details of each step in the performance monitoring and counting method described above have been described in detail in the corresponding performance monitoring and counting device, so they will not be repeated here.

[0148] It should be noted that although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0149] Furthermore, in an exemplary embodiment of this disclosure, an electronic device capable of implementing the performance monitoring and counting method described above is also provided.

[0150] Those skilled in the art will understand that various aspects of this disclosure can be implemented as a system, method, or program product. Therefore, various aspects of this disclosure can be embodied in the following forms: a completely hardware embodiment, a completely software embodiment (including firmware, microcode, etc.), or an embodiment combining hardware and software aspects, collectively referred to herein as a "circuit," "module," or "system."

[0151] The following reference Figure 5 To describe an electronic device 500 according to such an embodiment of the present disclosure. Figure 5 The electronic device 500 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0152] like Figure 5 As shown, the electronic device 500 is presented in the form of a general-purpose computing device. The components of the electronic device 500 may include, but are not limited to: at least one processing unit 510, at least one storage unit 520, a bus 530 connecting different system components (including storage unit 520 and processing unit 510), and a display unit 540.

[0153] The storage unit stores program code that can be executed by the processing unit 510, causing the processing unit 510 to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure. For example, the processing unit 510 can perform actions such as... Figure 4 In step S410, each performance monitoring slave unit independently counts the performance events generated during the runtime of the associated computing module to be analyzed, and generates corresponding count results. In step S420, in response to the count result output request from each performance monitoring slave unit, the performance monitoring master unit performs unified management and, according to a predetermined address mapping method, stores the count results from different performance monitoring slave units in the target cache unit through the system bus based on the count result output request.

[0154] Storage unit 520 may include readable media in the form of volatile storage units, such as random access memory (RAM) 521 and / or cache memory (Cache) 522, and may further include read-only memory (ROM) 523.

[0155] Storage unit 520 may also include a program / utility 524 having a set (at least one) program module 525, such program module 525 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0156] Bus 530 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0157] Electronic device 500 can also communicate with one or more external devices 570 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 500, and / or with any device that enables electronic device 500 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 550. Furthermore, electronic device 500 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 560. As shown, network adapter 560 communicates with other modules of electronic device 500 via bus 530. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 500, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0158] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0159] In exemplary embodiments of this disclosure, a computer-readable storage medium is also provided, on which a program product capable of implementing the methods described above is stored. In some possible embodiments, various aspects of this disclosure may also be implemented as a program product including program code that, when the program product is run on a terminal device, causes the terminal device to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure.

[0160] refer to Figure 6 As shown, a program product 600 for implementing the above-described performance monitoring and counting method according to an embodiment of the present disclosure is described. This product may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the program product of the present disclosure is not limited thereto. In this document, a readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0161] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0162] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0163] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0164] Program code for performing the operations of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0165] Furthermore, the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of this disclosure and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0166] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0167] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the claims.

[0168] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A performance monitoring and counting device, characterized in that, The device, used in a processor that supports multi-task parallel processing, includes: At least two performance monitoring slave units are provided, each of which is associated with a computing module to be analyzed in each chip partition of the processor. Each performance monitoring slave unit is used to independently count the performance events generated by its associated computing module and generate corresponding count results. The performance monitoring master unit is communicatively connected to the at least two performance monitoring slave units, and is used to receive and manage the counting result output requests from the at least two performance monitoring slave units, and to distinguish and store the counting results in the target cache unit through the system bus based on the counting result output requests.

2. The apparatus according to claim 1, characterized in that, Each of the aforementioned performance monitoring slave units includes: At least one performance event accumulator is used to count at least one input performance event signal in parallel, with one performance event accumulator corresponding to each performance event; A control signal processor is used to generate start counting, stop counting, and dump commands based on received control signals. An output buffer is used to cache the current count result of the at least one performance event accumulator when the dump command is triggered.

3. The apparatus according to claim 1 or 2, characterized in that, The performance monitoring and counting device also includes: A central control signal generator, which is communicatively connected to the control signal processor, is used to generate and broadcast a unified global control signal. The control signals received by the control signal processor include global control signals from the central control signal generator and / or control information generated based on local register configuration.

4. The apparatus according to claim 3, characterized in that, The central control signal generator outputs at least two global control signals, the at least two global control signals including an enable signal and a command signal; The control signal processor generates a start or stop counting command by detecting the edge of the enable signal, and generates a dump command by detecting the edge of the command signal.

5. The apparatus according to claim 3, characterized in that, The operating modes of the control signal processor include event-triggered mode and interval-triggered mode; In the event-triggered mode, the dump command is triggered by local register configuration; In the interval-triggered mode, the dump command is automatically triggered according to the configured interval period.

6. The apparatus according to claim 5, characterized in that, When the control signal processor receives a global control signal from the central control signal generator, it ignores the trigger mode configured in the local register and directly generates a command based on the global control signal.

7. The apparatus according to claim 1, characterized in that, The performance monitoring master unit includes an arbitrator, which is used to poll and arbitrate write requests from at least two performance monitoring slave units to obtain an arbitration result that includes the writing order of the calculation results, and write the counting result to the target cache unit through the system bus based on the arbitration result.

8. The apparatus according to claim 1, characterized in that, The performance monitoring master unit is configured to write the counting results of different performance monitoring slave units into non-overlapping address regions in the target cache unit according to a predetermined address mapping method, so as to achieve differentiated storage.

9. The apparatus according to claim 1 or 8, characterized in that, For the same performance monitoring slave unit, the performance monitoring master unit writes the count results dumped at different times into the target cache unit in a continuous address region or at fixed step intervals according to a predetermined address increment rule, so as to achieve differentiated storage of different batches of data in the same unit.

10. The apparatus according to claim 1 or 2, characterized in that, Each of the aforementioned performance monitoring slave units further includes: The dump address calculator is used to dynamically calculate the target memory address for each dump operation based on the configured base address, starting address offset, and dump step size.

11. The apparatus according to claim 10, characterized in that, The dump address calculator is also used to execute wraparound mode or stop mode when the calculated target memory address exceeds the configured memory space range; In the wraparound mode, the target memory address wraps back to the configured base address and continues to be dumped; In the stop mode, the counting stops and an address overflow error is reported.

12. The apparatus according to claim 2, characterized in that, The performance event accumulator includes either a relative counting mode or an absolute counting mode. In the relative counting mode, after each dump operation is completed, the count result of the corresponding performance event accumulator is cleared to zero; In the absolute counting mode, the count result of the performance event accumulator remains unchanged after dumping until it is cleared to zero upon receiving a stop counting command.

13. The apparatus according to claim 1, characterized in that, The performance monitoring unit is also used to generate dump pointer information, which includes the number of dumps and a last dump completion flag. The performance monitoring master unit writes the dump pointer information and the counting result together or separately into the target cache unit.

14. The apparatus according to claim 13, characterized in that, The performance monitoring unit, according to the configured pointer update frequency, triggers a write of the dump pointer information after each specified number of dump operations; and / or After receiving the stop counting command and completing the last dump operation, the dump pointer information is written once.

15. The apparatus according to claim 1, characterized in that, The performance monitoring unit also includes: The status reporting module is used to write the running status and error status into the status register; The running status and error status include one or more of the following: last dump completion flag, dump command overlap flag, counter overflow flag, and address space overflow flag.

16. The apparatus according to claim 1, characterized in that, The performance monitoring unit receives configuration information through a configuration register; The configuration information includes one or more combinations of enable bit, counter mode bit, address overflow handling mode bit, interval trigger period, pointer update frequency, memory base address, memory space size, starting address offset, and dump step size.

17. A performance monitoring and counting method, characterized in that, The method is applied to a processor that supports multi-task parallel processing, the processor including a performance monitoring and counting device as described in any one of claims 1-16, the performance monitoring and counting device including at least two performance monitoring slave units and a performance monitoring master unit for uniformly managing all the performance monitoring slave units; the method includes: Each performance monitoring unit independently counts the performance events generated during the runtime of its associated computing module to be analyzed, and generates corresponding counting results. In response to the count result output requests from each of the performance monitoring slave units, the performance monitoring master unit performs unified management and, based on a predetermined address mapping method, stores the count results from different performance monitoring slave units in the target cache unit through the system bus according to the count result output requests.

18. An electronic device, characterized in that, include: processor; as well as A memory storing computer-readable instructions that, when executed by the processor, implement the performance monitoring and counting method as described in claim 17.

19. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the performance monitoring and counting method as described in claim 17.

Images