SoC signal event analysis method and device, electronic equipment and storage medium

Abstract

This application provides a method, apparatus, electronic device, and storage medium for analyzing SoC signal events. The method involves acquiring an input waveform file to be analyzed, a configuration file, and an analysis processing time range; preprocessing the configuration file to determine at least one target signal to be analyzed; parsing the waveform file to be analyzed; extracting the time points and transition values ​​corresponding to at least one signal transition event of the target signal within the analysis processing time range; executing signal expressions at the time points corresponding to each signal transition event; recording accumulated events or target values ​​based on a counting mode; and outputting an SoC signal event analysis report for the waveform file to be analyzed based on the accumulated events or target values. This reduces the error rate and processing time, thus improving the efficiency and accuracy of SoC signal event analysis.

Description

Technical Field

[0001] This application relates to the field of chip performance analysis technology, and in particular to methods, apparatus, electronic devices and storage media for analyzing SoC signal events. Background Technology

[0002] SoC signal events refer to communication mechanisms triggered by hardware or software within a system-on-a-chip (SoC) to transmit status, control information, or synchronization instructions between different subsystems, IP cores, or processing units. SoC analysis and verification are required during chip development to ensure that the chip functions correctly and meets performance standards.

[0003] In existing technologies, simulations typically output changes to logs, and the analysis results are obtained by analyzing the logs; alternatively, engineers manually locate signal changes in the generated waveform files to obtain signal analysis results; or SoC signal event analysis is performed via bus access. These solutions lack the ability to adjust the approach in real time according to analysis needs, or suffer from low manual processing efficiency and high error rates, resulting in both low efficiency and low accuracy in SoC signal event analysis. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a method, apparatus, electronic device and storage medium for analyzing SoC signal events. Without modifying the test platform or design code, it can directly and automatically analyze and process the obtained waveform file to be analyzed according to the data in the configuration file to obtain the accumulated events or target values, and then output an SoC signal event analysis report for the waveform file to be analyzed. This can reduce the error rate of analysis and reduce the analysis and processing time, and help improve the efficiency and accuracy of SoC signal event analysis.

[0005] In a first aspect, embodiments of this application provide an analysis method for SoC signal events, the analysis method comprising:

[0006] The system acquires the input waveform file to be analyzed, the configuration file, and the analysis and processing time range; the configuration file includes at least one of the following data: signal expression and counting mode;

[0007] Preprocess the configuration file to determine at least one target analysis signal, parse the waveform file to be analyzed, and extract the time point and jump value corresponding to at least one signal jump event of at least one target analysis signal within the analysis and processing time range.

[0008] After executing the signal expression at the time point corresponding to each signal transition event, the accumulated event or target value is recorded based on the counting mode;

[0009] Based on the accumulated events or target values, output a SoC signal event analysis report for the waveform file to be analyzed.

[0010] In one possible implementation, the configuration file further includes configuration file information: the preprocessing of the configuration file to determine at least one target analysis signal includes:

[0011] Based on the configuration file information, parse the main configuration file in the configuration file;

[0012] The sub-configuration files referenced in the configuration file are recursively loaded to determine at least one target analysis signal for the waveform file to be analyzed.

[0013] In one possible implementation, the configuration file further includes view mode information; before parsing the waveform file to be analyzed and extracting at least one of the target analysis signals, and before the analysis processing time range includes parsing the waveform file to be analyzed and extracting the time point and jump value corresponding to at least one signal jump event, the analysis method further includes:

[0014] Based on the view mode information, it is detected whether the view mode indicated by the view mode information is a block view mode;

[0015] If the view mode indicated by the view mode information is a block view mode, load the logical block path mapping file and convert the logical path contained in the signal expression into the corresponding physical path.

[0016] In one possible implementation, before executing the signal expression at the time points corresponding to each signal transition event, the analysis method further includes:

[0017] The signal expression is compiled into a postfix expression.

[0018] In one possible implementation, executing the signal expression at the time points corresponding to each signal transition event includes:

[0019] For each signal transition event, determine the corresponding clock edge and execute the postfix expression at the corresponding clock edge.

[0020] In one possible implementation, the configuration file further includes report parameter setting information; the step of outputting a SoC signal event analysis report for the waveform file to be analyzed based on the accumulated event or target value includes:

[0021] Based on the report parameter settings, determine the target report type and type settings for the analysis report;

[0022] Based on the accumulated event or target value, output a SoC signal event analysis report of the waveform file to be analyzed, according to the type setting information.

[0023] In one possible implementation, the report parameter setting information further includes a target processing method; the step of outputting a SoC signal event analysis report of the waveform file to be analyzed of the target report type according to the type setting information based on the accumulated event or target value includes:

[0024] The target processing data in the SoC signal event analysis report is determined. After processing the target processing data according to the target processing method, the SoC signal event analysis report of the waveform file to be analyzed of the target report type is output according to the type setting information.

[0025] The target processing method includes at least highlighting the target processing data.

[0026] Secondly, embodiments of this application also provide an analysis device for SoC signal events, the analysis device comprising:

