Chip verification method, device, equipment, medium and chip

Abstract

The application relates to the chip verification field and provides a chip verification method, a device, equipment, a medium and a chip. The method comprises the following steps: a dynamic simulation verification environment of a design to be verified is established, a plurality of test scenes and corresponding test excitations are generated according to a design specification definition; the test excitations are sent to a driver through a sequencer, the test excitations are converted into signals conforming to an interface protocol of the design to be verified by the driver, and the signals are transmitted to the design to be verified; input signals and output signals of the design to be verified are collected in real time by a monitor, and the input signals and the output signals are converted into transactions and transmitted to a scoreboard; a reference model is compared with the output signals of the design to be verified, and a dynamic simulation verification result is generated; the state space is reduced according to the dynamic simulation result, the state space of a design part not covered by dynamic simulation in the design to be verified is traversed, and a formal verification analysis result is generated; and the design to be verified is evaluated according to the formal verification analysis result.

Description

Technical Field

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

[0002] As semiconductor manufacturing processes continue to evolve, the scale and functional complexity of integrated circuits are constantly increasing. The verification process needs to ensure that the design meets specifications under various operating scenarios and to identify potential defects as much as possible before tape-out, in order to reduce the risk of rework and control development costs.

[0003] Currently, chip verification primarily relies on two methods: dynamic simulation and formal verification. Dynamic simulation simulates the behavior of a design in a real-world operating environment based on a test platform, making it particularly suitable for functional verification of large-scale systems. However, existing simulation verification frameworks typically require extensive manual coding, making the setup process complex and error-prone. Furthermore, dynamic simulation is an abstract verification method, unable to exhaustively analyze all logical paths, thus limiting coverage improvement. Formal verification, on the other hand, is based on logical reasoning and mathematical models, constructing a complete or partial state space for the design and performing attribute checks. It can uncover deep logical defects that traditional dynamic simulation struggles to cover, and is widely used for verifying the correctness of critical modules. However, as design scale increases, formal verification is prone to state space explosion, drastically increasing verification time. Moreover, it is more suitable for module-level verification and struggles to handle system-level complete functional verification tasks.

[0004] Clearly, a single verification method is insufficient to meet the verification requirements of high-reliability chips. However, existing technologies such as dynamic simulation and formal verification differ significantly in verification environment, stimulus generation methods, and data organization, making direct integration difficult. Therefore, a technical solution is urgently needed to achieve verification system integration, thereby improving the verification efficiency and reliability of complex chips. Summary of the Invention

[0005] In this context, the embodiments of this application aim to provide a chip verification method, apparatus, device, medium, and chip that can achieve verification system integration and improve the verification efficiency and reliability of complex chips.

[0006] In a first aspect of the embodiments of this application, a chip verification method is provided, comprising:

[0007] Through dynamic simulation verification, a dynamic simulation verification environment is established for the design to be verified. Based on the functions and behaviors defined in the design specifications, multiple test scenarios are generated in the dynamic simulation verification environment, and corresponding test stimuli are generated for each test scenario.

[0008] The test stimulus is sent to the driver via a sequencer, and the driver converts the test stimulus into a signal that conforms to the interface protocol of the design to be verified, and transmits it to the design to be verified.

[0009] The system acquires the input and output signals of the design to be verified in real time through a monitor, converts the input and output signals into transactions, and transmits the transactions to the scoreboard in the dynamic simulation verification environment through a transaction-level transmission mechanism.

[0010] During the dynamic simulation verification process, the output signal of the reference model is compared with that of the design to be verified to generate dynamic simulation verification results, which include simulation reports, waveform files and coverage reports.

[0011] The state space of formal verification is reduced based on the dynamic simulation results. The formal verification tool is used to traverse the state space of the design part not covered by the dynamic simulation in the design to be verified, and the formal verification analysis results are generated.

[0012] Based on the formal verification analysis results, the design to be verified is evaluated, and if the evaluation results do not meet the verification indicators, the design to be verified is corrected and the dynamic simulation verification environment is optimized.

[0013] In a second aspect of the embodiments of this application, a chip verification apparatus is provided, comprising:

[0014] The building unit is used to establish a dynamic simulation verification environment for the design to be verified through dynamic simulation verification, and generate multiple test scenarios in the dynamic simulation verification environment according to the functions and behaviors defined in the design specifications, and generate corresponding test stimuli for each test scenario.

[0015] The dynamic simulation verification unit is used to send the test stimuli to the driver via a sequencer, and the driver converts the test stimuli into signals conforming to the interface protocol of the design to be verified, and transmits them to the design to be verified; it also collects the input and output signals of the design to be verified in real time through a monitor, converts the input and output signals into transactions, and transmits the transactions to the scoreboard in the dynamic simulation verification environment through a transaction-level transmission mechanism; during the dynamic simulation verification process, it compares the output signals of the reference model with those of the design to be verified to generate dynamic simulation verification results, which include simulation reports, waveform files, and coverage reports;

[0016] The formal verification unit is used to narrow down the state space of formal verification based on the dynamic simulation results, and to use formal verification tools to traverse the state space of the design parts not covered by the dynamic simulation in the design to be verified, and generate formal verification analysis results.

[0017] The evaluation unit is used to evaluate the design to be verified based on the formal verification analysis results, and to correct the design to be verified and optimize the dynamic simulation verification environment when the evaluation results do not meet the verification indicators.

[0018] In a third aspect of the embodiments of this application, a terminal device is provided, the terminal device comprising: at least one processor, a memory, and an input / output unit; wherein the memory is used to store a computer program, and the processor is used to invoke the computer program stored in the memory to execute the chip verification method described in any one aspect.

[0019] In a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided, which includes instructions that, when executed on a computer, cause the computer to perform the chip verification method described in any one of the first aspects.

[0020] In a fifth aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the chip verification method described in any one of the first aspects.

[0021] According to embodiments of this application, a chip verification method, apparatus, device, medium, and chip are disclosed. First, a dynamic simulation verification environment for the design to be verified is established through dynamic simulation verification. Based on the functions and behaviors defined in the design specifications, multiple test scenarios are generated in the dynamic simulation verification environment, and corresponding test stimuli are generated for each test scenario. Then, the test stimuli are sent to a driver via a sequencer, and the driver converts the test stimuli into signals conforming to the interface protocol of the design to be verified, which are then transmitted to the design to be verified. Next, the input and output signals of the design to be verified are acquired in real time through a monitor, and the input and output signals are converted into transactions. These transactions are then transmitted to a scoreboard in the dynamic simulation verification environment through a transaction-level transmission mechanism. During the dynamic simulation verification process, the output signals of the design to be verified are compared with those of a reference model to generate dynamic simulation verification results, which include a simulation report, waveform files, and coverage reports. Furthermore, the state space for formal verification is narrowed down based on the dynamic simulation results. Formal verification tools are used to traverse the state space of the design portion of the design not covered by the dynamic simulation in the design to be verified, generating formal verification analysis results. Finally, based on the formal verification analysis results, the design to be verified is evaluated, and if the evaluation results fail to meet the verification indicators, the design to be verified is corrected and the dynamic simulation verification environment is optimized. This application's implementation solves the core technical problems in the integration of existing verification systems by constructing a highly automated, data-interoperable, and complementary collaborative verification framework. The technical framework in this application does not simply juxtapose dynamic simulation and formal verification, but rather achieves the integration of the verification system through a closed-loop optimization mechanism that includes automated generation of the verification environment, templated and automated execution of formal verification configurations, input of dynamic simulation coverage data to formal verification, and bidirectional feedback of verification results. This deep coupling of dynamic simulation and formal verification at the process data level effectively solves the technical problems existing in the integration of existing verification systems, such as reliance on manually written and debugged verification tools, data incompatibility between different verification methods, and different verification granularities, thereby improving the verification efficiency and reliability of complex chips. Attached Figure Description

[0022] Figure 1 This is a schematic flowchart illustrating a chip verification method according to this application;

[0023] Figure 2 This is a schematic diagram of a chip verification architecture shown in this application;

[0024] Figure 3 This is a schematic diagram of the architecture of a dynamic simulation verification test bench shown in this application. Detailed Implementation

[0025] The following is for reference. Figure 1 , Figure 1This is a schematic flowchart illustrating a chip verification method according to an embodiment of this application. It should be noted that the implementation methods of this application can be applied to scenarios such as chip design, chip verification, and chip optimization.

[0026] Existing technologies for dynamic simulation and formal verification differ significantly in verification environment, stimulus generation methods, and data organization, leading to the following technical problems when combining them: First, dynamic simulation relies on a complete verification platform and stimulus construction, while formal verification is based on attribute expressions and state-space modeling. It is difficult for them to directly share verification data or context, typically requiring manual extraction of uncovered areas from dynamic simulation results and manual writing of formal verification scripts, resulting in high integration costs and a high risk of errors. Second, the coverage information generated by dynamic simulation is incompatible with the input format of formal verification tools. Coverage structures such as statements and branches cannot be directly mapped to the analysis objects of formal verification, requiring manual conversion and filtering. This process is easily influenced by experience and difficult to standardize. Third, dynamic simulation and formal verification differ in granularity. Dynamic simulation focuses on system-level behavioral verification, while formal verification focuses on module attribute verification. The lack of a mechanism to automatically map system-level defects to module-level verification targets leads to a fragmented verification process. In summary, as modern chip design develops towards ultra-large scale and ultra-complexity, a single verification method is insufficient to meet the verification requirements of high-reliability chips. Therefore, there is an urgent need to propose a technical solution to solve at least one technical problem in the integration process of the existing verification system, and to improve the verification efficiency and reliability of complex chips.

[0027] To address at least one of the aforementioned technical problems, embodiments of this application provide a chip verification method, apparatus, device, medium, and chip.

[0028] Specifically, this application's embodiments first overcome the high dependence on manual labor in the verification process through automation technology. On the dynamic simulation side, a standardized UVM verification environment skeleton is automatically generated using Python scripts based on JSON configuration. This transforms environment setup from time-consuming and error-prone manual labor into a minute-level automated process, significantly improving efficiency, reducing initial errors, and promoting the reuse of verification IPs through the excellent scalability of the generated components. On the formal verification side, configuration templates and scripts are used to simplify complex tool commands into fill-in-the-blank operations, lowering the barrier to entry and ensuring the consistency and repeatability of the verification process.

[0029] Secondly, this application's embodiments overcome the integration barrier of heterogeneous data structures from different verification methods by establishing a unified transaction-level data abstraction layer. A monitor is used to encapsulate low-level signals into high-level transactions in real time and transmit them through a transaction-level transmission mechanism. Here, transactions become the common language between dynamic simulation and formal verification, enabling the coverage report generated by dynamic simulation to be accurately interpreted by formal verification tools. This allows for the reduction of the formal verification state space based on dynamic simulation results, reducing the risk of state space explosion. This seamless data-level integration avoids errors and time consumption associated with manual conversion, laying a solid foundation for the collaborative work of the two methods.

[0030] Ultimately, this application's embodiments implement a broad-to-deep collaborative verification strategy, effectively integrating the granular differences of different verification methods. This application's embodiments first utilize dynamic simulation for broad screening, quickly covering common functions and system interactions; then, formal verification is guided to perform in-depth verification of local areas not covered by simulation, implementing a highly targeted exhaustive traversal. This strategy leverages the efficiency of simulation to quickly eliminate most defects, while also utilizing the mathematical completeness of formal verification to capture extremely hidden corner cases and dead code, forming a complementary verification synergy.

