Method, apparatus and computer device for analyzing chip performance

Abstract

This disclosure provides a method, apparatus, computer device, computer-readable storage medium, and computer program product for analyzing chip performance, relating to the field of digital integrated circuits. The method includes: obtaining a configuration file; parsing the configuration file to split a data path to obtain multiple functional units traversed by the data flow; generating a hardware monitor based on the multiple functional units; testing the chip; detecting multiple performance events occurring during the chip testing; recording event data of the performance events in response to the detection of performance events; and calculating chip performance metrics based on the event data and the configuration file for analysis, including: calculating unit performance metrics for each functional unit; and identifying and marking performance bottlenecks in the data path based on the unit performance metrics of the functional units, enabling precise quantification of the performance of each functional unit in the data path and automatic identification of performance bottlenecks in the data path.

Description

Technical Field

[0001] This disclosure relates to the field of integrated circuits, particularly to the field of chip testing, and especially to methods, apparatus, computer equipment, computer-readable storage media, and computer program products for analyzing chip performance. Background Technology

[0002] In the design and verification of complex chips (such as high-performance computing, AI accelerators and communication processors), precise performance debugging and bottleneck analysis of specific internal data paths are crucial to ensuring that the final chip performance meets the standards.

[0003] In the design and verification of complex chips (such as high-performance computing, AI accelerators, and communication processors), existing technologies mainly rely on discrete, manually configured performance monitoring points. Users must manually insert numerous independent performance counters or breakpoints into the Register Transfer Level (RTL) code based on their understanding of the data flow path to capture the state of specific signals during specific clock cycles. Subsequently, massive amounts of waveform or log data are collected through simulation or hardware prototyping. Then, using scripts or manual methods, these discrete data points are painstakingly correlated to piece together a complete timing and throughput profile of the data flow spanning multiple clock domains and functional modules.

[0004] Traditional methods suffer from the following significant drawbacks: They are complex and error-prone to configuration. For example, users must have a deep understanding of the interface protocols and internal state machines of each module, manually writing extensive monitoring logic. Furthermore, the configuration process is cumbersome and prone to overlooking key monitoring points or making configuration errors, leading to data failure. They also suffer from poor analytical correlation. For instance, there is a lack of automatic and accurate correlation mechanisms between the output events of upstream modules and the input events of downstream modules. Analysts need to manually compare the log timestamps of different modules, which is difficult and error-prone in complex multi-clock domain systems, making it difficult to accurately calculate the transmission delay between modules. Due to the discrete and fragmented nature of the data, there is a lack of a global view of the entire path, making it difficult to systematically identify key bottleneck modules limiting overall performance, often relying on user experience for guesswork and trial and error. Finally, they are inefficient and non-reusable. For example, each adjustment to the data path structure or change in monitoring requirements requires extensive manual configuration and analysis, hindering rapid response to architecture iterations and resulting in long debugging cycles and high costs. Summary of the Invention

[0005] This disclosure provides methods, apparatus, computer devices, computer-readable storage media, and computer program products for analyzing chip performance.

[0006] According to one aspect of this disclosure, a method for analyzing chip performance is provided. The method includes: obtaining a configuration file, which defines a reference clock signal, a source signal for triggering the performance event, a trigger condition type, a target trigger count, and a data path for each of a plurality of performance events to be monitored, wherein the target trigger count indicates an upper limit on the number of times the performance event can be triggered, the trigger condition type indicates the signal type that triggers the performance event, and the data path indicates the transmission path of the complete internal data flow of the chip; parsing the configuration file to split the data path to obtain a plurality of independent functional units through which the internal data flow of the chip passes; and generating one or more hardware monitors based on the plurality of independent functional units, wherein the one or more hardware monitors... This includes generating corresponding input and / or output monitors for each functional unit; testing the chip; detecting multiple performance events occurring during chip testing using one or more hardware monitors; recording event data of the detected performance event using one or more hardware monitors in response to the detection of any one of the multiple performance events; and calculating and analyzing chip performance metrics based on the recorded event data and configuration files, including: calculating unit performance metrics for each functional unit based on the recorded event data and configuration files, where unit performance metrics include input latency, output latency, and unit utilization; and identifying and marking performance bottlenecks in the data path based on the unit performance metrics of multiple independent functional units.

[0007] In some embodiments, the trigger condition types include signal rising edge triggering, signal falling edge triggering, signal high level triggering, and signal low level triggering.

[0008] In some embodiments, the event data includes an event start timestamp, an event end timestamp, and a clock cycle, wherein the event start timestamp is a timestamp recorded when the detected performance event is first triggered, and the event end timestamp is a timestamp recorded when the number of times the detected performance event is triggered reaches the target trigger count.

[0009] In some embodiments, the chip's performance metrics include at least one of the following: event duration, number of effective clock cycles, number of idle cycles, utilization, average latency, and bandwidth.

[0010] In some embodiments, the configuration file further defines at least one monitoring phase, each monitoring phase having a corresponding test time period and each monitoring phase corresponding to at least one hardware monitor among one or more hardware monitors. The method further includes: when testing the chip, according to the at least one monitoring phase, activating or deactivating at least one hardware monitor corresponding to the monitoring phase within the test time period corresponding to each monitoring phase.

[0011] According to another aspect of this disclosure, an apparatus for analyzing chip performance is provided. The apparatus includes: an acquisition module configured to acquire a configuration file, the configuration file defining a reference clock signal, a source signal for triggering the performance event, a trigger condition type, a target trigger count, and a data path for each performance event among a plurality of performance events to be monitored; a parsing module configured to parse the configuration file to split the data path, obtaining a plurality of independent functional units traversed by the internal data flow of the chip; and a generation module configured to generate one or more hardware monitors based on the plurality of independent functional units, wherein the one or more hardware monitors include generating a corresponding input monitor and / or input monitor for each functional unit. The system includes: an output monitor; a test module configured to test the chip; an event detection module configured to detect multiple performance events occurring during chip testing using one or more hardware monitors; a data acquisition module configured to record event data of the detected performance event using one or more hardware monitors in response to the detection of any one of the multiple performance events; and a performance calculation module configured to calculate and analyze the chip's performance metrics based on the recorded event data and configuration files. The performance calculation module includes: a unit performance calculation module configured to calculate unit performance metrics for each functional unit based on the recorded event data and configuration files, including input latency, output latency, and unit utilization; and an identification module configured to identify and mark performance bottlenecks in the data path based on the unit performance metrics of multiple independent functional units.