[0027] The file input module is used to acquire the input waveform file to be analyzed, the configuration file, and the analysis and processing time range; the configuration file includes at least one of the following data: signal expression and counting mode;

[0028] The waveform analysis module is used to preprocess the configuration file, determine at least one target analysis signal, parse the waveform file to be analyzed, and extract the time point and jump value corresponding to at least one signal jump event of the target analysis signal within the analysis and processing time range.

[0029] The event statistics module is used to record the accumulated events or target values ​​based on the counting mode after executing the signal expression at the time point corresponding to each signal transition event;

[0030] The report output module is used to output a SoC signal event analysis report for the waveform file to be analyzed, based on the accumulated event or target value.

[0031] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of the SoC signal event analysis method as described in any of the first aspects.

[0032] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the SoC signal event analysis method as described in any of the first aspects.

[0033] The SoC signal event analysis method, apparatus, electronic device, and storage medium provided in this application acquire an input waveform file to be analyzed, a configuration file, and an analysis processing time range. The configuration file includes at least one of the following data: a signal expression and a counting mode. The configuration file is preprocessed to determine at least one target analysis signal, parse the waveform file to be analyzed, and extract the time points and jump values ​​corresponding to at least one signal transition event of the at least one target analysis signal within the analysis processing time range. After executing the signal expression at the time points corresponding to each signal transition event, the accumulated event or target value is recorded based on the counting mode. Based on the accumulated event or target value, an SoC signal event analysis report for the waveform file to be analyzed is output. In this way, without modifying the test platform or design code, the acquired waveform file to be analyzed is automatically analyzed and processed according to the data in the configuration file to obtain the accumulated event or target value, and then an SoC signal event analysis report for the waveform file to be analyzed is output. This can reduce the error rate and reduce the analysis processing time, and help improve the efficiency and accuracy of SoC signal event analysis.

[0034] Furthermore, the introduction of automatic path mapping for logical block path mapping files enables the same configuration to be reused in both logical and block views, significantly improving the reusability of the verification environment and the efficiency of SoC signal event analysis.

[0035] Furthermore, the report type of the SoC signal event analysis report can be configured in the configuration file to generate multi-dimensional reports that meet user needs, thereby improving the user experience.

[0036] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0037] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0038] Figure 1A flowchart illustrating a method for analyzing SoC signal events provided in an embodiment of this application;

[0039] Figure 2 This is a schematic diagram of a modular configuration provided in an embodiment of this application;

[0040] Figure 3 This is a schematic diagram of the configuration content in the configuration file provided in the embodiments of this application;

[0041] Figure 4 This is a schematic diagram of the SoC signal event analysis report output process provided in the embodiments of this application;

[0042] Figure 5 A schematic diagram of the structure of a SoC signal event analysis device provided in an embodiment of this application;

[0043] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0044] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. Based on the embodiments of this application, every other embodiment obtained by those skilled in the art without inventive effort falls within the scope of protection of this application.

[0045] First, the applicable scenarios for this application will be introduced. This application can be applied to the field of chip performance analysis technology.

[0046] SoC signal events refer to communication mechanisms triggered by hardware or software within a system-on-a-chip (SoC) to transmit status, control information, or synchronization instructions between different subsystems, IP cores, or processing units. SoC analysis and verification are required during chip development to ensure that the chip functions correctly and meets performance standards.

[0047] In the current SoC (System on Chip) verification and performance analysis process, the monitoring and statistics of internal performance counters or key events mainly rely on the following three existing technical solutions:

[0048] (1) Outputting simulation events to the log: During the simulation, using the UVM (Universal Verification Methodology) environment or custom SystemVerilog code, when specific events (such as counter overflow or transaction completion) occur, functions such as $display or uvm_info are used to print the count value or event information to the log file. Engineers obtain performance data by parsing the log text.

[0049] (2) Open waveform viewing tools: Use commercial waveform viewing tools such as Verdi and SimVision to manually load the waveform files generated by simulation (such as FSDB, VCD, etc.), locate and observe the changes of specific signals on the time axis through the graphical interface, and manually count the number of events or the accumulated value of the counter.

[0050] (3) Accessing performance counters via bus: In simulation or hardware prototype (such as FPGA prototype, Emulator, ASIC), external test programs or embedded software periodically read the hardware performance counter register values ​​in the design via buses such as APB, AXI or JTAG (Joint Test Action Group) and output them as reports.

[0051] Regarding simulation log output solutions, this approach heavily relies on pre-embedded code in the testbench, making it inflexible in handling new or ad-hoc performance analysis needs. In scenarios such as Emulators, FPGAs, and ASIC prototypes, the lack of a complete UVM environment or simulation control logic makes it difficult to achieve dynamic, fine-grained event log output. Furthermore, log files are large, resulting in low parsing efficiency and an inability to intuitively present timing relationships and multi-dimensional statistical charts. For solutions that rely on waveform viewing tools, engineers must manually locate signals, visually judge transition edges, and manually record values—a tedious and error-prone process. For large-scale SoC designs, with deep signal layers and numerous signals, a single analysis can take hours or even days, failing to meet the demands of rapid iteration verification cycles. Moreover, this method struggles to automate the statistical analysis and trend analysis of batch signals. For bus / JTAG access solutions, reading counters via bus or JTAG relies on existing hardware counter registers in the design, making it impossible to directly monitor arbitrary custom signals or complex events (such as multi-signal logic combinations). Access frequency is limited by bus bandwidth and protocol, potentially missing critical transient events and exhibiting latency. In the early stages of simulation, before the hardware counters were integrated, this method was not applicable, resulting in low efficiency and accuracy for SoC signal event analysis.