[0031] In summary, the embodiments of this application construct a highly efficient closed-loop modern chip verification system through process automation, data unification, and strategy collaboration. These embodiments not only significantly improve verification efficiency by concentrating engineering resources on the most critical and challenging aspects, but also enhance the completeness and reliability of verification through the combination of the breadth of simulation and the depth of formal verification. This makes the system suitable for the verification scenarios of very large-scale integrated circuits, contributing to improved chip tape-out efficiency and reliability.

[0032] Figure 1 The flowchart of a chip verification method provided in one embodiment of this application, shown below, includes:

[0033] Step S101: Through dynamic simulation verification, a dynamic simulation verification environment for the design to be verified is established, and multiple test scenarios are generated in the dynamic simulation verification environment according to the functions and behaviors defined in the design specifications, and corresponding test stimuli are generated for each test scenario.

[0034] In this embodiment, the dynamic simulation verification environment is a modular and scalable verification framework built on Universal Verification Methodology (UVM), which is automatically generated by Python scripts to reduce manual intervention.

[0035] The core components of a dynamic simulation verification environment include UVM core components, objects, and mechanisms. Core components include a sequencer responsible for transaction generation and distribution, a driver that converts transactions into semaphore-level stimuli and transmits them to the design under test (DUT), a monitor that acquires interface signals in real time and converts them into transactions, a proxy component that encapsulates interface-related verification logic, a reference model that simulates the expected behavior of the design, a scoreboard that compares the output of the DUT with the reference model, and a virtual sequencer that coordinates the generation of transactions across multiple interfaces. Core objects include the transmission of transactions and sequences. Core mechanisms include a factory mechanism that supports dynamic component configuration, a phase mechanism that divides the verification process into stages, and an objection mechanism that controls the start and stop of the verification process. The generation process follows four steps: configuration, parsing, building, and coding. First, the name of the design under test, the verification personnel, the name and number of proxy components, and the scoreboard configuration are defined through the my_uvm.json configuration file. Then, a Python script parses the configuration file to extract key information. Based on the parsing results, the verification framework, including the environment, proxy components, and drivers, and related files are automatically generated. Finally, code conforming to the UVM specification is written into the files to complete the environment setup. The dynamic simulation verification environment has good scalability. Verification personnel can expand the functions of components such as driving logic and sampling logic according to the specific characteristics of the DUT (such as different types of interface protocols such as APB, AHB, AXI, etc.). They can also adapt to complex verification needs such as multi-interface interaction by integrating virtual sequencers and adding reference models.

[0036] Test scenarios are sets of verification scenarios defined by verification personnel based on the design functions and behaviors to be verified as specified in the design specification (SPEC). These scenarios cover the core logic, boundary conditions, and abnormal situations of the design. The design specification clearly defines the functions of each module (e.g., the number of cores and instruction set of the processor module, the capacity and read / write speed of the memory module, the protocol type and data rate of the interface module), functional characteristics (e.g., whether it supports multithreading, low-power mode, hardware encryption, etc.), and verification requirements (e.g., the modules, functions, and valid data range to be verified). Based on this information and the actual application scenarios of the design, verification personnel divide the test scenarios into comprehensive ones, including normal working scenarios (e.g., normal write and read operations of the memory module) as well as boundary condition and abnormal scenarios (e.g., continuing to write after the memory is full, continuing to read after the memory is empty, mismatch between write and read speeds, etc.). The design of test scenarios adopts a combination of random testing and targeted testing to ensure comprehensive coverage of the design functions. Random testing is used to cover a wide range of normal situations, while targeted testing is used to accurately verify specific functional points or abnormal scenarios.

[0037] Test stimuli are verification inputs containing specific data information, written by verification personnel for various test scenarios. They drive the design under test to execute corresponding functions and generate responses. For random test scenarios, the generation range of stimulus data strictly follows the valid data range defined in the design specification. Code is written to restrict random data within this range to ensure the effectiveness of the stimuli. For targeted test scenarios, the stimuli are constructed according to the requirements of the target functional point. For example, to verify a scenario where writing cannot continue after the memory is full, transaction data exceeding the memory capacity will be generated (e.g., generating 8 write data entries when the memory can store a maximum of 7 data entries). All test stimuli are sent to the driver via the sequencer's TLM (Transaction Level Modeling) mechanism. The driver converts these stimuli into signal-level stimuli that conform to the timing requirements of the interface protocol of the design under test, and then transmits them to the design under test via the communication bus, triggering the design to execute the corresponding processing flow.

[0038] As an optional embodiment, in step S101, dynamic simulation verification is performed to establish a dynamic simulation verification environment for the design to be verified, including: parsing the name of the design to be verified, verification personnel information, agent component names and quantities, scoreboard configuration, and environment parameters; generating component files and object files adapted to the Universal Verification Methodology (UVM) architecture based on the parsing results of the design to be verified; and writing UVM core mechanism files that match the parsing results into the component files and object files to form a dynamic simulation verification environment framework.

[0039] The component files include environment components, agent components, drivers, monitors, sequencers, and virtual sequencers; the object files include transport transaction objects and sequence objects; and the UVM core mechanism files include component registration and overloading procedures based on the factory mechanism, hierarchical phase function procedures based on the phase mechanism, TLM connection procedures between components, and flow control procedures based on the objection mechanism.

[0040] The parameters of the design to be verified form the basis of the environment construction. These include the name of the design to be verified, verification personnel information, the name and quantity of proxy components, scoreboard configuration, and environment parameters. These parameters clarify the customization requirements of the verification environment. Component files are the core functional carriers of the UVM environment, encompassing overall environment components, proxy components that encapsulate interface verification logic, drivers that convert stimulus formats, monitors that acquire interface signals, sequencers that schedule transactions, and virtual sequencers that coordinate multiple interfaces. Object files are used for data transmission and scenario construction, including data transmission transaction objects and sequence objects that define stimulus sequences. The UVM core mechanism files ensure the normal operation of the environment. The factory-based component registration and overloading program supports the dynamic creation and configuration of components; the phase-based hierarchical phase function program divides the verification process into ordered phases such as build_phase and connect_phase; the TLM connection program between components constructs data transmission channels; and the objection-based flow control program enables precise start and stop of the verification process.

[0041] Specifically, the script first parses the pre-configured `my_uvm.json` file using a Python script. This file contains key parameters of the design to be verified, such as `module name: module_test` (the name of the design to be verified), `agent_name: agent_in` and `agent_out` (two agent components), and `scb: scoreboard` (the name of the scoreboard). By parsing these parameters, the script accurately obtains the customized information required for environment building, avoiding errors from manual input. Next, based on the parsing results, the script automatically generates component and object files adapted to the UVM architecture. For example, for the `agent_in` and `agent_out` parameters, it generates two corresponding agent component files, and also creates files for transport transaction objects, sequence objects, etc. The file names and structures match the parameters of the design to be verified, ensuring the environment's specificity. Finally, the Python script writes matching UVM core mechanism files into the generated component and object files. For example, the driver file uses the macro uvm_component_utils(module_test_driver) to register components of the factory mechanism. In the environment component, the build_phase function is written to complete component instantiation, and the connect_phase function is written to establish TLM connections to realize data transmission between the sequencer and the driver, and between the monitor and the scoreboard. At the same time, the raise_objection and drop_objection functions of the objection mechanism are embedded to ensure that stimuli can be continuously sent when verification begins and the process ends normally after the critical tasks are completed. The code snippet of module_test_driver shows part of the implementation of this embedding process.

[0042] In this embodiment, the traditional UVM environment setup process, which relies on manual coding and configuration, is automated and standardized. By automatically obtaining parameters through configuration file parsing, errors from manual memorization and input are avoided, particularly reducing issues in error-prone areas such as component connections and mechanism configuration. The automated generation of component and object files significantly shortens the environment setup cycle, reducing the manual workload from weeks to hours. The standardized embedding of the UVM core mechanism ensures the standardization and stability of the verification environment, while the generated framework possesses good versatility. When the design to be verified changes, only the parameters in `my_uvm.json` need to be modified (e.g., changing the agent component to `agent_inout`) to quickly generate a new verification environment, without rewriting a large amount of basic code. This enhances the reusability of verification components, reduces the verification engineer's dependence on the UVM architecture, and provides an efficient and reliable foundational framework for subsequently refining the environment, generating test scenarios, and incentivizing based on design specificity.

[0043] In the above embodiment of step S101, optionally further, a UVM core mechanism file matching the parsing result is written into the component file and object file, including: generating a corresponding proxy component for each proxy component name based on the proxy component name and quantity obtained from the parsing result, and integrating the instantiation logic of the corresponding driver, monitor and sequencer into the proxy component; writing the component registration program, object registration program and overload program of the factory mechanism into all component files; defining different stages of simulation operation in the environment component based on the hierarchical stage execution function of the phase mechanism; and writing the transaction-level modeling TLM connection program to establish the data transmission channel between the driver and the sequencer, and the data transmission channel between the monitor and the scoreboard.

[0044] In this optional embodiment, the standardized component architecture and core mechanism synergy principle based on the UVM verification methodology all involve key concepts that serve the modular construction and efficient operation of the verification environment. Proxy components are modular units that encapsulate the verification logic related to the interface of the design to be verified. Each proxy component requires a driver, monitor, and sequencer to achieve complete functions of stimulus generation, signal acquisition, and transaction scheduling. The factory mechanism is the core of UVM's component and object management. It incorporates components and objects into the UVM management system through a registration program, and overloaded programs support dynamic replacement of component or object types without modifying the underlying code. The phase mechanism is a hierarchical control system for the verification process, ensuring the orderly execution of component instantiation, connection, and operation by defining different execution phases. The TLM transaction-level modeling mechanism is a standardized interface for data transmission between components, used to build data transmission channels without direct coupling, ensuring efficient flow of transaction data.

