Chip simulation verification method, device, equipment and medium

Abstract

The application relates to the chip verification technical field and discloses a chip simulation verification method, a chip simulation verification device, equipment and a medium. The chip simulation verification method provided by the application realizes automatic customization for different test cases by receiving a test case file and a chip design file, performing multi-dimensional optimization potential scoring based on the chip design file, generating a mapping library file and a simulation file, avoids manual configuration errors, has high automation, can dynamically adjust optimization strategies, and has high verification efficiency.

Description

Technical Field

[0001] This application relates to the field of chip verification technology, specifically to a chip simulation verification method, apparatus, equipment, and medium. Background Technology

[0002] In related technologies, chip verification relies on manually writing mapping library files. The process depends on manual operation, including module identification, model creation, and configuration file writing, which can easily lead to problems such as missing modules, syntax errors, or instance hierarchy mismatches. Summary of the Invention

[0003] This application provides a chip simulation verification method, apparatus, equipment, and medium.

[0004] In a first aspect, this application provides a chip simulation verification method, the method comprising: receiving a test case file and a chip design file; scoring the optimization potential of each module in the simulated chip from multiple dimensions based on the chip design file to obtain an optimization score, wherein the optimization potential is used to characterize the impact of replacing the module on the test effect of the corresponding test case; generating a mapping library file corresponding to each test case based on the optimization score and the test case file; and generating a simulation file corresponding to each test case based on the mapping library file.

[0005] Based on the above technical means, this method can dynamically generate differentiated optimization strategies according to the specific needs of each test case, overcoming the limitations of existing technologies where strategies are statically fixed and cannot be adjusted according to test cases.

[0006] In some optional embodiments of this application, the test case file includes a strategy configuration file and a test case list. Based on the optimization score and the test case file, a mapping library file corresponding to each test case is generated, including: parsing the strategy configuration file to obtain the test objective for each test case, the test objective being used to characterize the test intent for the test case; and replacing the corresponding modules for each test case in the test case list according to the test objective and the optimization score, thereby generating a mapping library file corresponding to each test case.

[0007] Based on the above technical means, each test case can obtain a mapping library file that matches its test requirements, thereby maximizing simulation efficiency while ensuring test quality. This effectively solves the defect in existing technologies that cannot dynamically adjust replacement strategies according to test cases, and significantly improves the automation level and overall efficiency of chip simulation verification.

[0008] In some optional embodiments of this application, based on the test objective and optimization score, each test case in the test case list undergoes corresponding module replacement to generate a mapping library file corresponding to each test case. This includes: parsing the test intent in the test objective, whereby the test intent describes the replacement of modules in the simulation chip; determining whether the test intent includes a target test case, whereby the target test case describes the replacement of modules in the simulation chip based on the optimization score; if the target test case is included, performing module replacement on the first target module determined based on the optimization score; if the target test case is not included, performing module replacement on the second target module based on the test intent; and generating a mapping library file corresponding to each test case based on the simulation chip after module replacement.

[0009] Based on the above technical means, while meeting the differentiated replacement requirements of different test cases, it also takes into account the flexibility of automated optimization and user customization, significantly improving the adaptability, efficiency and accuracy of the chip simulation verification process. In some optional embodiments of this application, module replacement includes replacing the target module with a substitute module.

[0010] In some optional embodiments of this application, the chip design file includes an RTL design file. Based on the chip design file, the optimization potential of each module in the simulation chip is scored from multiple dimensions to obtain an optimization score. This includes: parsing the RTL design file and constructing a module hierarchy tree corresponding to the simulation chip; extracting multi-dimensional feature information of each module in the module hierarchy tree, where the multi-dimensional feature information includes at least logic complexity, storage resource parameters, fan-in and fan-out parameters, module hierarchy depth, number of instantiated sub-modules within the module, module dependence on external signals, and whether the module contains any asynchronous logic. The logic complexity includes at least one of combinational logic depth, number of state machines, and number of always blocks; and calculating the optimization potential score of each module based on the multi-dimensional feature information using a preset model to obtain an optimization score for each module.

[0011] Based on the above-mentioned technical means, this application can automatically parse RTL design files, construct a module hierarchy tree, and extract feature information of modules from multiple dimensions, thereby getting rid of the dependence on human subjective judgment in traditional optimization potential assessment and significantly improving assessment efficiency and accuracy.

[0012] In some optional embodiments of this application, generating simulation files corresponding to each test case based on the mapping library file includes: calling a first compilation command to compile the chip design file into a common intermediate library; and calling a second compilation command to compile the common intermediate library into simulation files corresponding to each test case by referencing the mapping library files of each test case.

[0013] Based on the above technical means, simulation files that meet the testing requirements of the current test cases can be generated, thus effectively supporting the differentiated optimization needs of different test cases and significantly improving the efficiency and flexibility of chip simulation verification. In some optional embodiments of this application, the method includes: obtaining the test results for each test case, wherein the test results include at least one of simulation runtime, peak memory usage, and compilation time; comparing the test results with the corresponding target performance indicators to obtain the performance improvement ratio; and in the next optimization scoring, performing a scoring step of evaluating the optimization potential of each module in the simulation chip from multiple dimensions based on the performance improvement ratio and module replacement information to obtain an optimization score.

[0014] Based on the above technical means, this application constructs a complete closed-loop iterative mechanism for the optimization potential assessment of chip simulation verification, which solves the problems of lack of actual performance feedback and inability to accumulate experience in the original scheme for optimization potential assessment.

[0015] Secondly, this application provides a chip simulation verification device, comprising: a receiving module for receiving test case files and chip design files; a scoring module for scoring the optimization potential of each module in the simulated chip from multiple dimensions based on the chip design files, thereby obtaining an optimization score, wherein the optimization potential is used to characterize the impact of replacing the module on the test effect of the corresponding test cases; a first generation module for generating a mapping library file corresponding to each test case based on the optimization score and the test case files; and a second generation module for generating simulation files corresponding to each test case based on the mapping library files.

[0016] Thirdly, this application provides an electronic device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the chip simulation verification method of the first aspect or any corresponding embodiment described above.

[0017] Fourthly, this application provides a computer-readable storage medium storing computer instructions for causing a computer to execute the chip simulation verification method of the first aspect or any corresponding embodiment described above.