[0052] Based on this, embodiments of this application provide a method for analyzing SoC signal events to improve the efficiency and accuracy of SoC signal event analysis.

[0053] Please see Figure 1 , Figure 1 This is a flowchart illustrating a method for analyzing SoC signal events provided in an embodiment of this application. Figure 1 As shown in the embodiments of this application, the method for analyzing SoC signal events includes:

[0054] S101. Obtain the input waveform file to be analyzed, configuration file, and analysis processing time range; the configuration file includes at least one of the following data: signal expression and counting mode.

[0055] S102. Preprocess the configuration file, determine at least one target analysis signal, parse the waveform file to be analyzed, and extract the time point and jump value corresponding to at least one signal jump event of the target analysis signal within the analysis and processing time range.

[0056] S103. After executing the signal expression at the time point corresponding to each signal transition event, record the accumulated event or target value based on the counting mode.

[0057] S104. Based on the accumulated event or target value, output a SoC signal event analysis report for the waveform file to be analyzed.

[0058] The SoC signal event analysis method provided in this application embodiment can automatically analyze and process the obtained waveform file to be analyzed according to the data in the configuration file without modifying the test platform or design code, obtain the accumulated event or target value, and then output the SoC signal event analysis report for the waveform file to be analyzed. This can reduce the error rate of analysis and reduce the analysis and processing time, and help improve the efficiency and accuracy of SoC signal event analysis.

[0059] The exemplary steps of the embodiments of this application are described below:

[0060] S101. Obtain the input waveform file to be analyzed, configuration file, and analysis processing time range; the configuration file includes at least one of the following data: signal expression and counting mode.

[0061] Here, SoC signal events refer to communication mechanisms triggered by hardware or software within a system-on-a-chip (SoC) to transmit status, control information, or synchronization instructions between different subsystems, IP cores, or processing units. SoC analysis and verification are required during chip development to ensure that the chip functions correctly and meets performance standards.

[0062] In existing technologies, simulations typically output changes to logs, and the analysis results are obtained by analyzing the logs; alternatively, engineers manually locate signal changes in the generated waveform files to obtain signal analysis results; or SoC signal event analysis is performed via bus access. These solutions lack the ability to adjust the approach in real time according to analysis needs, or suffer from low manual processing efficiency and high error rates, resulting in both low efficiency and low accuracy in SoC signal event analysis.

[0063] Based on this, in the embodiments of this application, without modifying the test platform or design code, the obtained waveform file to be analyzed can be automatically analyzed and processed according to the data in the configuration file to obtain the accumulated events or target values, and then output a SoC signal event analysis report for the waveform file to be analyzed. This can reduce the error rate of the analysis and reduce the analysis processing time, which helps to improve the efficiency and accuracy of SoC signal event analysis.

[0064] In one possible implementation, the waveform file to be analyzed contains the simulation waveform that needs to be analyzed. Specifically, the simulation waveform is displayed in an EDA simulation tool (such as VCS, Xcelium, QuestaSim, Verilator, and the simulator that comes with Vivado / Quartus) in a time-signal value graphical form, showing the trajectory of each signal (net, register) in the design changing over time.

[0065] Here, the waveform file can be in the format of .fsdb or .vf, etc.

[0066] In one possible implementation, the configuration information in the configuration file can be set according to the SoC signal analysis event requirements for the waveform to be analyzed. Specifically, the configuration file includes at least one of the following data: signal expression and counting mode.

[0067] The signal expression supports multiple operation models. For example, it can support logical operations, arithmetic operations, shifting, sampling, and other calculation modes such as describing specific timing (event A occurs => event B occurs). Users can define the logical path, arithmetic mode, and sampling operator in the signal expression according to their analysis needs, thereby obtaining a signal expression that meets their requirements.

[0068] It also supports multiple counting modes. For example, the counting modes can include at least signed / unsigned accumulation and direct numerical counting modes, which can meet the real-time needs of users for SoC signal event analysis and thus improve the flexibility of SoC signal event analysis.

[0069] In one possible implementation, the user can also input both a start timestamp and an end timestamp, and then determine the analysis and processing time range based on the start timestamp and the end timestamp. In the subsequent analysis process, the focus will be on analyzing the waveforms that are within the analysis and processing time range.

[0070] Furthermore, after obtaining the input waveform file to be analyzed, configuration file, and analysis and processing time range, subsequent processing procedures can be carried out based on the above files.

[0071] S102. Preprocess the configuration file, determine at least one target analysis signal, parse the waveform file to be analyzed, and extract the time point and jump value corresponding to at least one signal jump event of the target analysis signal within the analysis and processing time range.

