SoC performance problem automatic locating and attribution method, device and equipment

Abstract

The application discloses a kind of SoC performance problem automatic positioning and attribution method, device and equipment, it is related to performance analysis technical field, the method includes obtaining FSDB waveform file, according to predefinition configuration to the FSDB waveform in target time period is parsed to extract performance signal, and target time period is divided into multiple statistical windows;Based on the performance signal of extraction carries out the construction of multiple-dimensional performance index set corresponding to each statistical window, establishes the performance bottleneck rule base for determining bottleneck conclusion and bottleneck reason between performance index relationship;The multiple-dimensional performance index set corresponding to statistical window is matched with rule in performance bottleneck rule base, according to the rule obtained by matching, obtain bottleneck conclusion and bottleneck reason.The application can improve the consistency and reusability of SoC performance problem analysis.

Description

Technical Field

[0001] This application relates to the field of performance analysis technology, specifically to a method, apparatus, and device for automatically locating and attributing SoC performance problems. Background Technology

[0002] In the SoC (System on Chip) design verification and performance analysis phase, existing performance problem analysis is typically based on simulation waveforms or runtime logs, with engineers manually reviewing waveform files such as FSDB (Fast Signal Database, a simulation waveform file format) and making judgments based on experience. This mainly includes the following methods: (1) Manually focus on a single module or a single type of signal, and locate the suspected performance abnormality by observing waveform characteristics such as arbitration authorization, back pressure, idle period, and request / response delay. This method is intuitive, but it relies heavily on the analyst's understanding of the system architecture, protocol details and specific scenarios, and is less efficient when facing complex concurrent business. (2) Based on scripts or local statistical tools, certain indicators are extracted offline, such as the average delay of a bus, the utilization rate of a port, or the throughput of a certain type of transaction. This method can reduce some manual workload, but it is mostly limited to single indicator, single module, or single-level analysis.

[0003] With the increasing concurrency of modules such as CPU (Central Processing Unit), GPU (Graphics Processing Unit), DMA (Direct Memory Access), NoC (Network On-Chip), and memory controller in complex SoCs, performance issues often manifest as cross-module, cross-link, and cross-layer interconnected phenomena. Current technologies lack a method to organize multi-dimensional performance metrics within a unified time window and further perform automatic correlation analysis, location, and attribution through rule-based approaches. Specifically: (1) Existing manual waveform analysis methods rely heavily on engineers' experience and personal skills, which is not conducive to forming a unified, standardized, and scalable performance analysis process; (2) Although the existing script-based statistical methods can extract some performance indicators, they can usually only observe local modules or single indicators, and it is difficult to express the relationship between multiple interfaces, multiple modules and multiple layers under a unified statistical standard. (3) When performance problems are caused by a combination of factors such as resource competition, NoC congestion, unfair arbitration, and insufficient incentives, the existing methods are unable to simultaneously provide the bottleneck type, time interval of occurrence, location of occurrence, and possible causes, and the analysis results lack systematicity. (4) For different SoC projects and different analysis objects, existing solutions often require rewriting scripts and rebuilding analysis experience. The rules are not reusable and scalable enough, making it difficult to support rapid performance regression and continuous optimization in complex scenarios. Summary of the Invention

[0004] This application provides a method, apparatus, and device for automatic localization and attribution of SoC performance problems, which can improve the consistency and reusability of SoC performance problem analysis.

[0005] In a first aspect, embodiments of this application provide an automatic method for locating and attributing SoC performance problems, the method comprising: Obtain the FSDB waveform file, parse the FSDB waveform within the target time period according to the predefined configuration to extract the performance signal, and divide the target time period into multiple statistical windows; Based on the extracted performance signals, a set of multi-dimensional performance indicators corresponding to each statistical window is constructed, and a performance bottleneck rule base is established to determine the bottleneck conclusion and the bottleneck cause based on the relationship between performance indicators. The set of multidimensional performance indicators corresponding to the statistical window is matched with the rules in the performance bottleneck rule base. Based on the matched rules, the bottleneck conclusion and the bottleneck cause are obtained.