[0018] Fifthly, this application provides a computer program product, including computer instructions for causing a computer to execute the chip simulation verification method described in the first aspect or any corresponding embodiment. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0020] Figure 1 This is a schematic diagram of the first type of chip simulation and verification method according to an embodiment of this application; Figure 2 This is a schematic diagram of the second process of the chip simulation and verification method according to an embodiment of this application; Figure 3 This is a schematic diagram of the third process of the chip simulation and verification method according to the embodiments of this application; Figure 4 This is a schematic diagram of the fourth process of the chip simulation and verification method according to the embodiments of this application; Figure 5 This is an example flowchart of a chip simulation and verification method according to an embodiment of this application; Figure 6 This is a structural block diagram of a chip simulation and verification device according to an embodiment of this application; Figure 7 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] It is understood that before using the technical solutions disclosed in the various embodiments of this application, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this application in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0023] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0024] Traditional chip simulation and verification methods generally rely on manually configuring mapping library files for module replacement to accelerate simulation. However, this method suffers from inefficiency and error-proneness due to its reliance on manual operation throughout the entire process; optimization strategies are static and fixed, unable to be dynamically adjusted according to different test cases; the lack of quantitative evaluation and feedback mechanisms makes it difficult to measure the optimization effect; and the disconnect between optimization strategies and design code and test cases increases maintenance difficulty and can easily lead to version management chaos and functional errors.

[0025] To address this issue, this application proposes a chip simulation verification method for verifying the functionality and performance of a chip design. For example... Figure 1 As shown, the method includes: Step S101: Receive test case files and chip design files.

[0026] The test case file contains test instructions and expected results used to drive the simulation process. The chip design file describes the chip's hardware structure and behavior, such as RTL code.

[0027] Specifically, receiving test case files and chip design files can be achieved in several ways. For example, the storage paths of the test case files and chip design files can be manually specified, or they can be passed to the simulation verification system via command-line parameters.

[0028] Step S102: Based on the chip design file, the optimization potential of each module in the simulation chip is scored from multiple dimensions to obtain an optimization score. The optimization potential is used to characterize the impact of replacing the module on the test effect of the corresponding test cases.

[0029] Here, a simulated chip refers to the abstract representation of a chip design file in a simulation environment. A module refers to an independent functional unit or hierarchical unit within the simulated chip. Optimization potential characterizes the degree to which replacing a module affects the test results of the corresponding test cases. Optimization score is a quantified value of the optimization potential.

[0030] Specifically, engineers can subjectively assess the optimization potential of each module based on their experience, combined with factors such as the module's functionality and lines of code, and manually assign a score. For example, a module with no internal state and only serving as a pass-through path will receive a low score; while a DDR controller IP that integrates a complex state machine and storage units will receive a higher score.

[0031] Step S103: Based on the optimized score and test case file, generate the mapping library file corresponding to each test case.

[0032] Among them, the mapping library files, which contain module replacement rules and configuration information, such as libmap files and config files, are used to guide the simulation tools to perform module replacements.

[0033] Specifically, a set of general replacement rules can be preset, for example, replacing all modules with simplified substitute modules whose optimization scores are below a certain threshold. Subsequently, these preset rules can be manually adjusted or modified according to the needs of each test case to generate libmap and config files specific to that test case.

[0034] Step S104: Generate simulation files corresponding to each test case based on the mapping library file.

[0035] The simulation file, which is a compiled executable file, is used to run the simulation.

[0036] Specifically, this can be achieved by calling standard compilation tools. For each test case, its corresponding mapping library file can be specified separately and compiled together with the chip design file to generate a simulation file specific to that test case.

[0037] It is understood that the chip simulation verification method proposed in this application effectively solves the problems of low efficiency and error-proneness caused by the reliance on manual operation throughout the entire process in traditional methods by introducing an automated scoring mechanism and generating mapping library files based on test cases. This method can dynamically generate differentiated optimization strategies according to the specific needs of each test case, overcoming the limitations of statically fixed strategies in existing technologies that cannot be adjusted according to test cases. Furthermore, by quantifying the optimization potential and generating customized simulation files, it lays the foundation for subsequent performance evaluation and feedback mechanisms, avoiding the maintenance difficulties of optimization strategies being separated from design code and test cases. In some of the above implementations, a mapping library file corresponding to each test case is generated based on the optimization score and test case file to achieve automated optimization of chip simulation. However, in this process, if the test objectives of the test cases themselves are not distinguished and the module replacement is completed uniformly according to the optimization score, it cannot adapt to the different test requirements of different test cases. It may result in replacing modules that should not be replaced, affecting the test accuracy, or failing to replace modules that need to be replaced, thus failing to achieve the expected simulation optimization effect. It will also continue the shortcomings of existing technologies that cannot dynamically adjust the replacement strategy according to test cases, and will still result in some test cases not being properly optimized. To achieve differentiated optimization, manual processing is still required, which is inefficient and prone to errors.

[0038] To address the aforementioned issues, this application subdivides the test case file into a strategy configuration file and a test case list. The strategy configuration file defines the module replacement strategy and test intent for different test cases. For example, it can specify which modules should be retained for a given test case to perform full functional verification, or which modules can be replaced to accelerate performance simulation. The test case list contains a collection of test cases that actually need to be run; for example, it is a text file listing the paths or names of all test cases to be tested.

[0039] Specifically, strategy configuration files can be obtained using either a Domain-Specific Language (DSL) or a Graphical User Interface (GUI). A DSL allows users to describe module replacement rules, test objectives, etc., in a concise, high-level manner. For example, a user could write a statement like, "For test case X, replace module A with a virtual model, and keep module B." A GUI simplifies the configuration process by providing intuitive visual elements such as buttons, drop-down menus, and text boxes, allowing users to define strategies interactively without writing code. For example, a user could select a test case on the interface, then check the modules to be replaced, and specify the replacement model.

[0040] This application further proposes a chip simulation verification method, such as... Figure 2 As shown, the method includes: Step S201: Receive the test case file and chip design file. See details in the following section. Figure 1 Step S101 in the embodiment will not be described again here.

[0041] Step S202: Based on the chip design file, the optimization potential of each module in the simulation chip is scored from multiple dimensions to obtain an optimization score. The optimization potential is used to characterize the impact of replacing a module on the test results of the corresponding test cases. See details... Figure 1 Step S102 in the embodiment will not be described again here.

[0042] Step S203: Based on the optimized score and test case files, generate the mapping library files corresponding to each test case. Specifically, this includes: Step S2031: Parse the strategy configuration file to obtain the test objectives for each test case. The test objectives are used to characterize the test intent for the test case.

[0043] Specifically, test objectives characterize the testing intent of test cases, clarifying the specific testing purpose of each test case and the specific requirements for module replacement. For example, one test objective might indicate that a test case is used to verify the correctness of a specific functional module, therefore that module should not be replaced; while another test objective might indicate that a test case is used to evaluate overall performance, therefore non-critical modules can be replaced to accelerate simulation. The parsing process can be handled by writing specialized parsers, such as tools based on lexical and parser generation, to process domain-specific language files, or by using standard libraries, such as JSON and XML parsing libraries, to parse structured configuration files, converting configuration information into internal data structures that the system can understand.

[0044] Step S2032: Based on the test objectives and optimization scores, perform corresponding module replacements on each test case in the test case list to generate the mapping library file corresponding to each test case.

