SoC verification acceleration method, system, medium and terminal based on simulation performance image

Abstract

The application provides a SoC verification acceleration method, system, medium and terminal based on simulation performance portrait, obtains running performance data of a plurality of historical simulation test cases and generates a simulation performance portrait; compares simulation configuration data of a current simulation test case with simulation configuration data of the historical simulation test cases, generates configuration consistency analysis results, determines a matching target performance portrait according to the configuration consistency analysis results, and generates bottleneck identification results; determines one or more target acceleration parameters according to the configuration consistency analysis results, the bottleneck identification results and parameter enabling rules, and executes the current simulation test case; collects running feedback data in the execution process to adjust the enabling priority of the target acceleration parameters. The application reduces repeated compilation, initialization and simulation running overhead, improves SoC simulation verification efficiency, and shortens the verification period.

Description

Technical Field

[0001] This application relates to the field of SoC simulation verification technology, and in particular to a method, system, medium and terminal for accelerating SoC verification based on simulation performance profiling. Background Technology

[0002] As the integration level of System-on-Chips (SoCs) continues to increase, the number and types of functional modules integrated into a single chip are constantly growing. Modern SoCs typically include a Central Processing Unit (CPU) subsystem, a Network on Chip (NoC) interconnect, a DDR controller, high-speed interface modules, an Artificial Intelligence (AI) computing unit, a security module, and various peripheral controllers. With the increasing complexity of chip functions, the degree of module coupling, and the level of hardware-software collaboration, chip verification has gradually evolved from single-intellectual property (IP) level verification to complex system-level joint verification of multiple subsystems and functional modules. In large-scale SoC development, it is usually necessary to construct a large number of test cases for different functions, data paths, interface protocols, operating states, and abnormal scenarios, and continuously verify the chip design through batch regression. Therefore, improving the efficiency of SoC simulation verification, shortening the verification cycle, and reducing the computing and storage resources consumed in the verification process are of great significance for improving chip development efficiency.

[0003] Current SoC simulation verification typically involves building a simulation environment based on register-transfer level design, a verification platform, and related verification components, sequentially going through stages such as compilation, elaboration, system initialization, and simulation execution. During compilation and elaboration, the SoC design files, verification platform files, and related verification components need to be processed to build the corresponding simulation environment. During system initialization, register configuration, memory data loading, and software startup are usually required. Subsequently, corresponding test cases drive the SoC design to run and complete the corresponding functional verification. In large-scale regression verification, the above compilation, elaboration, system initialization, and simulation execution processes often need to be repeatedly executed for a large number of test cases. Furthermore, in gate-level simulation (GLS) scenarios, gate-level netlists, standard cell libraries, and standard delay format (SDF) files also need to be loaded to complete timing annotation and environment construction to check the timing consistency and post-processing behavior correctness of the chip design. Since gate-level post-simulation projects are usually larger in scale, and the compilation, environment construction, and timing annotation processes are time-consuming, the efficiency problem of post-simulation verification becomes even more prominent.

[0004] However, the existing SoC simulation and verification process still has the following shortcomings:

[0005] (1) Due to the large scale of SoC design and the large number of functional modules it contains, the full compilation and elaboration process is time-consuming, which significantly increases the compilation time and affects the efficiency of verification iteration.

[0006] (2) During the simulation operation phase, a large number of complex functional modules participate in event scheduling and signal flipping. Unrelated complex modules introduce a lot of additional overhead, reducing the overall simulation operation speed.

[0007] (3) During the system initialization phase, operations such as register configuration, memory loading and software startup often need to be repeated for different test cases. Some register configurations are usually completed one by one through front gate bus transactions such as AXI, APB or AHB, resulting in low efficiency during the initialization phase.

[0008] (4) For gate-level post-simulation, even if different test cases use the same or basically the same gate-level netlist, SDF file and verification platform configuration, the compilation, refinement and SDF annotation environment construction may still be repeatedly executed, resulting in high gate-level post-simulation verification cost.

[0009] (5) Existing regression verification is usually performed according to a pre-configured set of test cases and a fixed scheduling method. It does not make full use of the commonalities in configuration, operational characteristics and differences in resource consumption among different test cases, resulting in a relatively crude regression scheduling problem.

[0010] (6) For configurations that affect verification efficiency, such as compilation method, initialization method, simulation model, access method and different simulation running modes, the existing solutions rely heavily on verification personnel to manually select and adjust based on project experience. It is difficult to perform targeted parameter tuning based on the actual running status of different test cases, and there is a problem that parameter tuning depends on manual experience. Summary of the Invention

[0011] In view of the shortcomings of the prior art described above, the purpose of this application is to provide a SoC verification acceleration method, system, medium and terminal based on simulation performance profiling, to solve the technical problems of low overall simulation verification efficiency and long verification cycle in the existing SoC simulation verification process.

[0012] To achieve the above and other related objectives, a first aspect of this application provides a SoC verification acceleration method based on simulation performance profiles, comprising: acquiring runtime performance data generated by the SoC design to be verified when executing multiple historical simulation test cases, and generating a simulation performance profile based on the runtime performance data; acquiring simulation configuration data of the current simulation test case, and comparing the simulation configuration data of the current simulation test case with the simulation configuration data of each of the historical simulation test cases to generate a configuration consistency analysis result for the current simulation test case; determining a target performance profile matching the current simulation test case from the simulation performance profile based on the configuration consistency analysis result, and generating a bottleneck identification result for the current simulation test case based on the target performance profile; determining one or more target acceleration parameters based on the configuration consistency analysis result and the bottleneck identification result, and based on parameter activation rules; executing the current simulation test case according to the one or more target acceleration parameters, and collecting runtime feedback data during the execution of the current simulation test case to update the activation priority of the target acceleration parameters.

[0013] In some embodiments of the first aspect of this application, the target acceleration parameters include snapshot reuse parameters; wherein, the method of executing the current simulation test case according to one or more of the target acceleration parameters includes: when the snapshot reuse parameters are enabled, determining a target simulation snapshot result from multiple generated simulation snapshot results; loading the target simulation snapshot result, and controlling the current simulation test case to start running from the simulation state corresponding to the target simulation snapshot result to execute the current simulation test case.

[0014] In some embodiments of the first aspect of this application, the method of collecting runtime feedback data and updating the activation priority of the target acceleration parameter includes: determining the acceleration benefit corresponding to the target acceleration parameter based on the runtime feedback data; if the acceleration benefit corresponding to the target acceleration parameter meets a preset benefit condition, then increasing the activation priority of the target acceleration parameter during the execution of subsequent simulation test cases of the same type; if the acceleration benefit corresponding to the target acceleration parameter does not meet the preset benefit condition, then decreasing the activation priority of the target acceleration parameter during the execution of subsequent simulation test cases of the same type.

[0015] In some embodiments of the first aspect of this application, the target acceleration parameters include RTL module simplification replacement parameters; wherein, the method of executing the current simulation test case according to one or more of the target acceleration parameters includes: when the RTL module simplification replacement parameters are enabled, determining a target RTL module from multiple RTL functional modules of the SoC design to be verified; replacing the target RTL module, and executing the current simulation test case based on the replaced SoC design to be verified.

[0016] In some embodiments of the first aspect of this application, the target acceleration parameters include register backdoor configuration parameters; wherein, the method of executing the current simulation test case according to one or more of the target acceleration parameters includes: when the register backdoor configuration parameters are enabled, determining the target register that is allowed to be accessed by the backdoor; switching the configuration mode of the target register from front door bus access to backdoor access in order to execute the current simulation test case.