[0006] In conjunction with the first aspect, in one implementation, acquiring the FSDB waveform file specifically includes: Obtain the FSDB waveform file and load the predefined configuration; The predefined configurations include start_time, end_time, slice_num, and intf_list; The start_time is used to limit the start time of the analysis, the end_time is used to limit the end time of the analysis, the slice_num is used to determine the number of slices in the statistical window, and the intf_list is used to specify the set of interfaces to be analyzed.

[0007] In conjunction with the first aspect, in one implementation, the step of parsing the FSDB waveform within a target time period according to a predefined configuration to extract performance signals, and dividing the target time period into multiple statistical windows, specifically includes: The FSDB waveform within the target time period is analyzed according to the predefined configuration, and key performance-related signals are extracted to achieve performance signal extraction. The key signals include request, response, authorization, backpressure, and effective transmission. The target time period is divided into multiple statistical windows based on predefined configurations.

[0008] In conjunction with the first aspect, in one implementation, the construction of a set of multidimensional performance indicators corresponding to each statistical window based on the extracted performance signal specifically includes: Based on the extracted performance signals, obtain the corresponding performance signals within the current statistical window; Performance indicators are calculated based on the performance signals obtained within the current statistical window, and a set of multidimensional performance indicators corresponding to the current statistical window is constructed, thereby realizing the construction of the set of multidimensional performance indicators corresponding to each statistical window.

[0009] In conjunction with the first aspect, in one implementation method, Each rule in the performance bottleneck rule base includes the monitoring object, performance index item, threshold conditions and / or logical conditions, time relationship, associated object, bottleneck conclusion, and bottleneck cause; The types of rules include single-module exception rules, resource contention rules, time-series association rules, and cross-level association rules; The single-module anomaly rule refers to setting threshold conditions and / or logical conditions for the performance indicators of a single interface, a single port, a single routing node, or a single functional module to identify local performance anomalies. The resource contention rules refer to the rules established for the competitive relationship between multiple master devices, multiple links, or multiple shared resource objects, and are used to identify bandwidth contention, arbitration conflicts, and shared storage resource contention. The time-series association rule refers to the rule that judges based on the temporal sequence, duration, overlap, or lag relationship of multiple performance anomalies, and is used to describe the temporal causality of performance problems. The cross-layer association rules refer to the rules for jointly judging the performance phenomena of the interface layer, link layer, routing layer, interconnection layer, storage layer or subsystem layer. They are used to associate local anomalies with system-level anomalies, thereby enabling the location of bottleneck problems and the summarization of causes.

[0010] In conjunction with the first aspect, in one implementation, the matching of the set of multidimensional performance indicators corresponding to the statistical window with rules in the performance bottleneck rule base specifically includes: The multidimensional performance index sets corresponding to each statistical window are all input into the performance bottleneck rule base for matching with the rules in the performance bottleneck rule base. The matching method involves jointly judging multiple performance indicators of different modules or interfaces within the same statistical window, and performing time-series correlation judgment on the sequential and continuous relationships of multiple performance phenomena between adjacent statistical windows, thereby identifying bottleneck types and locating the time interval of occurrence.

[0011] In conjunction with the first aspect, in one implementation, obtaining the bottleneck conclusion and bottleneck cause based on the matching rules specifically includes: Based on the matching rules, combined with the monitored objects, associated objects, and rule conclusions, the location of the module, link, port, or resource where the performance bottleneck occurs is determined, and the causes of the performance bottleneck are summarized.

[0012] In conjunction with the first aspect, in one implementation, after obtaining the bottleneck conclusion and the bottleneck cause, the method further includes: Based on the matching rules, the bottleneck conclusions and causes, a performance analysis report is generated. The performance analysis report includes the bottleneck type, the time interval of the bottleneck occurrence, the location of the bottleneck, the severity of the bottleneck, and the cause of the bottleneck.

[0013] Secondly, embodiments of this application provide an automatic SoC performance problem localization and attribution device, the SoC performance problem automatic localization and attribution device comprising: The parsing module is used to acquire FSDB waveform files, parse the FSDB waveforms within the target time period according to predefined configurations to extract performance signals, and divide the target time period into multiple statistical windows; Create a module that is used to construct a set of multi-dimensional performance indicators corresponding to each statistical window based on the extracted performance signals, and establish a performance bottleneck rule base for determining bottleneck conclusions and bottleneck causes based on the relationship between performance indicators. The matching module is used to match the set of multidimensional performance indicators corresponding to the statistical window with the rules in the performance bottleneck rule base, and obtain the bottleneck conclusion and bottleneck cause based on the matching rules.