[0012] According to another aspect of this disclosure, a computer device is provided, comprising: at least one processor; and a memory having a computer program stored thereon, wherein the computer program, when executed by the at least one processor, causes the at least one processor to perform the methods provided above in this disclosure.

[0013] According to another aspect of this disclosure, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, causes the processor to perform the methods provided above in this disclosure.

[0014] According to another aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, causes the processor to perform the methods as provided above in this disclosure.

[0015] According to one or more embodiments of this disclosure, complex data paths are automatically broken down into independent functional units. Through modular performance analysis, the performance of each functional unit in the data path can be accurately quantified, and performance bottlenecks in the data path can be automatically identified.

[0016] These and other aspects of this disclosure will be apparent from the embodiments described below, and will be elucidated with reference to the embodiments described below. Attached Figure Description

[0017] The accompanying drawings exemplify embodiments and form part of the specification, serving together with the textual description to explain exemplary implementations of the embodiments. The illustrated embodiments are for illustrative purposes only and do not limit the scope of this disclosure. Throughout the drawings, the same reference numerals refer to similar but not necessarily identical elements.

[0018] Figure 1 This is a flowchart illustrating a method for analyzing chip performance according to an exemplary embodiment.

[0019] Figure 2 This is a schematic diagram illustrating an example of a structured report in a method for analyzing chip performance according to an exemplary embodiment.

[0020] Figure 3 This is a block diagram illustrating an apparatus for analyzing chip performance according to an exemplary embodiment.

[0021] Figure 4 An example computer device is shown in which any of the embodiments described herein may be implemented. Detailed Implementation

[0022] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0023] In this disclosure, unless otherwise stated, the use of terms such as "first," "second," etc., to describe various elements is not intended to limit the positional, temporal, or importance relationships of these elements; such terms are merely used to distinguish one element from another. In some examples, the first element and the second element may refer to the same instance of that element, while in other cases, based on the context, they may refer to different instances.

[0024] The terminology used in the description of the various examples described in this disclosure is for the purpose of describing particular examples only and is not intended to be limiting. Unless the context explicitly indicates otherwise, an element may be one or more unless the number of elements is specifically limited. As used herein, the term "multiple" means two or more, and the term "based on" should be interpreted as "at least partially based on". Furthermore, the terms "and / or" and "at least one of..." cover any one of the listed items and all possible combinations thereof.

[0025] In the design and verification of complex chips (such as high-performance computing, AI accelerators, and communication processors), existing technologies mainly rely on discrete, manually configured performance monitoring points. Users must manually insert numerous independent performance counters or breakpoints into the Register Transfer Level (RTL) code based on their understanding of the data flow path to capture the state of specific signals during specific clock cycles. Subsequently, massive amounts of waveform or log data are collected through simulation or hardware prototyping. Then, using scripts or manual methods, these discrete data points are painstakingly correlated to piece together a complete timing and throughput profile of the data flow spanning multiple clock domains and functional modules.

[0026] Traditional methods suffer from the following significant drawbacks: They are complex and error-prone to configuration. For example, users must have a deep understanding of the interface protocols and internal state machines of each module, manually writing extensive monitoring logic. Furthermore, the configuration process is cumbersome and prone to overlooking key monitoring points or making configuration errors, leading to data failure. They also suffer from poor analytical correlation. For instance, there is a lack of automatic and accurate correlation mechanisms between the output events of upstream modules and the input events of downstream modules. Analysts need to manually compare the log timestamps of different modules, which is difficult and error-prone in complex multi-clock domain systems, making it difficult to accurately calculate the transmission delay between modules. Due to the discrete and fragmented nature of the data, there is a lack of a global view of the entire path, making it difficult to systematically identify key bottleneck modules limiting overall performance, often relying on user experience for guesswork and trial and error. Finally, they are inefficient and non-reusable. For example, each adjustment to the data path structure or change in monitoring requirements requires extensive manual configuration and analysis, hindering rapid response to architecture iterations and resulting in long debugging cycles and high costs.

[0027] The embodiments of this disclosure provide a method for analyzing chip performance. By automatically breaking down complex data paths into independent functional units for modular performance analysis, it can accurately quantify the performance of each functional unit in the data path and automatically identify performance bottlenecks in the data path. This fundamentally solves the problems of complex configuration, poor correlation, difficulty in bottleneck location, and low efficiency of traditional methods. It transforms data path performance debugging from a time-consuming manual task that takes months to complete into an automated and standardized process that can be completed in minutes, greatly improving the efficiency and reliability of chip design verification.

[0028] Figure 1 This is a flowchart illustrating a method 100 for analyzing chip performance according to an exemplary embodiment.

[0029] like Figure 1 As shown, this disclosure proposes a method 100 for analyzing chip performance, including: step S110, obtaining a configuration file, the configuration file defining a reference clock signal, a source signal for triggering the performance event, a trigger condition type, a target trigger count, and a data path for each performance event among multiple performance events to be monitored, wherein the target trigger count indicates the upper limit of the number of times the performance event can be triggered, the trigger condition type indicates the signal type that triggers the performance event, and the data path indicates the transmission path of the complete internal data flow of the chip; step S120, parsing the configuration file to split the data path to obtain multiple independent functional units through which the internal data flow of the chip passes; step S130, generating one or more hardware monitors based on the multiple independent functional units, wherein the one or more hardware monitors include generating for each functional unit. The chip is tested using one or more hardware monitors. Step S140 involves testing the chip. Step S150 involves detecting multiple performance events occurring during chip testing using one or more hardware monitors. Step S160 involves recording event data of the detected performance event using one or more hardware monitors in response to the detection of any one of the multiple performance events. Step S170 involves calculating and analyzing the chip's performance metrics based on the recorded event data and configuration file, including: Step S171 involves calculating the unit performance metrics for each functional unit based on the recorded event data and configuration file, where the unit performance metrics include input latency, output latency, and unit utilization. Step S172 involves identifying and marking performance bottlenecks in the data path based on the unit performance metrics of multiple independent functional units.