[0017] In some embodiments of the first aspect of this application, the target acceleration parameters include partitioned compilation parameters; wherein, the method of executing the current simulation test case according to one or more of the target acceleration parameters includes: when the partitioned compilation parameters are enabled, determining the affected compilation partition, the unaffected compilation partition, and the dependent compilation partitions that have a dependency relationship with the affected compilation partition; recompiling the affected compilation partition and the dependent compilation partition, and reusing the historical compilation results corresponding to the unaffected compilation partition, thereby executing the current simulation test case.

[0018] In some embodiments of the first aspect of this application, the target acceleration parameters include access mode parameters; wherein, the method of executing the current simulation test case according to one or more of the target acceleration parameters includes: when the access mode parameters are enabled, switching the CPU real execution mode corresponding to the current simulation test case to the VIP access mode; generating a VIP transaction according to the software access intent corresponding to the CPU real execution mode, and executing the current simulation test case based on the VIP transaction.

[0019] To achieve the above and other related objectives, a second aspect of this application provides a SoC verification acceleration system based on simulation performance profiles, comprising: a performance profile acquisition module, configured to acquire runtime performance data generated by the SoC design to be verified when executing multiple historical simulation test cases, and generate a simulation performance profile based on the runtime performance data; a configuration consistency analysis module, configured to acquire simulation configuration data of the current simulation test case, and compare the simulation configuration data of the current simulation test case with the simulation configuration data of each of the historical simulation test cases to generate a configuration consistency analysis result for the current simulation test case; a bottleneck identification module, configured to determine a target performance profile matching the current simulation test case from the simulation performance profiles based on the configuration consistency analysis result, and generate a bottleneck identification result for the current simulation test case based on the target performance profile; a parameter decision module, configured to determine one or more target acceleration parameters based on the configuration consistency analysis result and the bottleneck identification result of the current simulation test case, and based on parameter activation rules; and an acceleration management module, configured to execute the current simulation test case according to one or more target acceleration parameters, and collect runtime feedback data during the execution of the current simulation test case to update the activation priority of the target acceleration parameters.

[0020] To achieve the above and other related objectives, a third aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the SoC verification acceleration method based on simulation performance profiling as described above.

[0021] To achieve the above and other related objectives, a fourth aspect of this application provides an electronic terminal, including a memory, a processor, and a computer program stored in the memory; the processor executes the computer program to implement the SoC verification acceleration method based on simulation performance profiles as described above.

[0022] As described above, the SoC verification acceleration method, system, medium, and terminal based on simulation performance profiling of this application have the following beneficial effects:

[0023] (1) Reduce the overhead of repeated compilation and refinement: By generating simulation performance profiles and combining configuration consistency analysis, simulation test cases with reuse conditions are identified, and snapshot reuse parameters or partition compilation parameters are selected according to the bottleneck identification results, so that subsequent simulation test cases can reuse existing simulation states or historical compilation results that are not affected by file changes, reducing the repeated full compilation and refinement process and improving design iteration efficiency.

[0024] (2) Reduce the simulation overhead of irrelevant RTL functional modules: Identify high-overhead modules based on the processor time ratio, event hotspot distribution and signal flip rate of RTL functional modules, and replace irrelevant complex modules with lightweight models without affecting the current verification target, thereby reducing irrelevant event scheduling and signal flipping and improving the running speed of individual simulation test cases.

[0025] (3) Shorten system initialization and CPU execution time: For register configuration of non-verification targets, register backdoor configuration parameters can be enabled to reduce transaction overhead caused by configuring each item through the front door bus; For simulation test cases that do not depend on the actual software execution process of the CPU, VIP access mode can be used to generate equivalent access transactions, thereby reducing simulation time caused by repeated register configuration, software startup and instruction execution.

[0026] (4) Reduce the cost of repeated construction of gate-level post-simulation environment: By comparing the current gate-level post-simulation configuration with the image configuration information of the existing gate-level post-simulation image, the gate-level post-simulation image can be reused when the matching conditions are met, so that multiple post-simulation test cases can share the existing gate-level netlist compilation, refinement and SDF timing annotation environment construction results, reduce repeated post-simulation environment construction and improve gate-level post-simulation verification efficiency.

[0027] (5) Improve the utilization of historical information between different simulation test cases: By forming a simulation performance profile of historical simulation test cases and performing configuration consistency analysis between current simulation test cases and historical simulation test cases, the performance characteristics of historical test cases can be used to predict the performance bottlenecks that may exist in the current test cases, thereby determining the corresponding target acceleration parameters for different simulation scenarios and improving the targeting of parameter configuration in large-scale regression verification.

[0028] (6) Reduce the dependence of acceleration parameter selection on human experience: By configuring consistency analysis, bottleneck identification and parameter activation rules, one or more target acceleration parameters are automatically determined, and running feedback data is collected during the simulation execution. The activation priority of the corresponding target acceleration parameters is dynamically adjusted according to the actual acceleration benefits, so that the acceleration parameters can be continuously optimized in combination with historical execution effects, reducing the problem of relying on verification personnel to manually select and statically configure parameters. Attached Figure Description

[0029] Figure 1 The diagram shown is a flowchart of a SoC verification acceleration method based on simulation performance profiling in one embodiment of this application.

[0030] Figure 2 The diagram shows a flowchart of updating the target acceleration parameter enable priority in one embodiment of this application.

[0031] Figure 3 The diagram shown is a schematic block diagram of a SoC verification acceleration system based on simulation performance profiling in one embodiment of this application.

[0032] Figure 4 The diagram shown is a structural schematic of an electronic terminal according to an embodiment of this application. Detailed Implementation

[0033] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, unless otherwise specified, the following embodiments and features in the embodiments can be combined with each other.

[0034] In the embodiments of this application, the terms "first" and "second" are used to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that the terms "first" and "second" do not necessarily imply that they are different.

[0035] It should be noted that, in the embodiments of this application, the words "exemplary" or "for example" indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0036] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0037] Before providing a further detailed description of this application, the nouns and terms used in the embodiments of this application are explained, and the nouns and terms used in the embodiments of this application shall be interpreted as follows:

[0038] <1> RTL (Register Transfer Level): A digital circuit design abstraction level used to describe the data transfer relationships between registers, as well as the combinational and sequential logic that controls these data transfers.

[0039] <2> DDR (Double Data Rate): In the field of integrated circuit and memory technology, it usually refers specifically to Double Data Rate Synchronous Dynamic Random Access Memory.

[0040] <3> AXI (Advanced eXtensible Interface): Advanced eXtensible Interface.

[0041] <4> APB (Advanced Peripheral Bus): Advanced Peripheral Bus.

[0042] <5> AHB (Advanced High-performance Bus): Advanced High-performance bus.

[0043] <6> GPU (Graphics Processing Unit): A graphics processor used to perform computational tasks such as graphics rendering and parallel data processing.

[0044] <7> ISP (Image Signal Processor): An image signal processor is used to process the raw image data output by the image sensor, such as noise reduction, white balance, color correction, and exposure adjustment.

[0045] <8> DMA (Direct Memory Access): Direct memory access allows data transfer between memory, peripherals, or different storage spaces directly by DMA control logic without requiring continuous CPU involvement in data movement.

[0046] <9> VIP (Verification IP): A verification component in a simulation verification environment. It can actively generate, receive, or monitor transactions according to a specific bus or interface protocol to simulate the protocol behavior of a real master or slave device.

[0047] To facilitate understanding of the embodiments of this application, firstly, in conjunction with Figure 1 Detailed explanation. Figure 1 This document illustrates a flowchart of the SoC verification acceleration method based on simulation performance profiling, as described in an embodiment of this application. The SoC verification acceleration method based on simulation performance profiling in this embodiment mainly includes the following steps:

[0048] S101: Obtain the runtime performance data generated by the SoC design to be verified when executing multiple historical simulation test cases, and generate a simulation performance profile based on the runtime performance data.