[0072] In one possible implementation, before performing SoC signal event analysis on the waveform to be analyzed, preprocessing is required based on the configuration file to build a configuration environment that meets the user's needs.

[0073] Specifically, the step "preprocessing the configuration file to determine at least one target analysis signal" includes:

[0074] a1: Based on the configuration file information, parse the main configuration file in the configuration file.

[0075] a2: Recursively load the sub-configuration files referenced in the configuration file to determine at least one target analysis signal for the waveform file to be analyzed.

[0076] In one possible implementation, the configuration file also includes configuration file information, which can determine the configuration file, sub-configuration files, and their underlying HDL paths and alias prefixes to be analyzed for the current SoC signal event analysis, and supports modular configuration reuse during the analysis process.

[0077] For example, please refer to Figure 2 , Figure 2 This is a schematic diagram of a modular configuration provided in an embodiment of this application, such as... Figure 2As shown, the entire SoC configuration file module is named SoC_config.yml. The SoC configuration file includes the IP_CPU performance configuration module, named ip_cpu_perf.yml, the IP_GPU performance configuration module, named ip_gpu_perf.yml, and the IP_MEM performance configuration module, named ip_mem_perf.yml. Furthermore, the IP_CPU performance configuration module also includes a CPU core configuration submodule, named cpu_core.yml, and a cache configuration submodule, named cache.yml.

[0078] In one possible implementation, during the analysis of SoC signal events, if the entire SoC configuration file is not yet ready, the analysis process can be performed on the completed IP_CPU performance configuration file first. If the analysis process determines that the entire SoC configuration file is ready, the analysis process can be performed directly on this SoC configuration file by modifying the file prefix (the name before .yml), thus meeting the user's real-time needs for SoC signal event analysis and improving the flexibility of SoC signal event analysis.

[0079] In one possible implementation, during the preprocessing process, the main configuration file in the configuration file is first parsed according to the configuration file information in the configuration file, and the referenced sub-configuration files are recursively loaded according to the main configuration file. Then, based on the configuration information in the configuration file, at least one target analysis signal that needs to be analyzed in the waveform file to be analyzed is determined.

[0080] Furthermore, the configuration file also includes view mode information, which records the RTL view mode. Here, the RTL view mode is a high-level, logical circuit schematic representation provided by EDA tools (such as Vivado, Quartus, Synopsys, etc.). It shows the circuit structure before the RTL code (Register Transfer Level, code written in hardware description languages ​​such as Verilog / VHDL) is synthesized and mapped to a specific technology library.

[0081] In one possible implementation, the RTL view can include a logic view and a block view. Specifically, the logic view is an abstract representation of the function and structure of a digital circuit design, focusing on the correctness of the logic, data flow, control flow, and interconnections between modules. The block view (or physical planning view) is a representation of the physical design phase, showing the division and layout of the entire chip in physical space. It focuses on area, shape, location, interconnection planning, power distribution, and physical hierarchy.

[0082] In one possible implementation, when processing the waveform to be analyzed, it is generally processed based on the logical view by default. During the SoC physical implementation stage, the RTL hierarchy changes due to block division. If the switch is made from the logical view to the block view, all signal paths will change. In order to ensure the accuracy of subsequent processing, in the preprocessing stage, the view mode indicated by the detection view mode can be determined according to the view mode information in the configuration file. The path conversion operation can be performed for the block view mode.

[0083] Specifically, before the step of "parse the waveform file to be analyzed and extract at least one of the target analysis signals corresponding to at least one signal transition event within the analysis processing time range and the transition value", the analysis method further includes:

[0084] b1: Based on the view mode information, detect whether the view mode indicated by the view mode information is a block view mode.

[0085] b2: If the view mode indicated by the view mode information is a block view mode, load the logical block path mapping file and convert the logical path contained in the signal expression into the corresponding physical path.

[0086] In one possible implementation, based on the view mode information in the configuration file, it is detected whether the view mode indicated by the view mode information is a block view mode. If it is determined that the view mode indicated by the view mode information is a block view mode, the logical block path mapping file is automatically loaded to convert the logical path in the signal expression into a physical path, and to ensure the accuracy of subsequent waveform signal processing through the signal expression.

[0087] In another possible implementation, if the view mode indicated by the view mode information in the configuration file is determined to be a logical view mode, then the logical path is directly used in the signal expression to perform subsequent processing operations.

[0088] Furthermore, if it is determined that preprocessing is performed according to the configuration file first, and the configuration environment that meets the user's needs is completed, the waveform file to be analyzed can be directly parsed, thereby extracting the time point and jump value corresponding to at least one signal transition event of at least one target analysis signal within the analysis and processing time range.

[0089] In one possible implementation, a waveform file can be read by calling a third-party Python library, and then the time point and jump value corresponding to at least one signal transition event of the target analysis signal within the analysis and processing time range can be extracted.

[0090] For example, a third-party Python library could be PyFSDB, which can read the waveform file to be analyzed through a standard waveform interface and extract the time point and jump value corresponding to at least one signal transition event of the target analysis signal within the analysis and processing time range.