[0045] Specifically, the system iterates through each test case in the test case list. For each test case, it first determines which modules must be retained (e.g., core functional modules) and which modules are allowed to be replaced, based on its corresponding test objective. Then, from the set of replaceable modules, it selects modules with high optimization potential and those that will significantly improve simulation efficiency after replacement, based on the previously calculated optimization scores. For example, if the test objective is "performance optimization, but retaining the CPU module," the system will prioritize replacing modules other than the CPU that have high optimization scores. After making the module replacement decision, the system automatically generates mapping library files containing libmap and config files based on the replacement results. These files will contain specific module replacement instructions for the current test case, guiding the simulator to perform precise module replacements during the compilation phase.

[0046] Step S204: Generate simulation files corresponding to each test case based on the mapping library file. See details in [link / reference]. Figure 1 Step S104 in the embodiment will not be described again here.

[0047] It is understood that, through the above technical solutions, this application can implement differentiated module replacement strategies for the specific needs of different test cases. By introducing strategy configuration files and test case lists, and supporting configuration in domain-specific languages ​​or graphical user interfaces, the definition process of complex simulation strategies is simplified, avoiding the inefficiency and error-proneness of traditional manual configuration. Parsing the strategy configuration file to obtain the test objectives enables the system to clearly understand the test intent of each test case. Thus, during module replacement, it can fully utilize optimized scoring to accelerate simulation while ensuring that critical modules are not mistakenly replaced, guaranteeing the accuracy of the test. Each test case can obtain a mapping library file that matches its test requirements, thereby maximizing simulation efficiency while ensuring test quality. This effectively solves the deficiency in existing technologies that cannot dynamically adjust replacement strategies according to test cases, significantly improving the automation level and overall efficiency of chip simulation verification. In some of the solutions described above in this application, a corresponding module replacement is proposed for each test case in the test case list based on the test objective and optimization score. This generates a mapping library file for each test case to meet the differentiated replacement needs of different test cases and improve the adaptability of chip simulation optimization. However, this process does not distinguish between module replacement rules under different test intentions, and cannot simultaneously address the needs of both user-defined replacement modules and automatic selection of replacement modules based on optimization potential scores. If all module selection relies on preset optimization scores, it cannot meet specific user test intentions or adapt to special test requirements. If all replacement modules are manually specified, the automatic selection of high-potential optimization modules by optimization scores cannot be utilized, thus failing to reduce manual operations, lower process efficiency, and ultimately leading to module replacements that do not meet test requirements, slowing down the overall simulation process, and failing to flexibly adapt to diverse chip test scenarios.

[0048] In response, this application further proposes a method for replacing corresponding modules in each test case in the test case list based on the test objectives and optimization scores, thereby generating a mapping library file corresponding to each test case. This method includes: Step a1: Analyze the test intent in the test target. The test intent is used to characterize the description of replacing the module in the simulation chip.

[0049] Step a2: Determine whether the test intent includes target test cases, where target test cases are used to characterize test cases that replace modules in the simulation chip based on optimization scores.

[0050] Step a3: If target test cases are included, replace the first target module determined based on the optimization score.

[0051] Step a4: If the target test case is not included, then the second target module is replaced based on the test intent.

[0052] Step a5: Based on the simulation chip after module replacement, generate the mapping library file corresponding to each test case.

[0053] Specifically, this involves parsing the test intent within the test objectives. Test intent describes the replacement of modules in the simulated chip. This step aims to extract specific instructions or descriptions on how to replace modules in the simulated chip from pre-defined test objectives. Test intent is a clear indication from the user or system to the simulation optimization strategy; it determines which modules should be replaced, how they should be replaced, and the purpose of the replacement. For example, semantic analysis of text-based test objectives can be performed using Natural Language Processing (NLP) techniques to identify keywords, phrases, and structures related to module replacement, thereby extracting the test intent, such as identifying instructions like "replace module A," "keep module B," and "optimize performance." Alternatively, this can be achieved using a parser for structured configuration files. Test objectives can be pre-defined as configuration files in XML, JSON, or YAML formats, containing explicit fields describing the intent for module replacement. The parser simply reads and extracts the values ​​of the corresponding fields; for example, the configuration file might contain `"replace_modules": ["module_X", "module_Y"]` or `"optimization_strategy": "auto_select_high_potential"`.

[0054] Next, it is determined whether the test intent includes a target test case. A target test case represents a test case that replaces modules in the simulated chip based on an optimization score. This step aims to help the system identify, based on the parsed test intent, whether the current test belongs to a scenario where automatic module selection based on a pre-calculated optimization score is required. A target test case represents an automated, data-driven optimization strategy designed to maximize simulation acceleration. For example, this can be indicated by setting a specific flag or keyword in the test intent; if the test intent contains instructions such as "auto_optimize" or "use_optimization_score," it is determined to include a target test case. Alternatively, it can be determined by analyzing the structure and content of the test intent. If the test intent does not explicitly specify a list of modules to be replaced but instead instructs on "general performance optimization" or "accelerated simulation," it can be inferred that it belongs to a target test case and requires module selection based on the optimization score.

[0055] If the system determines that the target test case is included, it replaces the first target module determined based on the optimization score. This step means that when the test intent indicates automated optimization, the system uses the previously calculated module optimization score to automatically select the most suitable module for replacement, i.e., the first target module, and executes the replacement operation. The aim is to guide module selection with quantitative data, achieving efficient simulation acceleration. For example, the system can sort all modules based on the optimization score and select the top N modules with the highest or lowest scores as the first target modules for replacement, replacing them with simplified substitute models. Alternatively, it can combine preset replacement rules and optimization scores; for example, only modules with optimization scores above a certain threshold and meeting specific conditions, such as module type or hierarchical depth, can be replaced to ensure the effectiveness and safety of the replacement.

[0056] If the test case is determined not to include the target test case, the second target module is replaced based on the test intent. This step means that when the test intent explicitly specifies the module to be replaced or the replacement strategy, the system will strictly follow these user-defined instructions to perform the replacement operation on the specified module, i.e., the second target module. This satisfies the user's need for fine-grained control over module replacement in specific test scenarios. For example, the test intent can directly contain a list of module names or instance paths. The system will iterate through the list and perform the replacement for each specified module, such as when the user explicitly specifies `"replace_list": ["top.sub_module_A", "top.sub_module_B"]` in the strategy configuration file. Alternatively, the test intent can also contain more complex rules, such as "replace all modules of type FIFO" or "keep all modules containing asynchronous logic." The system will identify and replace the corresponding second target module according to these rules.

[0057] Finally, based on the simulated chip after module replacement, mapping library files corresponding to each test case are generated. This step refers to the system solidifying these replacement rules into mapping library files, such as libmap / config files, after completing the module replacement decisions mentioned above. These files will guide the subsequent compilation and simulation processes, ensuring that the simulator can load and execute according to the expected replacement strategy. For example, the system can dynamically generate libmap and config files based on the module replacement results. The libmap file defines the mapping relationship between the original module and the substitute module, while the config file specifies which instance paths need to apply these mappings. Alternatively, mapping library files can be generated through template filling. A template for the mapping library file is predefined, and then the specific information of the module replacement, such as the original module name, the substitute module name, and the instance path, is filled into the corresponding positions in the template to finally generate a complete mapping library file.