[0049] In this embodiment, runtime performance data generated by the SoC design to be verified during the execution of multiple historical simulation test cases is obtained. The SoC design includes multiple RTL functional modules. The historical simulation test cases are test cases that have been simulated and run for the SoC design to be verified. The runtime performance data is used to reflect the performance overhead generated by each historical simulation test case at different simulation stages, including but not limited to: simulation stage-level performance data and module-level performance data. Among them, simulation stage-level performance data includes but is not limited to: compilation time, refinement time, system initialization time, simulation execution time, etc. Module-level performance data includes but is not limited to: processor time percentage, event hotspot distribution, signal toggle rate, etc., corresponding to each RTL functional module, to characterize the contribution of each RTL functional module to the overall simulation runtime overhead.

[0050] In this embodiment, the runtime performance data corresponding to each historical simulation test case is associated with the corresponding historical simulation test case, and the runtime performance data is collected according to the simulation test case and simulation stage to generate a simulation performance profile. The simulation performance profile is used to characterize the performance overhead of different historical simulation test cases in one or more stages of compilation, refinement, system initialization, and simulation operation. With the collection of module-level performance data, it further characterizes the performance overhead distribution of each RTL functional module in the execution process of the corresponding historical simulation test case, so as to provide historical runtime performance information for identifying the performance bottleneck of the current simulation test case.

[0051] S102: Obtain the simulation configuration data of the current simulation test case, and compare the simulation configuration data of the current simulation test case with the simulation configuration data of each of the historical simulation test cases to generate the configuration consistency analysis result of the current simulation test case.

[0052] In this embodiment, simulation configuration data for the current simulation test case is obtained. This data characterizes the design version, verification environment, and runtime environment configuration corresponding to the current simulation test case. The simulation configuration data includes, but is not limited to: RTL files, file lists, macro definitions, include file paths, top-level module names, verification platform configurations, verification component configurations, initialization images, register configurations, software images, gate-level netlists, SDF files, and simulation tool versions. For different types of simulation test cases, corresponding configuration items can be selected based on the specific simulation scenario. For example, in an RTL simulation scenario, RTL files, file lists, macro definitions, top-level module names, verification platform configurations, and verification component configurations can be selected. In a gate-level post-simulation scenario, gate-level netlists, SDF files, and simulation tool versions can also be selected.

[0053] In this embodiment, each simulation configuration data of the current simulation test case is compared item by item with the simulation configuration data corresponding to each historical simulation test case. This determines the consistent and differing configuration items between the current simulation test case and each historical simulation test case, and generates a configuration consistency analysis result based on the comparison results. The configuration consistency analysis result characterizes the degree of configuration consistency between the current simulation test case and the corresponding historical simulation test case.

[0054] S103: Based on the configuration consistency analysis results, determine the target performance profile that matches the current simulation test case from the simulation performance profile, and generate the bottleneck identification result of the current simulation test case based on the target performance profile.

[0055] In this embodiment, based on the configuration consistency analysis results between the current simulation test case and each historical simulation test case, one or more target historical simulation test cases with the same or similar configuration as the current simulation test case are identified from multiple historical simulation test cases. Then, the runtime performance data corresponding to one or more target historical simulation test cases is extracted from the simulation performance profile to form a target performance profile matching the current simulation test case. The target performance profile includes, but is not limited to: compilation time, refinement time, system initialization time, simulation runtime, processor time percentage for each RTL functional module, event hotspot distribution, and signal toggle rate, etc., corresponding to the target historical simulation test case. This allows the actual runtime performance of historical simulation test cases with the same or similar configurations to characterize the potential performance characteristics of the current simulation test case.

[0056] In this embodiment, performance bottlenecks in the current simulation test case are identified based on various runtime performance data in the target performance profile, and bottleneck identification results are generated. For example, when the target performance profile indicates high compilation or refinement time, the compilation or refinement stage can be identified as the bottleneck stage. When system initialization time is high, the system initialization stage can be identified as the bottleneck stage. When the processor time of one or more RTL functional modules is high during simulation, forming event hotspots, or having a high signal toggle rate, the corresponding RTL functional module can be identified as the bottleneck module of the simulation run phase.

[0057] S104: Based on the configuration consistency analysis results of the current simulation test case and the bottleneck identification results, and based on the parameter activation rules, perform parameter activation determination to determine one or more target acceleration parameters.

[0058] In this embodiment, the target acceleration parameters include, but are not limited to: snapshot reuse parameters, dummy empty RTL module replacement parameters, register backdoor access parameters, partition compile parameters, access mode parameters, and gate-level post-image reuse parameters.

[0059] In this embodiment, based on the configuration consistency analysis results and bottleneck identification results, one or more of the above-mentioned snapshot reuse parameters, RTL module simplified replacement parameters, register backdoor configuration parameters, partition compilation parameters, access mode parameters, and gate-level post-image reuse parameters are selected for use in combination.

[0060] In this embodiment, the parameter enabling rules include snapshot enabling rules. The snapshot enabling rules determine whether to enable snapshot reuse parameters. The snapshot enabling rules include:

[0061] (1) Based on the bottleneck identification results, determine whether the current simulation test case has a target bottleneck suitable for reducing simulation overhead through snapshot reuse. For example, when the bottleneck identification result indicates that the compilation time or refinement time reaches the corresponding first preset time threshold, it is determined that the current simulation test case has a compilation bottleneck or refinement bottleneck. When the bottleneck identification result indicates that the system initialization time reaches the corresponding second preset time threshold, it is determined that the current simulation test case has a system initialization bottleneck. In the gate-level post-simulation scenario, when the gate-level post-simulation environment construction time reaches the corresponding third preset time threshold, it is determined that the current simulation test case has a gate-level post-simulation environment construction bottleneck. In the simulation scenario that requires CPU software startup, when the CPU software startup time reaches the corresponding fourth preset time threshold, it is determined that the current simulation test case has a software startup bottleneck.

[0062] (2) Based on the configuration consistency analysis results, determine whether the current simulation test case meets the configuration consistency conditions corresponding to snapshot reuse. Specifically, compare at least one of the following with the corresponding historical simulation test cases: RTL file, file list, macro definition, include file path, top-level module name, verification platform configuration, verification component configuration, initialization image, register configuration, software image, gate-level netlist, SDF file, and simulation tool version. When the current simulation test case is consistent with the preset key configuration items corresponding to the current simulation scenario, and only the runtime parameters such as simulation test case name, access address, data mode, random seed, check item, or waveform dump range differ, it is determined that the current simulation test case meets the configuration consistency conditions corresponding to snapshot reuse.

[0063] (3) When the bottleneck identification result indicates that the current simulation test case has a target bottleneck that is suitable for reducing simulation overhead through snapshot reuse, and the configuration consistency analysis result indicates that the current simulation test case meets the configuration consistency conditions corresponding to snapshot reuse, the snapshot reuse parameter is determined as the target acceleration parameter.

[0064] In this embodiment, the parameter activation rules include replacement activation rules. Based on the replacement activation rules, it is determined whether to enable the RTL module to simplify parameter replacement. The replacement activation rules include:

[0065] (1) Based on the bottleneck identification results, candidate RTL modules with high simulation runtime overhead are identified from the multiple RTL functional modules constituting the SoC design to be verified. Specifically, the simulation runtime overhead generated by the corresponding RTL functional module during the execution of the current simulation test case can be determined based on the processor time consumption ratio, event hotspot distribution, or signal toggle rate of each RTL functional module, and the RTL functional modules with high simulation runtime overhead are identified as candidate RTL modules.