[0014] Thirdly, embodiments of this application provide an automatic SoC performance problem localization and attribution device, the SoC performance problem localization and attribution device including a processor, a memory, and an SoC performance problem localization and attribution program stored in the memory and executable by the processor, wherein when the SoC performance problem localization and attribution program is executed by the processor, it implements the steps of the SoC performance problem localization and attribution method described above.

[0015] The beneficial effects of the technical solutions provided in this application include: (1) By regularizing and automating the FSDB waveform analysis process, the reliance on human experience is significantly reduced, and the consistency and reusability of SoC performance problem analysis are improved; (2) Constructing a set of performance indicators with multiple interfaces, multiple modules, and multiple levels under a unified time window can more systematically characterize the performance behavior in complex SoC scenarios compared to methods that only observe a single indicator or local phenomena. (3) By introducing an extensible performance bottleneck rule base and combining it with cross-module, cross-level and time series correlation analysis mechanisms, it can simultaneously output the bottleneck type, occurrence time interval, occurrence location and possible causes, thereby improving the automatic location and attribution capabilities. (4) This application supports the continuous expansion and cross-project migration of rules. It can be used for performance analysis in the design verification phase, as well as for architecture optimization, performance regression and experience accumulation, and has strong engineering practical value. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating the automatic location and attribution method for SoC performance issues in this application. Figure 2 This is a schematic diagram of the functional modules of the SoC performance problem automatic location and attribution device in this application. Figure 3 This is a schematic diagram of the hardware structure of the device for automatically locating and attributing SoC performance problems in this application. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0019] Firstly, this application provides an automatic method for locating and attributing SoC performance problems. It elevates the SoC performance analysis process based on FSDB waveform files from a discrete, experience-dependent approach to a rule-based diagnostic process that is automatically executed, reusable, and scalable. Within a unified time window, it quantifies and statistically analyzes the performance behavior of multiple modules, interfaces, and different levels, forming a multi-dimensional performance indicator set capable of comprehensive judgment. A preset rule model is used to automatically match, correlate across modules, and correlate across levels of these multi-dimensional performance indicators to quickly identify performance bottleneck types and accurately locate their occurrence time intervals and hardware locations. While locating performance bottlenecks, it also performs causal induction on multiple related performance phenomena, outputting possible causes and structured analysis results with engineering guidance significance. Specifically, using FSDB waveform files as input, the performance behavior of multiple interfaces, modules, and levels is quantified within a unified time window to construct a multi-dimensional performance indicator set. Based on this, a preset performance bottleneck rule base is invoked to automatically match, correlate, and summarize the causes of the performance indicators, ultimately outputting a structured performance analysis report.

[0020] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating the automatic localization and attribution method for SoC performance issues in this application. Figure 1 As shown, the methods for automatic localization and attribution of SoC performance issues include: S1: Obtain the FSDB waveform file, parse the FSDB waveform within the target time period according to the predefined configuration to extract the performance signal, and divide the target time period into multiple statistical windows; S2: Based on the extracted performance signals, construct a set of multi-dimensional performance indicators corresponding to each statistical window, and establish a performance bottleneck rule base for determining bottleneck conclusions and bottleneck causes based on the relationship between performance indicators. S3: Match the set of multidimensional performance indicators corresponding to the statistical window with the rules in the performance bottleneck rule base, and obtain the bottleneck conclusion and bottleneck cause based on the matched rules.

[0021] Furthermore, in one embodiment, obtaining the FSDB waveform file specifically includes: Obtain the FSDB waveform file and load the predefined configuration; The predefined configuration includes start_time, end_time, slice_num, and intf_list; start_time is used to limit the start time of the analysis, end_time is used to limit the end time of the analysis, slice_num is used to determine the number of slices in the statistical window, and intf_list is used to specify the set of interfaces to be analyzed.