[0045] Specifically, firstly, based on the proxy component names and quantities obtained by parsing the my_uvm.json file using a Python script, corresponding proxy component files are generated accordingly. Simultaneously, the instantiation logic for drivers, monitors, and sequencers is embedded within each proxy component. For example, after parsing the proxy component names agent_in and agent_out, the script generates separate files for these two proxy components, including the declaration and instantiation code for drivers, monitors, and sequencers, ensuring that each proxy component has the basic functionality to independently complete the corresponding interface verification. Subsequently, the registration and overriding procedures for the factory mechanism are written into all generated component files (including environment components, proxy components, drivers, etc.) and object files (transfer transactions, sequences, etc.). Component registration is implemented using the uvm_component_utils macro, and object registration is implemented using the uvm_object_utils macro. For example, in the module_test_driver component file, uvm_component_utils(module_

[0046] The `test_driver` macro completes component registration, and the overloaded program supports dynamically replacing the implementation class of components or objects through the UVM factory mechanism to meet flexible configuration requirements. Next, in the environment component file, hierarchical phase execution functions are written based on the phase mechanism, clearly defining the different phases of simulation execution and their corresponding operations, including `build_phase` for component instantiation, `connect_phase` for component connection, and `run_phase` for verification execution, ensuring the verification process proceeds in a predetermined order. Finally, in the `connect_phase` phase of the environment component, the TLM connection program is written, establishing a data transmission channel by binding the component's TLM port. The sequencer and driver transmit transaction-level stimuli through TLM port binding, while the monitor and scoreboard report collected data through TLM analysis port binding. For example, the monitor's `analysis_port` is connected to the scoreboard's `export` port to ensure that transaction data captured by the monitor is transmitted to the scoreboard in real time.

[0047] In this embodiment, a standardized mechanism is embedded and components are connected to construct a well-structured and highly efficient UVM verification environment framework. The automatic instantiation of proxy components and their supporting sub-components avoids omissions or errors during manual component configuration, significantly improving the modularity of the verification logic and facilitating subsequent maintenance and expansion. The factory mechanism's registration and overload program embedding provides the verification environment with flexible dynamic configuration capabilities, supporting rapid replacement of component or object types in different verification scenarios without refactoring the entire environment. The hierarchical phase definition of the phase mechanism standardizes the execution order of the verification process, ensuring orderly connection of component instantiation, connection, and operation, avoiding verification anomalies caused by process chaos. The standardized embedding of the TLM connection program constructs a loosely coupled data transmission channel between components, ensuring smooth flow of transaction data between components such as the sequencer, driver, monitor, and scoreboard. This provides reliable support for the effective transmission of test stimuli and accurate comparison of verification results, significantly reducing the complexity and error rate of manually building a UVM environment and improving the consistency, reusability, and construction efficiency of the verification environment.

[0048] As an optional embodiment, in step S101, according to the functions and behaviors defined in the design specifications, multiple test scenarios are generated in the dynamic simulation verification environment, including: establishing driving logic in the driver to convert transmission transactions into timing signals according to the interface protocol of the design to be verified, and establishing sampling logic in the monitor to convert timing signals into transmission transactions; integrating the reference model into the dynamic simulation verification environment, and configuring a scoreboard to establish comparison rules between the expected output of the reference model and the actual output of the design to be verified; for test scenarios involving multiple interface interactions, by integrating a virtual sequencer and writing a virtual sequence, coordinating the working timing of multiple proxy components, and generating multi-channel synchronous or asynchronous test stimuli.

[0049] This optional embodiment is based on the design specification-driven, scenario-based verification principle. Its core is to construct comprehensive test scenarios covering both single functions and complex interactions by adapting interface protocols, integrating core verification components, and coordinating the timing of multiple interfaces. The interface protocol is the standard rule for the interaction between the design to be verified and the verification environment, such as APB, AHB, AXI, etc. 2Different protocols, such as C and UART, have different effective data reception conditions and timing relationships, which determines the implementation methods of the driving logic and sampling logic. The driving logic is the core logic of the driver, which converts abstract transmission transactions into signal-level stimuli that conform to the protocol requirements. The sampling logic is the reverse conversion logic of the monitor, which restores the interface timing signals back to transaction data. The reference model is a design behavior simulation component written in high-level modeling languages ​​such as C and C++, strictly adhering to the architecture document and functional description, serving as the gold standard for verification. The scoreboard comparison rules are the basis for judging the correctness of the design function to be verified, covering key dimensions such as data value consistency and timing response validity. The virtual sequencer is the scheduling core that coordinates multiple interface proxy components. It defines the synchronous or asynchronous timing of multi-channel stimuli through virtual sequences, adapting to the verification needs of complex interaction scenarios.

[0050] In a UVM verification environment, a virtual sequencer is a component that coordinates multiple child sequencers. It doesn't directly generate transactions; instead, it controls other sequencers to synchronize or coordinate test scenarios across multiple interfaces. For example, in a design to be verified, multiple proxy components might be used, each with its own sequencer. A design might contain three sequencers: an AXI sequencer, an APB sequencer, and a UART sequencer. For ease of use, the UVM verification methodology typically manages and invokes these sequencer handles within a virtual sequencer. Virtual sequencers are standardized components in the UVM verification methodology, with standardized code. When a virtual sequencer is needed, the corresponding code is simply written and integrated into the verification environment. The following is a sample code snippet for a virtual sequencer:

[0051] class my_virtual_sequencer extends uvm_sequencer;

[0052] `uvm_component_utils(my_virtual_sequencer)

[0053] / / Handle to the child Sequencer

[0054] axi_sequenceraxi_sqr;

[0055] apb_sequencerapb_sqr;

[0056] uart_sequencer uart_sqr;

[0057] function new(string name, uvm_component parent);

[0058] super.new(name, parent);

[0059] endfunction

[0060] ...

[0061] endclass

[0062] The reference model described above is essentially the same as the virtual sequencer. The UVM verification methodology also has its standardized code specifications. When using the reference model, you only need to write the corresponding code file according to the code specifications and then integrate it into the verification environment.

[0063] Specifically, firstly, based on the interface protocol type of the design to be verified as specified in the design specifications, corresponding driver logic is written in the driver to ensure that transmission transactions can be converted into signal-level stimuli according to the clock edge and timing constraints specified in the protocol. For example, for the burst transmission characteristics of the AXI protocol, the driver logic will define the synchronization timing of the address channel and data channel, converting information such as address length data in the transaction into signal toggling that conforms to the protocol. At the same time, sampling logic is established in the monitor to monitor interface signal transitions in real time. When a valid transmission conforming to the protocol specification is detected, the signal value is captured and encapsulated into a transmission transaction. For example, after the start signal, data bits, and acknowledge bit sequence of the I2C protocol are identified by the monitor, they are converted into a transaction object containing device address data. Next, the reference model, which is pre-written based on the design specifications, is integrated into the dynamic simulation verification environment. The algorithm logic of the reference model is directly translated from the specifications to ensure that each design function is clearly implemented. Subsequently, the comparison rules of the scoreboard are configured, including data consistency comparison between the expected output of the reference model and the actual output of the design to be verified, and validity comparison of whether the response timing meets the protocol requirements. For example, in the verification of the memory module, the comparison rules will clearly define the consistency judgment criteria for written data and read data. For complex test scenarios involving multiple interface interactions, a virtual sequencer component is first integrated. Within the virtual sequencer, sub-sequencer handles corresponding to each interface proxy component are declared, such as AXI sequencer, APB sequencer, and UART sequencer. Then, the scheduling logic for multi-channel stimuli is written in the virtual sequencer definition. For example, it controls the synchronous execution of read / write operations on the AXI interface and configuration operations on the APB interface, or makes data transmission on the SPI interface and status queries on the I2C interface asynchronous. This method generates complex test stimuli covering the collaborative work of multiple interfaces, including AXI, SPI, and I2C.2 In a verification environment with multiple interfaces, the virtual sequencer simulates complex interactive scenarios by managing the sequencers of each interface.

[0064] The core function of the above embodiments is to construct a comprehensive test scenario system that closely matches the actual application of the design. The protocol adaptation design of the driving logic and sampling logic ensures the effectiveness of test stimuli and the accuracy of data acquisition, avoiding verification deviations caused by protocol incompatibility and solving the complex problem of verification logic adaptation under different interface protocols. The integration of the reference model and scoreboard comparison rules enables automated judgment of the correctness of the design function, replacing the tedious process of manual comparison, significantly reducing human error. Simultaneously, the high-level language implementation of the reference model reduces its own verification difficulty and ensures the reliability of the comparison benchmark. The introduction of virtual sequencers and virtual sequences effectively covers complex scenarios of multi-interface collaborative work, compensating for the limitations of single-interface test scenarios and extending the test scenarios from single-function coverage to system-level interaction coverage. The overall process, guided by the unified design specifications, ensures a high degree of fit between the test scenarios and design requirements, improving the relevance and comprehensiveness of verification, laying the foundation for the efficient execution of subsequent dynamic simulation verification, reducing the risk of incomplete verification due to scenario omissions, and improving the early detection rate of chip functional defects.

[0065] It's worth noting that the reference model is a baseline component simulating the expected behavior of the design to be verified. It's implemented using high-level modeling languages ​​with higher abstractions, such as those at the object or algorithm level, and doesn't involve specific hardware details. Its core function is to provide a reliable predictive output for judging the correctness of the design's functionality. The implementation principle of the reference model is based on a faithful replication of the design specifications, ensuring complete consistency with the behavioral logic of the RTL design. Obtaining the reference model requires a standardized construction and verification process. First, it uses the detailed design specifications provided by the designer as the core basis, including architecture documents and functional descriptions, clearly defining key information such as the module functions, interface protocols, and data processing logic of the design to be verified. Then, it's written using high-level modeling languages ​​such as C or C++. These languages ​​are better at expressing algorithmic functions and don't require attention to the underlying hardware implementation, reducing the difficulty of verifying and debugging the model itself. During the modeling process, each design function in the specifications is directly translated into explicit algorithmic logic in the model, ensuring a faithful expression of the original specifications and avoiding functional deviations. After initial construction, the reference model undergoes multiple rounds of independent verification. Consistency of output is verified using known and correct test stimuli, and robustness is verified using boundary value stimuli and anomaly stimuli. Simultaneously, professional technicians conduct multiple rounds of review to ensure the model's correctness and reliability. For example, for a memory module reference model, algorithms simulating normal read / write operations, writeouts after the memory is full, and readouts after the memory is empty are written in C language, based on the memory capacity, read / write timing, and anomaly handling rules specified in the specifications. These algorithms are then tested and reviewed multiple times to ensure usability. The core function of the reference model is to compare its output with the actual output of the design to be verified during dynamic simulation verification. An automatic comparison mechanism is established using a scoreboard, replacing manual comparison processes and significantly reducing human error. The technical benefits are significant: the use of a high-level language reduces the verification difficulty of the model itself; multiple rounds of verification and professional review ensure the reliability of the comparison benchmark; and verification personnel can quickly identify functional defects in the design to be verified through accurate comparison, improving the accuracy and efficiency of verification. It also provides core support for the automation of dynamic simulation verification, creating a complete closed loop from stimulus generation to result determination, reducing reliance on manual intervention.

[0066] In step S102, the test stimulus is sent to the driver through the sequencer, and the driver converts the test stimulus into a signal that conforms to the interface protocol of the design to be verified and transmits it to the design to be verified.

[0067] In the UVM dynamic simulation and verification environment, the sequencer and driver are the core components responsible for test stimulus scheduling and signal conversion. Their implementation principle is based on UVM's Transaction Level Modeling (TLM) mechanism and interface protocol timing specifications, ensuring the accurate flow of test stimuli from abstract transactions to physical signals. Here, the sequencer is the scheduling core connecting test cases and drivers. Its core function is to generate and distribute transmission transactions according to predetermined rules, coordinating the execution priorities of multiple sequences through the UVM arbitration mechanism, and sending stimulus transactions to drivers in a specified order as needed, thereby constructing dynamic test scenarios. The driver is the conversion and transmission carrier of stimulus signals. Its core responsibility is to receive transaction-level stimuli sent by the sequencer, convert them into signal-level stimuli that conform to the interface protocol requirements of the design under test (DUT), and transmit them to the DUT through the interface.

[0068] It can be explained that the sequencer first generates abstract transaction-level stimulus objects based on the sequence corresponding to the test scenario. These transactions contain key data information required for the design to be verified, such as write addresses and data content in memory module verification. Then, the transactions are sent to the driver via the TLM port. During transmission, the UVM arbitration mechanism handles stimulus requests from multiple sequences to ensure the orderly transmission of stimulus. After receiving the transactions, the driver strictly adheres to the interface protocols defined in the design specifications (such as AXI, APB, I...). 2 The driver (e.g., C, etc.) determines the signal timing relationship, converting abstract data in a transaction into physical-level signal transitions. For example, for burst transmissions in the AXI protocol, the driver drives signal changes at the DUT input ports according to the clock edge, address, and data channel synchronization rules specified by the protocol. Simultaneously, it maintains synchronization with the sequencer through a handshake mechanism to ensure the reliability of the stimulus transmission. The code snippet for `module_test_driver` demonstrates the basic implementation of the driver. By inheriting the `uvm_driver` class, initialization and configuration are completed in stages such as `build_phase`. Subsequent extensions of the signal conversion logic can be made according to specific interface protocols.

[0069] The sequencer enables the ordered scheduling and distribution of test stimuli, avoiding stimulus conflicts and ensuring accurate reproduction of test scenarios. The core function of the driver is to resolve the compatibility issue between transaction-level stimuli and the physical interface of the DUT, enabling the DUT to recognize and respond to abstract stimuli. The sequencer's automated scheduling reduces the workload of manually writing stimulus sending logic and lowers the risk of stimulus timing errors. The driver's protocol adaptability allows the verification environment to flexibly accommodate designs to be verified with different interface protocols without requiring the reconstruction of core components, enhancing the reusability of the verification environment. Simultaneously, the separation of transaction-level transmission and signal-level conversion ensures both the flexibility of test scenario construction and the accuracy of stimulus transmission, enabling dynamic simulation verification to efficiently cover different test scenarios and providing a foundation for the reliability of subsequent verification results.

[0070] As an optional embodiment, in step S102, in the dynamic simulation verification environment, the sequencer generates an abstract transaction-level stimulus object according to the test scenario and sends it to the driver through the TLM port; the driver receives the transaction-level stimulus object and drives the input port signal of the design to be verified to flip according to the clock edge and timing constraints of the interface protocol; during the transmission process, the driver keeps synchronized with the sequencer through a handshake mechanism.

[0071] In the above steps, based on the UVM transaction-level modeling and component collaboration principles, the core is to ensure that test stimuli are accurately and reliably transmitted to the design to be verified through a layered design of abstract transaction transmission and signal-level conversion. Specifically, the transaction-level stimulus object is an abstract data carrier generated by the sequencer, containing key information required by the test scenario (such as operation type, address, data content, etc.), without involving low-level signal details, and adapting to the general transmission requirements of different interface protocols. The TLM port is a standardized interface for transaction transmission between UVM components, providing a loosely coupled communication channel for the sequencer and driver to realize transaction-level data transmission between components. The clock edge and timing constraints of the interface protocol are the interaction rules of the interface of the design to be verified. Different protocols (such as AXI, APB, I2C, etc.) have different clock triggering methods and signal synchronization requirements, which determine the specific logic of driver signal conversion. The handshake mechanism is the synchronization mechanism between the sequencer and the driver, ensuring that transaction transmission is not lost or duplicated through bidirectional confirmation, thus guaranteeing the reliability of stimulus transmission.

[0072] In the specific implementation process, the sequencer first generates a corresponding transaction-level stimulus object based on the preset test scenario (such as normal read / write of the memory module, writing after the memory is full, etc.). The object encapsulates the core data required by the scenario. For example, in the scenario of verifying writing after the memory is full, the transaction-level stimulus object will contain 8 data entries and the corresponding write operation instructions. Subsequently, the sequencer transmits the transaction object to the driver's TLM receive port through its own TLM transmit port. The transmission process follows the UVM TLM communication specification and does not require direct coupling of the component's internal logic. After receiving the transaction-level stimulus object, the driver strictly follows the interface protocol requirements defined in the design specification, identifies the clock edge (such as rising edge triggering or falling edge triggering) and timing constraints (such as signal setup time, hold time, burst transmission timing, etc.) corresponding to the protocol, and converts the abstract transaction data into physical-level signal toggling. For example, for the APB protocol, the driver will drive the address signal, data signal, and write enable signal to change in a predetermined order on the rising edge of the clock to ensure that the signals conform to the protocol interaction standard. Throughout the transmission process, the handshake mechanism plays a continuous role. For example, after the sequencer sends a transaction, it waits for the driver to return a receive confirmation signal. After the driver completes the transaction reception and preliminary processing, it sends a confirmation message back to the sequencer. Once the sequencer receives the confirmation, it continues to send the next transaction. If no confirmation is received, it either waits or retryes. The synchronization between the driver and the sequencer is achieved through this mechanism. Taking the transmission of 8 data entries in the memory module as an example, the transmission of each data entry goes through a synchronization process of the sequencer sending, the driver receiving confirmation, the driver switching signals, and the sequencer sending the next entry, ensuring that the 8 data entries are transmitted in order and without errors.

[0073] The above embodiments establish a reliable transmission link from the abstract test scenario to the DUT's recognizable signals, enabling the orderly generation, efficient transmission, and accurate conversion of stimuli. The abstract design of transaction-level stimulus objects eliminates the need to focus on underlying signal details during test scenario construction, reducing the difficulty of test case development while adapting to the common transmission requirements of different interface protocols. Standardized transmission via the TLM port avoids direct coupling between components, improving the modularity and maintainability of the verification environment. Protocol-based signal conversion by the driver ensures compatibility between the stimulus and the DUT interface, preventing verification failures due to protocol incompatibility; adaptation requirements for different interface protocols are all achieved through this logic. The introduction of the handshake mechanism ensures the reliability of stimulus transmission, effectively avoiding transaction loss or duplicate transmission, especially suitable for scenarios involving continuous transmission of multiple data streams. This process significantly reduces the workload of manually writing signal-level stimulus and synchronization logic, lowers the risk of timing errors, and improves the reusability of the verification environment. When the interface protocol changes, only the driver's signal conversion logic needs adjustment; the core logic of the sequencer, TLM port, and handshake mechanism can be directly reused, providing crucial support for the efficient execution of dynamic simulation verification.

[0074] Step S103: The input and output signals of the design to be verified are acquired in real time through the monitor, and the input and output signals are converted into transactions. The transactions are then transmitted to the scoreboard in the dynamic simulation verification environment through a transaction-level transmission mechanism.

[0075] As an optional embodiment, in step S103, the input and output signals of the design to be verified are acquired in real time by the monitor, and the input and output signals are converted into transactions, including: the monitor monitors the signal transitions on the interface of the design to be verified in real time; when valid data transmission conforming to the protocol specification is detected, the monitor captures the signal value at the current moment; the monitor encapsulates the captured signal value into a transmission transaction object and broadcasts it to the reference model and the scoreboard through the analysis port.

[0076] This optional embodiment is based on the UVM transaction-level modeling and interface protocol signal detection principle. A monitor performs bidirectional conversion between the interface signals and transaction-level data of the design under test, providing accurate data support for subsequent verification result comparison. Key concepts involved revolve around the reliability of signal acquisition and data transmission. The monitor is the core component in the UVM dynamic simulation verification environment responsible for observing the behavior of the interface of the design under test. Its core responsibility is to acquire signal-level activities on the interface in real time and convert them into transactions, transmitting them to other components through a transaction-level transmission mechanism. Signal transitions refer to the high and low level changes of the pins of the interface of the design under test, representing the physical manifestation of data transmission. Protocol specifications are the interaction guidelines for the interface of the design under test. Different interface protocols (such as AXI, APB, I2C, UART, etc.) have specific requirements for the signal combinations and timing relationships of valid data transmission. Different protocols have different conditions and timing relationships for receiving valid data, which is a key basis for judging valid transmission. The transmission transaction object is an abstract carrier encapsulating signal data, containing key information of interface transmission (such as address, data, control signals, etc.), adapting to the general requirements of transaction-level transmission. The analysis port is a standardized TLM interface for the monitor to broadcast transaction data to the reference model and scoreboard, ensuring that data is delivered accurately to both core components simultaneously.

[0077] Specifically, the monitor continuously monitors all signal transitions on the interface of the design under test in real time, maintaining dynamic awareness of interface behavior. For example, for the I2C interface, it continuously monitors the level changes of the SDA and SCL pins, capturing the trigger events of each rising and falling edge. When the monitored signal transitions meet the valid data transmission conditions of the corresponding interface protocol specification, such as I... 2In the C protocol, upon detecting the start signal, a combination of 8 consecutive data bits and an acknowledge bit is detected. Alternatively, in the AXI protocol, if the address channel's valid and ready signals are simultaneously valid and the address signal is stable, the monitor immediately captures the specific values ​​of all relevant interface signals at that moment, including the level states of data signals, control signals, and address signals. Subsequently, following the standardized format of UVM transactions, the monitor encapsulates the captured discrete signal values ​​into structured transport transaction objects. These transaction objects clearly identify key information such as data type, transmission direction, and relevant control parameters. For example, an I2C interface transaction object would include the slave device address, data content, and read / write control bits. Finally, the monitor broadcasts the encapsulated transport transaction object simultaneously to the reference model and the scoring board via its own TLM analysis port. This ensures the reference model can promptly acquire input data to generate the expected output, and the scoring board can synchronously receive the original input transaction and the output transaction of the design to be verified, preparing for subsequent comparisons. The monitor transmits transactions to other components through a transaction-level transport mechanism, which is achieved through broadcasting via this analysis port.

[0078] The above embodiments enable the establishment of a connection channel between the physical interface signals of the design to be verified and the transaction-level data of the verification environment, achieving automation and standardization of data acquisition, conversion, and transmission. Real-time signal monitoring by the monitor ensures the complete acquisition of interface data, avoiding errors and delays caused by manual signal observation, and is particularly suitable for high-frequency data transmission scenarios with high-speed interfaces. Valid data judgment based on protocol specifications ensures the validity of the acquired data, filters out invalid signal interference, and provides an accurate data source for subsequent verification and comparison. Standardized encapsulation of transaction objects unifies the data format, adapts to the receiving requirements of the reference model and the scoreboard, eliminates the need for additional data conversion operations, and improves data transmission efficiency. The broadcast mechanism of the analysis port enables synchronous data distribution, ensuring the timing consistency between the expected results generated by the reference model and the actual data received by the scoreboard, providing timing guarantees for dynamic comparison. Meanwhile, the signal acquisition and conversion logic of the monitor can be specifically extended according to different interface protocols. Furthermore, different protocols require specific code to capture data. This enables the verification environment to flexibly adapt to the design to be verified with various interface types, enhances the reusability and scalability of the environment, significantly reduces manual intervention in the data acquisition process, improves the automation level and data reliability of the verification process, and lays a solid foundation for the accurate comparison of the output of the reference model and the design to be verified.

[0079] Furthermore, in step S103, transactions are transmitted to the scoreboard in the dynamic simulation verification environment through a transaction-level transmission mechanism. Specifically, based on the standardized communication principle of UVM Transaction-Level Modeling (TLM), a unified data transmission mechanism enables efficient and synchronous flow of transactions between components, providing a complete data source for the scoreboard's comparison work. The Transaction-Level Transmission Mechanism (TLM) is a standardized method for data interaction between UVM components. By defining ports, interfaces, and communication rules, it achieves decoupled communication between components and is used for transaction transmission between the monitor and other components, and between the reference model and the scoreboard. A transaction is an abstract data carrier that encapsulates key information of interface signals, including the address, data, control signals, etc., required for transmission, ensuring universal data transmission between different components. The scoreboard is the core component for dynamically comparing the actual output of the design under test (DUT) with the expected output of the reference model; its comparison function relies on transaction data synchronously received from different components.

[0080] Specifically, in step S103, firstly, during the dynamic simulation verification environment setup phase, a TLM analysis port is configured in the monitor using a Python script, and a corresponding TLM export port is configured in the scoreboard, establishing a binding relationship between the two. Simultaneously, the reference model also establishes a connection with the scoreboard through the TLM port, forming a dual data transmission link between the monitor and the scoreboard, and between the reference model and the scoreboard. When verification is executed, the monitor captures the DUT's input and output signals and encapsulates them into transactions. These transactions, including the DUT's actual output transactions, are then synchronously transmitted to the scoreboard through the bound TLM analysis port. At the same time, the reference model receives the input transactions transmitted by the monitor, calculates the expected output results, and also sends the expected output transactions to the scoreboard through the TLM mechanism. Taking memory module verification as an example, when the verification continues to write after the memory is full, the monitor will capture 8 input transactions of written data and write failure response transactions returned by the DUT. Both types of transactions are transmitted to the scoreboard. The reference model generates the expected output transaction of "only the first 7 writes are successful and the 8th write fails" based on the memory capacity limit logic and transmits it to the scoreboard. The scoreboard synchronously receives these three types of transactions through the TLM mechanism (input transactions are used for context matching, and actual output is used to compare with expected output).

[0081] The above steps provide the scoreboard with a complete and synchronous comparison data source, ensuring the implementation of the comparison work. The standardized transmission of the TLM mechanism avoids direct coupling between components, allowing the monitor, reference model, and scoreboard designs to be independently expandable, adapting to different interface protocols and verification scenarios. Expansion of the verification environment under different interface protocols all rely on this mechanism. The abstract encapsulation of transactions unifies the data format, eliminating the need for format conversion between different components, reducing data transmission errors, and improving transmission efficiency. The synchronous transmission of dual links ensures that the scoreboard can simultaneously acquire the actual output transactions of the DUT and the expected output transactions of the reference model, avoiding comparison errors caused by data timing misalignment, especially suitable for high-frequency, multi-scenario verification processes. The entire transmission process requires no manual intervention, achieving full automation from data acquisition and encapsulation to transmission, significantly reducing the risk of human operation. At the same time, the standardized transmission logic enhances the reusability of the verification environment. When changing the design to be verified or expanding the test scenario, only the core data fields within the transaction need to be adjusted; the core logic of the transmission link can be directly reused, providing stable and reliable data support for subsequent dynamic comparisons of the scoreboard, thereby improving the accuracy and efficiency of the entire dynamic simulation verification.

[0082] Step S104: During the dynamic simulation verification process, the output signal of the reference model is compared with that of the design to be verified to generate dynamic simulation verification results.

[0083] In this embodiment, the dynamic simulation verification results include a simulation report, waveform files, and a coverage report. The simulation report records the comparison results, the waveform files record the signal change trajectory, and the coverage report verifies the coverage of the dynamic simulation verification results.

[0084] As an optional embodiment, in step S104, during the dynamic simulation verification process, the output signal of the reference model is compared with that of the design to be verified to generate a dynamic simulation verification result. This includes: sending the transmission transaction corresponding to the input signal converted by the monitor to the reference model, calculating the expected output result by the reference model, and transmitting it to the scoreboard through the TLM mechanism; directly transmitting the transmission transaction corresponding to the output signal of the design to be verified obtained by the monitor to the scoreboard through the TLM mechanism; driving the scoreboard to compare the expected output result of the reference model with the transmission transaction corresponding to the actual output signal of the design to be verified in real time, and recording error information if the comparison is inconsistent; using the objection mechanism of UVM to control the flow of the run_phase stage of verification, ensuring that all test stimuli are sent and the response data is processed by the scoreboard, and ending the simulation process; collecting the comparison records, waveform data, code coverage and functional coverage data during the simulation process, and summarizing them to generate the dynamic simulation verification result.

[0085] In this embodiment of the application, based on the principle of UVM component collaboration and automated data comparison, the core is to determine the correctness of the function by comparing the output of the reference model with the design to be verified (DUT), and to ensure the integrity of the process and the comprehensiveness of the results by leveraging the UVM mechanism.

[0086] The TLM mechanism is a standardized channel for inter-component transaction transmission, ensuring efficient data synchronization and flow. The objection mechanism is a process control tool in the run_phase of UVM, which enables precise start and stop of the verification process through raise_objection and drop_objection.

[0087] Specifically, the monitor converts the captured DUT input signals into transport transactions and sends them to the reference model via the TLM mechanism. The reference model calculates the expected output result based on its built-in algorithm logic consistent with the DUT's behavior and then transmits this expected result to the scoring board via the TLM mechanism. Simultaneously, the monitor converts the captured DUT output signals into transport transactions and also sends them directly to the scoring board via the TLM mechanism. Taking a scenario where writing continues after the memory module is full as an example, after receiving eight write data input transactions, the reference model generates an expected output transaction of "the first seven writes were successful, the eighth write failed" based on the memory capacity limitation logic and transmits it to the scoring board. The monitor then converts the actual response returned by the DUT (such as the feedback signal indicating the eighth write failed) into a transaction and transmits it to the scoring board. The scoring board then initiates real-time comparison, comparing the expected output with the actual output transaction data (including data values, response timing, etc.). If an inconsistency occurs (such as the DUT mistakenly writing the eighth data), error information is automatically recorded, including the time of inconsistency, input stimulus, expected result, and actual result. Throughout the verification process, the objection mechanism plays a continuous role. At the start of verification, the stimulus generation and data processing flow is activated via `raise_objection` to ensure that the sequencer continuously sends test stimuli and the monitor fully captures the signals. After all test stimuli have been sent and the scoreboard has completed the comparison of all response data, the `drop_objection` terminates the `run_phase` phase to prevent premature termination or excessive extension of the process. Finally, the system automatically collects the comparison records (including error messages and consistency results), signal waveform data (completely recording the interface signal transition trajectory), code coverage (such as line coverage and condition coverage), and functional coverage (based on the functional point coverage defined in the design specifications) during the simulation process. This data is then compiled to generate dynamic simulation verification results including a simulation report, waveform files, and a coverage report. The coverage report serves as an important input for subsequent formal verification.

[0088] The above embodiments achieve automated judgment of DUT functional correctness and comprehensive collection of verification results. The high-level language implementation of the reference model and multi-round verification ensure the reliability of the expected output, providing a precise benchmark for comparison and avoiding errors from manually setting expected values. Real-time automated comparison by the scoreboard replaces the cumbersome manual comparison process, significantly improving verification efficiency. Detailed error logging facilitates rapid location of DUT functional defects. The objection mechanism's process control ensures that all test scenarios and response data are fully processed, avoiding incomplete verification due to process control issues. The three types of verification results generated comprehensively cover comparison conclusions, signal trajectories, and coverage levels. This provides designers with a basis for defect investigation (such as tracing signal anomalies through waveform files) and clarifies the uncovered key areas for subsequent formal verification. It effectively solves the problems of low comparison efficiency, easy process control failure, and incomplete results in traditional dynamic simulation, while enhancing the standardization and reusability of the verification process, laying a data foundation for the collaboration between dynamic simulation and formal verification.

[0089] Step S105: Based on the dynamic simulation results, the state space of the formal verification is reduced, and the formal verification tool is used to traverse the state space of the design part not covered by the dynamic simulation in the design to be verified, and generate formal verification analysis results.

[0090] As an optional embodiment, in step S105, the state space of formal verification is narrowed down based on the dynamic simulation results. The formal verification tool is used to traverse the state space of the part of the design not covered by the dynamic simulation in the design to be verified, and generate formal verification analysis results. This includes: parsing the coverage report in the dynamic simulation verification results, extracting the uncovered lines of code, conditional branches, and function points; generating the configuration file required by the formal verification tool, setting the uncovered lines of code, conditional branches, state machines, and function points as the target state space of formal verification, and constraining and / or pruning the covered parts; calling the formal verification tool, loading the design to be verified and the configuration file, performing an exhaustive traversal of the target state space, and outputting the formal verification analysis results.

[0091] This optional embodiment is based on the principle of complementary advantages between dynamic simulation and formal verification. Its purpose is to use the coverage results of dynamic simulation to accurately locate the target range of formal verification and solve the state space explosion problem of formal verification through state space pruning.

[0092] The state space is the set of all possible logical states and transition paths of the design to be verified. Formal verification's exhaustive traversal must cover this space, while complex logic and boundary conditions that are difficult for dynamic simulation to cover constitute the uncovered state space. The coverage report is the core output of dynamic simulation verification, recording the coverage of lines of code, conditional branches, and functional points. Its uncovered items provide precise target guidance for formal verification. The formal verification configuration file is a set of parameters generated based on a standardized template, containing key configurations such as design module information, target state space definition, resource allocation, and maximum verification time, used for automated configuration of formal verification tools. Formal verification tools use mathematical methods for exhaustive checking and support depth-first traversal of a specified state space. Commonly used tools include VC Formal and Jasper Gold.

[0093] Here, the core mathematical method employed by the formal verification tool is based on model checking and theorem proving, combined with logical reasoning and state-space optimization techniques to achieve exhaustive correctness verification of the chip design. The principle of model checking involves abstracting the design to be verified into mathematical models such as finite state machines and transition systems. Then, propositional logic and sequential logic (such as LTL linear sequential logic and CTL computation tree logic) are used to transform the properties the design must satisfy (e.g., "data must be correctly read back after a write operation" and "all registers must be cleared when the reset signal is valid") into reasonable logical formulas. Subsequently, an automated algorithm traverses all possible state transition paths in the model to check for violations of the logical formulas. For example, regarding the "write is prohibited after full" property of a memory module, the tool abstracts the memory capacity limit and read / write control logic into a state machine, uses CTL logic to describe the property "if all memory cells are occupied, no write request will be responded to," and then traverses all state transition paths from "idle - write - half full - full - continue writing" to verify whether this property always holds true. Theorem proving is suitable for complex designs or scenarios with infinite state spaces. It transforms the problem of design correctness into mathematical theorems, using axioms and reasoning rules to gradually deduce and prove whether the theorem holds true, without traversing all states. For example, when verifying the correctness of the AES algorithm implementation in an encryption module, the tool transforms the algorithm logic into a mathematical theorem and proves through algebraic reasoning that its output is consistent with the theoretical result of the standard AES algorithm. In addition, the tool also incorporates optimization techniques such as symbolic execution (representing the set of states using logical expressions rather than specific values) and abstract interpretation (simplifying the design model while retaining key attributes) to alleviate the state space explosion problem. For example, when dealing with interface protocol logic containing multi-level nested conditions, symbolic execution uses logical expressions to summarize all possible input combinations, avoiding traversing specific values ​​one by one and significantly improving verification efficiency.

[0094] Specifically, the coverage report generated by dynamic simulation is first analyzed to extract key uncovered content, including unexecuted lines of code, untriggered conditional branches (such as the second condition not being met in a logical AND operation), uncovered functionalities (such as the abnormal power-off recovery function of the memory module), and untraversed state machine transition paths. These are the key targets for formal verification. Subsequently, a configuration file is generated based on the formal verification configuration template. The template integrates basic parameters such as design module naming, file paths, and clock / reset signal definitions. Verification personnel only need to supplement the constraints and pruning rules of the target state space, explicitly setting uncovered lines of code and conditional branches as verification objects. Simultaneously, constraints are added to the covered parts or they are directly pruned to avoid repeated traversal by the tool. The configuration file also sets resource allocation parameters (e.g., 5000) and maximum verification time (e.g., 24H) based on the complexity of the target state space and the number of uncovered items. For complex designs or with many uncovered items, the resource allocation and verification time are appropriately increased. Finally, the formal verification tool is invoked, and the design file to be verified and the above configuration file are loaded. The tool will exhaustively traverse the target state space according to the configuration, without covering the states that have been verified by dynamic simulation. For example, if the dynamic simulation does not cover the combination scenario of high-frequency burst transmission and parity error of a certain interface module, the formal verification tool will only traverse and analyze the state path corresponding to the scenario. The final output includes a dead code report, an updated coverage file, and a log of the traversal of uncovered states. The dead code report clearly identifies the code segments that cannot be run during verification, and the updated coverage file reflects the coverage of the target state space.

[0095] The core function of the above embodiments is to precisely focus on the verification scope of formal verification, achieving a synergistic effect between the broad coverage of dynamic simulation and the in-depth exploration of formal verification. By parsing the coverage report to extract uncovered items, formal verification does not need to traverse the entire state space of the design, significantly narrowing the verification scope and effectively solving the state space explosion problem when formal verification handles complex designs. This improves verification efficiency compared to directly using formal verification tools. The generation of standardized configuration files simplifies the preparation work for formal verification, reduces the risk of errors in manual configuration, and the dynamic adjustment of resource allocation and maximum verification time adapts to the verification needs of different designs, ensuring efficient progress of the verification process. The exhaustive traversal of formal verification can cover complex logic and boundary conditions that are difficult for dynamic simulation to reach, such as untriggered nested conditional branches and state transitions in extreme cases, significantly improving the completeness of verification. Combined with dead code reports and updated coverage files, verification and design teams can accurately grasp the unverified parts and potential redundancies of the design, further optimizing the design and verification environment. The overall process achieves deep synergy between the two verification methods, leveraging the scenario coverage advantage of dynamic simulation and highlighting the mathematical completeness advantage of formal verification. This significantly improves the defect detection rate of chip design, especially reducing the risk of missing deep logic errors, and provides a strong guarantee for successful tape-out on the first attempt.

[0096] In the above embodiment of step S105, optionally, generating the configuration file required by the formal verification tool, setting the uncovered lines of code, conditional branches, state machines, and function points as the target state space for formal verification, includes: calling the formal verification configuration template, filling in the design file path, clock signal definition, and reset signal definition according to the attribute information of the design to be verified, and setting resource allocation parameters and maximum verification time parameters according to the complexity of the target state space; using the formal verification automation script to read the filled configuration template and the coverage report, and generating the configuration file.

[0097] This optional embodiment is based on the collaborative principle of formal verification configuration templates and automated scripts. Through standardized template filling and dynamic parameter adjustment, it generates a formal verification configuration file that accurately adapts to the target state space, providing a clear execution basis for the formal verification tool. The formal verification configuration template is a standardized text file that integrates the core parameters required by the verification tool. It includes key configuration items such as design module naming conventions, design file paths, clock signal definitions, reset signal definitions, resource allocation parameters, and maximum verification time, used to quickly build the basic configuration file. The attribute information of the design to be verified is the core content to be filled in the configuration template, including the actual storage path of the design file, the specific name of the clock signal, and the definition of the reset signal, directly determining the compatibility between the configuration file and the design to be verified. The resource allocation parameters and the maximum verification time parameter are dynamic configuration items adapted to the complexity of the target state space. The resource allocation parameter specifies the computational resources that the verification tool can call, and the maximum verification time parameter limits the maximum duration of verification execution. For example, the resource allocation parameter can be set to 5000, and the maximum verification time parameter can be set to 24H. The formal verification automated script is the core tool for automating configuration file generation. It can parse the filled template and the coverage report of dynamic simulation, integrating the target state space information to generate the final configuration file.

[0098] Specifically, the process begins by invoking a pre-defined formal verification configuration template. Basic parameters are then populated based on the attribute information of the design to be verified. For example, if the design to be verified is `module_test`, the design file path is filled with the actual storage path, the clock signal definition is filled with the corresponding clock signal name, and the reset signal definition is filled with the corresponding reset signal name, ensuring that the configuration file matches the basic information of the design to be verified. Subsequently, dynamic parameters are adjusted based on the complexity of the target state space. If there are many uncovered lines of code, multiple levels of nested conditional branches, or complex state machine transitions, indicating a high complexity of the target state space, the resource allocation parameter is set to no less than 5000, and the maximum verification time parameter is set to no less than 24 hours. If the target state space is relatively simple, the parameter configuration is appropriately reduced. These two parameters need to be dynamically adjusted based on the amount of uncovered code and the complexity of the design. Finally, the formal verification automation script is launched. This script reads the populated and adjusted configuration template to obtain basic configuration and dynamic parameter information. On the other hand, it parses the coverage report of the dynamic simulation to extract target state space information such as uncovered lines of code, conditional branches, state machines, and function points. It integrates this information with the template parameters to automatically generate a complete formal verification configuration file containing the target state space definition, basic configuration, resource and time constraints. For example, the script will clearly mark in the configuration file "the target verification scope is the 30 lines of code, 5 conditional branches, and 2 state machine transition paths not covered in the coverage report", and write the populated design file path, clock reset signal name, and set resource and time parameters.

[0099] To provide a precise and adaptable execution configuration for formal verification tools, the above embodiments can determine the verification scope and resource constraints. Standardized configuration template filling avoids the tediousness and errors of manually writing configuration files, especially reducing errors in defining clock or reset signals and filling in file paths, thus improving the standardization and accuracy of configuration files. Dynamic adjustment of resource allocation parameters and maximum verification time parameters allows configuration files to adapt to target state spaces of varying complexity, avoiding resource waste and ensuring that verification of complex state spaces can be fully executed without interruption due to insufficient resources or time constraints. The integration of templates and coverage reports by automated scripts achieves seamless fusion of target state space information and configuration parameters, ensuring that formal verification tools can accurately focus on uncovered parts without repeating verification of covered state spaces, effectively solving the state space explosion problem in formal verification. The overall process transforms configuration file generation from manual operation to an automated process, significantly shortening the preparation time for formal verification, reducing reliance on the professional configuration capabilities of verification personnel, and enhancing the reusability of configuration files through standardized configuration logic, laying a solid foundation for the efficient and accurate execution of subsequent formal verification tools.

[0100] This application proposes a formal verification configuration template to improve the efficiency and reusability of formal verification environment construction through a standardized configuration process. This formal verification configuration template systematically integrates various key parameters required by verification tools, including but not limited to: design module naming conventions, design file path configuration, clock / reset signal definitions, and other core configuration items. Based on this template, verification personnel can quickly create a basic configuration file and modify it appropriately according to the actual design characteristics and verification requirements to obtain a formal verification configuration file suitable for the current design. This formal verification configuration template makes the configuration process more standardized and unified, and also facilitates the reuse of verification environment settings across different projects, effectively reducing the workload of formal verification preparation. For example, an exemplary content of the formal verification configuration template is shown below:

[0101] formal mode = “example mode”;

[0102] module name = “example name”;

[0103] design path= “example path”;

[0104] ...

[0105] clock_single name = “example clk”;

[0106] reset_single name = “example rst”;

[0107] ...

[0108] resource allocation = “5000”

[0109] max time = “24H”

[0110] The formal verification configuration template file is a text file that defines the parameters shown above, such as the name of the design to be verified, the design file path, clock signals, and reset signals. Verification personnel simply need to modify the parameters in the formal verification configuration template according to the relevant information of the design to be verified.

[0111] This application also provides a Python automated script for formal verification to simplify the formal verification execution process. The script can read a pre-configured formal verification configuration file, the DUT, and related files, and automatically launch the formal verification tool to complete the formal verification. This automated approach reduces manual steps, lowers the possibility of configuration errors, and improves the efficiency of the verification work. The script adopts a modular design, allowing for functional expansion according to actual needs and supporting the verification requirements of different projects. The script file parses the modified formal verification configuration template file to obtain the corresponding parameter content for configuring the formal verification tool. The formal verification tool is launched using a command line; in this patent, this command is integrated into the automated script. After parsing the formal verification tool configuration template, the automated script automatically uses the command to launch the formal verification tool and configures the tool for verification according to the configuration information.

[0112] Optionally, the formal verification analysis results include a dead code report and an updated coverage file. Based on this, in the above embodiment of step S105, the step of invoking the formal verification tool, loading the design to be verified and the configuration file, exhaustively traversing the target state space, and outputting the formal verification analysis results includes: formally describing the attribute information of the design to be verified to obtain assertion attributes for the design to be verified; traversing the target state space in the formal verification tool to search for paths in the design to be verified that violate the assertion attributes; if a path violating the assertion attributes is found, generating a formal verification analysis result containing counterexample paths, where the counterexample paths contain the input stimulus sequence and state waveform that cause the attribute information violation; and generating the dead code report and dynamically updating the coverage file based on the formal verification analysis result containing the counterexample paths, whereby the dead code report indicates code segments that cannot run in the target state space, and the coverage file records the coverage of the state space of the design to be verified after formal verification.

[0113] This optional embodiment is based on the assertion checking and exhaustive traversal principles of formal verification. It generates analysis results containing counterexamples and improves coverage and redundant code information by formally describing design attributes and accurately searching for violation paths. Here, assertion attributes are mathematically verifiable logical statements that transform the functional requirements, interface protocol rules, and other attribute information of the design to be verified. They are the core basis for judging the correctness of design behavior. Counterexample paths are the specific execution paths that violate assertion attributes, discovered by the formal verification tool. They include the input stimulus sequence that triggers the violation and the corresponding state waveform, providing direct clues for locating design defects. Dead code reports are one of the key outputs after formal verification. They indicate code segments that cannot be run in the target state space even with all possible effective stimuli applied, clarifying whether they are redundant code and requiring joint analysis by verification and design personnel. The updated coverage file integrates coverage data from dynamic simulation and formal verification, comprehensively recording the coverage of the state space of the design to be verified, providing data support for verification completeness assessment.

[0114] Specifically, the formal verification tool first formally describes the design attributes (such as functional characteristics, interface protocol requirements, and boundary constraints) specified in the design specification (SPEC). This transforms concrete requirements like "prohibit writing after memory is full" and "clear registers when the reset signal is valid" into assertion attributes recognizable by the formal verification tool. For example, regarding memory module capacity limitations, the assertion attribute can be described as "when the number of memory cells occupied equals the maximum capacity, the response signal corresponding to the write request is invalid." Then, the formal verification tool loads the design file to be verified and the configured target state space configuration file, exhaustively traversing the state space not covered by dynamic simulation, checking each path for violations of assertion attributes. If a violation path is found, such as receiving and storing new data after the memory is full, the tool automatically generates a formal verification analysis result containing this violation path. The violation path records in detail the input stimulus sequence that caused the violation (such as the specific content and transmission timing of the 8th written data) and the corresponding state waveforms (such as the change trajectory of the write enable signal and the number of memory cells occupied signal). Building upon this foundation, the tool further analyzes the code execution within the target state space, marking all code segments that are untouchable under any possible stimuli and generating a dead code report. For example, a piece of code used for exception handling but not triggered by any test scenario will be included in the report. Simultaneously, the tool merges the new state space data from formal verification coverage with the existing dynamic simulation coverage data, dynamically updating the coverage file and supplementing it with new coverage items such as conditional branches and state machine transitions.

[0115] The core function of the above embodiments is to locate design defects, identify redundant code, and improve verification coverage evaluation. The formal description of assertion attributes transforms design requirements into automatically verifiable logic, avoiding the subjectivity and omissions of manual judgment and ensuring consistency between verification standards and design specifications. The generation of counterexample paths provides precise clues for design defect investigation, allowing designers to quickly locate the root cause of violations without having to check every line of code, significantly shortening the debugging cycle. For example, the abnormal scenario of writing even after the memory is full can be directly reproduced through the input stimulus sequence in the counterexample. The output of dead code reports helps designers identify redundant or invalid code, reducing chip area and power consumption, while avoiding potential logical conflicts caused by redundant code. The updated coverage file comprehensively integrates coverage data from dynamic simulation and formal verification, providing the verification team with a complete state-space coverage view, clearly presenting uncovered parts, and providing a clear direction for subsequent verification optimization. The overall process focuses on the target state space not covered by dynamic simulation, which not only solves the state space explosion problem in formal verification, but also improves the accuracy of defect detection through assertion checking and counterexample generation. Combined with dead code analysis and coverage updates, it further optimizes design quality and verification completeness, and significantly reduces the defect risk before chip tape-out.

[0116] Step S106: Based on the formal verification analysis results, evaluate the design to be verified, and if the evaluation results do not meet the verification indicators, correct the design to be verified and optimize the dynamic simulation verification environment.

[0117] As an optional embodiment, in step S106, the design to be verified is evaluated based on the formal verification analysis results, and the design to be verified is corrected and the dynamic simulation verification environment is optimized when the evaluation results do not meet the verification indicators. This includes: analyzing the dead code report, and in conjunction with the functional specifications of the design to be verified, confirming whether the parts marked as dead code are redundant logic or unreachable logic caused by constraints; merging the updated coverage file with the coverage report in the dynamic simulation verification results, and calculating the final verification completeness index; if the evaluation results determine that there are design defects or redundant logic, then the register transfer level code of the design to be verified is corrected, and the verification process is re-executed; if the evaluation results determine that the state is not covered due to the lack of test stimuli in the dynamic simulation verification environment, then targeted test cases for the uncovered state are added to the dynamic simulation verification environment.

[0118] This optional embodiment uses formal verification analysis results to reverse-evaluate the rationality of the design to be verified and the dynamic simulation verification environment, forming a closed-loop process from evaluation to correction to optimization. The dead code report is a key output of formal verification, indicating code segments that cannot be run by any valid stimuli within the target state space. The verification completeness index is a quantitative indicator calculated by combining dynamic simulation and formal verification coverage data, reflecting the degree of coverage of the design's functions and logic, and is the core basis for evaluating the verification effect. Register-transfer level code is the core implementation carrier of the design to be verified, and its correction directly affects the correctness of the design's functions. Targeted test cases are test stimuli specifically designed for uncovered states, used to supplement the coverage gaps in the dynamic simulation verification environment, and are generated by constructing application scenarios for specific functional points.

[0119] Specifically, the verification and design teams first jointly analyze the dead code report output by formal verification. Combining this with the functional specifications of the design to be verified, they examine each segment marked as dead code to determine its attributes. If a code segment is unrelated to the core functionality of the design and has no practical application scenario, such as redundant exception handling logic, it is determined to be redundant logic. If the code itself is a necessary function of the design but cannot be reached due to the constraints set by formal verification or the incentive limitations of dynamic simulation, it is determined to be unreachable logic. Subsequently, the updated coverage file from formal verification is merged with the coverage report from the dynamic simulation verification results. Various coverage data, such as lines of code, conditional branches, and function points, are integrated to calculate the final verification completeness index, clarifying whether the current verification coverage of the design meets the preset standard. If the evaluation results show that the design to be verified has functional defects (such as logical errors revealed by formal verification counterexamples) or redundant logic, the designers specifically correct the register transfer level code. For example, they fix logic vulnerabilities where writing is still possible even after the memory is full, or delete redundant dead code segments. After correction, the complete verification process from dynamic simulation to formal verification is re-executed to ensure that the defects are completely resolved. If the evaluation results determine that the failure to meet the verification indicators is due to the lack of test stimuli in the dynamic simulation verification environment, resulting in some states not being covered, such as the boundary state of continuing to read after the memory is empty, the verification personnel shall supplement the corresponding targeted test cases in the dynamic simulation verification environment, such as constructing a stimulus sequence for sending read instructions after the memory is empty, so as to accurately cover the state space that has not met the standards.

[0120] The core function of the above embodiments is to thoroughly resolve design defects and insufficient verification environment through a closed-loop optimization mechanism, ensuring that verification indicators meet the standards. In-depth analysis of dead code reports avoids redundant logic occupying chip area and power consumption, and also identifies unreachable effective logic due to constraint or stimulus issues, ensuring the rationality and completeness of the design. Quantitative calculation of verification completeness indicators provides a clear evaluation standard for verification effectiveness, avoiding insufficient verification due to subjective judgment. Correction of design defects and redundant logic directly improves the functional correctness and simplicity of the design to be verified, reducing the risk of errors after tape-out. Targeted test case supplementation in the dynamic simulation verification environment fills coverage gaps, eliminating the need to repeatedly build a large number of test cases, and improving the targeting and efficiency of the verification environment. The entire process forms a two-way feedback between verification results and the design and verification environment, effectively solving the problem that a single verification method cannot cover all scenarios, ensuring that the design to be verified meets the preset indicators in terms of functional correctness and verification completeness. At the same time, the optimized verification environment can be reused for subsequent verification of similar designs, further improving verification efficiency and consistency.

[0121] For example, refer to Figure 2 This demonstrates an example of a verification architecture for a memory chip design, showcasing the interaction logic between the chip design to be verified and the chip verification platform, as well as the output format of the verification results. Figure 2 The chip design to be verified is the target verification object (taking a memory chip with read / write and capacity limiting functions as an example). The chip verification platform is the core carrier for executing the verification process, containing two core functional units: a dynamic simulation verification environment and a formal verification analysis module. These two units work together to complete a comprehensive verification of the memory chip. Specifically, firstly, the memory chip design to be verified interacts with the dynamic simulation verification environment. The dynamic simulation verification environment builds a verification framework adapted to the memory based on the UVM methodology, generating stimuli covering test scenarios such as normal read / write, write after full, and read after empty. After executing the dynamic simulation, it outputs multiple verification result files (e.g., ...). Figure 2The verification result files 1 to 4 correspond to the simulation report, waveform file, code coverage report, etc. from the previous steps. The coverage report records the lines of code and conditional branches that have been covered for the memory chip. Subsequently, the dynamic simulation verification environment passes these result files (especially the coverage report) to the formal verification analysis module. The formal verification analysis module extracts the uncovered state space based on the report (such as complex interaction scenarios of high-frequency burst writes and parity errors in memory), loads the memory chip design file and configuration file, performs exhaustive traversal verification, and outputs formal verification analysis files 1 to 3 (corresponding to the dead code report, updated coverage file, and negative example path report, etc.). At the same time, the formal verification analysis module also interacts directly with the memory chip design to be verified to obtain its logic implementation details to support the traversal of the state space. The interaction between the dynamic simulation verification environment and the formal verification analysis module also supports feeding back the coverage gaps found by formal verification to the dynamic simulation, such as supplementing targeted test cases for continuous read boundary scenarios after a read-empty state. Finally, through the collaboration of the two, a complete verification result is output, realizing the evaluation of the functional correctness and verification completeness of the memory chip design.

[0122] In this embodiment, the deep coupling of dynamic simulation and formal verification at the process data level enables the integration of the verification system. This effectively solves the technical problems existing in the integration of the current verification system, such as reliance on manual writing and debugging of verification tools, data incompatibility between different verification methods, and different verification granularities. This improves the verification efficiency and reliability of complex chips.

[0123] For example, Figure 3 This demonstrates an example of a dynamic simulation verification test bench architecture for memory chips, used to automate the verification of the functional correctness of memory chip designs with capacity limitations and read / write response capabilities. Figure 3The design to be verified refers to the register-transfer level implementation of the target memory chip (e.g., a chip supporting read / write of 16 memory cells). It interacts with the test bench components through an interface, which corresponds to the physical signal ports of the memory (including address, data, read / write enable, and response signals). The test environment is the top-level container of the entire UVM verification framework, integrating all functional components. The proxy component is the core unit encapsulating the memory interface verification logic, containing three sub-components. The driver is responsible for converting abstract transaction-level stimuli into signals conforming to the interface protocol (e.g., converting a transaction of "writing data 0x12 to address 0x00" into timing transitions of address and data signals on the interface). The sequencer is responsible for scheduling transactions corresponding to the test scenario (e.g., sending stimuli transactions in sequence such as "normal write, write after full, read after empty"). The monitor collects signals on the interface in real time, restoring the memory's input (e.g., write requests) and output (e.g., write success / failure responses) back to transaction-level data. The virtual sequencer coordinates the timing of stimulus transmission (expandable to support multi-channel synchronization if the memory has multiple interfaces), triggering the transaction distribution of the corresponding test scenario by controlling the sequencer within the proxy component. The reference model serves as the gold standard for simulating the expected behavior of the memory (strictly adhering to the design specification of "reject writing when the memory cell is full"). For example, after receiving 8 write transactions, it will output the expected result that the first 7 writes were successful and the 8th write failed. The scoreboard synchronously receives the actual output transactions of the memory collected by the monitor and the expected output transactions of the reference model, and compares the consistency between the two in real time (for example, comparing whether the actual write failure response returned by the memory in the write scenario after the memory is full matches the expected result of the reference model).

[0124] Taking the verification scenario of "writing after the memory is full" as an example, the virtual sequencer triggers the sequencer to send 8 write transactions. The driver converts these transactions into interface signals and transmits them to the memory to be verified. The monitor collects the memory's input (8 write requests) and output (the response signal of the 8th write request) and converts them into transactions, which are then synchronously transmitted to the reference model and the scoring board. The reference model outputs the expected transaction of "the 8th write failed." The scoring board compares the actual response with the expected result. If they match, the verification is recorded as successful; otherwise, a verification log containing error details is generated. This architecture, through the collaboration of modular components, achieves automated stimulus generation, signal acquisition, and result comparison for memory verification, significantly improving the efficiency of verification and the accuracy of correctness determination.

[0125] After introducing the method of the exemplary embodiments of this application, the following describes a chip verification apparatus according to an exemplary embodiment of this application. The apparatus includes: a construction unit, configured to establish a dynamic simulation verification environment for the design to be verified through dynamic simulation verification, and generate multiple test scenarios in the dynamic simulation verification environment according to the functions and behaviors defined in the design specifications, and generate corresponding test stimuli for each test scenario; a dynamic simulation verification unit, configured to send the test stimuli to a driver through a sequencer, and the driver converts the test stimuli into signals conforming to the interface protocol of the design to be verified, and transmits them to the design to be verified; and a monitor to collect the input signals and output signals of the design to be verified in real time, and convert the input signals and output signals into transactions. The system transmits data to a scoreboard in the dynamic simulation verification environment via a transaction-level transmission mechanism. During dynamic simulation verification, the output signal of the design to be verified is compared with that of the reference model to generate dynamic simulation verification results, which include a simulation report, waveform files, and coverage report. A formal verification unit is used to narrow down the state space of the formal verification based on the dynamic simulation results, and uses formal verification tools to traverse the state space of the design not covered by the dynamic simulation in the design to be verified, generating formal verification analysis results. An evaluation unit is used to evaluate the design to be verified based on the formal verification analysis results, and corrects the design to be verified and optimizes the dynamic simulation verification environment if the evaluation results do not meet the verification indicators. The above apparatus can implement the steps described in the above method implementation, and the specific implementation methods of each step will not be repeated here.

[0126] After introducing the methods and apparatus of the exemplary embodiments of this application, a terminal device of the exemplary embodiments of this application will be described next. The terminal device can implement the steps described in the above method embodiments, and the specific implementation of each step will not be repeated here.

[0127] After introducing the methods, apparatus, and terminal devices of exemplary embodiments of this application, the computer-readable storage medium of exemplary embodiments of this application will now be described. The computer-readable storage medium is an optical disc, on which a computer program (i.e., a program product) is stored. When the computer program is run by a processor, it implements the steps described in the above-described method embodiments. The specific implementation methods of each step will not be repeated here.

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

Claims

1. A chip verification method, characterized in that, The method includes: Dynamic simulation verification establishes a dynamic simulation verification environment for the design to be verified, including: parsing the name of the design to be verified, verification personnel information, proxy component names and quantities, scoreboard configuration, and environment parameters; generating component files and object files adapted to the Universal Verification Methodology (UVM) architecture based on the parsing results of the design to be verified; writing UVM core mechanism files matching the parsing results into the component files and object files to form a dynamic simulation verification environment framework; wherein, the component files include environment components, proxy components, drivers, monitors, sequencers, and virtual sequencers, the object files include transport transaction objects and sequence objects, and the UVM core mechanism files include component registration and overloading procedures based on the factory mechanism, hierarchical phase function procedures based on the phase mechanism, TLM connection procedures between components, and flow control procedures based on the objection mechanism; and generating multiple test scenarios in the dynamic simulation verification environment according to the functions and behaviors defined in the design specifications, and generating corresponding test stimuli for each test scenario. The test stimulus is sent to the driver via a sequencer, and the driver converts the test stimulus into a signal that conforms to the interface protocol of the design to be verified, and transmits it to the design to be verified. The system acquires the input and output signals of the design to be verified in real time through a monitor, converts the input and output signals into transactions, and transmits the transactions to the scoreboard in the dynamic simulation verification environment through a transaction-level transmission mechanism. During the dynamic simulation verification process, the output signal of the reference model is compared with that of the design to be verified to generate dynamic simulation verification results, which include simulation reports, waveform files and coverage reports. The state space for formal verification is narrowed down based on the dynamic simulation results. A formal verification tool is then used to traverse the state space of the design portion not covered by the dynamic simulation in the design to be verified, generating formal verification analysis results. This includes: parsing the coverage report in the dynamic simulation verification results and extracting uncovered code lines, conditional branches, and function points; generating the configuration file required by the formal verification tool, setting the uncovered code lines, conditional branches, state machines, and function points as the target state space for formal verification, including: calling the formal verification configuration template, filling in the design file path, clock signal definition, and reset signal definition according to the attribute information of the design to be verified, and setting resource allocation parameters and maximum verification time parameters according to the complexity of the target state space; using a formal verification automation script to read the filled configuration template and the coverage report to generate the configuration file; and constraining and / or pruning the covered portions; calling the formal verification tool, loading the design to be verified and the configuration file, performing an exhaustive traversal of the target state space, and outputting the formal verification analysis results. Based on the formal verification analysis results, the design to be verified is evaluated, and if the evaluation results do not meet the verification indicators, the design to be verified is corrected and the dynamic simulation verification environment is optimized.

2. The chip verification method according to claim 1, characterized in that, The step of writing a UVM core mechanism file that matches the parsing results into the component file and object file includes: Based on the proxy component names and quantities obtained from the parsing results, a corresponding proxy component is generated for each proxy component name, and the instantiation logic of the corresponding driver, monitor and sequencer is integrated into the proxy component. Write the component registration program, object registration program, and overload program of the factory mechanism in all component files; In the environment components, a hierarchical phase execution function based on the phase mechanism defines different phases of the simulation run; and a transaction-level modeling TLM connection program is written to establish data transmission channels between the driver and the sequencer, as well as between the monitor and the scoreboard.

3. The chip verification method according to claim 1, characterized in that, Based on the functions and behaviors defined in the design specifications, multiple test scenarios are generated in the dynamic simulation verification environment, including: Based on the interface protocol of the design to be verified, drive logic is established in the driver to convert transmission transactions into timing signals, and sampling logic is established in the monitor to convert timing signals into transmission transactions. The reference model is integrated into the dynamic simulation verification environment, and a scoreboard is configured to establish a comparison rule between the expected output of the reference model and the actual output of the design to be verified. For test scenarios involving multiple interface interactions, a virtual sequencer is integrated and a virtual sequence is written to coordinate the working sequence of multiple proxy components and generate multi-channel synchronous or asynchronous test stimuli.

4. The chip verification method according to claim 1, characterized in that, The step of sending the test stimulus to the driver via a sequencer, and having the driver convert the test stimulus into a signal conforming to the interface protocol of the design to be verified, includes: In the dynamic simulation verification environment, the sequencer generates abstract transaction-level stimulus objects based on the test scenario and sends them to the driver through the TLM port; The driver receives the transaction-level stimulus object and drives the input port signal of the design to be verified to toggle according to the clock edge and timing constraints of the interface protocol. During transmission, the driver keeps synchronized with the sequencer through a handshake mechanism.

5. The chip verification method according to claim 1, characterized in that, The process of acquiring the input and output signals of the design to be verified in real time via a monitor and converting the input and output signals into transactions includes: The monitor tracks signal transitions on the interface of the design to be verified in real time. When valid data transmission conforming to the protocol specifications is detected, the monitor captures the signal value at the current moment. The monitor encapsulates the captured signal values ​​into a transmission transaction object and broadcasts it to the reference model and scoreboard via the analysis port.

6. The chip verification method according to claim 1, characterized in that, During the dynamic simulation verification process, the output signal of the reference model is compared with that of the design to be verified to generate dynamic simulation verification results, including: The transmission transaction corresponding to the input signal obtained from the monitor is sent to the reference model, the reference model calculates the expected output result, and transmits it to the scoreboard through the TLM mechanism. The transmission transactions corresponding to the output signals of the design to be verified obtained from the monitor are directly transmitted to the scoreboard through the TLM mechanism. The drive scoreboard compares the expected output of the reference model with the actual output signal of the design to be verified in real time. If the comparison is inconsistent, the error information is recorded. The UVM objection mechanism is used to control the flow of the verification run phase, ensuring that the simulation process ends after all test stimuli have been sent and the response data has been processed by the scoreboard. Collect comparison records, waveform data, code coverage and functional coverage data during the simulation process, and summarize them to generate the dynamic simulation verification results.

7. The chip verification method according to claim 1, characterized in that, The formal verification analysis results include dead code reports and updated coverage files; The formal verification tool is invoked, the design to be verified and the configuration file are loaded, an exhaustive traversal of the target state space is performed, and the formal verification analysis results are output, including: The attribute information of the design to be verified is formally described to obtain the assertion attributes for the design to be verified; The formal verification tool traverses the target state space to search for paths in the design to be verified that violate the assertion properties. If a path that violates the assertion property is found, a formal verification analysis result containing counterexample paths is generated. The counterexample paths contain the input stimulus sequence and state waveform that caused the property information to be violated. Based on the formal verification analysis results including counterexample paths, the dead code report is generated and the coverage file is dynamically updated. The dead code report is used to indicate code segments that cannot run in the target state space, and the coverage file is used to record the coverage of the state space of the design to be verified after formal verification.

8. The chip verification method according to claim 7, characterized in that, The step of evaluating the design to be verified based on the formal verification analysis results, and correcting the design to be verified and optimizing the dynamic simulation verification environment when the evaluation results do not meet the verification indicators, includes: Analyze the dead code report and, in conjunction with the functional specifications of the design to be verified, confirm whether the part marked as dead code is redundant logic in the design or unreachable logic caused by constraints. Merge the updated coverage file with the coverage report in the dynamic simulation verification results, and calculate the final verification completeness index; If the evaluation results indicate that there are design flaws or redundant logic, the register transfer level code of the design to be verified is corrected and the verification process is re-executed. If the evaluation results indicate that the state is not covered due to the lack of test stimuli in the dynamic simulation verification environment, then targeted test cases for the uncovered state are added to the dynamic simulation verification environment.

9. A chip verification device, characterized in that, include: The building unit is used to establish a dynamic simulation verification environment for the design to be verified through dynamic simulation verification, and generate multiple test scenarios in the dynamic simulation verification environment according to the functions and behaviors defined in the design specifications, and generate corresponding test stimuli for each test scenario. The construction unit, when establishing a dynamic simulation verification environment for the design to be verified through dynamic simulation verification, is specifically used for: parsing the name of the design to be verified, verification personnel information, agent component names and quantities, scoreboard configuration, and environment parameters; generating component files and object files adapted to the Universal Verification Methodology (UVM) architecture based on the parsing results of the design to be verified; writing UVM core mechanism files matching the parsing results into the component files and object files to form a dynamic simulation verification environment framework; wherein, the component files include environment components, agent components, drivers, monitors, sequencers, and virtual sequencers, the object files include transport transaction objects and sequence objects, and the UVM core mechanism files include component registration and overloading procedures based on the factory mechanism, hierarchical phase function procedures based on the phase mechanism, TLM connection procedures between components, and flow control procedures based on the objection mechanism; The dynamic simulation verification unit is used to send the test stimuli to the driver via a sequencer, and the driver converts the test stimuli into signals conforming to the interface protocol of the design to be verified, and transmits them to the design to be verified; it also collects the input and output signals of the design to be verified in real time through a monitor, converts the input and output signals into transactions, and transmits the transactions to the scoreboard in the dynamic simulation verification environment through a transaction-level transmission mechanism; during the dynamic simulation verification process, it compares the output signals of the reference model with those of the design to be verified to generate dynamic simulation verification results, which include simulation reports, waveform files, and coverage reports; The formal verification unit is used to narrow down the state space of formal verification based on the dynamic simulation results, and to use formal verification tools to traverse the state space of the design parts not covered by the dynamic simulation in the design to be verified, and generate formal verification analysis results. Specifically, the formal verification unit is used to: parse the coverage report in the dynamic simulation verification results, extract uncovered lines of code, conditional branches, and function points; generate the configuration file required by the formal verification tool, set the uncovered lines of code, conditional branches, state machines, and function points as the target state space for formal verification, and constrain and / or prune the covered parts; call the formal verification tool, load the design to be verified and the configuration file, perform an exhaustive traversal of the target state space, and output the formal verification analysis results. The formal verification unit generates the configuration file required by the formal verification tool. When setting uncovered lines of code, conditional branches, state machines, and function points as the target state space for formal verification, it is specifically used for: calling the formal verification configuration template, filling in the design file path, clock signal definition, and reset signal definition according to the attribute information of the design to be verified, and setting resource allocation parameters and maximum verification time parameters according to the complexity of the target state space; and using the formal verification automation script to read the filled configuration template and the coverage report to generate the configuration file. The evaluation unit is used to evaluate the design to be verified based on the formal verification analysis results, and to correct the design to be verified and optimize the dynamic simulation verification environment when the evaluation results do not meet the verification indicators.

10. An electronic device, characterized in that, include: Memory, used to store computer software programs; A processor for reading and executing the computer software program to implement the chip verification method according to any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The storage medium stores a computer software program, which, when executed by a processor, implements the chip verification method as described in any one of claims 1-8.

12. A chip, characterized in that, The chip verification method according to any one of claims 1-8 is applied to the chip verification process of the chip.

Images