[0066] (2) Based on the verification objective of the current simulation test case, determine the applicability of the candidate RTL module for replacement. Specifically, determine whether the candidate RTL module is a direct verification object of the current simulation test case, and whether the output of the candidate RTL module affects the correctness of the current verification objective. When the candidate RTL module is not a direct verification object of the current simulation test case, and its output does not affect the correctness of the current verification objective, further determine whether the candidate RTL module can maintain system stability through fixed response, idle response, or protocol compatible response, and whether the top-level connection, reset behavior, and basic protocol timing of the SoC design to be verified can be maintained after replacement, and whether the replacement behavior can be enabled or disabled through configuration parameters.

[0067] (3) When a candidate RTL module is not a direct verification object of the current simulation test case, its output does not affect the correctness of the current verification target, and it can maintain system stability through a simplified response method, and can maintain top-level connections, reset behavior, and basic protocol timing after replacement, and the replacement behavior can be enabled or disabled through configuration parameters, the candidate RTL module is determined to meet the replacement enable rule. At this time, the simplified replacement parameters of the RTL module are enabled, and the simplified replacement parameters of the RTL module are determined as one of the target acceleration parameters. When performing simulation acceleration operations in the future, the RTL functional modules that meet the replacement enable rule are replaced with empty modules, fixed response modules, lightweight behavior models, or interface preservation models.

[0068] In this embodiment, the parameter enabling rules include backdoor configuration enabling rules. Based on the backdoor configuration enabling rules, it is determined whether to enable the register backdoor configuration parameters. The backdoor configuration enabling rules include:

[0069] (1) Based on the bottleneck identification results, determine whether there is simulation time related to register configuration in the current simulation test case. When the bottleneck identification results indicate that there is high simulation time in the system initialization or configuration phase, analyze the register configuration process in the current simulation test case and determine the candidate registers to be configured through the front gate bus access.

[0070] (2) Based on the verification objective of the current simulation test case, determine the applicability of candidate registers for backdoor access. When a candidate register is only used to construct the pre-test state of the current simulation test case, and the verification objective of the current simulation test case does not include the front-door access process of the candidate register, determine that the candidate register has the conditions to be configured using the backdoor access method. For example, in DMA data transfer or NoC data transfer simulation test cases, when a candidate register is only used to configure the base address, transfer length, interrupt masking or enable state, and the verification objective of the current simulation test case is the data transfer process, further determine the backdoor access of the candidate register.

[0071] (3) Determine whether backdoor access to the candidate registers is allowed based on their register type and access attributes. For candidate registers with attributes such as write-clear, read-clear, write-triggered, read-only, write-only, or hardware update, determine whether backdoor access is allowed based on whether it affects the semantics of the corresponding register. Candidate registers that allow backdoor access are designated as backdoor-configurable registers. When a backdoor-configurable register exists in the current simulation test case, enable the register backdoor configuration parameter and designate it as one of the target acceleration parameters.

[0072] In this embodiment, the parameter enabling rules include partition compilation enabling rules. Based on the partition compilation enabling rules, it is determined whether to enable partition compilation parameters. The partition compilation enabling rules include:

[0073] (1) Based on the bottleneck identification results, determine whether there is a performance bottleneck in the compilation stage of the current simulation test case, and obtain the range of file changes of the SoC design to be verified or the verification environment relative to the historical compilation version. When the bottleneck identification results indicate that there is a high simulation time consumption in the compilation stage, and the range of file changes is limited to some compilation partitions, it is determined that there is a compilation bottleneck in the current simulation test case that is suitable for optimization by partitioned compilation.

[0074] (2) Determine the scope of compilation impact corresponding to the file change based on the scope of file changes and the dependencies between multiple compilation partitions. Multiple compilation partitions can be divided according to the CPU subsystem, NoC subsystem, DDR subsystem, peripheral subsystem in the SoC design to be verified, as well as the verification platform software package and VIP software package in the verification environment. Dependencies include module dependencies, software package dependencies, or interface dependencies. When the compilation partitions directly involved by the file change and the associated compilation partitions affected by dependencies do not cover all compilation partitions, it is determined that the file change meets the local partition impact condition.

[0075] (3) Based on the configuration consistency analysis results and historical compilation results, determine whether there are reusable historical compilation results in the compilation partitions that are not affected by file changes. When the current simulation test case has a compilation bottleneck that is suitable for optimization by partitioned compilation, the file changes meet the local partition impact conditions, and there are reusable historical compilation results in the unaffected compilation partitions, enable the partitioned compilation parameters and determine the partitioned compilation parameters as one of the target acceleration parameters.

[0076] In this embodiment, the parameter enabling rules include access mode change enabling rules. Based on the access mode change enabling rules, it is determined whether to enable access mode parameters. The access mode change enabling rules include:

[0077] (1) Based on the bottleneck identification results, determine whether the current simulation test case has a performance bottleneck related to the actual CPU execution. Specifically, based on the software startup time, CPU execution time ratio, and bus access type corresponding to the current simulation test case, determine whether the CPU software startup, instruction execution, or software polling process generates high simulation overhead. When the software startup time or CPU execution time ratio is high, it is determined that the current simulation test case has a performance bottleneck that is suitable for optimization through access mode changes.

[0078] (2) Based on the verification objectives of the current simulation test case, determine whether the current simulation test case depends on the actual CPU execution process. When the verification objectives include CPU startup, exception handling, interrupt response, cache behavior, software flow, or instruction execution behavior, determine that the current simulation test case depends on the actual CPU execution process and maintain the actual CPU execution mode. When the verification objectives include NoC path, DDR bandwidth, AXI access, register basic read / write, DMA data path, or peripheral interface response, and do not depend on CPU instruction-level execution behavior, determine that the current simulation test case meets the access mode change conditions.

[0079] (3) For the current simulation test case that meets the access mode change conditions, determine whether the bus access, register configuration or data transfer generated in the CPU real execution mode can be equivalently implemented through VIP transactions. When the corresponding VIP transaction can be generated according to the software access intent corresponding to the CPU real execution mode, enable the access mode parameter and determine the access mode parameter as one of the target acceleration parameters so that the VIP access mode replaces the CPU real execution mode to complete the corresponding access operation when the current simulation test case is executed in the future.

[0080] In this embodiment, the parameter enabling rules include mirror reuse enabling rules. Based on the mirror reuse enabling rules, it is determined whether to enable gate-level post-mirror reuse parameters. The mirror reuse enabling rules include:

[0081] (1) Based on the bottleneck identification results, determine whether there is a performance bottleneck in the gate-level post-simulation environment construction stage of the current simulation test case. When the current simulation test case is a gate-level post-simulation test case, and the bottleneck identification results indicate that there is a high simulation time consumption in the gate-level netlist compilation, refinement, SDF timing annotation or post-simulation environment construction process, it is determined that the current simulation test case has a performance bottleneck that is suitable for optimization by gate-level post-simulation image reuse.

[0082] (2) Obtain the gate-level post-simulation configuration corresponding to the current simulation test case, and determine whether there is a reusable gate-level post-simulation image based on the gate-level post-simulation configuration. The gate-level post-simulation configuration includes, but is not limited to: gate-level netlist, SDF file, standard cell library, verification platform configuration, macro definition, simulation parameters, etc. For each pre-generated gate-level post-simulation image, save the image configuration information corresponding to its post-simulation environment construction result. By comparing the gate-level post-simulation configuration of the current simulation test case with the image configuration information corresponding to each gate-level post-simulation image, determine whether there is a gate-level post-simulation image that matches the current gate-level post-simulation configuration.

[0083] (3) When the current simulation test case has a performance bottleneck suitable for optimization through gate-level post-simulation image reuse, and a gate-level post-simulation image that matches the gate-level post-simulation configuration of the current simulation test case exists, the gate-level post-simulation image reuse parameter is enabled, and the gate-level post-simulation image reuse parameter is determined as one of the target acceleration parameters. When there is no gate-level post-simulation image that matches the current gate-level post-simulation configuration, the corresponding gate-level post-simulation compilation and SDF timing annotation environment construction can be re-executed, and the post-simulation environment construction result obtained by the re-construction can be saved as a new gate-level post-simulation image for reuse in subsequent simulation test cases.