[0022] Furthermore, in one embodiment, the FSDB waveform within the target time period is parsed according to a predefined configuration to extract performance signals, and the target time period is divided into multiple statistical windows, specifically including: S101: Analyze the FSDB waveform within the target time period according to the predefined configuration, extract key performance-related signals, and realize performance signal extraction. The key signals include request, response, authorization, backpressure, and effective transmission. S102: Divide the target time period into multiple statistical windows according to the predefined configuration, that is, divide the target analysis time period into multiple statistical intervals, so as to perform unified quantitative statistics on performance-related behaviors in each statistical interval.

[0023] Specifically, performance-related signals within the target time period are parsed, and a unified time window is established. This involves analyzing the FSDB waveform within the target time period according to a predefined configuration to extract key performance-related signals such as requests, responses, authorizations, backpressure, and effective transmissions. The target time period is then divided into multiple statistical windows, allowing the behavior of different interfaces and modules to be compared under a unified time benchmark.

[0024] Among them, the interfaces can be master device interfaces, slave device interfaces, bus interfaces, NoC link interfaces, storage interfaces, and bridge interfaces; the modules can be CPUs, GPUs, NPUs, DMAs, NoC routers, interconnect modules, storage controllers, cache subsystems, or other functional modules involved in performance-related behaviors.

[0025] Furthermore, in one embodiment, a set of multidimensional performance indicators corresponding to each statistical window is constructed based on the extracted performance signal, specifically including: S201: Based on the extracted performance signal, obtain the corresponding performance signal within the current statistical window; S202: Based on the performance signals obtained within the current statistical window, performance indicators are calculated, and a multi-dimensional performance indicator set corresponding to the current statistical window is constructed, thereby realizing the construction of the multi-dimensional performance indicator set corresponding to each statistical window. In this application, performance indicators refer to quantitative results such as latency, bandwidth, utilization, backpressure ratio, and license ratio calculated within the time window (i.e., statistical window) that can be used to analyze performance status.

[0026] Specifically, a multi-dimensional performance metric set is constructed within each statistical window. Within the current statistical window, performance metrics such as latency, bandwidth, utilization, backpressure percentage, and authorization percentage are extracted for each interface in intf_list. If necessary, derived signals for objects such as ports, links, routers, and storage channels can be further generated for subsequent rule judgments.

[0027] Among them, signals obtained by further calculation, combination, aggregation or correlation of basic performance indicators can be used as derived signals, such as port busy cycle percentage, port idle cycle percentage, port blocking cycle percentage, port backpressure duration, link throughput, link utilization, link idle rate, link congestion percentage, etc.

[0028] In this application, each rule in the performance bottleneck rule base includes at least the monitoring object, performance metric, threshold conditions and / or logical conditions, temporal relationship, associated objects, bottleneck conclusion, and bottleneck cause. The performance bottleneck rule base refers to a predefined and extensibly maintainable set of rules used to identify bottleneck types and attribute causes based on the relationships between multiple performance metrics. Furthermore, the performance bottleneck rule base supports adding, modifying, and deleting rules.

[0029] The types of rules include at least single-module exception rules, resource contention rules, time-series association rules, and cross-level association rules.

[0030] Single-module anomaly rules refer to setting threshold conditions and / or logical conditions for the performance indicators of a single interface, single port, single routing node, or single functional module to identify local performance anomalies; for example, high latency anomalies, low bandwidth anomalies, low efficiency anomalies, and local blocking anomalies.

[0031] Resource contention rules refer to rules established for the competitive relationship between multiple master devices, multiple links, or multiple shared resource objects. They are used to identify bandwidth contention, arbitration conflicts, and shared storage resource contention. For example, when the access latency of the first master device increases and the bandwidth utilization of the second master device continues to be higher than the threshold, it can be determined that there is resource contention.

[0032] Temporal correlation rules refer to rules that determine the temporal causal relationship of multiple performance anomalies based on their sequential, persistent, overlapping, or lagging relationships. They are used to describe the temporal causal relationship of performance problems. For example, if a subsequent anomaly begins to appear and persist after a previous anomaly has lasted for several statistical windows, it can be determined that there is a temporal correlation between the two.