[0030] In step S110, a configuration file can be obtained. The configuration file is used to define the reference clock signal, the source signal used to trigger the occurrence of the performance event, the trigger condition type, the target trigger count, and the data path for each performance event among the multiple performance events to be monitored. The target trigger count indicates the upper limit of the number of times the performance event can be triggered, the trigger condition type indicates the signal type that triggers the performance event, and the data path indicates the transmission path of the complete internal data flow of the chip.

[0031] In the example, users can write configuration files, such as cfg.txt, which can use concise key-value pairs or a structured format to explicitly define each performance event to be monitored. The configuration file can define the reference clock signal clk, the source signal trigger_src used to trigger the performance event, the trigger condition type trigger_type, the target trigger count trigger_cnt, and the data path for each of the multiple performance events to be monitored. The target trigger count trigger_cnt indicates the maximum number of times the performance event can be triggered, the trigger condition type trigger_type indicates the type of signal that triggers the performance event, and the data path indicates the complete internal data flow transmission path of the chip.

[0032] In the example, the configuration file can also name the generated monitors for easy identification in the testbench.

[0033] In step S120, the configuration file can be parsed to split the data path and obtain the multiple independent functional units through which the internal data flow of the chip passes.

[0034] In the example, the configuration file can be parsed to obtain each functional unit in the data path (such as the double data rate memory read controller ddr_rd, the write direct memory access controller wdma, etc.).

[0035] In the example, method 100 may also include dynamically calculating and assigning a unique timestamp storage address to each performance event to be monitored as defined in the configuration file.

[0036] In step S130, one or more hardware monitors can be generated based on multiple independent functional units, wherein the one or more hardware monitors include generating a corresponding input monitor and / or output monitor for each functional unit.

[0037] In the example, input monitors and / or output monitors for each functional unit can be automatically generated based on each functional unit obtained from the split. For example, special modules (e.g., the complex addressing of the Last Level Cache (LLC) module required for Double Data Rate Memory (DDR) reads) can also be automatically handled and all monitors can be generated in the end.

[0038] In this example, users no longer need to configure each monitor individually; instead, they can define the complete data path using declarative syntax. For instance, users only need to describe the start and end points of the target data path and the functional units it flows through using declarative syntax, and the system can automatically generate all necessary and precisely associated monitor configurations. For example, a monitor configuration could be a complete, compileable (e.g., compiled during simulation) SystemVerilog wrapper module file, `custom_profiling.sv`. This module instantiates all user-defined `sig_trigger` units (hardware monitors) and integrates a unified control and data dump logic. This logic is responsible for initializing counters at the start of the simulation and automatically writing all event data captured by the hardware monitors to a specified output data file (such as `raw_data.txt`) at the end of the simulation. In simulation-based tests, when dumping data, it is only necessary to call a system function to print information and then write it to the output data file.

[0039] In step S140, the chip is tested.

[0040] In the example, chip testing can be achieved through simulation (such as through emulators VCS, Xcelium) or by running a hardware prototype (when testing with a hardware prototype, the data to be transferred can be written into a memory such as debug SRAM by modifying the dump file inside the custom_profiling module, and then read out for analysis after the hardware prototype test is completed).

[0041] In step S150, multiple performance events that occur during chip testing are detected by one or more hardware monitors.

[0042] In the example, when testing the chip, one or more hardware monitors can continuously detect the trigger_src signal. Once a performance event matching the trigger_type condition is detected, the internal counter of the hardware monitor is incremented by 1 to indicate that a performance event matching the trigger_type condition has been detected.

[0043] In step S160, in response to detecting any one of the multiple performance events, the event data of the detected performance event is recorded by one or more hardware monitors.

[0044] In the example, one or more hardware monitors can generate event data raw_data.txt during the simulation process, recording the detected performance events.

[0045] In step 170, the chip's performance metrics are calculated and analyzed based on the recorded event data and configuration files.

[0046] In the example, the timestamps and period information in the event data raw_data.txt can be read, and the timestamps and period information can be associated with specific performance events according to the configuration file to calculate a series of performance metrics.

[0047] In step 171, based on the recorded event data and configuration files, the unit performance metrics for each functional unit are calculated, including input latency, output latency, and unit utilization.

[0048] In step 172, based on the unit performance indicators of multiple independent functional units, performance bottlenecks in the data path are identified and marked.

[0049] In the example, each individual functional unit requiring performance analysis can be separated using the data path declared in the configuration file (e.g., "ddr_rd → internal bus → PE → wdma"). Subsequently, event data recorded by the hardware monitor during simulation can be read. This data includes the timestamps (start_stamp and end_stamp) captured at the input and output terminals of each functional unit. Combined with information such as the clock period (clk_period) defined in the configuration file, performance metrics for each functional unit can be calculated individually.

[0050] Let's take ddr_rd as an example. As the starting point of the data path, ddr_rd connects to the DDR controller interface at its input and to the internal bus or downstream cache module (such as LLC) at its output. Based on the input and output monitors defined for ddr_rd in the configuration file, two types of timestamps can be extracted from the recorded event data: one is the moment when ddr_rd successfully receives read response data from the DDR (corresponding to the input completion moment), and the other is the moment when ddr_rd forwards the data to the downstream module (corresponding to the output completion moment).