[0084] S105: Execute the current simulation test case according to one or more of the target acceleration parameters, and collect runtime feedback data during the execution of the current simulation test case to update the activation priority of the target acceleration parameters.

[0085] In this embodiment, the target acceleration parameters include snapshot reuse parameters; wherein, the method of executing the current simulation test case according to one or more of the target acceleration parameters includes:

[0086] (1) When the snapshot reuse parameter is enabled, the target simulation snapshot result is determined from multiple generated simulation snapshot results.

[0087] (2) Load the target simulation snapshot result and control the current simulation test case to start running from the simulation state corresponding to the target simulation snapshot result in order to execute the current simulation test case.

[0088] In this embodiment, when the snapshot reuse parameter is enabled, multiple pre-generated simulation snapshot results for the SoC design to be verified are obtained. The generated simulation snapshot results are formed by saving the corresponding simulation state or simulation environment construction results when historical simulation test cases are run to the corresponding snapshot generation point. The corresponding snapshot generation point can be determined based on the simulation scenario and performance bottlenecks corresponding to the historical simulation test cases.

[0089] (1) In RTL regression scenarios where compilation or refinement takes a long time, the location where refinement is completed can be determined as the snapshot generation point.

[0090] (2) In SoC simulation scenarios where system initialization takes a long time, the system initialization completion point after register configuration, DDR data loading, mailbox parameter setting and startup parameter writing can be determined as the snapshot generation point.

[0091] (3) In the gate-level post-simulation scenario, the gate-level netlist, standard cell library, SDF file and the location where the verification platform environment is built can be determined as the snapshot generation point.

[0092] (4) In scenarios where the CPU software startup time is high and the CPU startup status of multiple simulation test cases is consistent, the location where the CPU completes the basic startup process can be determined as the snapshot generation point.

[0093] In this embodiment, after the historical simulation test cases run to the corresponding snapshot generation point, the corresponding simulation state or simulation environment construction result is saved to form the corresponding simulation snapshot result.

[0094] In this embodiment, each generated simulation snapshot result is associated with corresponding simulation configuration information and simulation status information. The target simulation snapshot result is determined from multiple generated simulation snapshot results by comparing the simulation configuration data of the current simulation test case with the simulation configuration information corresponding to each simulation snapshot result.

[0095] In this embodiment, the target simulation snapshot result is loaded, the simulation state saved in the target simulation snapshot result is restored, and the current simulation test case is controlled to start running from the restored simulation state. This eliminates the need for the current simulation test case to re-execute the simulation process that was completed before the state corresponding to the target simulation snapshot result. For example, when the target simulation snapshot result corresponds to the refinement completion state, the repeated compilation and refinement processes can be skipped. When the target simulation snapshot result corresponds to the system initialization completion state, the repeated register configuration, DDR data loading, mailbox parameter setting, and startup parameter writing processes can be skipped. When the target simulation snapshot result corresponds to the gate-level post-simulation environment construction completion state, the repeated gate-level netlist, standard cell library, and SDF file loading and environment construction processes can be skipped. When the target simulation snapshot result corresponds to the CPU basic startup completion state, the repeated software startup process can be skipped, thereby reducing the repetitive simulation overhead during the execution of the current simulation test case.

[0096] In this embodiment, the target acceleration parameters include RTL module simplified replacement parameters; wherein, the method of executing the current simulation test case according to one or more of the target acceleration parameters includes:

[0097] (1) When the simplified replacement parameters of the RTL module are enabled, the target RTL module is determined from multiple RTL functional modules of the SoC design to be verified.

[0098] (2) Replace the target RTL module and execute the current simulation test case based on the replaced SoC design to be verified.

[0099] In this embodiment, after determining that the simplified replacement parameters for the RTL module are enabled, a target RTL module is selected from multiple RTL functional modules of the SoC design to be verified. Specifically, the candidate RTL modules that meet the replacement enable rules identified in the aforementioned replacement enable determination process are selected as the target RTL modules. For example, if the current simulation test case is used to verify the NoC to DDR data access path or bandwidth performance, and the GPU module and ISP module are not part of the current verification data path, the GPU module or ISP module that meets the replacement enable rules can be selected as the target RTL module.

[0100] In this embodiment, the target RTL module is replaced. Specifically, an empty module, a fixed-response module, a lightweight behavioral model, or an interface-maintaining model can be used to replace the target RTL module to reduce the event scheduling overhead caused by irrelevant modules participating in the simulation. The replacement module retains the ports, clocks, reset, and protocol handshake signals required for connection and interaction between the target RTL module and other modules in the SoC design to be verified, and maintains the system operating state required by the current simulation test case through fixed responses, idle responses, or protocol-compatible responses. At the same time, state machines, storage logic, data paths, or other complex functional logic irrelevant to the current verification target within the target RTL module are omitted.

[0101] In this embodiment, after replacing the target RTL module, the current simulation test case is executed based on the replaced SoC design to be verified. During execution, the replaced module provides the interface responses required for the current simulation test case to run, instead of executing complex logic within the original target RTL module that is unrelated to the current verification target. This reduces the event scheduling, signal toggling, and corresponding simulation computation overhead generated by the target RTL module, improving simulation efficiency while keeping the current simulation test case verification target unaffected.

[0102] In this embodiment, the target acceleration parameters include register backdoor configuration parameters; wherein, the method of executing the current simulation test case according to one or more of the target acceleration parameters includes:

[0103] (1) When the register backdoor configuration parameters are enabled, determine the target register that the backdoor is allowed to access.

[0104] (2) Switch the configuration mode of the target register from front door bus access to back door access in order to execute the current simulation test case.

[0105] In this embodiment, after determining the backdoor configuration parameters, the target register is selected from the backdoorable registers corresponding to the current simulation test case based on the determination result of the aforementioned backdoor configuration enable rules. A backdoorable register is one that is only used to construct the pre-test state of the current simulation test case, whose verification target does not include its frontdoor access process, and whose backdoor access will not violate the semantics of the corresponding register. For example, in DMA data transfer or NoC data transfer simulation test cases, a register used to set the base address, transfer length, interrupt masking, or enable state, and which meets the backdoor access conditions, can be selected as the target register. For registers whose semantics, such as write clear, read clear, write trigger, or hardware update, might be affected by backdoor access, the frontdoor bus access method is continued for configuration.

[0106] In this embodiment, the configuration method of the target register is switched from front-door bus access to back-door access, and the configuration of the target register is completed through back-door access. Front-door bus access can be achieved through bus transactions such as Advanced Extensible Interfaces (ALEs), Advanced Peripheral Buses (APBs), or Advanced High Performance Buses (ATBs). Back-door access can be implemented through register model back-door paths, simulation hierarchy paths, direct programming interfaces, or back-door access interfaces provided by the simulator. After the back-door configuration of the target register is completed, the current simulation test case is executed based on the pre-test state formed by the configuration. This reduces the simulation overhead caused by generating and executing register access transactions item by item through the front-door bus, thereby reducing the simulation time during the system initialization or configuration phases.

[0107] In this embodiment, the target acceleration parameters include partitioned compilation parameters; wherein, the method of executing the current simulation test case according to one or more of the target acceleration parameters includes:

[0108] (1) When the partition compilation parameters are enabled, determine the affected compilation partition, the unaffected compilation partition, and the dependent compilation partitions that have a dependency relationship with the affected compilation partition.

[0109] (2) Recompile the affected compilation partition and the dependent compilation partition, and reuse the historical compilation results corresponding to the unaffected compilation partition to execute the current simulation test case.