[0033] Cross-layer association rules refer to rules that jointly judge performance phenomena at the interface layer, link layer, routing layer, interconnection layer, storage layer, or subsystem layer. They are used to associate local anomalies with system-level anomalies, enabling bottleneck problem localization and cause summarization. For example, when high latency at the interface layer, high backpressure at the NoC layer, and high busyness at the storage layer all meet preset conditions, it can be determined that the performance bottleneck originates from cross-layer path congestion.

[0034] Furthermore, in one embodiment, the set of multidimensional performance indicators corresponding to the statistical window is matched with rules in the performance bottleneck rule base, specifically including: The multi-dimensional performance index set corresponding to each statistical window is input into the performance bottleneck rule base for matching with the rules in the performance bottleneck rule base. The matching method is as follows: for the same statistical window, multiple performance indicators of different modules or different interfaces are jointly judged; for adjacent statistical windows, the sequential relationship and persistence relationship of multiple performance phenomena are judged by time sequence correlation, so as to identify the bottleneck type and locate the time interval of occurrence.

[0035] Specifically, the multi-dimensional performance indicators in each statistical window are input into the performance bottleneck rule base for automatic matching: within the same statistical window, multiple performance indicators of different modules or different interfaces are jointly judged; between adjacent statistical windows, the temporal correlation judgment of the sequential and continuous relationships of multiple performance phenomena is performed, thereby identifying the bottleneck type and locating the time interval of occurrence.

[0036] Furthermore, in one embodiment, the bottleneck conclusion and bottleneck cause are obtained based on the matching rules, specifically including: Based on the matching rules, combined with the monitored objects, associated objects, and rule conclusions, the location of the module, link, port, or resource where the performance bottleneck occurs is determined, and the causes of the performance bottleneck are summarized.

[0037] Specifically, for the matched rules, the location of the performance bottleneck module, link, port, or resource is determined by combining the monitored object, related objects, and rule conclusions, and the possible causes of the bottleneck are summarized. For example: when the CPU access latency is consistently higher than the threshold and the GPU bandwidth utilization rate within the same window is higher than the preset ratio, it can be determined as a memory bandwidth contention bottleneck, and the GPU is marked as the main source of contention; when the backpressure ratio of a certain input port of the NoC router is too high and the corresponding output link utilization is high, it can be determined that there is local congestion on that port; when the number of DMA0 grants is significantly lower than that of GPU0 and the DMA0 requests are continuously valid, it can be determined as unfair arbitration rather than insufficient incentives.

[0038] The following is a detailed explanation of the rules for matching.

[0039] When multidimensional performance indicators from one or more adjacent statistical windows are input into the performance bottleneck rule base, if the monitoring object, performance indicator item, threshold condition and / or logical condition, time relationship and associated object required by a certain rule are all met, then the rule is a hit rule, thereby triggering the bottleneck conclusion and cause description information corresponding to the rule.

[0040] For example, for resource contention rules, when the CPU access latency is consistently higher than a preset threshold within a statistical window, and the GPU bandwidth utilization rate is higher than a preset ratio within the same statistical window, the resource contention rule can be determined to be hit, and the bottleneck conclusion of "memory bandwidth contention" can be output, while the GPU is marked as the main source of contention. For cross-level association rules, when the backpressure ratio of a NoC router's input port is higher than a threshold, and the corresponding output link utilization rate is high, the local congestion rule can be determined to be hit, and the corresponding router and port can be located. For arbitration rules, when the DMA0 request is consistently valid, and the number of authorizations it obtains within the statistical window is significantly lower than that of GPU0, the arbitration unfairness rule can be determined to be hit, rather than insufficient incentive.

[0041] Furthermore, in one embodiment, after obtaining the bottleneck conclusion and the bottleneck cause, the method further includes: Based on the matching rules, the bottleneck conclusions and causes, a performance analysis report is generated; wherein, the performance analysis report includes the bottleneck type, the time interval of the bottleneck occurrence, the location of the bottleneck occurrence, the severity of the bottleneck, and the cause of the bottleneck.

[0042] Specifically, based on the results of rule matching and correlation analysis, a structured report is automatically generated, which includes the bottleneck type, time interval of the bottleneck occurrence, location of the bottleneck occurrence, severity of the bottleneck, and cause of the bottleneck. This report is used to support SoC performance problem investigation, architecture optimization, rule reuse, and regression analysis.