[0058] It is understood that, through the above technical solution, this application achieves intelligent routing of module replacement strategies by introducing a mechanism for parsing and judging test intent. Specifically, by parsing the test intent in the test target, the true needs of the user or system for module replacement can be clearly identified. When the test intent explicitly indicates the need for automated module selection based on optimization scores, the system can accurately identify the target test case and automatically filter and replace the first target module based on the pre-calculated optimization score. This reduces manual intervention, improves the efficiency and accuracy of module selection, and ensures that the replaced module does indeed have high optimization potential, thereby effectively improving the simulation acceleration effect. On the other hand, when the test intent does not contain target test cases, i.e., when the user has a clear custom replacement requirement, this application can flexibly replace the second target module directly based on the test intent. This avoids the interference of automated selection on the user's specific needs and ensures that the user can accurately control the replacement of modules according to the actual test scenario. For example, in functional testing, the complete behavior of key modules can be retained, or in specific performance testing, a specified module can be replaced to verify specific optimization effects. Ultimately, this application can generate customized mapping library files for each test case based on the simulated chip after module replacement. This satisfies the differentiated replacement requirements of different test cases while taking into account the flexibility of automated optimization and user customization, significantly improving the adaptability, efficiency, and accuracy of the chip simulation verification process. In some of the solutions mentioned above in this application, module replacement is proposed to replace the target module of the simulation chip, adapting to the differentiated test optimization requirements of different test cases, thereby accelerating simulation. However, in its implementation, the specific implementation form of module replacement is not clearly defined, and there is no unified replacement specification. This can easily lead to configuration errors due to inconsistent replacement methods, increasing maintenance difficulty. It also cannot guarantee that the replacement will not affect the test results and achieve stable simulation optimization. In fact, improper replacement methods may even affect the original test results.

[0059] In response, this application further proposes module replacement, which includes replacing the target module with a substitute module. Specifically, the target module refers to the original module identified as having optimization potential in the simulated chip. It is typically a functional block, IP core, or hierarchical module in the chip design file, carrying complete internal logic and functionality. The substitute module, on the other hand, refers to a simplified module designed to simulate the external interface behavior and critical timing of the target module, but with its internal logic significantly simplified or omitted. For example, the substitute module can be a behavioral-level model, written using a high-level hardware description language, implementing only the input / output responses required by the target module in a specific test scenario, while ignoring its complex internal calculations; or, in some cases, the substitute module can be an empty module or a pass-through module, used only to connect input / output ports, containing no actual logic. Module replacement refers to the process of replacing a specific target module instance in the simulated chip with its corresponding substitute module instance through a configuration mechanism during the simulation preparation phase.

[0060] Through the above technical solutions, this application clarifies the specific implementation form of module replacement, unifies the replacement specifications, and can ensure the reliability and stability of simulation optimization while meeting testing requirements. In some of the embodiments described above in this application, a scoring method is proposed to evaluate the optimization potential of each module in the simulation chip from multiple dimensions based on the chip design file, thereby obtaining an optimization score. This score is used to automatically quantify the impact of replacing each module on the test results, providing a quantitative basis for generating mapping library files adapted to different test cases. However, in its implementation, there is a lack of standardized and unified methods for multi-dimensional feature extraction and quantification calculation. The evaluation of optimization potential still relies on subjective human judgment, which is not only inefficient but also prone to judgment bias. This leads to inaccurate subsequent module replacements, failure to obtain the expected simulation optimization effect, and difficulty in accumulating reusable optimization evaluation experience.

[0061] In response, this application further proposes a chip simulation verification method, such as... Figure 3 As shown, the method includes: Step S301: Receive the test case file and chip design file. See details in the [link / reference] section. Figure 1 Step S101 in the embodiment will not be described again here.

[0062] Step S302: Based on the chip design file, the optimization potential of each module in the simulation chip is scored from multiple dimensions to obtain an optimization score. The optimization potential is used to characterize the impact of replacing a module on the test results of the corresponding test cases. Specifically, this includes: Step S3021: Parse the RTL design file and construct the module hierarchy tree corresponding to the simulation chip.

[0063] Specifically, an RTL design file is a source code file written in a hardware description language such as Verilog, VHDL, or System Verilog. It describes the function and structure of digital circuits at the register transfer level. This file is the standard input in the chip design flow, containing information such as module definitions, instantiation, port connections, and internal logic implementation, and serves as the foundation for subsequent module analysis and feature extraction.

[0064] After obtaining the RTL design file, it needs to be parsed to construct the module hierarchy tree corresponding to the simulation chip. The purpose of parsing the RTL design file is to convert the raw text code into a structured data representation, thus clearly showing the calling relationships and hierarchical structure of the internal modules of the chip. The implementation of constructing the module hierarchy tree can include: utilizing existing EDA tools, such as Synopsys VCS and Cadence Xcelium, with their built-in RTL parsers to perform syntactic and semantic analysis on the design file, generating an internal abstract syntax tree, and extracting module definition and instantiation information from it to construct a tree-like module hierarchy structure; or, developing a custom RTL parser that uses lexical and syntactic analysis to identify key information such as module declarations, port lists, and instantiation statements, and establishes parent-child relationships between modules based on this information to form a complete module hierarchy tree.

[0065] Step S3022: Extract multi-dimensional feature information of each module in the module hierarchy tree. The multi-dimensional feature information includes at least the logical complexity, storage resource parameters, fan-in and fan-out parameters, module hierarchy depth, number of instantiated sub-modules within the module, module dependence on external signals, and whether the module contains asynchronous logic. The logical complexity includes at least one of the following: combinational logic depth, number of state machines, and number of always blocks.

[0066] Specifically, logical complexity measures the complexity of the internal logic of a module and is typically positively correlated with the computational load required by the simulator to process that module. Logical complexity includes at least one of the following: combinational logic depth, number of state machines, and number of always blocks. Combinational logic depth can be obtained by analyzing the combinational logic paths within the module and calculating the number of gate levels on the longest path; the number of state machines can be counted by identifying the number of finite state machines (FSMs) defined in the module; and the number of always blocks can be obtained by counting the number of always blocks or processes containing sequential or combinational logic within the module.

[0067] Storage resource parameters are used to measure the number and bit width of storage units used within a module, such as registers, RAM, and ROM. These resources affect the emulator's memory usage. Extraction methods can include: counting the total number or number of register variables defined in the module; or analyzing how many RAM / ROM IP cores the module instantiates and obtaining their configuration parameters, such as depth and bit width.