[0110] In this embodiment, after determining the enabled partitioned compilation parameters, based on the range of file changes in the SoC design to be verified or the verification environment relative to historical compilation versions, and considering the dependencies between multiple compilation partitions, affected compilation partitions, unaffected compilation partitions, and dependent compilation partitions are determined. Affected compilation partitions are those directly associated with the changed files. Dependent compilation partitions are those with module, package, or interface dependencies that are required to be recompiled along with the affected compilation partition. Unaffected compilation partitions are those not directly affected by file changes and have no associated dependencies requiring recompilation. For example, when a peripheral RTL file in the SoC design to be verified changes, the peripheral compilation partition to which the peripheral RTL file belongs can be identified as the affected compilation partition, the related compilation partitions that depend on the peripheral compilation partition can be identified as dependent compilation partitions, and compilation partitions unaffected by file changes, such as CPU compilation partitions, NoC compilation partitions, DDR compilation partitions, or unrelated VIP compilation partitions, can be identified as unaffected compilation partitions.

[0111] In this embodiment, the affected compilation partitions and dependent compilation partitions are recompiled, and the historical compilation results corresponding to the unaffected compilation partitions are obtained and reused. After recompilation, the recompiled compilation results of the affected and dependent compilation partitions are combined with the historical compilation results corresponding to the unaffected compilation partitions to construct the simulation environment corresponding to the current simulation test case, and the current simulation test case is executed based on the simulation environment. Therefore, when only local file changes occur in the SoC design to be verified or the verification environment, it is not necessary to recompile all compilation partitions, thereby reducing the overhead of full recompilation caused by local modifications and improving the compilation efficiency of SoC simulation verification.

[0112] In this embodiment, the target acceleration parameters include access mode parameters; wherein, the method of executing the current simulation test case according to one or more of the target acceleration parameters includes:

[0113] (1) When the access mode parameter is enabled, the CPU real execution mode corresponding to the current simulation test case is switched to VIP access mode.

[0114] (2) Generate a VIP transaction based on the software access intent corresponding to the actual CPU execution mode, and execute the current simulation test case based on the VIP transaction.

[0115] In this embodiment, after determining the access mode parameters, the CPU's actual execution mode corresponding to the current simulation test case is switched to VIP access mode. CPU actual execution mode refers to a simulation operation mode where the CPU executes the corresponding software program, generating bus access, register configuration, or data transfer through software startup, instruction execution, and software control processes. VIP access mode refers to directly generating bus access transactions through the VIP corresponding to the corresponding bus protocol, replacing the access operations generated by the CPU executing the corresponding software process.

[0116] In this embodiment, the software access intent corresponding to the current simulation test case in the CPU's actual execution mode is obtained, and a VIP transaction is generated based on the software access intent. The software access intent is used to characterize the access operation that the CPU expects to complete through software execution. The VIP transaction includes, but is not limited to: access address, burst transfer length, burst transfer type, data width, read / write direction, transaction identifier, quality of service attributes, cache attributes, protection attributes, data mode, etc. This ensures that the VIP transaction corresponds to the corresponding bus access generated in the CPU's actual execution mode at the protocol level.

[0117] In this embodiment, the current simulation test case is executed based on a VIP transaction. The VIP directly initiates the VIP transaction and completes the corresponding bus access, register configuration, or data transfer through the VIP transaction, without requiring the CPU to perform the software startup, instruction execution, or software polling process corresponding to the access operation. For example, when the current simulation test case is used to verify the NoC path, DDR bandwidth, or DMA data path, the data access required for the current verification target can be directly generated through the corresponding VIP transaction, thereby reducing the simulation overhead generated by the actual CPU software execution while keeping the verification target of the current simulation test case unchanged.

[0118] In this embodiment, the target acceleration parameters include gate-level post-simulation image reuse parameters; wherein, the method of executing the current simulation test case according to one or more of the target acceleration parameters includes:

[0119] (1) When the gate-level post-simulation image reuse parameter is enabled, a target gate-level post-simulation image that matches the gate-level post-simulation configuration of the current simulation test case is determined from a plurality of pre-generated gate-level post-simulation images; wherein, the gate-level post-simulation image is used to save the post-simulation environment construction results corresponding to the gate-level netlist, standard cell library and SDF file;

[0120] (2) Load the target gate-level post-simulation image and execute the current simulation test case based on the target gate-level post-simulation image.

[0121] In this embodiment, after determining that the gate-level post-simulation image reuse parameters are enabled, a target gate-level post-simulation image matching the gate-level post-simulation configuration of the current simulation test case is selected from a plurality of pre-generated gate-level post-simulation images. The gate-level post-simulation image is a reusable simulation image formed by saving the post-simulation environment construction results after compiling, refining, and timing-annotating the gate-level netlist, standard cell library, and corresponding SDF files during the execution of historical gate-level post-simulation test cases.

[0122] In this embodiment, based on the determination result of the aforementioned image reuse enabling rule, a target gate-level post-simulation image is determined from the gate-level post-simulation images that match the gate-level post-simulation configuration of the current simulation test case. The target gate-level post-simulation image is loaded, and the post-simulation environment construction results saved in the target gate-level post-simulation image are restored. The current simulation test case is then executed based on the restored gate-level post-simulation environment. Therefore, the current simulation test case does not need to re-execute the gate-level netlist compilation, refinement, and SDF timing annotation environment construction processes already completed by the target gate-level post-simulation image, thereby reducing the overhead of redundant post-simulation environment construction between multiple simulation test cases using the same or matching gate-level post-simulation configurations and improving gate-level post-simulation verification efficiency.

[0123] In this embodiment, as Figure 2 The diagram illustrates the flowchart for updating the activation priority of target acceleration parameters in an embodiment of this application. During the execution of the current simulation test case based on one or more target acceleration parameters, runtime feedback data corresponding to each target acceleration parameter is collected, and the actual acceleration effect of the corresponding target acceleration parameter is determined based on the runtime feedback data. The runtime feedback data characterizes the acceleration effect produced by the target acceleration parameters after they are actually applied to the current simulation test case, including but not limited to: the overall simulation time after applying the target acceleration parameters, the actual time consumed in the corresponding simulation stage, the time saved, and the actual execution result of the target acceleration parameters. For cases where multiple target acceleration parameters are enabled simultaneously, the runtime feedback data corresponding to each target acceleration parameter is recorded separately to evaluate the actual acceleration effect produced by each target acceleration parameter. The method for collecting runtime feedback data and updating the activation priority of target acceleration parameters includes:

[0124] S201: Based on the operational feedback data, determine the acceleration benefit corresponding to the target acceleration parameter.

[0125] In this embodiment, the acceleration benefit corresponding to the target acceleration parameter is determined based on the runtime feedback data. Specifically, the runtime feedback data after applying the target acceleration parameter is compared with the historical runtime performance data when the corresponding target acceleration parameter is not applied. The acceleration benefit of the target acceleration parameter is determined based on the reduction in time consumption of the corresponding simulation stage or the overall reduction in simulation time. For example, for snapshot reuse parameters, the corresponding acceleration benefit can be determined based on the compilation, refinement, or initialization time saved after snapshot loading. For RTL module simplification and replacement parameters, the corresponding acceleration benefit can be determined based on the change in simulation runtime before and after replacement. For register backdoor configuration parameters, partition compilation parameters, access mode parameters, and gate-level post-simulation image reuse parameters, the corresponding acceleration benefit can also be determined based on the reduction in time consumption of the corresponding configuration, compilation, execution, or post-simulation environment construction process.

[0126] S202: If the acceleration benefit corresponding to the target acceleration parameter meets the preset benefit conditions, then the activation priority of the target acceleration parameter will be increased during the execution of subsequent simulation test cases of the same type.