[0043] The overall process of the SoC performance problem automatic localization and attribution method in this application is as follows: waveform analysis, time slicing, multi-dimensional indicator construction, rule matching, cross-module / cross-level correlation analysis, bottleneck location, cause attribution, and structured report output.

[0044] Secondly, embodiments of this application also provide an automatic location and attribution device for SoC performance problems.

[0045] In one embodiment, reference is made to Figure 2 , Figure 2 This is a schematic diagram of the functional modules of the SoC performance problem automatic localization and attribution device in this application. Figure 2 As shown, the automatic location and attribution device for SoC performance issues includes: a parsing module, a creation module, and a matching module.

[0046] The parsing module is used to acquire FSDB waveform files, parse the FSDB waveforms within the target time period according to predefined configurations to extract performance signals, and divide the target time period into multiple statistical windows; the creation module is used to construct a set of multi-dimensional performance indicators corresponding to each statistical window based on the extracted performance signals, and establish a performance bottleneck rule base for determining bottleneck conclusions and bottleneck causes based on the relationships between performance indicators; the matching module is used to match the set of multi-dimensional performance indicators corresponding to the statistical window with the rules in the performance bottleneck rule base, and obtain bottleneck conclusions and bottleneck causes based on the matched rules.

[0047] Thirdly, embodiments of this application provide an automatic SoC performance problem localization and attribution device, which can be a personal computer (PC), laptop, server, or other device with data processing capabilities.

[0048] Reference Figure 3 , Figure 3 This is a schematic diagram of the hardware structure of the SoC performance problem automatic localization and attribution device involved in the embodiments of this application. In the embodiments of this application, the SoC performance problem automatic localization and attribution device may include a processor, memory, communication interface, and communication bus.

[0049] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0050] Communication interfaces include input / output (I / O) interfaces, physical interfaces, and logical interfaces used for automatic SoC performance problem localization and attribution; interfaces for interconnection between the SoC performance problem localization and attribution device and other devices (such as other computing devices or user equipment); physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0051] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0052] The processor can be a general-purpose processor, which can call the SoC performance problem automatic localization and attribution program stored in memory and execute the SoC performance problem automatic localization and attribution method provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the SoC performance problem automatic localization and attribution program is called can be referred to the various embodiments of the SoC performance problem automatic localization and attribution method of this application, and will not be repeated here.

[0053] Those skilled in the art will understand that Figure 3 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0054] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0055] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0056] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0057] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0058] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0059] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for automatically locating and attributing SoC performance problems, characterized in that, The automatic location and attribution method for SoC performance issues includes: Obtain the FSDB waveform file, parse the FSDB waveform within the target time period according to the predefined configuration to extract the performance signal, and divide the target time period into multiple statistical windows; Based on the extracted performance signals, a set of multi-dimensional performance indicators corresponding to each statistical window is constructed, and a performance bottleneck rule base is established to determine the bottleneck conclusion and the bottleneck cause based on the relationship between performance indicators. The set of multidimensional performance indicators corresponding to the statistical window is matched with the rules in the performance bottleneck rule base. Based on the matched rules, the bottleneck conclusion and the bottleneck cause are obtained.

2. The method for automatic localization and attribution of SoC performance problems as described in claim 1, characterized in that, The acquisition of the FSDB waveform file specifically includes: Obtain the FSDB waveform file and load the predefined configuration; The predefined configurations include start_time, end_time, slice_num, and intf_list; The start_time is used to limit the start time of the analysis, the end_time is used to limit the end time of the analysis, the slice_num is used to determine the number of slices in the statistical window, and the intf_list is used to specify the set of interfaces to be analyzed.

3. The method for automatic localization and attribution of SoC performance problems as described in claim 2, characterized in that, The step of parsing the FSDB waveform within the target time period according to a predefined configuration to extract performance signals, and dividing the target time period into multiple statistical windows, specifically includes: The FSDB waveform within the target time period is analyzed according to the predefined configuration, and key performance-related signals are extracted to achieve performance signal extraction. The key signals include request, response, authorization, backpressure, and effective transmission. The target time period is divided into multiple statistical windows based on predefined configurations.