[0091] Here, a signal transition event refers to the change in the level value of a signal (wire network or register) in a digital circuit from '0' to '1' (rising edge) or from '1' to '0' (falling edge) at discrete time points. Therefore, the reading and processing of the waveform to be analyzed is to determine the time point and transition value of each rising or falling edge in the target signal to be analyzed.

[0092] Furthermore, after identifying at least one signal transition event, signal expressions can be executed at the time points corresponding to each signal transition event, and then the accumulated events or target values ​​can be recorded through technical modes.

[0093] S103. After executing the signal expression at the time point corresponding to each signal transition event, record the accumulated event or target value based on the counting mode.

[0094] In one possible implementation, to improve the efficiency of computation and evaluation, the signal expression can be compiled to obtain a postfix expression, and then the signal expression can be executed at the time points corresponding to each signal transition event.

[0095] Specifically, before the step "execute the signal expression at the time point corresponding to each signal transition event", the analysis method further includes:

[0096] c1: Compile the signal expression into a postfix expression.

[0097] Here, the signal expression records the current reading target and reading requirements for the waveform to be analyzed.

[0098] For example, the analysis requirement corresponding to the signal expression top.cpu.l1_dcache_ctrl.hit_cnt[63:0] is to directly read the 64-bit counter value; the analysis requirement corresponding to the signal expression (top.axi_noc.node1.arvalid&&top.axi_noc.node1.arready) @ aclk is to count AR channel handshake events; and the analysis requirement corresponding to the signal expression (top.cpu.inst_retired>>2)&1 is to perform shift and mask operations on the instruction retirement counter.

[0099] In one possible implementation, postfix expressions, also known as Reverse Polish notation, are expressions in which the operators are written after the operands. During the compilation of signal expressions, lexical analysis, syntax tree construction, and intermediate code generation can be performed on the signal expressions to convert them into postfix expressions.

[0100] Here, the logical block path mapping file can be generated by EDA tools during the physical implementation phase based on the mapping relationship between logical units and block regions.

[0101] Furthermore, the signal expression is executed at the time point corresponding to each signal event, and then subsequent counting and statistics are performed.

[0102] Specifically, the step "execute the signal expression at the time points corresponding to each signal transition event" includes:

[0103] d1: For each signal transition event, determine the corresponding clock edge and execute the postfix expression at the corresponding clock edge.

[0104] In one possible implementation, for each signal transition event, the postfix expression can be executed at the current time point or the simulation step before the rising edge, and then subsequent recording can be performed.

[0105] Here, the counting mode can include signed / unsigned accumulation, direct numerical processing modes, etc. The specific counting method after executing the postfix expression is recorded in the configuration file.

[0106] In one possible implementation, composite events are also supported during counting. These composite events can correspond to multiple clock edges during the counting process. Composite events can be marked in the configuration file to ensure statistical accuracy.

[0107] For example, a composite event can be an event such as a transaction handshake or a cache hit rate calculation.

[0108] Furthermore, after determining the accumulated events or target values, a SoC signal event analysis report can be output based on the accumulated events or target values ​​for the waveform file to be analyzed.

[0109] S104. Based on the accumulated event or target value, output a SoC signal event analysis report for the waveform file to be analyzed.

[0110] In this embodiment of the application, in order to improve the user experience and ensure that the generated SoC signal event analysis report meets the user's needs, the configuration file also includes report parameter setting information. That is, the report type of the SoC signal event analysis report can be configured in the configuration file to generate a report that meets the user's needs, thereby improving the user experience.

[0111] Specifically, the step "based on the accumulated event or target value, output a SoC signal event analysis report for the waveform file to be analyzed" includes:

[0112] e1: Based on the report parameter settings, determine the target report type and type settings of the analysis report.

[0113] e2: Based on the accumulated event or target value, output the SoC signal event analysis report of the waveform file to be analyzed according to the type setting information.

[0114] Here, the target report type may include at least one of the following: text report, scatter plot, pie chart, and regression-discounted plot.

[0115] Specifically, text reports can list each signal alias, statistical value, percentage, etc. in tabular form, and support highlighting key indicators; scatter plots can be used to show the distribution of SoC signal event occurrence rate over time, with optional moving average filtering; pie charts can visualize the proportion of each SoC signal event count in the total events; regression line charts can perform multinomial fitting (such as linear regression) on time series data and extrapolate future behavior from trends.

[0116] In one possible implementation, after setting the target report type, type setting information corresponding to the target report type can also be set to determine the presentation format of the report under different report types, such as report size and other information.

[0117] For example, the sliding window size can be set for the scatter plot to determine the size of each point in the SoC signal event analysis report scatter plot, so as to meet the user's presentation requirements for the SoC signal event analysis report.

[0118] Here, data fitting and plotting for regression line plots can be handled using open-source libraries such as SciPy and Matplotlib.

[0119] In another possible implementation, the report parameter settings also include a target processing method. The processing method for the target processing data in the report can be determined by configuring the target processing method, thereby obtaining the SoC signal event analysis report.