[0127] In this embodiment, the preset benefit condition is used to determine whether the actual acceleration benefit generated by the target acceleration parameter reaches the expected benefit level. The preset benefit condition includes: the reduction in time consumption corresponding to the target acceleration parameter reaches a preset time-saving threshold, or the reduction ratio of simulation time after applying the target acceleration parameter to simulation time without applying the target acceleration parameter reaches a preset benefit ratio threshold. When the acceleration benefit reaches the corresponding threshold, it is determined that the acceleration benefit corresponding to the target acceleration parameter meets the preset benefit condition. Otherwise, it is determined that the acceleration benefit corresponding to the target acceleration parameter does not meet the preset benefit condition.

[0128] In this embodiment, if the acceleration benefit corresponding to the target acceleration parameter meets a preset benefit condition, the activation priority of the target acceleration parameter for subsequent simulation test cases of the same type is increased. Simulation test cases of the same type refer to simulation test cases that have the same or similar characteristics in at least one aspect of the verification target, simulation scenario, configuration features, or bottleneck type. Activation priority is used to characterize the degree to which each acceleration parameter is determined as a target acceleration parameter when multiple acceleration parameters meet their respective parameter activation rules. When a target acceleration parameter has a high actual acceleration benefit in historical simulation test cases of the same type, it is given a higher activation priority in the parameter activation determination process for subsequent simulation test cases of the same type.

[0129] S203: If the acceleration benefit corresponding to the target acceleration parameter does not meet the preset benefit condition, the activation priority of the target acceleration parameter will be reduced during the execution of subsequent simulation test cases of the same type.

[0130] In this embodiment, if the acceleration benefit corresponding to the target acceleration parameter does not meet the preset benefit conditions, the activation priority of the target acceleration parameter for subsequent simulation test cases of the same type is reduced, so that the target acceleration parameter has a lower activation priority in the parameter activation determination process of subsequent simulation test cases of the same type. Therefore, the activation priority of each acceleration parameter can be dynamically adjusted according to the actual simulation operation feedback.

[0131] It is worth noting that the SoC verification acceleration method based on simulation performance profiling proposed in this application has the following advantages:

[0132] (1) Reduce the overhead of repeated compilation and refinement: By generating simulation performance profiles and combining configuration consistency analysis, simulation test cases with reuse conditions are identified, and snapshot reuse parameters or partition compilation parameters are selected according to the bottleneck identification results, so that subsequent simulation test cases can reuse existing simulation states or historical compilation results that are not affected by file changes, reducing the repeated full compilation and refinement process and improving design iteration efficiency.

[0133] (2) Reduce the simulation overhead of irrelevant RTL functional modules: Identify high-overhead modules based on the processor time ratio, event hotspot distribution and signal flip rate of RTL functional modules, and replace irrelevant complex modules with lightweight models without affecting the current verification target, thereby reducing irrelevant event scheduling and signal flipping and improving the running speed of individual simulation test cases.

[0134] (3) Shorten system initialization and CPU execution time: For register configuration of non-verification targets, register backdoor configuration parameters can be enabled to reduce transaction overhead caused by configuring each item through the front door bus; For simulation test cases that do not depend on the actual software execution process of the CPU, VIP access mode can be used to generate equivalent access transactions, thereby reducing simulation time caused by repeated register configuration, software startup and instruction execution.

[0135] (4) Reduce the cost of repeated construction of gate-level post-simulation environment: By comparing the current gate-level post-simulation configuration with the image configuration information of the existing gate-level post-simulation image, the gate-level post-simulation image can be reused when the matching conditions are met, so that multiple post-simulation test cases can share the existing gate-level netlist compilation, refinement and SDF timing annotation environment construction results, reduce repeated post-simulation environment construction and improve gate-level post-simulation verification efficiency.

[0136] (5) Improve the utilization of historical information between different simulation test cases: By forming a simulation performance profile of historical simulation test cases and performing configuration consistency analysis between current simulation test cases and historical simulation test cases, the performance characteristics of historical test cases can be used to predict the performance bottlenecks that may exist in the current test cases, thereby determining the corresponding target acceleration parameters for different simulation scenarios and improving the targeting of parameter configuration in large-scale regression verification.

[0137] (6) Reduce the dependence of acceleration parameter selection on human experience: By configuring consistency analysis, bottleneck identification and parameter activation rules, one or more target acceleration parameters are automatically determined, and running feedback data is collected during the simulation execution. The activation priority of the corresponding target acceleration parameters is dynamically adjusted according to the actual acceleration benefits, so that the acceleration parameters can be continuously optimized in combination with historical execution effects, reducing the problem of relying on verification personnel to manually select and statically configure parameters.

[0138] Figure 3 This is a schematic block diagram of a SoC verification acceleration system based on simulation performance profiling provided in an embodiment of this application. Figure 3 As shown, the SoC verification acceleration system 300 based on simulation performance profiling includes:

[0139] The performance profile acquisition module 301 is used to acquire the running performance data generated by the SoC design to be verified when executing multiple historical simulation test cases, and generate a simulation performance profile based on the running performance data.

[0140] The configuration consistency analysis module 302 is used to obtain the simulation configuration data of the current simulation test case and compare the simulation configuration data of the current simulation test case with the simulation configuration data of each of the historical simulation test cases to generate the configuration consistency analysis result of the current simulation test case.

[0141] The bottleneck identification module 303 is used to determine the target performance profile that matches the current simulation test case from the simulation performance profile based on the configuration consistency analysis results, and to generate the bottleneck identification result of the current simulation test case based on the target performance profile.

[0142] The parameter decision module 304 is used to determine one or more target acceleration parameters based on the configuration consistency analysis results of the current simulation test case and the bottleneck identification results, and based on the parameter activation rules.

[0143] The acceleration management module 305 is used to execute the current simulation test case according to one or more of the target acceleration parameters, and to collect running feedback data during the execution of the current simulation test case, so as to update the activation priority of the target acceleration parameters.

[0144] It should be understood that the specific process of each module performing the above-mentioned corresponding steps has been described in detail in the above method embodiments, and will not be repeated here for the sake of brevity.

[0145] It should also be understood that the module division in the embodiments of this application is illustrative and only represents a logical functional division; in actual implementation, there may be other division methods. Furthermore, the functional modules in the various embodiments of this application can be integrated into a single processor, exist as separate physical entities, or be integrated into a single module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0146] Figure 4 This is a schematic block diagram of an electronic terminal provided in an embodiment of this application. The electronic terminal includes a memory, a processor, and a computer program stored in the memory. The processor executes the computer program to implement the SoC verification acceleration method based on simulation performance profiling as described above. Figure 4 As shown, the electronic terminal 400 includes at least one processor 401, a memory 402, at least one network interface 403, and a user interface 405. The various components in the electronic terminal 400 are coupled together via a bus system 404. It is understood that the bus system 404 is used to implement communication between these components. In addition to a data bus, the bus system 404 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in… Figure 4 The general will label all buses as bus systems.

[0147] The user interface 405 may include a monitor, keyboard, mouse, trackball, clicker, button, touchpad, or touch screen.

[0148] It is understood that memory 402 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM) or programmable read-only memory (PROM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM) and synchronous static random access memory (SSRAM). The memories described in the embodiments of this application are intended to include, but are not limited to, these and any other suitable categories of memory.

[0149] In this embodiment, memory 402 is used to store various types of data to support the operation of electronic terminal 400. Examples of this data include any executable program that operates on electronic terminal 400, such as operating system 4021 and application program 4022. Operating system 4021 contains various system programs, such as framework layer, core library layer, driver layer, etc., used to implement various basic services and handle hardware-based tasks. Application program 4022 may contain various applications, such as media player, browser, etc., used to implement various application services. The SoC verification acceleration method based on simulation performance profile provided in this embodiment can be included in application program 4022.