[0068] Fan-in and fan-out parameters are used to measure the degree of interconnectivity between modules. Fan-in refers to the number of signals input to the module, and fan-out refers to the number of output signals connected to other modules. High fan-in and fan-out may indicate that the module needs to interact frequently with other modules during simulation. Extraction methods can include: counting the number of input and output ports of the module; or analyzing the number of instances where the module's internal signals are connected to other modules.

[0069] Module hierarchy depth reflects a module's position within the overall design hierarchy tree; deeper modules may be more difficult to replace or optimize. Extraction methods can include: calculating the path length to the current module starting from the root node of the module hierarchy tree; or defining the absolute depth of a module, i.e., calculated from the top-level module, or the relative depth, i.e., relative to its parent module.

[0070] The number of instantiated submodules within a module reflects the complexity of the module's internal structure. Extraction methods can include: traversing the module hierarchy tree and counting the number of direct child nodes of the current module; or parsing the RTL code and counting the number of instantiation statements within the module.

[0071] A module's dependence on external signals reflects how much of its output signal is used by other modules, or how much of its input signal comes from other modules. High dependence may mean that replacing the module requires more caution. This can be extracted by analyzing the number of instances where the module's output ports are connected to other modules, or by analyzing how much of the module's input port receives signals from top-level or sibling modules.

[0072] Checking whether a module contains asynchronous logic is used to determine if asynchronous reset, asynchronous set, asynchronous clock switching, or similar logic exists within the module. Asynchronous logic typically increases the complexity and difficulty of simulation verification. Its extraction methods can include: identifying always blocks with asynchronous signal sensitivity lists through RTL code analysis; or using formal verification tools or static timing analysis tools to detect the presence of asynchronous logic.

[0073] Step S3023: Based on multi-dimensional feature information, calculate the optimization potential score of each module through a preset model to obtain the optimization score of each module.

[0074] Specifically, the preset model can include either a weighted linear model or a machine learning model. The weighted linear model assigns a weight to each extracted feature, then multiplies the feature values ​​by their weights and sums the results to obtain a final optimization potential score. The weights can be set based on the experience and knowledge of domain experts; for example, modules with high logical complexity can be assigned higher weights, as can asynchronous logic modules.

[0075] Machine learning models are trained using historical simulation data, including module features, replacement effects, and simulation speedup ratios, enabling them to automatically learn the complex nonlinear relationship between features and optimization potential. This can be achieved by employing supervised learning models, such as decision trees, random forests, or neural networks, taking multidimensional features as input and outputting an optimization potential score.

[0076] Step S303: Based on the optimized score and test case files, generate the mapping library files corresponding to each test case. Specifically, this includes: Step S3031: Parse the strategy configuration file to obtain the test objectives for each test case. The test objectives characterize the testing intent for each test case. See details... Figure 2 Step S2031 in the embodiment will not be described again here.

[0077] Step S3032: Based on the test objectives and optimization scores, perform corresponding module replacements for each test case in the test case list, generating the mapping library file corresponding to each test case. See details... Figure 2 Step S2032 in the embodiment will not be described again here.

[0078] Step S304: Generate simulation files corresponding to each test case based on the mapping library files. See details in [link to documentation]. Figure 1 Step S104 in the embodiment will not be described again here.

[0079] It is understood that, through the above technical solution, this application can automatically parse RTL design files, construct a module hierarchy tree, and extract module feature information from multiple dimensions, thereby eliminating the reliance on subjective human judgment in traditional optimization potential assessment and significantly improving assessment efficiency and accuracy. By quantifying key indicators such as logical complexity, storage resource parameters, fan-in and fan-out parameters, module hierarchy depth, the number of instantiated sub-modules within a module, the module's dependence on external signals, and whether the module contains asynchronous logic, this solution achieves a comprehensive and objective assessment of module characteristics, avoiding the bias that may arise from single-dimensional assessment. Furthermore, it supports two preset models: a weighted linear model and a machine learning model, making the optimization potential scoring process more flexible and adaptable, allowing the selection of the most suitable assessment strategy based on different design scales, complexities, and historical data. The final optimization score is quantitative and objective, providing a solid data foundation for subsequent module replacement for different test cases, facilitating more accurate and effective simulation acceleration, and enabling the accumulation and reuse of optimization assessment experience, thereby reducing the workload of engineers and improving the overall efficiency and quality of chip simulation verification. In some of the solutions mentioned above in this application, simulation files corresponding to each test case are generated based on the mapping library file to realize the generation of simulation files with corresponding adaptive module replacement strategies for different test cases. However, in this process, if all chip design files are completely recompiled for each test case, a large amount of repetitive and redundant compilation work will be generated, which will not only slow down the compilation process and waste computing and storage resources, but also make it difficult to efficiently support the need for different test cases to use different replacement rules. Therefore, a more efficient simulation file generation and compilation method is needed.

[0080] In response, this application further proposes a method for generating simulation files corresponding to each test case based on a mapping library file. This method includes: Step b1: The first compilation command is invoked to compile the chip design file into a common intermediate library. The first compilation command includes the vlogan command. The common intermediate library does not contain the libmap replacement rules.

[0081] Step b2: Invoke the second compilation command to compile the common intermediate library into simulation files corresponding to each test case by referencing the mapping library files of each test case. The second compilation command includes the vcs command.

[0082] Specifically, the first compilation command compiles the chip design files into a common intermediate library. This step aims to perform a preliminary compilation of the chip design files, such as RTL code, generating an intermediate artifact that can be reused in subsequent stages. This intermediate library is "common," meaning it does not contain any test case-specific substitution rules, and therefore can be shared by all test cases, avoiding repeated compilation of the underlying design. This process can be accomplished by executing specific compilation instructions provided by EDA tools. For example, using the vlogan command in the Synopsys VCS toolchain, which is responsible for compiling hardware description language files such as Verilog / SystemVerilog into intermediate formats, such as the contents of the `.vdb` or `work` libraries. Alternatively, similar functionality can be provided by other EDA simulation tools, such as Cadence Xcelium and Mentor QuestaSim, which use their respective compilation front-ends to convert the design files into an internal intermediate representation, forming a universal compilation result independent of specific simulation configurations. The first compilation command includes the `vlogan` command. `vlogan` is a core compilation tool in the Synopsys VCS simulator suite, specifically designed to compile source files of hardware description languages ​​such as Verilog and System Verilog into intermediate code or library files that the simulator can recognize. Its function is to parse RTL code, perform syntax checking and semantic analysis, and generate optimized internal representations to prepare for subsequent simulations. In practice, `vlogan` can be called directly from the command line, specifying the RTL design file path and output library name, for example, `vlogan -sverilog -workcommon_lib design.sv`; or it can be automated through scripts, integrated into the entire verification process to ensure the correctness and consistency of compilation parameters and file lists. The common intermediate library does not contain libmap replacement rules. It is a set of chip design files after initial compilation; it is a basic, general-purpose compilation output. The absence of libmap replacement rules means that this library is a pure design logic representation, without any configuration information specific to any simulation acceleration strategy. This ensures the general applicability of the intermediate library, allowing it to be referenced by any test case requiring different libmap configurations, thus achieving compile once and reuse multiple times. In implementation, when calling the first compilation command (such as vlogan), no libmap-related compilation options or configuration files can be passed in, ensuring that the compilation process only handles the RTL design itself; alternatively, the compilation system can explicitly manage the libmap configuration as an independent element introduced in subsequent stages when generating the common intermediate library, ensuring the purity of the common intermediate library.