[0120] Specifically, the step "based on the accumulated event or target value, outputting a SoC signal event analysis report of the waveform file to be analyzed of the target report type according to the type setting information" includes:

[0121] f1: Determine the target processing data in the SoC signal event analysis report. After processing the target processing data according to the target processing method, output the SoC signal event analysis report of the waveform file to be analyzed of the target report type according to the type setting information.

[0122] The target processing method includes at least highlighting the target processing data.

[0123] In one possible implementation, metadata can be configured in the configuration file to indicate the target processing method, that is, to set the required target processing method to the enabled state. For example, rpt_highlight=true corresponds to the target processing method of highlighting the target processing data in the report.

[0124] Here, the target processing method for target data not only includes highlighting the target processed data, but can also be customized according to user needs to meet different viewing requirements of users for SoC signal event analysis reports.

[0125] Furthermore, the configuration file can also include a reset signal expression. The reset signal expression is used to reset the event statistics. After the reset signal expression is triggered, the accumulation process of the event or target value will no longer be performed in the current period.

[0126] In another possible implementation, the configuration file also includes alias information, which is used to indicate the intuitive name of the SoC signal event analysis report output.

[0127] For further details, please refer to Figure 3 , Figure 3 This is a schematic diagram of the configuration content in the configuration file provided in the embodiments of this application; for example... Figure 3As shown, the configuration content includes a report setting dictionary 310, a signal list 320, a configuration file list 330, an RTL view mode 340, and a reset signal 350. The report setting dictionary 310 includes pie charts, regression line charts, and scatter plots; the signal list 320 includes signal expressions, counting modes, aliases, and a metadata list; and the configuration file list 330 includes paths, base HDL paths, and alias prefixes. The configuration file can be obtained by filling in the configuration content through user settings.

[0128] For example, the configuration data in the configuration file can be represented by the following code:

[0129] yaml

[0130] rtl_view: "tile" # Automatically load logical2tile.map

[0131] include_configs:

[0132] - path: "ip_cpu_perf.yml

[0133] base_hdl_path: "top.cpu_subsys"

[0134] alias_prefix: "CPU_"

[0135] signals:

[0136] - expression: "bp_hit @ core_clk"

[0137] count_mode : "unsigned_accumulate"

[0138] alias: "BP_HIT_CNT"

[0139] metadata : {"rpt_highlight": true}

[0140] - expression: "(awvalid&&awready) @ noc_clk"

[0141] count_mode: "unsigned_accumulate"

[0142] alias: "AXI_AW_TRANSACTIONS"

[0143] report_settings:

[0144] scatter_plot :

[0145] window_size: 100

[0146] regression_line:

[0147] fit_method: "linear_polynomial"

[0148] reset_signal: "top.preset_n

[0149] Specifically, the configuration file includes: selecting Tile-View, the system automatically loads the logical2tile.map mapping file, converting the logical path in the signal expression into a physical path; referencing the sub-configuration file ip_cpu_perf.yml and its underlying HDL path top.cpu_subsys with the alias prefix "CPU_"; signal expression: bp_hit @core_clk; counting mode: unsigned accumulation; alias: BP_HIT_CNT; metadata: report highlighting; signal expression: (awvalid&&awready) @ noc_clk; counting mode: unsigned accumulation; alias: AXI_AW_TRANSACTIONS; report settings: scatter plot: sliding window size of 100; regression line plot: fit_method: "linear_polynomial"; and reset signal expression: "top.preset_n".

[0150] For further details, please refer to Figure 4 , Figure 4 This is a schematic diagram of the SoC signal event analysis report output process provided in the embodiments of this application; as follows: Figure 4 As shown, the input layer takes waveform files, configuration files, and analysis time ranges as input. Further, preprocessing is performed through a configuration parsing and preprocessing engine. Specifically, the main configuration file is parsed, and referenced sub-configurations are recursively loaded. The RTL view mode is determined; if it's a logical view mode, the logical path is used directly; if it's a block view mode, the logical block path mapping file is loaded, converting the logical paths contained in the signal expression into corresponding physical paths. Further, waveform analysis is performed through the core processing engine. Specifically, the waveform parsing module reads signal transition events, the expression compilation module compiles the signal expression into an optimized postfix expression, and the event statistics module executes the expression on the clock edge, accumulating or recording values ​​according to the calculation mode. Finally, the output generator outputs reports including text reports, scatter plots, pie charts, and regression line charts.

[0151] In this embodiment, waveform files are directly parsed without intruding into the test platform or design code, making it suitable for various scenarios such as simulation, emulator, and FPGA prototyping, overcoming the dependence of existing technologies on specific environments. Monitoring targets are defined through configuration files, supporting batch signals and complex events, replacing manual log parsing or waveform browsing, and improving processing efficiency. Automatic path mapping of logic block path mapping files is introduced, allowing the same configuration to be reused in both logic views and block views, significantly improving the reusability of the verification environment and the efficiency of project iteration. Multiple statistical analysis algorithms and visualization charts are integrated to enhance the richness of report output dimensions and styles.