4. The method for automatic localization and attribution of SoC performance problems as described in claim 1, characterized in that, The construction of a set of multidimensional performance indicators corresponding to each statistical window based on the extracted performance signals specifically includes: Based on the extracted performance signals, obtain the corresponding performance signals within the current statistical window; Performance indicators are calculated based on the performance signals obtained within the current statistical window, and a set of multidimensional performance indicators corresponding to the current statistical window is constructed, thereby realizing the construction of the set of multidimensional performance indicators corresponding to each statistical window.

5. The method for automatic localization and attribution of SoC performance problems as described in claim 1, characterized in that: Each rule in the performance bottleneck rule base includes the monitoring object, performance index item, threshold conditions and / or logical conditions, time relationship, associated object, bottleneck conclusion, and bottleneck cause; The types of rules include single-module exception rules, resource contention rules, time-series association rules, and cross-level association rules; The single-module anomaly rule refers to setting threshold conditions and / or logical conditions for the performance indicators of a single interface, a single port, a single routing node, or a single functional module to identify local performance anomalies. The resource contention rules refer to the rules established for the competitive relationship between multiple master devices, multiple links, or multiple shared resource objects, and are used to identify bandwidth contention, arbitration conflicts, and shared storage resource contention. The time-series association rule refers to the rule that judges based on the temporal sequence, duration, overlap, or lag relationship of multiple performance anomalies, and is used to describe the temporal causality of performance problems. The cross-layer association rules refer to the rules for jointly judging the performance phenomena of the interface layer, link layer, routing layer, interconnection layer, storage layer or subsystem layer. They are used to associate local anomalies with system-level anomalies, thereby enabling the location of bottleneck problems and the summarization of causes.

6. The method for automatic localization and attribution of SoC performance problems as described in claim 1, characterized in that, The matching of the set of multidimensional performance indicators corresponding to the statistical window with the rules in the performance bottleneck rule base specifically includes: The multidimensional performance index sets corresponding to each statistical window are all input into the performance bottleneck rule base for matching with the rules in the performance bottleneck rule base. The matching method involves jointly judging multiple performance indicators of different modules or interfaces within the same statistical window, and performing time-series correlation judgment on the sequential and continuous relationships of multiple performance phenomena between adjacent statistical windows, thereby identifying bottleneck types and locating the time interval of occurrence.

7. The method for automatic localization and attribution of SoC performance problems as described in claim 1, characterized in that, The process of obtaining bottleneck conclusions and bottleneck causes based on the matching rules specifically includes: Based on the matching rules, combined with the monitored objects, associated objects, and rule conclusions, the location of the module, link, port, or resource where the performance bottleneck occurs is determined, and the causes of the performance bottleneck are summarized.

8. The method for automatic localization and attribution of SoC performance problems as described in claim 1, characterized in that, After determining the bottleneck and its causes, the following is also included: Based on the matching rules, the bottleneck conclusions and causes, a performance analysis report is generated. The performance analysis report includes the bottleneck type, the time interval of the bottleneck occurrence, the location of the bottleneck, the severity of the bottleneck, and the cause of the bottleneck.

9. An automatic location and attribution device for SoC performance problems, characterized in that, The automatic SoC performance problem localization and attribution device includes: The parsing module is used to acquire FSDB waveform files, parse the FSDB waveforms within the target time period according to predefined configurations to extract performance signals, and divide the target time period into multiple statistical windows; Create a module that is used to construct a set of multi-dimensional performance indicators corresponding to each statistical window based on the extracted performance signals, and establish a performance bottleneck rule base for determining bottleneck conclusions and bottleneck causes based on the relationship between performance indicators. The matching module is used to match the set of multidimensional performance indicators corresponding to the statistical window with the rules in the performance bottleneck rule base, and obtain the bottleneck conclusion and bottleneck cause based on the matching rules.

10. A device for automatically locating and attributing SoC performance problems, characterized in that, The SoC performance problem auto-location and attribution device includes a processor, a memory, and an SoC performance problem auto-location and attribution program stored in the memory and executable by the processor, wherein when the SoC performance problem auto-location and attribution program is executed by the processor, it implements the steps of the SoC performance problem auto-location and attribution method as described in any one of claims 1 to 8.

Images