[0083] Building upon this, the second compilation command is invoked to compile the common intermediate library into simulation files corresponding to each test case by referencing the mapping library files of each test case. This involves introducing a unique mapping library file for each specific test case, containing module replacement rules, and ultimately generating an executable simulation file, such as `simv`. Compiling the common intermediate library into simulation files corresponding to each test case avoids repeated compilation of the basic design files, significantly improving compilation efficiency. This process can be accomplished using the linking / compiling commands of simulation tools, such as `vcs`. This command loads the libmap / config file of the current test case, then combines it with the generated common intermediate library to perform final linking and code generation, forming a simulation executable file optimized for that test case. The second compilation command includes the `vcs` command, which is the main compilation and linking tool in the Synopsys VCS simulator suite. It is responsible for linking all compiled intermediate files and simulation configurations together to generate an executable simulation binary file. In practical applications, vcs can be invoked from the command line, specifying the public intermediate library previously generated by vlogan, the libmap / config file of the current test case, and other necessary simulation options; or vcs can be invoked through an automated script or integrated development environment (IDE) to encapsulate the compilation and linking process, simplify user operations, and ensure the correct passing of parameters.

[0084] It is understood that, through the above technical solution, this application adopts a phased, separate compilation approach to generate simulation files for each test case. This effectively solves the problems of repetitive and redundant compilation work, slowed compilation processes, wasted computing and storage resources, and difficulty in efficiently supporting different replacement rules for different test cases, which are caused by completely recompiling all chip design files for each test case. Specifically, the first step calls the first compilation command to compile the chip design files into a common intermediate library that does not contain libmap replacement rules. This unifies the compilation of chip design content shared by all test cases, reducing redundant compilation work at the source. The universality of the common intermediate library ensures that it can be referenced by any test case. The second step calls the second compilation command to compile the common intermediate library into simulation files corresponding to each test case by referencing the mapping library files of each test case, reducing the time spent on a single compilation. At the same time, each test case carries its own unique mapping library, that is, its own unique module replacement rules, which can generate simulation files that meet the testing requirements of the current test case. This effectively supports the differentiated optimization requirements of different test cases and significantly improves the efficiency and flexibility of chip simulation verification. In some of the solutions mentioned above in this application, a scheme is proposed to score the optimization potential of each module in the simulation chip from multiple dimensions, and then generate corresponding simulation files based on the scores to complete the chip simulation verification. However, in this process, the optimization potential score is completed only by pre-set rules, without combining the actual simulation performance after module replacement to obtain feedback. It is impossible to form an optimization closed loop of configuration simulation evaluation feedback, and it is impossible to quantify the actual optimization effect brought about by module replacement. Optimization experience is difficult to accumulate and reuse, and it is also impossible to guarantee the accuracy of the optimization potential score under different design versions and different test scenarios. It is easy to have blind spots in optimization effect and cannot dynamically adjust the optimization score to adapt to the actual simulation requirements.

[0085] In response, this application further proposes a chip simulation verification method, such as... Figure 4 As shown, the method includes: Step S401: Receive the test case file and chip design file. See details in the [link / reference] section. Figure 1 Step S101 in the embodiment will not be described again here.

[0086] Step S402: Based on the chip design file, the optimization potential of each module in the simulation chip is scored from multiple dimensions to obtain an optimization score. The optimization potential is used to characterize the impact of replacing a module on the test results of the corresponding test cases. Specifically, this includes: Step S4021: Parse the RTL design file and construct the module hierarchy tree corresponding to the simulation chip. See details... Figure 3 Step S3021 in the embodiment will not be described again here.

[0087] Step S4022: Extract the multidimensional feature information of each module in the module hierarchy tree. See details in the [link to relevant documentation]. Figure 3 Step S3022 in the embodiment will not be described again here.

[0088] Step S4023: Based on multi-dimensional feature information, calculate the optimization potential score of each module using a preset model to obtain the optimization score for each module. See details... Figure 3 Step S3023 in the embodiment will not be repeated here.

[0089] Step S403: Based on the optimized score and test case files, generate the mapping library files corresponding to each test case. Specifically, this includes: Step S4031: Parse the strategy configuration file to obtain the test objectives for each test case. The test objectives characterize the testing intent for each test case. See details... Figure 2 Step S2031 in the embodiment will not be described again here.

[0090] Step S4032: Based on the test objectives and optimization scores, perform corresponding module replacements for each test case in the test case list, generating the mapping library file corresponding to each test case. See details... Figure 2 Step S2032 in the embodiment will not be described again here.

[0091] Step S404: Generate simulation files corresponding to each test case based on the mapping library files. See details in [link to documentation]. Figure 1 Step S104 in the embodiment will not be described again here.

[0092] Step S405: Obtain the test results for each test case. The test results shall include at least one of the following: simulation runtime, peak memory usage, and compilation time.

[0093] Specifically, this step aims to collect performance data during the actual simulation process, providing objective evidence for subsequent performance evaluation and optimization feedback. For example, after the simulation is completed, the simulation runtime, peak memory usage, and compilation time for each test case can be automatically extracted and recorded using the log parsing function or API interface provided by the simulation tool. This data can be stored in a database or file. Additionally, monitoring agents or scripts can be deployed to collect system resource usage in real-time or periodically during the simulation environment, including process CPU time and memory usage, and summarize this data into test results after the simulation ends. Compilation time can be obtained by recording the execution time of the compilation commands.

[0094] Step S406: Compare the test results with the corresponding target performance indicators to obtain the performance improvement ratio, wherein the performance improvement ratio includes the speedup ratio.

[0095] Specifically, this step aims to quantify the actual performance improvement or decline brought about by the module replacement strategy, transforming the abstract optimization effect into comparable numerical values. For example, target performance metrics for each test case under ideal conditions or without module replacement can be pre-defined, such as target simulation runtime or target peak memory usage. The actual test results are then mathematically compared to these target metrics, using methods like ratios or percentage differences, to calculate the performance improvement ratio. For instance, the speedup ratio can be defined as the baseline simulation runtime divided by the simulation runtime after module replacement. Alternatively, a historical performance database can be established to store performance data for different design versions and test cases under standard configurations as a benchmark. After a new simulation is completed, the test results are compared to the corresponding benchmark data in the database to calculate the performance improvement ratio. The performance improvement ratio can be a comprehensive metric or a metric specific to a single performance parameter.

[0096] Step S407: In the next optimization scoring, based on the performance improvement ratio and module replacement information, the optimization potential of each module in the simulation chip is scored from multiple dimensions to obtain the optimization score.