[0150] The methods disclosed in the embodiments of this application can be applied to processor 401, or implemented by processor 401. Processor 401 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 401 or by instructions in the form of software. The processor 401 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 401 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. General-purpose processor 401 may be a microprocessor or any conventional processor, etc. The steps of the accessory optimization method provided in the embodiments of this application can be directly reflected as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software module may be located in a storage medium, which is located in memory. The processor reads the information in the memory and combines it with its hardware to complete the steps of the aforementioned method.

[0151] In an exemplary embodiment, the electronic terminal 400 may be used by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), or complex programmable logic devices (CPLDs) to execute the aforementioned method.

[0152] According to the method provided in the embodiments of this application, this application also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the method as described in any of the embodiments above.

[0153] According to the method provided in the embodiments of this application, this application also provides a computer program product, which includes: computer program code, which, when run on a computer, causes the computer to perform the method of any of the embodiments described above.

[0154] As used in this specification, the terms "component," "module," "system," etc., are used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, and / or a computer. As illustrated, applications running on computing devices and computing devices can both be components. One or more components may reside in a process and / or an execution thread, and components may be located on a single computer and / or distributed among two or more computers. Furthermore, these components can be executed from various computer-readable media on which various data structures are stored. Components can communicate, for example, via local and / or remote processes based on signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system, and / or a network, such as the Internet interacting with other systems via signals).

[0155] Those skilled in the art will recognize that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

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

[0157] 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. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

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

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

[0160] In the above embodiments, the functions of each functional unit can be implemented entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. A computer program product includes one or more computer instructions (programs). When the computer program instructions (programs) are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. Available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., high-density digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0161] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a 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 part 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 of 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.

[0162] In summary, this application provides a SoC verification acceleration method, system, medium, and terminal based on simulation performance profiling. It acquires runtime performance data from multiple historical simulation test cases and generates simulation performance profiles. The simulation configuration data of the current simulation test case is compared with the simulation configuration data of historical simulation test cases to generate configuration consistency analysis results. Based on this, a matching target performance profile is determined, and bottleneck identification results are generated. According to the configuration consistency analysis results, bottleneck identification results, and parameter activation rules, one or more target acceleration parameters are determined, and the current simulation test case is executed. During execution, runtime feedback data is collected to adjust the activation priority of the target acceleration parameters. This application reduces the overhead of repeated compilation, initialization, and simulation execution, improves SoC simulation verification efficiency, and shortens the verification cycle. Therefore, this application effectively overcomes the various shortcomings of existing technologies and has high industrial applicability.

[0163] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A method for accelerating SoC verification based on simulation performance profiling, characterized in that, include: Obtain the runtime performance data generated by the SoC design to be verified when executing multiple historical simulation test cases, and generate a simulation performance profile based on the runtime performance data; Obtain the simulation configuration data of the current simulation test case, and compare the simulation configuration data of the current simulation test case with the simulation configuration data of each of the historical simulation test cases to generate the configuration consistency analysis result of the current simulation test case; Based on the configuration consistency analysis results, a target performance profile matching the current simulation test case is determined from the simulation performance profile, and a bottleneck identification result for the current simulation test case is generated based on the target performance profile. Based on the configuration consistency analysis results of the current simulation test cases and the bottleneck identification results, and based on the parameter activation rules, parameter activation determination is performed to identify one or more target acceleration parameters. Based on one or more of the target acceleration parameters, execute the current simulation test case, and collect runtime feedback data during the execution of the current simulation test case to update the activation priority of the target acceleration parameters.

2. The SoC verification acceleration method based on simulation performance profiling according to claim 1, characterized in that, The target acceleration parameters include snapshot reuse parameters; wherein, the method of executing the current simulation test case according to one or more of the target acceleration parameters includes: When the snapshot reuse parameter is enabled, the target simulation snapshot result is determined from multiple generated simulation snapshot results; Load the target simulation snapshot result, and control the current simulation test case to start running from the simulation state corresponding to the target simulation snapshot result in order to execute the current simulation test case.

3. The SoC verification acceleration method based on simulation performance profiling according to claim 1, characterized in that, The methods for collecting operational feedback data and updating the activation priority of target acceleration parameters include: Based on the operational feedback data, determine the acceleration benefits corresponding to the target acceleration parameters; If the acceleration benefit corresponding to the target acceleration parameter meets the preset benefit conditions, the activation priority of the target acceleration parameter will be increased during the execution of subsequent simulation test cases of the same type. If the acceleration benefit corresponding to the target acceleration parameter does not meet the preset benefit conditions, the activation priority of the target acceleration parameter will be reduced during the execution of subsequent simulation test cases of the same type.

4. The SoC verification acceleration method based on simulation performance profiling according to claim 1, characterized in that, The target acceleration parameters include RTL module simplified replacement parameters; wherein, the method of executing the current simulation test case based on one or more of the target acceleration parameters includes: When the simplified replacement parameters of the RTL module are enabled, the target RTL module is determined from multiple RTL functional modules of the SoC design to be verified. The target RTL module is replaced, and the current simulation test case is executed based on the replaced SoC design to be verified.

5. The SoC verification acceleration method based on simulation performance profiling according to claim 1, characterized in that, The target acceleration parameters include register backdoor configuration parameters; wherein, the method of executing the current simulation test case according to one or more of the target acceleration parameters includes: When enabling the register backdoor configuration parameters, determine the target register that the backdoor is allowed to access; Switch the configuration mode of the target register from front-door bus access to back-door access in order to execute the current simulation test case.

6. The SoC verification acceleration method based on simulation performance profiling according to claim 1, characterized in that, The target acceleration parameters include partitioned compilation parameters; wherein, the method of executing the current simulation test case according to one or more of the target acceleration parameters includes: When the partition compilation parameters are enabled, the affected compilation partitions, unaffected compilation partitions, and dependent compilation partitions that have a dependency relationship with the affected compilation partitions are identified. The affected compilation partitions and the dependent compilation partitions are recompiled, and the historical compilation results corresponding to the unaffected compilation partitions are reused to execute the current simulation test cases.

7. The SoC verification acceleration method based on simulation performance profiling according to claim 1, characterized in that, The target acceleration parameters include access mode parameters; wherein, the method of executing the current simulation test case according to one or more of the target acceleration parameters includes: When the access mode parameter is enabled, the CPU real execution mode corresponding to the current simulation test case is switched to VIP access mode; Based on the software access intent corresponding to the actual CPU execution mode, a VIP transaction is generated, and the current simulation test case is executed based on the VIP transaction.

8. A SoC verification acceleration system based on simulation performance profiling, characterized in that, include: The performance profile acquisition module is used to acquire the runtime performance data generated by the SoC design to be verified when executing multiple historical simulation test cases, and generate a simulation performance profile based on the runtime performance data. The configuration consistency analysis module is used to obtain the simulation configuration data of the current simulation test case and compare the simulation configuration data of the current simulation test case with the simulation configuration data of each of the historical simulation test cases to generate the configuration consistency analysis result of the current simulation test case. The bottleneck identification module is used to determine the target performance profile that matches the current simulation test case from the simulation performance profile based on the configuration consistency analysis results, and generate the bottleneck identification result of the current simulation test case based on the target performance profile. The parameter decision module is used to determine one or more target acceleration parameters based on the configuration consistency analysis results of the current simulation test case and the bottleneck identification results, and based on the parameter activation rules. The acceleration management module is used to execute the current simulation test case according to one or more of the target acceleration parameters, and to collect runtime feedback data during the execution of the current simulation test case, so as to update the activation priority of the target acceleration parameters.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the SoC verification acceleration method based on simulation performance profiling as described in any one of claims 1 to 7.

10. An electronic terminal, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the SoC verification acceleration method based on simulation performance profiling as described in any one of claims 1 to 7.

Images