Intelligent excitation generation method for chip verification
By employing a five-stage closed-loop process and dynamic constraint technology, the problems of test case redundancy and incomplete coverage in traditional chip verification are solved, enabling accurate stimulus generation and early vulnerability detection, thereby improving the efficiency and reliability of chip verification.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- YUANQIXIN (SHANDONG) SEMICONDUCTOR TECHNOLOGY CO LTD
- Filing Date
- 2025-12-09
- Publication Date
- 2026-04-10
AI Technical Summary
Traditional chip verification methods suffer from redundant test cases, incomplete functional coverage, and frequent manual intervention. They are difficult to generate accurate stimuli, cover all scenarios comprehensively, and have a low degree of automation, thus failing to meet the high-efficiency verification needs of complex chips.
It adopts a five-stage closed-loop process, including coverage variable randomization, functional data path operation, coverage data collection, and automated feedback loop. It generates precise incentives through dynamic constraint technology, realizes non-repeating directional generation of coverage variables and automated feedback loop, and automatically generates a verification report.
It achieves accurate incentive generation, accelerated coverage and early vulnerability detection, significantly improving chip verification efficiency and reliability, adapting to the verification needs of complex chips such as SoC, eliminating manual intervention and achieving 100% functional coverage.
Smart Images
Figure CN121835540A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of integrated circuit design verification technology, specifically to a smart stimulus generation method for chip verification. Background Technology
[0002] In the chip design process, functional verification is a crucial step in ensuring chip reliability. Its core objective is to comprehensively examine chip functionality and identify potential design flaws by generating appropriate stimuli. Traditional chip verification methods employ a multi-round iterative model of "test case development - regression testing - simulation coverage merging - manual analysis - constraint / seed modification." This model has the following significant technical shortcomings:
[0003] 1. Redundancy of test cases: Due to the complex architecture of chips with multiple modules and multiple protocols, it is necessary to develop independent test cases for each functional scenario, resulting in a surge in the number of test cases.
[0004] 2. Incomplete functional coverage: Relying on manual adjustment of constraints and seeds makes it impossible to traverse all potential functional scenarios, especially prone to overlooking boundary conditions, which leads to design flaws being exposed in actual applications;
[0005] 3. Frequent manual intervention: Simulation coverage analysis and test case modification require a lot of manual operation, which is not only inefficient, but also prone to human error and affects the accuracy of verification.
[0006] While existing technologies such as constrained random testing have made attempts to optimize stimulus generation, they still fail to address the core issues of "stimulus duplication," "insufficient early vulnerability detection," and "lack of closed-loop automation," making it difficult to meet the high-efficiency verification requirements of complex chips. Therefore, the industry urgently needs a verification method that can achieve accurate stimulus generation, comprehensive scenario coverage, and a high degree of automation. Summary of the Invention
[0007] This invention addresses the needs and shortcomings of current technological development by providing an intelligent stimulus generation method for chip verification. By constructing a five-stage closed-loop process of "coverage variable randomization - functional data path execution - coverage data collection - automated feedback loop - verification report generation", it achieves accurate stimulus generation, accelerated coverage, and early vulnerability detection, significantly optimizing chip verification efficiency.
[0008] The present invention provides a smart stimulus generation method for chip verification, and the technical solution adopted to solve the above-mentioned technical problems is as follows:
[0009] A smart stimulus generation method for chip verification includes the following steps:
[0010] S1. Coverage Variable Randomization: Obtain the functional coverage requirements of the chip design, define the coverage groups and coverage blocks, and extract the coverage variables that need to hit the coverage blocks; based on the correspondence between the coverage blocks and the coverage variables, generate the initial coverage variable values for the first stage of simulation; after the simulation is completed, generate unique variable values for the next stage based on the coverage results using dynamic constraint technology.
[0011] S2. Functional Data Path Execution: Based on the coverage variable configuration, the specified functional scenario adapted to the chip target module is triggered, and the preset functional data path is called to verify and cover the corresponding coverage module; wherein, the preset chip functional data path includes chip key signals, registers and component information;
[0012] S3. Coverage Data Collection: Real-time and accurate collection of coverage data from coverage groups and coverage warehouses to provide decision-making basis for feedback loops;
[0013] S4, Automatic Feedback Loop: Automatically determines whether the coverage data has reached the preset coverage target: If the coverage target has not been reached, the current coverage result is fed back to the coverage variable randomization stage of S1, and the coverage variable is regenerated to cover the missed scenarios; If the coverage target has been reached, the generation of the verification report in the next stage is triggered.
[0014] S5. Validation Report Generation: Automatically generates a validation report in Excel format, including: number of iterations and coverage percentage of each coverage group / coverage repository.
[0015] Optionally, step S1 specifically includes the following operations:
[0016] S1.1 Coverage Requirement Analysis: The functional coverage requirements of the chip design are imported through the coverage_cfg configuration class in the UVM environment, including coverage group definition, coverage bin division and coverage weight; the coverage variable manager reads the instance and configuration information of the coverage_cfg configuration class from the environment through the UVM configuration database, automatically extracts the coverage variables that need to hit the coverage bin, and establishes a mapping relationship table between coverage variables and coverage bins.
[0017] S1.2 Initial Variable Generation: The coverage variable manager generates the initial coverage variable values for the first stage simulation based on the coverage variable-coverage bin mapping table. For discrete variables, the coverage variable manager selects the initial value from the coverage bin value set using a uniform random strategy. For continuous variables, the coverage variable manager uses an interval segmented random strategy, randomly selecting one initial value from the sub-intervals formed by interval segmentation to ensure the uniformity of the initial excitation coverage.
[0018] S1.3 Iterative Variable Optimization: After the first stage of simulation is completed, the coverage variable manager receives the coverage results and generates unique variable values for the next stage through dynamic constraint technology.
[0019] Preferably, the dynamic constraint technique employs an optimization strategy that integrates "constrained random testing and directed testing," dynamically adjusting the stimulus generation direction based on test coverage, as follows:
[0020] (a) For uncovered coverage areas, dynamic constraint technology generates directional constraints to directly lock the value range of the uncovered areas, ensuring that the incentive generation can accurately target the scene to be covered.
[0021] (b) For covered bins, dynamic constraint technology generates random constraints that include covered and uncovered values, and optimizes the probability of value selection by adjusting the weights, setting the weight of uncovered values higher than that of covered values, thereby increasing the likelihood of uncovered values being selected.
[0022] (c) To avoid incentive duplication, dynamic constraint technology achieves control through historical value deduplication constraints, maintains a designated queue to store historical variable values, adds constraints that are not equal to historical values to the current variable generation, and ensures that the newly generated variable value does not duplicate the historical value.
[0023] Optionally, step S2 specifically includes:
[0024] S2.1 Data Path Loading: During the execution of the data path, the user-preset functional data path script is loaded. This script covers the hardware logic interaction process of the chip target module, key signal timing control and storage access rules.
[0025] S2.2 Variable Configuration Injection: Based on the overriding variable configuration, the variable values are injected into the corresponding signals of the data path through the signal binding mechanism; at the same time, the key parameters of the data path are adjusted according to the variable values to ensure that the variable configuration is compatible with the data path.
[0026] S2.3 Functional Scenario Execution: Following the flow defined in the functional data path script, drive the target chip module to execute the corresponding functional scenario, thereby verifying the function of the target chip module and completing the coverage of the corresponding coverage module.
[0027] Optionally, step S3 specifically includes the following operations:
[0028] S3.1 Layered Acquisition of Coverage Data: The coverage data collector adopts a top-down layered acquisition strategy to acquire coverage data at the coverage group level and coverage warehouse level respectively.
[0029] (a) Coverage group level data acquisition: Obtain the coverage of the entire coverage group by calling the SystemVerilog get_coverage() task;
[0030] (b) Coverage bin-level data collection: The coverage rate of a single coverage bin is obtained through the get_bin_coverage() task. This task needs to be defined in the coverage group definition.
[0031] (c) Cross-coverage data acquisition: For cross-coverage scenarios, the coverage rate of the cross-coverage bins is obtained through the get_cross_coverage() task, and the coverage status of each cross combination is returned;
[0032] S3.2 Data Validation: Validate the validity of the collected data;
[0033] S3.3 Data Format Conversion: Convert the original overlay data that has passed the validity check into a key-value pair format for easy use later.
[0034] Preferably, the collected data is validated, specifically including:
[0035] (i) Timing verification: Check whether the data acquisition time is in a stable working state of the data acquisition unit. If it is in a reset state rst_n=0, mark the data as invalid and re-acquire it.
[0036] (ii) Consistency check: Compare the sum of the coverage rates of each coverage warehouse under the same coverage group with the logical consistency of the coverage rate of the coverage group;
[0037] (iii) Duplicate verification: Check whether the coverage data collected in two consecutive times are completely consistent. If the data is the same in three consecutive times and the preset coverage target is not reached, it is determined that there may be an excitation dead loop. An alarm needs to be triggered and the coverage variable manager needs to be notified to adjust the constraint strategy.
[0038] Optionally, the coverage targets can be configured using two modes: absolute targets and relative targets.
[0039] (a) Absolute target mode: By using a preset fixed coverage threshold as the judgment standard, the coverage of the coverage group and the coverage of all coverage warehouses are required to reach the specified threshold.
[0040] (b) Relative target mode: The preset coverage improvement threshold is used as the judgment standard. The target is judged based on the coverage improvement rate. The core rule is that if the coverage improvement rate meets the preset threshold condition, the target is judged to be achieved.
[0041] The real-time collected coverage data is compared with the preset coverage target, and the compliance determination is completed according to the threshold rules of the corresponding configuration mode:
[0042] (i) When using the absolute target mode, it is necessary to verify whether the real-time coverage data fully meets the preset fixed threshold requirements. If all requirements are met, the target is determined to be achieved; otherwise, the target is determined not to be achieved.
[0043] (ii) When using the relative target mode, it is necessary to verify whether the iterative improvement of the real-time coverage data meets the preset improvement threshold requirements. If it does, it is determined that the target has been achieved; otherwise, it is determined that the target has not been achieved.
[0044] Optionally, in step S4, if the coverage data fails to reach the preset coverage target, an iteration direction instruction is sent to the coverage variable manager based on the priority of the uncovered scenario.
[0045] (a) High-priority scenarios: The instruction override variable manager generates targeted stimuli, prioritizing the override of missed scenarios;
[0046] (b) Medium priority scenarios: The instruction coverage variable manager adopts a stimulus generation strategy that combines directional and random approaches to balance coverage efficiency and scenario diversity. directional stimulus is used to quickly cover core and key instruction coverage points to ensure coverage efficiency. Random stimulus is used to traverse boundary, exception, and long-tail scenarios to ensure scenario diversity, ultimately achieving a balance between coverage efficiency and scenario diversity.
[0047] (c) Low-priority scenarios: The instruction manager adopts a random stimulus generation strategy to reduce resource consumption in high-priority scenarios.
[0048] Optionally, the verification report may be derived from the full coverage data collected, the scenario execution logs of the data path execution, and the iterative statistical data of the automatic feedback loop. The aforementioned data may be integrated into a report data source to support the generation of verification reports, making it easier for engineers to trace problems, analyze design defects, and form a verification closed loop.
[0049] The intelligent stimulus generation method for chip verification of the present invention has the following advantages compared with the prior art:
[0050] 1. This invention constructs a five-stage intelligent incentive generation closed-loop system of "coverage variable randomization - functional data path operation - coverage data collection - automated feedback loop - verification report generation". It can target and cover missed scenarios, eliminate manual intervention, and detect boundary vulnerabilities in advance. It effectively solves the problems of traditional verification methods that rely on manual design of test cases and adjustment of constraints, resulting in redundant test cases, incomplete coverage, and delayed vulnerability discovery. It significantly improves the efficiency and reliability of complex chip verification.
[0051] 2. This invention achieves non-repeating and targeted generation of coverage variables through dynamic constraint generation technology, accurately collects coverage group and coverage bin data through a hierarchical calling mechanism, achieves iterative optimization without manual intervention through automated feedback loop, captures boundary vulnerabilities in advance through an early start mechanism, and automatically generates a visual verification report to complete closed-loop traceability. Overall, this method can achieve accurate stimulus generation, improved coverage efficiency and early vulnerability detection for chip verification, and achieve 100% functional coverage without multiple rounds of simulation iteration, effectively adapting to the verification needs of complex chips such as SoC.
[0052] 3. This invention can be widely applied to the design and verification process of complex integrated circuits such as SoC chips, MCUs, and high-end processors. It is compatible with the functional verification requirements of core modules such as DMA and AXI bus, and overcomes the industry pain points of redundant test cases, long cycles, and easy omission of boundary vulnerabilities in traditional chip verification. Attached Figure Description
[0053] Appendix Figure 1 This is a schematic diagram of the method flow of the present invention. Detailed Implementation
[0054] To make the technical solution, the technical problem solved, and the technical effect of the present invention clearer, the technical solution of the present invention will be clearly and completely described below in conjunction with specific embodiments.
[0055] Example 1:
[0056] Combined with appendix Figure 1 This embodiment proposes a smart stimulus generation method for chip verification, including the following steps:
[0057] S1. Coverage Variable Randomization: Obtain the functional coverage requirements of the chip design, define the coverage groups and coverage blocks, and extract the coverage variables that need to hit the coverage blocks; based on the correspondence between coverage blocks and coverage variables, generate the initial coverage variable values for the first stage of simulation; after the simulation, based on the coverage results, generate unique variable values for the next stage using dynamic constraint technology. This process specifically includes the following operations:
[0058] S1.1 Coverage Requirement Analysis: The functional coverage requirements of the chip design are imported through the coverage_cfg configuration class in the UVM (Universal Verification Methodology) environment, including the definition of coverage groups, the division of coverage bins, and the coverage weights. The coverage variable manager reads the instance and configuration information of the coverage_cfg configuration class from the environment through the UVM configuration database (uvm_config_db#(coverage_cfg)), automatically extracts the coverage variables that need to hit the coverage bins, and establishes a mapping table between coverage variables and coverage bins.
[0059] S1.2 Initial Variable Generation: The coverage variable manager generates the initial coverage variable values for the first stage simulation based on the coverage variable-coverage bin mapping table. For discrete variables, the coverage variable manager selects initial values from the coverage bin value set using a uniform random strategy. For continuous variables, the coverage variable manager uses an interval segmented random strategy, randomly selecting one initial value from each sub-interval formed by interval segmentation to ensure the uniformity of the initial excitation coverage. For example, the coverage bin interval [0:15] is divided into four sub-intervals [0:3], [4:7], [8:11], and [12:15], and one initial value is randomly selected from each sub-interval.
[0060] S1.3 Iterative Variable Optimization: After the first stage of simulation is completed, the coverage variable manager receives the coverage results and generates unique variable values for the next stage through dynamic constraint technology.
[0061] The dynamic constraint technique employs an optimization strategy that integrates random and targeted testing, dynamically adjusting the stimulus generation direction based on test coverage, as detailed below:
[0062] (a) For uncovered coverage bins, dynamic constraint technology generates directional constraints to directly lock the uncovered value range, ensuring that the stimulus generation can accurately point to the scene to be covered; for example, if the range [12:15] in the awlen_txs coverage bin is not covered, then the constraint awlen_0inside{[12:15]} is added.
[0063] (b) For covered bins, dynamic constraint technology generates random constraints containing covered and uncovered values, and optimizes the probability of value selection by adjusting the weights. The weight of uncovered values is set higher than that of covered values to increase the likelihood of uncovered values being selected. For example, in the awsize_txs covered bin, {1,2,3} is covered and {4} is not covered. Then, the constraint awsize_0inside{[1:4]} is added, and the weight of uncovered values is set to 3, and the weight of covered values is set to 1.
[0064] (c) To avoid incentive duplication, dynamic constraint technology manages the issue by using historical value deduplication constraints. It maintains a designated queue to store historical variable values and adds constraints to the current variable that are not equal to historical values, ensuring that the newly generated variable value does not duplicate historical values. For example, if the historical variable value is {AWLEN=5, AWSIZE=2}, then the next stage variable value can be generated as {AWLEN=13, AWSIZE=4}, which covers the [12:15] interval of awlen_txs while avoiding duplication with historical values.
[0065] S2. Functional Data Path Execution: Based on the coverage variable configuration (centered around the chip design's functional coverage requirements, using the correspondence between "coverage group - coverage module - coverage variable" as the core, a phased dynamic value retrieval scheme is formulated to hit the coverage module, including the initial coverage variable value in the first stage and subsequent iterative variable values generated by dynamic constraint technology based on the coverage results), the specified functional scenario adapted to the chip target module is triggered, and the preset functional data path is called to verify and cover the corresponding coverage module; wherein, the preset chip functional data path includes chip key signals, registers, and component information. This process specifically includes the following operations:
[0066] S2.1 Data Path Loading: During the execution of the data path, the user-preset functional data path script is loaded through uvm_resource_db. This script covers the hardware logic interaction process of the chip target module, key signal timing control and storage access rules.
[0067] S2.2 Variable Configuration Injection: Based on the overriding variable configuration, the variable values are injected into the corresponding signals of the data path through the signal binding mechanism; for example, AWLEN=13, AWSIZE=4, AWID=3, AWLEN=13 is bound to the AWLEN signal of the AXI write address channel, AWSIZE=4 is bound to the AWSIZE signal, and AWID=3 is bound to the AWID signal;
[0068] At the same time, adjust the key parameters of the data path according to the variable values to ensure that the variable configuration is compatible with the data path; for example, if AWSIZE=4 means that the transmission data width is 32 bits, then configure the WDATA signal width of the AXI write data channel to 32 bits to ensure that the variable configuration is compatible with the data path.
[0069] S2.3 Functional Scenario Execution: Following the flow defined in the functional data path script, drive the target chip module to execute the corresponding functional scenario, thereby verifying the function of the target chip module and completing the coverage of the corresponding coverage module.
[0070] Taking a write transfer from DMA to DDR as an example, the specific execution process is as follows:
[0071] Write 0x0000_0001 to the DMA_CTRL register to enable DMA;
[0072] Write 0x0000_1000 to SRC_ADDR and 0x8000_0000 to DEST_ADDR;
[0073] Initiate an AXI write address transaction: drive AWVALID=1, AWADDR=0x8000_0000, AWLEN=13, AWSIZE=4, AWID=3, and wait for AWREADY=1 to complete the address transfer;
[0074] Initiate an AXI write data transaction: Transmit data in 14 (AWLEN+1) steps, each time driving WVALID=1 and WDATA=0x0000_1000+i×4 (i is the number of transmissions), and wait for WREADY=1 to complete the data transmission;
[0075] Receive AXI write response: Wait for BVALID=1, read the BRESP signal to determine if the transmission was successful. If BRESP=0 (OKAY), update the DONE bit of the DMA status register DMA_STATUS to 1.
[0076] Interrupt Trigger: If the INT_EN bit of DMA_CTRL is 1, the DMA_INT signal is set to 1 to notify the CPU that the transfer is complete. During execution, the data path executor monitors the module signals in real time through uvm_monitor to ensure that the scene execution meets the design expectations. If a signal timing error occurs (such as AWVALID becoming valid more than 2 clock cycles before AWREADY), the error log is automatically recorded and execution is paused, awaiting manual confirmation before restarting.
[0077] S3. Coverage Data Collection: Real-time and accurate collection of coverage data from coverage groups and coverage warehouses to provide a basis for decision-making in the feedback loop. This process specifically includes the following operations:
[0078] S3.1 Layered Acquisition of Coverage Data: The coverage data collector adopts a top-down layered acquisition strategy to acquire coverage data at the coverage group level and coverage warehouse level respectively.
[0079] (a) Coverage group level data acquisition: The coverage rate of the entire coverage group is obtained by calling the SystemVerilog get_coverage() task; taking the AXI write transaction coverage group axi_write_traffic as an example, if the coverage group is instantiated in the top.dut module, the coverage rate of the coverage group is obtained by Grp_Coverage = top.dut.axi_write_traffic.get_coverage, and the return value is a floating-point number between 0 and 100;
[0080] (b) Coverage repository-level data collection: The coverage rate of a single coverage repository is obtained through the get_bin_coverage() task. This task needs to be defined in the coverage group definition. For example, to obtain the coverage rate of the awlen_txs coverage repository, it is implemented by Bin_AWLEN_Coverage = top.dut.axi_write_traffic_inst.awlen_txs.get_bin_coverage(). The return value is the coverage status of the coverage repository (0 indicates no coverage, 1 indicates coverage) and the number of coverages (e.g., 3 indicates that the repository was hit 3 times).
[0081] (c) Cross-coverage data acquisition: For cross-coverage scenarios, the `get_cross_coverage()` task is used to obtain the coverage rate of the cross-coverage bins and return the coverage status of each cross combination (Cross_Coverage = ...).
[0082] top.dut.axi_write_traffic_inst.awlen_x_awsize_cross.get_cross_coverage());
[0083] S3.2 Data Validation: Validate the collected data, specifically including:
[0084] (i) Timing verification: Check whether the data acquisition time is in a stable working state of the data acquisition unit. If it is in a reset state rst_n=0, mark the data as invalid and re-acquire it.
[0085] (ii) Consistency check: Compare the sum of the coverage rates of each coverage warehouse under the same coverage group with the logical consistency of the coverage group's coverage rate; for example, if the sum of the coverage rates of 16 warehouses in awlen_txs is 12 (12 warehouses are covered) and the sum of the coverage rates of 4 warehouses in awsize_txs is 3 (3 warehouses are covered), then the theoretical coverage rate of the coverage group should be (12+3) / (16+4)=75%. If the actual collected coverage rate of the coverage group is 70%, then the data is marked as abnormal, and it is necessary to check whether there is an error in the coverage group definition;
[0086] (iii) Duplicate verification: Check whether the coverage data collected in two consecutive times are completely consistent. If the data is the same for three consecutive times and the preset coverage target is not reached, it is determined that there may be an excitation dead loop. An alarm needs to be triggered and the coverage variable manager needs to be notified to adjust the constraint strategy.
[0087] S3.3 Data Format Conversion: The original overlay data that has passed validity verification is converted into a key-value pair format for easier subsequent use. The converted data is sent to the next process via uvm_tlm_analysis_port.
[0088] S4. Automatic Feedback Loop: Automatically determines whether the coverage data has reached the preset coverage target (e.g., 100% functional coverage).
[0089] The coverage target supports two configuration modes: absolute target and relative target.
[0090] (a) Absolute target mode: By using a preset fixed coverage threshold as the judgment standard, the coverage of the coverage group and the coverage of all coverage warehouses are required to reach the specified threshold.
[0091] (b) Relative target mode: The preset coverage improvement threshold is used as the judgment standard. The target is judged based on the coverage improvement rate of each iteration. The core rule is that if the coverage improvement rate meets the preset threshold condition, the target is judged to be achieved; if the coverage improvement rate is ≤0.5% for 3 consecutive iterations, the target is judged to be achieved.
[0092] The real-time collected coverage data is compared with the preset coverage target, and the compliance determination is completed according to the threshold rules of the corresponding configuration mode:
[0093] (i) When using the absolute target mode, it is necessary to verify whether the real-time coverage data fully meets the preset fixed threshold requirements. If all requirements are met, the target is determined to be achieved; otherwise, the target is determined not to be achieved.
[0094] (ii) When using the relative target mode, it is necessary to verify whether the iterative improvement of the real-time coverage data meets the preset improvement threshold requirements. If it does, it is determined that the target has been achieved; otherwise, it is determined that the target has not been achieved.
[0095] For example, if the preset absolute target is 100% coverage of the coverage group, and the real-time coverage rate is 85.6%, then the target is not achieved; if the real-time coverage rate is 100% and all coverage areas are covered, then the target is achieved.
[0096] Based on the above operations, when it is automatically determined that the coverage data has not reached the coverage target, the current coverage result is fed back to the coverage variable randomization stage of S1 to regenerate the coverage variable to cover the missed scenarios. In this process, the iteration direction instruction is sent to the coverage variable manager according to the priority of the uncovered scenarios:
[0097] (a) High-priority scenarios (such as critical coverage modules of core chip functional modules, coverage modules associated with discovered vulnerabilities): The instruction coverage variable manager generates targeted incentives to prioritize coverage of missed scenarios; for example, if the SRAM address coverage module addr_8([256:511]) is not covered and belongs to high priority, then the instruction manager adds the constraint addr_0inside{[256:511]}.
[0098] (b) Medium priority scenarios (such as the coverage repository of ordinary functional modules): The instruction coverage variable manager adopts a combination of targeted and random incentive generation strategy to balance coverage efficiency and scenario diversity. Among them, targeted incentives are used to quickly cover core and key instruction coverage points to ensure coverage efficiency; random incentives are used to traverse boundary, exception and long tail scenarios to ensure scenario diversity, and finally achieve a balance between coverage efficiency and scenario diversity.
[0099] (c) Low-priority scenarios (such as the overlay of redundant functional branches): The instruction manager adopts a random stimulus generation strategy to reduce the resource consumption of high-priority scenarios.
[0100] Based on the above operations, when the coverage data reaches the coverage target, the system automatically determines that the next stage of the verification report will be generated.
[0101] S5. Validation Report Generation: Automatically generates a validation report in Excel format, including: number of iterations and coverage percentage of each coverage group / coverage module. This validation report is used to present the validation process and results in a visual way, making it easier for engineers to trace problems, analyze design defects, and form a validation loop.
[0102] The verification report is derived from the full coverage data collected (including coverage groups, coverage bins, and cross-coverage data for each iteration), the scenario execution logs of the data path execution (including variable configuration, execution time, and whether errors exist for each iteration), and the iteration statistics of the automatic feedback loop (including total number of iterations, number of exceptions, and number of retries). The aforementioned data are integrated into the report data source to support the generation of the verification report, making it easier for engineers to trace problems, analyze design defects, and form a verification closed loop.
[0103] In summary, the intelligent stimulus generation method for chip verification of this invention, by constructing a five-stage closed-loop process of "coverage variable randomization - functional data path execution - coverage data collection - automated feedback loop - verification report generation," can achieve accurate stimulus generation, accelerated coverage, and early vulnerability detection, significantly optimizing chip verification efficiency. It overcomes the limitation of traditional verification requiring all test cases to pass, enabling stimulus generation and coverage analysis to begin early in the verification process, accurately capturing boundary vulnerabilities and solving the problems of late vulnerability discovery and high remediation costs associated with traditional methods. It achieves full coverage of chip functions through a single simulation iteration, eliminating the need for multiple rounds of regression testing and simulation analysis, significantly reducing the chip verification cycle and accelerating product launch. Furthermore, the feedback loop enables fully automated operation of stimulus generation, test execution, coverage collection, and stimulus optimization, eliminating manual intervention and significantly improving verification efficiency.
[0104] The above specific examples illustrate the principles and implementation methods of the present invention in detail. These embodiments are merely for the purpose of helping to understand the core technical content of the present invention. Based on the above specific embodiments of the present invention, any improvements and modifications made to the present invention by those skilled in the art without departing from the principles of the present invention should fall within the patent protection scope of the present invention.
Claims
1. A smart stimulus generation method for chip verification, characterized in that, Includes the following steps: S1. Coverage Variable Randomization: Obtain the functional coverage requirements of the chip design, identify the coverage groups and coverage blocks, and extract the coverage variables that need to hit the coverage blocks; based on the correspondence between the coverage blocks and the coverage variables, generate the initial coverage variable values for the first stage of simulation. After the simulation is completed, unique variable values for the next stage are generated based on the coverage results using dynamic constraint techniques. S2. Functional Data Path Execution: Based on the coverage variable configuration, the specified functional scenario adapted to the chip target module is triggered, and the preset functional data path is called to verify and cover the corresponding coverage module; wherein, the preset chip functional data path includes chip key signals, registers and component information; S3. Coverage Data Collection: Real-time and accurate collection of coverage data from coverage groups and coverage warehouses to provide decision-making basis for feedback loops; S4, Automatic Feedback Loop: Automatically determines whether the coverage data has reached the preset coverage target: If the coverage target has not been reached, the current coverage result is fed back to the coverage variable randomization stage of S1, and the coverage variable is regenerated to cover the missed scenarios; If the coverage target has been reached, the generation of the verification report in the next stage is triggered. S5. Validation Report Generation: Automatically generates a validation report in Excel format, including: number of iterations and coverage percentage of each coverage group / coverage repository.
2. The intelligent stimulus generation method for chip verification according to claim 1, characterized in that, Step S1 specifically includes the following operations: S1.1 Coverage Requirement Analysis: The functional coverage requirements of the chip design are imported through the coverage_cfg configuration class in the UVM environment, including coverage group definition, coverage bin division and coverage weight; the coverage variable manager reads the instance and configuration information of the coverage_cfg configuration class from the environment through the UVM configuration database, automatically extracts the coverage variables that need to hit the coverage bin, and establishes a mapping relationship table between coverage variables and coverage bins. S1.2 Initial Variable Generation: The coverage variable manager generates the initial coverage variable values for the first stage simulation based on the coverage variable-coverage bin mapping table. For discrete variables, the coverage variable manager selects the initial value from the coverage bin value set using a uniform random strategy. For continuous variables, the coverage variable manager uses an interval segmented random strategy, randomly selecting one initial value from the sub-intervals formed by interval segmentation to ensure the uniformity of the initial excitation coverage. S1.3 Iterative Variable Optimization: After the first stage of simulation is completed, the coverage variable manager receives the coverage results and generates unique variable values for the next stage through dynamic constraint technology.
3. The intelligent stimulus generation method for chip verification according to claim 2, characterized in that, The dynamic constraint technique employs an optimization strategy that integrates random and targeted testing, dynamically adjusting the stimulus generation direction based on test coverage, as follows: (a) For uncovered coverage areas, dynamic constraint technology generates directional constraints to directly lock the value range of the uncovered areas, ensuring that the incentive generation can accurately target the scene to be covered. (b) For covered bins, dynamic constraint technology generates random constraints that include covered and uncovered values, and optimizes the probability of value selection by adjusting the weights, setting the weight of uncovered values higher than that of covered values, thereby increasing the likelihood of uncovered values being selected. (c) To avoid incentive duplication, dynamic constraint technology achieves control through historical value deduplication constraints, maintains a designated queue to store historical variable values, adds constraints that are not equal to historical values to the current variable generation, and ensures that the newly generated variable value does not duplicate the historical value.
4. The intelligent stimulus generation method for chip verification according to claim 1, characterized in that, Step S2 specifically includes: S2.1 Data Path Loading: During the execution of the data path, the user-preset functional data path script is loaded. This script covers the hardware logic interaction process of the chip target module, key signal timing control and storage access rules. S2.2 Variable Configuration Injection: Based on the overriding variable configuration, the variable values are injected into the corresponding signals of the data path through the signal binding mechanism; at the same time, the key parameters of the data path are adjusted according to the variable values to ensure that the variable configuration is compatible with the data path. S2.3 Functional Scenario Execution: Following the flow defined in the functional data path script, drive the target chip module to execute the corresponding functional scenario, thereby verifying the function of the target chip module and completing the coverage of the corresponding coverage module.
5. The intelligent stimulus generation method for chip verification according to claim 1, characterized in that, Step S3 specifically includes the following operations: S3.1 Layered Acquisition of Coverage Data: The coverage data collector adopts a top-down layered acquisition strategy to acquire coverage data at the coverage group level and coverage warehouse level respectively. (a) Coverage group level data acquisition: Obtain the coverage of the entire coverage group by calling the SystemVerilog get_coverage() task; (b) Coverage bin-level data collection: The coverage rate of a single coverage bin is obtained through the get_bin_coverage() task. This task needs to be defined in the coverage group definition. (c) Cross-coverage data acquisition: For cross-coverage scenarios, the coverage rate of the cross-coverage bins is obtained through the get_cross_coverage() task, and the coverage status of each cross combination is returned; S3.2 Data Validation: Validate the validity of the collected data; S3.3 Data Format Conversion: Convert the original overlay data that has passed the validity check into a key-value pair format for easy use later.
6. The intelligent stimulus generation method for chip verification according to claim 5, characterized in that, The collected data is validated, specifically including: (i) Timing verification: Check whether the data acquisition time is in a stable working state of the data acquisition unit. If it is in a reset state rst_n=0, mark the data as invalid and re-acquire it. (ii) Consistency check: Compare the sum of the coverage rates of each coverage warehouse under the same coverage group with the logical consistency of the coverage rate of the coverage group; (iii) Duplicate verification: Check whether the coverage data collected in two consecutive times are completely consistent. If the data is the same in three consecutive times and the preset coverage target is not reached, it is determined that there may be an excitation dead loop. An alarm needs to be triggered and the coverage variable manager needs to be notified to adjust the constraint strategy.
7. The intelligent stimulus generation method for chip verification according to claim 1, characterized in that, Coverage targets support two configuration modes: absolute targets and relative targets. (a) Absolute target mode: By using a preset fixed coverage threshold as the judgment standard, the coverage of the coverage group and the coverage of all coverage warehouses are required to reach the specified threshold. (b) Relative target mode: The preset coverage improvement threshold is used as the judgment standard. The target is judged based on the coverage improvement rate. The core rule is that if the coverage improvement rate meets the preset threshold condition, the target is judged to be achieved. The real-time collected coverage data is compared with the preset coverage target, and the compliance determination is completed according to the threshold rules of the corresponding configuration mode: (i) When using the absolute target mode, it is necessary to verify whether the real-time coverage data fully meets the preset fixed threshold requirements. If all requirements are met, the target is determined to be achieved; otherwise, the target is determined not to be achieved. (ii) When using the relative target mode, it is necessary to verify whether the iterative improvement of the real-time coverage data meets the preset improvement threshold requirements. If it does, it is determined that the target has been achieved; otherwise, it is determined that the target has not been achieved.
8. The intelligent stimulus generation method for chip verification according to claim 7, characterized in that, In step S4, if the coverage data does not reach the preset coverage target, an iteration direction instruction is sent to the coverage variable manager according to the priority of the uncovered scenario: (a) High-priority scenarios: The instruction override variable manager generates targeted stimuli, prioritizing the override of missed scenarios; (b) Medium priority scenarios: The instruction coverage variable manager adopts a stimulus generation strategy that combines directional and random approaches to balance coverage efficiency and scenario diversity. directional stimulus is used to quickly cover core and key instruction coverage points to ensure coverage efficiency. Random stimulus is used to traverse boundary, exception, and long-tail scenarios to ensure scenario diversity, ultimately achieving a balance between coverage efficiency and scenario diversity. (c) Low-priority scenarios: The instruction manager adopts a random stimulus generation strategy to reduce resource consumption in high-priority scenarios.
9. The intelligent stimulus generation method for chip verification according to claim 1, characterized in that, The verification report is derived from the full coverage data collected, the scenario execution logs of the data path execution, and the iterative statistical data of the automatic feedback loop. The aforementioned data is integrated into the report data source to support the generation of the verification report, which makes it easier for engineers to trace problems, analyze design defects, and form a verification closed loop.