[0097] Specifically, this step aims to form an optimization loop, using the actual effect of the previous module replacement to correct and improve the optimization potential score for the next iteration, making the score more accurate and closer to actual needs. For example, a feedback mechanism can be established, using the performance improvement ratio as one of the input features of a preset model, such as a weighted linear model or a machine learning model. Simultaneously, it records which modules were replaced in the current simulation, i.e., module replacement information, and the contribution of these replacements to the performance improvement ratio. In the next scoring iteration, the model will adjust the module weights or model parameters based on this feedback data, thereby more accurately evaluating the optimization potential of each module. If a module's speedup is significant after replacement, its optimization potential score will increase accordingly; if performance decreases after replacement, the score will decrease. Alternatively, reinforcement learning or adaptive algorithms can be used. Module replacement is considered an "action," and the performance improvement ratio is considered a "reward." The system continuously tries different module replacement strategies and adjusts the optimization potential scoring strategy for each module based on the obtained "rewards." Module replacement information can be included as part of the state, helping the algorithm understand the impact of different module replacement combinations on performance. In this way, the optimization potential score will be dynamically adjusted with each iteration to maximize overall simulation performance.

[0098] It is understood that, through the above technical solution, this application constructs a complete closed-loop iterative mechanism for evaluating the optimization potential of chip simulation verification, solving the problems of lack of actual performance feedback and inability to accumulate experience in the original solution. First, by collecting actual test results for each test case, including objective and quantifiable data such as simulation runtime, peak memory usage, and compilation time, the original method relying on subjective human judgment of optimization effects is replaced. This provides accurate factual basis for subsequent feedback adjustments, ensuring that adjustments conform to actual simulation operation. Second, the collected test results are compared with the corresponding target performance indicators to obtain the performance improvement ratio, including the speedup ratio. This quantifies the actual performance changes brought about by module replacement, clearly revealing the actual optimization effect of each module after replacement. This provides a clear quantitative basis for subsequent adjustments to the optimization potential score, avoiding bias caused by subjective judgment. Finally, in the next optimization potential score evaluation, the score is completed by combining the performance improvement ratio obtained this time with the module replacement information, feeding the actual optimization effect back to the initial optimization potential score evaluation stage, thus realizing a closed-loop iterative process for the entire optimization process. This allows the optimization potential score to be continuously revised based on actual test results, making subsequent optimization potential assessments increasingly aligned with actual simulation optimization needs. It also allows for the accumulation of optimization experience, ensuring the accuracy of the optimization potential score even when design versions are updated or test requirements change. This eliminates the blind spots in the effectiveness of the original optimization schemes and significantly improves the efficiency and accuracy of chip simulation verification. In one example, such as Figure 5 As shown, the above technical solution will be explained in more detail through a more specific example: In a chip design verification scenario, User A needs to simulate and verify a System-on-a-Chip (SoC) that includes a complex AI accelerator module, a CPU core module, and multiple peripheral modules. The SoC design file is `soc_design.v`, and a regression test suite exists, containing hundreds of test cases, described in the file `test_suite.json`.

[0099] First, the system receives `test_suite.json` as the test case file and `soc_design.v` as the chip design file.

[0100] Next, the system scores the optimization potential of each module in the simulated chip based on the `soc_design.v` file. The specific process includes: the system parses `soc_design.v`, i.e., the RTL design file, and constructs the module hierarchy tree corresponding to the simulated chip. Subsequently, the system extracts multi-dimensional feature information for each module from this hierarchy tree. For example, the logical complexity of the AI ​​accelerator module includes combinational logic depth, number of state machines, number of always blocks, storage resource parameters, fan-in and fan-out parameters, module hierarchy depth, number of instantiated sub-modules within the module, module dependence on external signals, and whether it contains asynchronous logic. Based on this multi-dimensional feature information, the system calculates the optimization potential score for each module using a pre-defined machine learning model or a pre-defined model, thus obtaining the optimization score for each module. For example, the AI ​​accelerator module, due to its high complexity, may receive a higher optimization score, while a simple GPIO peripheral module may receive a lower score. This step addresses the lack of quantitative evaluation in existing technologies, providing data support for subsequent optimization decisions.

[0101] Then, based on these optimization scores and the `test_suite.json` file, the system generates mapping library files corresponding to each test case. The `test_suite.json` file includes a strategy configuration file `strategy_config.yaml` and a list of test cases. The system parses `strategy_config.yaml` to obtain the test objective for each test case. For example, for a test case named `test_case_func_AI`, which aims to verify the functionality of the AI ​​accelerator module, its test objective might be "verify the functionality of the AI ​​accelerator module and replace non-critical peripheral modules"; while for another test case named `test_case_perf_CPU`, which aims to evaluate the performance of the CPU core module, its test objective might be "measure the performance of the CPU core module and replace all non-CPU modules with high optimization potential".

[0102] Based on these test objectives and the previously obtained optimization scores, the system performs corresponding module replacements for each test case in the test case list, generating a mapping library file. Specifically, the system parses the test intent in the test objectives. For `test_case_perf_CPU`, its test intent might include "replacing modules in the simulation chip based on the optimization score." In this case, the system determines that the test intent includes target test cases, and therefore identifies the AI ​​accelerator module and some complex peripheral modules as the first target modules based on the optimization score, replacing them with simplified substitute modules. For `test_case_func_AI`, its test intent might explicitly specify "replacing the GPIO module and UART module." In this case, the system determines that the test intent does not include target test cases, and therefore, based on the test intent, it replaces the GPIO module and UART module as the second target modules with substitute modules. Based on the simulated chip description after module replacement, the system generates dedicated `libmap_func_AI.libmap` and `config_func_AI.config` files for `test_case_func_AI`, and dedicated `libmap_perf_CPU.libmap` and `config_perf_CPU.config` files for `test_case_perf_CPU`. These files constitute the mapping library files corresponding to each test case. This process enables dynamic adjustment of the replacement strategy according to test cases, solving the problem of static and fixed strategies in existing technologies that cannot be dynamically adjusted according to test cases, and significantly reducing the reliance on manual operations.

[0103] Finally, the system generates simulation files corresponding to each test case based on these mapping library files. The system first calls a first compilation command, such as `vlogan`, to compile the `soc_design.v` file into a common intermediate library, which does not contain any libmap replacement rules. Then, for `test_case_func_AI`, the system calls a second compilation command, such as `vcs`, which references the previously generated common intermediate library and compiles the `libmap_func_AI.libmap` and `config_func_AI.config` files into the `simv_func_AI` simulation file. Similarly, for `test_case_perf_CPU`, the system calls the same second compilation command, referencing the common intermediate library and compiling the `libmap_perf_CPU.libmap` and `config_perf_CPU.config` files into the `simv_perf_CPU` simulation file. This two-step compilation method allows the core design to be compiled only once, while replacement rules for different test cases can be flexibly applied in the second compilation step, avoiding the cumbersome process of repeatedly compiling the entire design for each differentiation strategy in existing technologies.