[0051] Based on this, the following unit performance metrics of ddr_rd can be calculated: (1) Input latency. For ddr_rd, input latency refers to the time difference between when ddr_rd initiates a read request and when DDR returns the first valid data. This latency value is calculated by associating the timestamps of the "read request initiation event" and the "read data return event" defined in the configuration file. This metric directly reflects the access response speed of the DDR memory and is a key basis for evaluating memory bottlenecks; (2) Output latency. For ddr_rd, output latency refers to the time difference between when ddr_rd receives data returned by DDR and when the data is successfully transmitted to the downstream module (e.g., LLC or directly to PE). This latency value is calculated by associating the timestamp of the data preparation event inside ddr_rd with the timestamp of the handshake success event of the downstream module. This metric reflects the additional overhead caused by the data caching, format conversion, or flow control logic inside ddr_rd; (3) Unit utilization. The utilization of ddr_rd refers to the proportion of the total number of clock cycles that ddr_rd actually performs in the effective data transmission or processing. The utilization percentage is calculated by dividing the number of successful data handshakes at the output of ddr_rd by the total number of observed cycles. For example, in a simulation of 10,000 clock cycles, if ddr_rd only outputs valid data for 2,000 cycles, and the remaining 8,000 cycles are idle due to waiting for DDR response or downstream backpressure, then its utilization rate is 20%. This metric reveals whether ddr_rd is being fully utilized; a low utilization rate indicates insufficient upstream DDR supply or downstream congestion.

[0052] The performance metrics of the intermediate unit are explained using the Processing Engine (PE) as an example. PE input latency refers to the time difference between data transmission from upstream modules (such as ddr_rd or LLC) to the PE successfully receiving that data. PE output latency refers to the time difference required for the PE to output the result data to downstream modules (such as WDMA) after completing internal calculations. This metric reflects the computational depth and processing efficiency of the PE's internal pipeline. PE utilization refers to the proportion of cycles in which the PE actually performs effective operations such as multiplication and addition out of the total observed cycles. If the PE performs operations in 6,000 cycles out of 10,000 cycles, and the remaining 4,000 cycles are idle while waiting for input data (i.e., bubble cycles), then its utilization rate is 60%. By comparing the 20% utilization rate of ddr_rd with the 60% utilization rate of PE, it can be preliminarily determined that the bottleneck may not be in the PE itself, but rather in the fact that ddr_rd fails to provide sufficient data supply.

[0053] The calculation of end-unit performance metrics is illustrated using the Write Direct Memory Access Controller (WDMA) as an example. WDMA input latency refers to the time difference between the preparation of the calculation result output by the PE and the successful reception of that data by the WDMA. WDMA output latency refers to the average time required for the WDMA to actually write data to DDR; this metric reflects the contention and write efficiency of the DDR write channel. WDMA utilization refers to the proportion of cycles in which the WDMA successfully writes data to DDR out of the total observed cycles. If the WDMA is effectively writing in only 1000 out of 10000 cycles, the utilization rate is 10%, indicating that there may be severe contention in the DDR write bandwidth or that the WDMA write request scheduling strategy needs optimization.

[0054] By calculating the input latency, output latency, and unit utilization of each functional unit, the performance of a complete data path (such as ddr_rd→PE→wdma) can be decomposed into each functional unit, thus providing accurate and modular data support for subsequent bottleneck identification and optimization suggestions.

[0055] Therefore, by automatically breaking down complex data paths into independent functional units for modular performance analysis, it is possible to accurately quantify the performance of each functional unit in the data path and automatically identify performance bottlenecks in the data path.

[0056] In some embodiments, the trigger condition type may include signal rising edge triggering, signal falling edge triggering, signal high level triggering, and signal low level triggering.

[0057] In the example, the trigger condition type can also include other signal types (such as signals with specific waveforms or frequencies), without limitation.

[0058] Therefore, there's no need to write separate RTL code for each trigger type; the monitoring behavior can be specified simply by using a parameter in the configuration file (e.g., `trigger_type=posedge`). When generating the `custom_profiling.sv` module, the corresponding edge detection or level detection logic is automatically instantiated based on this parameter, including necessary synchronizers, filters, and counting circuits, ensuring stable operation under different clock domains and signal jitter conditions. This standardized and configurable design significantly improves the reusability and reliability of the performance monitoring logic, while greatly reducing the workload and error risk of users manually writing monitoring code.

[0059] In some embodiments, event data may include an event start timestamp start_stamp, an event end timestamp end_stamp, and a clock period clk_period, wherein the event start timestamp start_stamp is a timestamp recorded when the detected performance event is first triggered, and the event end timestamp end_stamp is a timestamp recorded when the number of times the detected performance event is triggered reaches the target trigger count.

[0060] In the example, when the detected performance event is triggered for the first time, the hardware monitor can immediately latch the current simulation timestamp (obtained via the $time system function) as start_stamp, and record it along with other information such as clock cycle clk_period to the results file. When the counter reaches the preset trigger_cnt, the hardware monitor can latch the current timestamp as end_stamp, and record it along with other information such as clock cycle clk_period and trigger_cnt to the results file.

[0061] In some embodiments, the chip's performance metrics include at least one of the following: event duration, number of effective clock cycles, number of idle cycles, utilization, average latency, and bandwidth.

[0062] In the example, the event duration can be obtained by subtracting the start_stamp from the end_stamp. The effective clock cycle count `util_cycles` can be calculated based on `duration` and `clk_period`, or provided directly by the monitor. The idle cycle count `bubble_cycles`, also known as bubble cycles, refers to the number of clock cycles in the hardware pipeline that should have been processing valid data but were idle for some reason, with no valid data passing through. Utilization is obtained by dividing the effective working cycle count `util_cycles` by the total observed cycle count `total_observed_cycles`, where the effective working cycle count refers to the clock cycles a module or unit spends processing the data or task it is designed to process. For example, for a PE (processing engine), this refers to the cycles it spends performing multiply-accumulate operations; for a ddr_rd (DDR read controller), this refers to the cycles it spends successfully reading data from DDR (Double Data Rate memory). The total cycle count refers to the total number of clock cycles that elapse during the entire simulation or observation period. The total cycle count can be very long, encompassing various states such as module or unit working, idle, waiting, and blocked. Average latency is a core performance metric that measures the processing speed and response efficiency of a data path or module. It is typically obtained by repeatedly measuring the latency of the same type of transactions and then calculating their arithmetic mean. Data transmission bandwidth is the total amount of data successfully transmitted by a system or module per unit time, and can be calculated in conjunction with the transaction data volume.