[0152] The SoC signal event analysis method provided in this application acquires an input waveform file to be analyzed, a configuration file, and an analysis processing time range. The configuration file includes at least one of the following data: a signal expression and a counting mode. The configuration file is preprocessed to determine at least one target analysis signal. The waveform file to be analyzed is parsed, and the time points and jump values ​​corresponding to at least one signal transition event of the at least one target analysis signal within the analysis processing time range are extracted. After executing the signal expression at the time points corresponding to each signal transition event, the accumulated event or target value is recorded based on the counting mode. Based on the accumulated event or target value, an SoC signal event analysis report for the waveform file to be analyzed is output. In this way, without modifying the test platform or design code, the acquired waveform file to be analyzed is automatically analyzed and processed according to the data in the configuration file to obtain the accumulated event or target value, and then an SoC signal event analysis report for the waveform file to be analyzed is output. This can reduce the error rate of the analysis and reduce the analysis processing time, which helps to improve the efficiency and accuracy of SoC signal event analysis.

[0153] Based on the same inventive concept, this application also provides an SoC signal event analysis device corresponding to the SoC signal event analysis method. Since the principle of the device in this application is similar to the SoC signal event analysis method described above in this application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0154] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of a SoC signal event analysis device provided in an embodiment of this application. Figure 5 As shown, the analysis device 500 includes:

[0155] The file input module 510 is used to acquire the input waveform file to be analyzed, the configuration file, and the analysis and processing time range; the configuration file includes at least one of the following data: signal expression and counting mode;

[0156] Waveform analysis module 520 is used to preprocess the configuration file, determine at least one target analysis signal, parse the waveform file to be analyzed, and extract the time point and jump value corresponding to at least one signal jump event of at least one target analysis signal within the analysis and processing time range.

[0157] The event statistics module 530 is used to record the accumulated event or target value based on the counting mode after executing the signal expression at the time point corresponding to each signal transition event;

[0158] The report output module 540 is used to output a SoC signal event analysis report for the waveform file to be analyzed based on the accumulated event or target value.

[0159] In one possible implementation, the configuration file further includes configuration file information: when the waveform analysis module 520 is used to preprocess the configuration file and determine at least one target analysis signal, the waveform analysis module 520 is used to:

[0160] Based on the configuration file information, parse the main configuration file in the configuration file;

[0161] The sub-configuration files referenced in the configuration file are recursively loaded to determine at least one target analysis signal for the waveform file to be analyzed.

[0162] In one possible implementation, the configuration file further includes view mode information; the analysis device 500 also includes a path conversion module (not shown in the figure), the path conversion module being used for:

[0163] Based on the view mode information, it is detected whether the view mode indicated by the view mode information is a block view mode;

[0164] If the view mode indicated by the view mode information is a block view mode, load the logical block path mapping file and convert the logical path contained in the signal expression into the corresponding physical path.

[0165] In one possible implementation, the analysis device 500 further includes an expression conversion module (not shown in the figure), the expression conversion module being used for:

[0166] The signal expression is compiled into a postfix expression.

[0167] In one possible implementation, when the waveform analysis module 520 executes the signal expression at the time points corresponding to each signal transition event, the waveform analysis module 520 is configured to:

[0168] For each signal transition event, determine the corresponding clock edge and execute the postfix expression at the corresponding clock edge.

[0169] In one possible implementation, the configuration file further includes report parameter setting information; when the report output module 540 outputs a SoC signal event analysis report for the waveform file to be analyzed based on the accumulated event or target value, the report output module 540 is used for:

[0170] Based on the report parameter settings, determine the target report type and type settings for the analysis report;

[0171] Based on the accumulated event or target value, output a SoC signal event analysis report of the waveform file to be analyzed, according to the type setting information.

[0172] In one possible implementation, the report parameter setting information further includes a target processing method; when the report output module 540 outputs a SoC signal event analysis report of the waveform file to be analyzed of the target report type according to the type setting information based on the accumulated event or target value, the report output module 540 is used to:

[0173] The target processing data in the SoC signal event analysis report is determined. After processing the target processing data according to the target processing method, the SoC signal event analysis report of the waveform file to be analyzed of the target report type is output according to the type setting information.

[0174] The target processing method includes at least highlighting the target processing data.

[0175] The SoC signal event analysis apparatus provided in this application acquires an input waveform file to be analyzed, a configuration file, and an analysis processing time range. The configuration file includes at least one of the following data: a signal expression and a counting mode. The configuration file is preprocessed to determine at least one target analysis signal. The waveform file to be analyzed is parsed, and the time points and jump values ​​corresponding to at least one signal transition event of the at least one target analysis signal within the analysis processing time range are extracted. After executing the signal expression at each time point corresponding to a signal transition event, the accumulated event or target value is recorded based on the counting mode. Based on the accumulated event or target value, an SoC signal event analysis report for the waveform file to be analyzed is output. In this way, without modifying the test platform or design code, the acquired waveform file to be analyzed is automatically analyzed according to the data in the configuration file to obtain the accumulated event or target value, and then an SoC signal event analysis report for the waveform file to be analyzed is output. This reduces the error rate and processing time, and helps improve the efficiency and accuracy of SoC signal event analysis.