[0104] Furthermore, after simulation, the system acquires the test results for each test case, such as simulation runtime, peak memory usage, and compilation time. The system compares these test results with the corresponding target performance metrics to obtain the performance improvement ratio, i.e., the speedup ratio. In the next optimization scoring, the system will use these performance improvement ratios and module replacement information to score the optimization potential of each module in the simulated chip from multiple dimensions. This forms a closed-loop feedback mechanism, enabling the optimization strategy to continuously learn and improve, solving the problem of the lack of quantitative evaluation and feedback mechanisms in existing technologies.

[0105] This embodiment also provides a chip simulation and verification device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0106] This embodiment provides a chip simulation and verification device, such as... Figure 6 As shown, it includes: The receiving module 601 is used to receive test case files and chip design files.

[0107] The scoring module 602 is used to score the optimization potential of each module in the simulated chip from multiple dimensions based on the chip design file, and obtain the optimization score. The optimization potential is used to characterize the impact of replacing the module on the test effect of the corresponding test cases.

[0108] The first generation module 603 is used to generate mapping library files corresponding to each test case based on the optimization score and test case files.

[0109] The second generation module 604 is used to generate simulation files corresponding to each test case based on the mapping library file.

[0110] In some alternative implementations, the first generation module 603 includes: The first unit is used to parse the strategy configuration file and obtain the test objectives for each test case. The test objectives are used to characterize the test intent for the test case.

[0111] The second unit is used to replace the corresponding modules for each test case in the test case list according to the test objectives and optimization scores, and generate the corresponding mapping library file for each test case.

[0112] The chip simulation and verification apparatus provided in this application can execute the chip simulation and verification method provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects for executing the method. Further functional descriptions of each module and unit are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0113] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0114] The following is a detailed reference. Figure 7 The diagram illustrates a structural schematic suitable for implementing the electronic device described in the embodiments of this application. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 701, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 702 or a program loaded from memory 708 into random access memory (RAM) 703. The RAM 703 also stores various programs and data required for the operation of the electronic device. The processor 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0115] Typically, the following devices can be connected to I / O interface 705: input devices 706 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 707 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 708 including, for example, magnetic tapes, hard disks, etc.; and communication devices 709. Communication device 709 allows electronic devices to exchange data via wireless or wired communication with other devices. Although Figure 7 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0116] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 709, or installed from a memory 708, or installed from a ROM 702. When the computer program is executed by the processor 701, it performs the functions defined in the chip simulation verification method of embodiments of this application.

[0117] Figure 7 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0118] This application also provides a computer-readable storage medium. The methods described in this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the chip simulation verification method shown in the above embodiments is implemented.

[0119] A portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0120] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A chip simulation and verification method, characterized in that, The method includes: Receive test case files and chip design files; Based on the chip design file, the optimization potential of each module in the simulation chip is scored from multiple dimensions to obtain an optimization score. The optimization potential is used to characterize the impact of replacing the module on the test effect of the corresponding test cases. Based on the optimization score and the test case file, generate a mapping library file corresponding to each test case; Based on the mapping library file, generate simulation files corresponding to each test case; The test case file includes a strategy configuration file and a list of test cases. The step of generating a mapping library file corresponding to each test case based on the optimized score and the test case file includes: The strategy configuration file is parsed to obtain the test objectives for each test case, which are used to characterize the test intent for the test case; Based on the test objectives and the optimization scores, each test case in the test case list is replaced with a corresponding module, generating a mapping library file corresponding to each test case.

2. The method according to claim 1, characterized in that, The step involves replacing corresponding modules for each test case in the test case list based on the test objective and the optimization score, generating a mapping library file corresponding to each test case, including: The test intent in the test objective is analyzed, and the test intent is used to characterize the description of replacing the module in the simulation chip; Determine whether the test intent includes a target test case, wherein the target test case is used to characterize a test case that replaces a module in the simulation chip based on the optimization score; If the target test cases are included, the first target module determined based on the optimization score is replaced. If the target test case is not included, then the second target module is replaced based on the test intent; Based on the simulation chip after module replacement, a mapping library file corresponding to each test case is generated.

3. The method according to claim 2, characterized in that, The module replacement includes replacing the target module with a substitute module.

4. The method according to claim 1, characterized in that, The chip design files include RTL design files. Based on the chip design file, the optimization potential of each module in the simulation chip is scored from multiple dimensions to obtain an optimization score, including: Parse the RTL design file and construct the module hierarchy tree corresponding to the simulation chip; Extract multidimensional feature information of each module in the module hierarchy tree. The multidimensional feature information includes at least logical complexity, storage resource parameters, fan-in and fan-out parameters, module hierarchy depth, number of instantiated sub-modules within the module, module dependence on external signals, and whether the module contains asynchronous logic. The logical complexity includes at least one of combinational logic depth, number of state machines, and number of always blocks. Based on the multidimensional feature information, the optimization potential score of each module is calculated using a preset model to obtain the optimization score of each module.

5. The method according to claim 1, characterized in that, The step of generating simulation files corresponding to each test case based on the mapping library file includes: The first compilation command is invoked to compile the chip design file into a public intermediate library; The second compilation command is invoked to compile the common intermediate library into simulation files corresponding to each test case by referencing the mapping library files of each test case.

6. The method according to claim 1, characterized in that, The method includes: Obtain the test results for each test case, and the test results shall include at least one of the following: simulation runtime, peak memory usage, and compilation time. The test results are compared with the corresponding target performance indicators to obtain the performance improvement ratio; In the next optimization scoring, based on the performance improvement ratio and module replacement information, the optimization potential of each module in the simulation chip is scored from multiple dimensions to obtain the optimization score.

7. A chip simulation and verification device, characterized in that, The device includes: The receiving module is used to receive test case files and chip design files; The scoring module is used to score the optimization potential of each module in the simulation chip from multiple dimensions based on the chip design file, and obtain an optimization score. The optimization potential is used to characterize the impact of replacing the module on the test effect of the corresponding test cases. The first generation module is used to generate a mapping library file corresponding to each test case based on the optimization score and the test case file; The second generation module is used to generate simulation files corresponding to each test case based on the mapping library file; The test case file includes a strategy configuration file and a test case list. Based on the optimization score and the test case file, a mapping library file corresponding to each test case is generated, including: The strategy configuration file is parsed to obtain the test objectives for each test case, which are used to characterize the test intent for the test case; Based on the test objectives and the optimization scores, each test case in the test case list is replaced with a corresponding module, generating a mapping library file corresponding to each test case.

8. An electronic device, characterized in that, include: A memory and a processor are interconnected, the memory stores computer instructions, and the processor executes the computer instructions to perform the chip simulation verification method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the chip simulation verification method according to any one of claims 1 to 6.

Images