[0063] In some examples, parallel or multiplexed data paths can be analyzed by merging them. For example, multiple parallel instances of the same functional unit can be automatically merged to calculate the start time, end time, and total throughput of the merged data.

[0064] In some examples, dynamic path extension can be supported, allowing new functional units to be added before or after existing data pathways.

[0065] In the example, some standard protocol monitoring modes can be predefined, such as the AXI protocol handshake and valid signal counting. If the extended module interface meets these predefined protocols, it can be automatically recognized. Custom protocols can also be defined, requiring the user to explicitly define the triggered signals and types. Additionally, some specific data path connection methods are predefined, such as data flow within the PE, and the data flow from a node in the NOC (e.g., the last-level cache LLC) to the PE node. This allows users to automatically generate the corresponding specific path by specifying which LLC to view the data flow to which PE node, or which Engine within the PE to view the data flow to which Engine (e.g., specifying node coordinates). Users can also update the data flow direction and data interface in the corresponding template according to the corresponding chip structure for convenient later use.

[0066] Suppose the user initially focuses on the data path within the AI ​​chip, from the last-level cache (LLC) to the processing engine (PE), and wants to perform performance analysis between the LLC output and the PE input. The user writes the following basic path configuration file: LLC→PE. Upon receiving this configuration file, the system automatically parses the two functional units in the path: LLC and PE. Subsequently, corresponding hardware monitor (sig_trigger) instances are generated for the LLC output and the PE input, respectively, and the simulation is run. The analysis report shows that the data transmission latency at the LLC output is very low and the utilization rate is high, but the reception latency at the PE input is significantly high, and there are a large number of bubble cycles. The preliminary conclusion of the report may be that data transmission encounters a blockage in the process from LLC to PE, but it is unclear whether the bottleneck is located inside the LLC, on the bus between LLC and PE, or in the PE's own input handshake logic.

[0067] To further pinpoint the bottleneck, the monitoring scope can be expanded by adding a DDR read controller (ddr_rd) to the front end of the LLC to observe the entire upstream process of data entering the LLC from DDR. Users do not need to delete the existing configuration or rewrite the entire path; they simply add "ddr_rd" before "LLC" in the existing path, updating the configuration file to: ddr_rd→LLC→PE. Then, the expanded path is parsed to identify the newly added ddr_rd module. Hardware monitors are automatically generated for the input (DDR interface side) and output (data sending side to LLC) of ddr_rd, while retaining all existing hardware monitors for the LLC and PE. Finally, the system automatically establishes a timestamp association between the new hardware monitor and the existing hardware monitors, ensuring that the complete timeline from the ddr_rd initiating a read request to the PE finally receiving the data can be accurately tracked.

[0068] In the example, after resimulating and generating a new analysis report, it was found that the output latency of ddr_rd was normal, but its input latency waited for DDR response for hundreds of cycles, with a cell utilization of only 15%. Considering the matching latency of the LLC input, the bottleneck was ultimately confirmed to be in the DDR read response stage, rather than the LLC-PE transmission bus. Therefore, users can focus their optimization efforts on the DDR controller's scheduling strategy or the DDR memory's bandwidth configuration.

[0069] In some examples, multi-PE parallel analysis capabilities can also be provided, allowing simultaneous analysis of the data path performance of multiple processing units.

[0070] In some embodiments, method 100 further includes generating a structured report containing performance metrics based on performance metrics.