[0176] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6 As shown, the electronic device 600 includes a processor 610, a memory 620, and a bus 630.

[0177] The memory 620 stores machine-readable instructions executable by the processor 610. When the electronic device 600 is running, the processor 610 and the memory 620 communicate via the bus 630. When the machine-readable instructions are executed by the processor 610, they can perform the operations described above. Figure 1 The steps of the SoC signal event analysis method in the method embodiment shown are described in detail in the method embodiment, and will not be repeated here.

[0178] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can perform the above-described actions. Figure 1 The steps of the SoC signal event analysis method in the method embodiment shown are described in detail in the method embodiment, and will not be repeated here.

[0179] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0180] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0181] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0182] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0183] If the aforementioned functions 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. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0184] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for analyzing SoC signal events, characterized in that, The analytical method includes: The system acquires the input waveform file to be analyzed, configuration file, and analysis processing time range. The configuration file includes at least one of the following data: signal expression and counting mode. SoC signal events refer to communication mechanisms triggered by hardware or software within the system-on-a-chip (SoC) for transmitting status, control information, or synchronization instructions between different subsystems, IP cores, or processing units. The signal expression supports multiple operational models and multiple counting modes. The signal expression is determined by defining the logical path, arithmetic mode, and sampling operator within the signal expression based on the analysis requirements. Preprocess the configuration file to determine at least one target analysis signal, parse the waveform file to be analyzed, and extract the time point and jump value corresponding to at least one signal jump event of at least one target analysis signal within the analysis and processing time range. After executing the signal expression at the time point corresponding to each signal transition event, the accumulated event or target value is recorded based on the counting mode; Based on the accumulated events or target values, output a SoC signal event analysis report for the waveform file to be analyzed.

2. The analytical method according to claim 1, characterized in that, The configuration file also includes configuration file information: the preprocessing of the configuration file to determine at least one target analysis signal includes: Based on the configuration file information, parse the main configuration file in the configuration file; The sub-configuration files referenced in the configuration file are recursively loaded to determine at least one target analysis signal for the waveform file to be analyzed.

3. The analytical method according to claim 1, characterized in that, The configuration file also includes view mode information; before parsing the waveform file to be analyzed and extracting at least one of the target analysis signals, and before the analysis processing time range includes at least one signal transition event corresponding to the time point and transition value, the analysis method further includes: Based on the view mode information, it is detected whether the view mode indicated by the view mode information is a block view mode; If the view mode indicated by the view mode information is a block view mode, load the logical block path mapping file and convert the logical path contained in the signal expression into the corresponding physical path.

4. The analytical method according to claim 1, characterized in that, Before executing the signal expression at the time points corresponding to each signal transition event, the analysis method further includes: The signal expression is compiled into a postfix expression.

5. The analytical method according to claim 4, characterized in that, Executing the signal expression at the time points corresponding to each signal transition event includes: For each signal transition event, determine the corresponding clock edge and execute the postfix expression at the corresponding clock edge.

6. The analytical method according to claim 1, characterized in that, The configuration file also includes report parameter settings; the step of outputting a SoC signal event analysis report for the waveform file to be analyzed based on the accumulated event or target value includes: Based on the report parameter settings, determine the target report type and type settings for the analysis report; Based on the accumulated event or target value, output a SoC signal event analysis report of the waveform file to be analyzed, according to the type setting information.

7. The analytical method according to claim 6, characterized in that, The report parameter settings also include the target processing method; the SoC signal event analysis report, which outputs the waveform file to be analyzed of the target report type according to the type settings based on the accumulated event or target value, includes: The target processing data in the SoC signal event analysis report is determined. After processing the target processing data according to the target processing method, the SoC signal event analysis report of the waveform file to be analyzed of the target report type is output according to the type setting information. The target processing method includes at least highlighting the target processing data.

8. An analysis device for SoC signal events, characterized in that, The analytical apparatus includes: The file input module is used to acquire the input waveform file to be analyzed, configuration file, and analysis processing time range. The configuration file includes at least one of the following data: signal expression and counting mode. SoC signal events refer to communication mechanisms triggered by hardware or software within the system-on-a-chip (SoC) for transmitting status, control information, or synchronization instructions between different subsystems, IP cores, or processing units. The signal expression supports multiple computational models and multiple counting modes. The signal expression is determined by defining the logical path, arithmetic mode, and sampling operator within the signal expression based on the analysis requirements. The waveform analysis module is used to preprocess the configuration file, determine at least one target analysis signal, parse the waveform file to be analyzed, and extract the time point and jump value corresponding to at least one signal jump event of the target analysis signal within the analysis and processing time range. The event statistics module is used to record the accumulated events or target values ​​based on the counting mode after executing the signal expression at the time point corresponding to each signal transition event; The report output module is used to output a SoC signal event analysis report for the waveform file to be analyzed, based on the accumulated event or target value.

9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the memory via the bus, and the processor executes the machine-readable instructions to perform the steps of the SoC signal event analysis method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the SoC signal event analysis method according to any one of claims 1 to 7.

Images