[0071] In the example, the calculation results are output in a clear, structured format (such as Markdown, CSV, or HTML) to the final structured report analysis_rpt.txt. This report not only includes numerical results but may also include brief data quality checks (e.g., whether the timestamps are reasonable) and comparisons with preset targets (e.g., comparison of measured bandwidth with the architecture's target bandwidth). It can also provide bottleneck analysis and optimization suggestions to help users quickly locate problems and develop optimization strategies.

[0072] refer to Figure 2 , Figure 2 The diagram shows a result report using the DDR to PE internal transmission path as an example. The data path is ddr_rd→wdma, which shows the size of the transmitted data (1KB), and the performance indicators of the input monitor (“in”) and output monitor (“out”) of the two functional units ddr_rd and wdma, such as utilization (“utilrate”), bubble cycle count (“bubble”), inter-module latency, and effective working cycle count (“util cycle”).

[0073] In some embodiments, the configuration file further defines at least one monitoring phase, each monitoring phase having a corresponding test time period and each monitoring phase corresponding to at least one hardware monitor among one or more hardware monitors. The method 100 further includes: when testing the chip, according to the at least one monitoring phase, activating or deactivating at least one hardware monitor corresponding to the monitoring phase within the test time period corresponding to each monitoring phase.

[0074] In the example, when testing different load modes, certain monitors can be activated or deactivated during the corresponding simulation time period to achieve fine-grained measurement of the chip's performance under different operating modes.

[0075] In some examples, hardware monitors (e.g., the generated custom_profiling.sv module) can communicate with advanced verification environments (e.g., UVM) via SystemVerilog interfaces (e.g., VPI / DPI) or standard file I / O, feeding performance metrics back to the scoreboard or functional coverage model in real time. This enables the linkage between performance verification and functional verification, ensuring that the chip not only functions correctly but also meets performance standards.

[0076] For example, the custom_profiling.sv module can be integrated into the verification environment. The hardware monitoring unit in this module is configured to monitor the output of the ddr_rd, calculating its effective data transfer bandwidth and average read latency in real time. custom_profiling.sv, through the DPI-C interface (DPI stands for Direct Programming Interface, and DPI-C is its C language binding), calls a predefined callback function in the UVM environment at fixed time intervals (e.g., every 1000 clock cycles), passing the currently measured bandwidth and latency values ​​to the UVM environment.

[0077] After receiving this performance data, the UVM environment performs the following operations: 1. Real-time performance checks: For example, while comparing the data for correctness, the scoreboard checks whether the current average read latency exceeds the maximum latency threshold specified in the design specifications (e.g., 200 clock cycles). If latency exceeds the limit multiple times consecutively, the scoreboard immediately triggers a performance warning, marks the test case as "functionally correct but performance substandard," and records the current stimulus sequence and internal state for subsequent analysis; 2. Dynamic stimulus adjustment: For example, the stimulus generator dynamically adjusts the sending density of read requests based on the received bandwidth feedback. When it detects that the actual bandwidth of ddr_rd is close to the theoretical limit (e.g., reaching over 90%) and the latency begins to rise significantly, the stimulus generator actively reduces the sending rate of new requests to avoid oversaturation and performance degradation. If a false deadlock or timeout occurs, conversely, when ddr_rd is detected to be in a low-bandwidth, low-latency state for an extended period, the stimulus generator gradually increases the request density to explore the true performance limit of ddr_rd. This performance-aware stimulus generation method allows the verification environment to automatically focus on the chip's performance boundary regions and discover functional defects that only surface under specific load conditions (such as distorted or lost response data under high bandwidth pressure). 3. Real-time performance data recording: For example, the UVM environment writes the received performance data into the simulation database and stores it in association with functional coverage information. During subsequent analysis, users can query questions such as "What is the functional coverage when the DDR read latency exceeds 150 cycles?" to assess whether performance bottlenecks affect the verification coverage of key functional scenarios.

[0078] In the example, performance metrics can be incorporated into the functional coverage evaluation model. For instance, a coverage point is defined in a UVM environment: data integrity of ddr_rd under continuous high-bandwidth read requests. Traditional methods can only cover this scenario through functional checks, but cannot quantify the specific extent of "high bandwidth." The linkage mechanism allows users to use performance metrics (such as "actual ddr_rd bandwidth exceeds 80% of theoretical bandwidth") as trigger conditions for coverage points. Only when the function is correct and the performance meets the standard is the coverage point marked as covered. This approach ensures that verification not only verifies "whether a function has been tested," but also verifies "whether the function has been tested under real performance pressure," significantly improving the confidence of the verification.

[0079] This allows for the early detection of performance-related functional defects. Some functional errors only surface under specific performance conditions; for example, during high-speed continuous write operations, the WDMA address pointer may incorrectly increment due to race conditions. Traditional functional verification, if run only under low speed or low load, may never uncover these defects. This linkage mechanism between functional and performance verification ensures that performance monitoring and functional checks are performed simultaneously, enabling these hidden defects to be captured promptly.

[0080] Figure 3 This is a block diagram illustrating an apparatus 300 for analyzing chip performance according to an exemplary embodiment.

[0081] refer to Figure 3In some embodiments, the apparatus 300 for analyzing chip performance includes: an acquisition module 310 configured to acquire a configuration file, the configuration file defining a reference clock signal, a source signal for triggering the performance event, a trigger condition type, a target trigger count, and a data path for each performance event among a plurality of performance events to be monitored, wherein the target trigger count indicates the upper limit of the number of times the performance event can be triggered, the trigger condition type indicates the signal type that triggers the performance event, and the data path indicates the transmission path of the complete internal data flow of the chip; a parsing module 320 configured to parse the configuration file to split the data path and obtain a plurality of independent functional units through which the internal data flow of the chip passes; a generation module 330 configured to generate one or more hardware monitors based on the plurality of independent functional units, wherein the one or more hardware monitors include generating a corresponding input monitor and / or output monitor for each functional unit; and a test module. Block 340 is configured to test the chip; event detection module 350 is configured to detect multiple performance events occurring during chip testing via one or more hardware monitors; data acquisition module 360 ​​is configured to record event data of the detected performance event via one or more hardware monitors in response to the detection of any one of the multiple performance events; and performance calculation module 370 is configured to calculate chip performance metrics for analysis based on the recorded event data and configuration file. Performance calculation module 370 includes: unit performance calculation module 371, configured to calculate unit performance metrics for each functional unit based on the recorded event data and configuration file, including input latency, output latency, and unit utilization; and identification module 372, configured to identify and identify performance bottlenecks in the data path based on the unit performance metrics of multiple independent functional units.

[0082] Therefore, the complex data path is automatically broken down into independent functional units. Through modular performance analysis, the performance of each functional unit in the data path can be accurately quantified, and performance bottlenecks in the data path can be automatically identified.

[0083] In some embodiments, the apparatus 300 for analyzing chip performance may further include a report generation module configured to generate a structured report containing performance metrics based on performance metrics.

[0084] In some embodiments, the configuration file further defines at least one monitoring phase, each monitoring phase having a corresponding test time period and each monitoring phase corresponding to at least one hardware monitor among one or more hardware monitors. The apparatus 300 for analyzing chip performance may further include: a detector control module configured to, when testing the chip, activate or deactivate at least one hardware monitor corresponding to the monitoring phase within the test time period corresponding to the at least one monitoring phase.

[0085] The operations of the aforementioned acquisition module 310, parsing module 320, generation module 330, testing module 340, event detection module 350, data acquisition module 360, performance calculation module 370, unit performance calculation module 371, and identification module 372 can be combined. Figure 1 The operations of steps S110, S120, S130, S140, S150, S160, S170, S171 and S172 are the same, so the details of each aspect will not be repeated here.

[0086] According to one aspect of this disclosure, a computer device is also provided, comprising: at least one processor; and a memory storing a computer program thereon, wherein the computer program, when executed by the at least one processor, causes the at least one processor to perform the steps of any of the method embodiments described above.

[0087] According to one aspect of this disclosure, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, causes the processor to perform the steps of any of the method embodiments described above.

[0088] According to one aspect of this disclosure, a computer program product is also provided, which includes a computer program that, when executed by a processor, implements the steps of any of the method embodiments described above.

[0089] Figure 4 An example computer device 400 is shown in which any of the embodiments described herein may be implemented. Computer device 400 may be used to implement one or more components of the systems and methods described above. Computer device 400 may include a bus 402 or other communication mechanism for communicating information, and one or more processors 404 coupled to the bus 402 for processing information. Processor 404 may be, for example, one or more general-purpose microprocessors.

[0090] Computer device 400 may also include main memory 406, such as random access memory (RAM), cache, and / or other dynamic storage devices, coupled to bus 402, for storing information and instructions to be executed by processor 404. Main memory 406 may also be used to store temporary variables or other intermediate information during the execution of instructions to be executed by processor 404. Such instructions, when stored in a storage medium accessible to processor 404, can make computer device 400 a special-purpose machine customized to perform the operations specified in the instructions. Main memory 406 may include non-volatile media and / or volatile media. Non-volatile media may include, for example, optical discs or magnetic disks. Volatile media may include dynamic memory. Common media formats may include, for example, floppy disks, collapsible disks, hard disks, solid-state drives, magnetic tapes or any other magnetic data storage media, CD-ROMs (read-only optical disc drives), any other optical data storage media, any physical media with a perforated arrangement, RAM (random access memory), DRAM (dynamic random access memory), PROM (programmable read-only memory) and EPROM (erasable programmable read-only memory), FLASH-EPROM (fast erase programmable read-only memory), NVRAM (non-volatile random access memory), any other memory chips or tape cartridges, or network versions of the above.

[0091] Computer device 400 may implement the techniques described herein using custom hardwired logic, one or more ASICs (Application-Specific Integrated Circuits) or FPGAs (Field-Programmable Gate Arrays), firmware, and / or program logic, which, when combined with computer device 400, enable computer device 400 to become a special-purpose machine or to be programmed therein. According to one embodiment, the techniques described herein are executed by computer device 400 in response to processor 404 executing one or more sequences of one or more instructions contained in main memory 406. Such instructions may be read into main memory 406 from another storage medium, such as storage device 408. Executing the sequence of instructions contained in main memory 406 causes processor 404 to perform the processing steps described herein. For example, the processes / methods disclosed herein may be implemented by computer program instructions stored in main memory 406. When these instructions are executed by processor 404, they may perform the steps shown in the corresponding figures and as described above. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions.

[0092] Computer device 400 also includes a network interface 410 coupled to bus 402. Network interface 410 can provide bidirectional data communication coupled to one or more network links connected to one or more networks. As another example, network interface 410 can be a local area network (LAN) card to provide data communication connectivity with a compatible LAN (or a WAN component communicating with a WAN (wide area network)). Wireless links can also be implemented.

[0093] The performance of certain operations can be distributed across processors, not just residing within a single machine, but deployed across many machines. In some exemplary embodiments, the processor or the processor-implemented engine may reside in a single geographic location (e.g., in a home environment, office environment, or server farm). In other exemplary embodiments, the processor or the processor-implemented engine may be distributed across many geographic locations.

[0094] Each process, method, and algorithm described in the preceding sections can be embodied in a code module executed by one or more computer systems or computer processors including computer hardware, and can be fully or partially automated by them. These processes and algorithms can be implemented, in part or in whole, in a specific application circuit.

[0095] When the functions disclosed herein are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Specific technical solutions (all or part) disclosed herein, or aspects contributing to the prior art, can be embodied in the form of a software product. This software product can be stored in a storage medium and includes instructions to cause a computer device (which may be a personal computer, server, network device, etc.) to perform all or part of the steps of the methods described in the embodiments of this application. The storage medium may include a flash drive, a portable hard drive, ROM, RAM, a magnetic disk, an optical disk, another medium suitable for storing program code, or any combination thereof.

[0096] The embodiments disclosed herein can be implemented via a cloud platform, server, or group of servers that interact with a client. The client can be a terminal device or a client registered by a user on the platform, wherein the terminal device can be a mobile terminal, a personal computer (PC), or any device that can install platform applications.

[0097] The various features and processes described above can be used independently or combined in various ways. All possible combinations and sub-combinations are intended to fall within the scope of this disclosure. Furthermore, certain method or process blocks may be omitted in some embodiments. The methods and processes described herein are not limited to any particular order, and associated blocks or states may be executed in other suitable orders. For example, described blocks or states may be executed in a non-specifically disclosed order, or multiple blocks or states may be combined in a single block or state. Exemplary blocks or states may be executed serially, in parallel, or otherwise. Blocks or states may be added to or removed from the disclosed exemplary embodiments. The exemplary systems and components described herein may be configured differently from those described. For example, elements may be added, removed, or rearranged compared to the disclosed exemplary embodiments.

[0098] The various operations of the exemplary methods described herein can be performed at least in part by an algorithm. An algorithm may consist of program code or instructions stored in memory (such as the non-transitory computer-readable storage medium described above). Such an algorithm may include a machine learning algorithm. In some embodiments, the machine learning algorithm may not be explicitly programmed into the computer to perform the function, but may learn from training data to obtain a predictive model for performing that function.

[0099] The various operations of the exemplary methods described herein can be performed at least in part by one or more processors, which are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors can constitute the engine of a processor implementation whose operation is to perform one or more of the operations or functions described herein.

[0100] Similarly, the methods described herein can be implemented at least partially by a processor, where a specific processor or one or more processors are examples of hardware. For example, at least some operations of the methods can be performed by one or more processors or an engine implemented by a processor. Furthermore, one or more processors can also run in a “cloud computing” environment or as “Software as a Service” (SaaS) to support the execution of the relevant operations. For example, at least some operations can be performed by a group of computers (as an example of a machine including processors), which can be accessed via a network (e.g., the Internet) and through one or more appropriate interfaces (e.g., application programming interfaces (APIs)).

[0101] The performance of certain operations can be distributed across processors, not just residing within a single machine, but deployed across many machines. In some exemplary embodiments, the processor or the processor-implemented engine may reside in a single geographic location (e.g., in a home environment, office environment, or server farm). In other exemplary embodiments, the processor or the processor-implemented engine may be distributed across many geographic locations.

[0102] In this specification, multiple instances may implement components, operations, or structures described as a single instance. Although individual operations of one or more methods are described and illustrated as independent operations, one or more individual operations may be performed concurrently, and these operations are not required to be performed in the order shown. Structures and functionalities presented as independent components in the example configuration may be implemented as combined structures or components. Similarly, structures and functionalities presented as individual components may be implemented as independent components. These and other variations, modifications, additions, and improvements are all within the scope of this document.

[0103] As used herein, “or” is inclusive rather than exclusive unless explicitly stated or indicated by context. Furthermore, “and” is both common and individual unless explicitly stated or indicated by context. Moreover, multiple instances may be provided for the resources, operations, or structures described herein as a single example. Furthermore, the boundaries between various resources, operations, engines, and data stores are somewhat arbitrary, and specific operations are illustrated within the context of a particular illustrative configuration. The allocation of other functionalities is conceivable and may fall within the scope of various embodiments of this disclosure. Generally, structures and functionalities presented as independent resources in example configurations may be implemented as combined structures or resources. Similarly, structures and functionalities presented as individual resources may be implemented as independent resources. These and other variations, modifications, additions, and improvements are all within the scope of embodiments of this disclosure. Therefore, this specification and accompanying drawings should be viewed in an illustrative rather than restrictive sense.

[0104] The terms “comprising” or “including” are used to indicate the presence of a subsequently stated feature, but do not preclude the addition of other features. Conditional language, in particular, such as “may,” “can,” or “may,” unless specifically stated or otherwise understood in the context of use, is generally intended to express that certain embodiments include certain features, elements, and / or steps, while other embodiments do not. Therefore, such conditional language generally does not imply that a feature, element, and / or step is necessary in any way for one or more embodiments, or that one or more embodiments must include logic that, with or without user input or prompting, determines whether such features, elements, and / or steps are included in any particular embodiment, or whether they are to be performed in any particular embodiment.

Claims

1. A method for analyzing chip performance, characterized by, The method includes: Obtain the configuration file, which is used to define the reference clock signal, the source signal used to trigger the occurrence of the performance event, the trigger condition type, the target trigger count, and the data path for each performance event among the multiple performance events to be monitored. The target trigger count indicates the upper limit of the number of times the performance event can be triggered, the trigger condition type indicates the signal type that triggers the performance event, and the data path indicates the transmission path of the complete internal data flow of the chip. The configuration file is parsed to break down the data path, resulting in multiple independent functional units through which the data flow inside the chip passes. One or more hardware monitors are generated based on the plurality of independent functional units, wherein the one or more hardware monitors include generating a corresponding input monitor and / or output monitor for each functional unit; The chip was tested; The plurality of performance events occurring during testing of the chip are detected by the one or more hardware monitors; In response to the detection of any one of the plurality of performance events, the event data of the detected performance event is recorded by the one or more hardware monitors; and The performance metrics of the chip are calculated and analyzed based on the recorded event data and the configuration file, including: Based on the recorded event data and the configuration file, unit performance metrics for each functional unit are calculated, including input latency, output latency, and unit utilization; and Based on the unit performance indicators of the multiple independent functional units, identify and mark the performance bottlenecks in the data path.

2. The method according to claim 1, characterized in that, The triggering condition types include signal rising edge triggering, signal falling edge triggering, signal high level triggering, and signal low level triggering.

3. The method according to claim 1, characterized in that, The event data includes an event start timestamp, an event end timestamp, and a clock cycle. The event start timestamp is the timestamp recorded when the detected performance event is first triggered, and the event end timestamp is the timestamp recorded when the number of times the detected performance event is triggered reaches the target trigger count.

4. The method according to claim 1, characterized in that, The performance metrics of the chip include at least one of the following performance metrics: Event duration, number of active clock cycles, number of idle cycles, utilization, average latency, and bandwidth.

5. The method according to claim 1, characterized in that, The method further includes: Generate a structured report containing the performance metrics based on the performance metrics.

6. The method according to claim 1, characterized in that, The configuration file also defines at least one monitoring phase, each monitoring phase having a corresponding test time period and each monitoring phase corresponding to at least one of the one or more hardware monitors, and the method further includes: When testing the chip, the at least one hardware monitor corresponding to each monitoring stage is activated or deactivated during the test time period corresponding to each monitoring stage, according to the at least one monitoring stage.

7. An apparatus for analyzing chip performance, characterized in that, The device includes: The acquisition module is configured to acquire a configuration file, which defines the reference clock signal, the source signal used to trigger the performance event, the trigger condition type, the target trigger count, and the data path for each performance event among multiple performance events to be monitored. The target trigger count indicates the upper limit of the number of times the performance event can be triggered, the trigger condition type indicates the signal type that triggers the performance event, and the data path indicates the transmission path of the complete internal data flow of the chip. The parsing module is configured to parse the configuration file to split the data path and obtain multiple independent functional units through which the data flow inside the chip passes. The generation module is configured to generate one or more hardware monitors based on the plurality of independent functional units, wherein the one or more hardware monitors include generating a corresponding input monitor and / or output monitor for each functional unit; The test module is configured to test the chip; An event detection module is configured to detect the plurality of performance events that occur during testing of the chip via one or more hardware monitors; The data acquisition module is configured to, in response to the detection of any one of the plurality of performance events, record event data of the detected performance event via the one or more hardware monitors; and A performance calculation module is configured to calculate and analyze the chip's performance metrics based on the recorded event data and the configuration file. The performance calculation module includes: A unit performance calculation module is configured to calculate unit performance metrics for each functional unit based on the recorded event data and the configuration file. These unit performance metrics include input latency, output latency, and unit utilization. The identification module is configured to identify and mark performance bottlenecks in the data path based on the unit performance indicators of the plurality of independent functional units.

8. A computer device, characterized in that, The computer device includes: At least one processor; A memory having a computer program stored thereon, wherein, when executed by the at least one processor, the computer program causes the at least one processor to perform the method of any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, causes the processor to perform the method of any one of claims 1-6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, causes the processor to perform the method of any one of claims 1-6.

Images