Verification code generation method and device, equipment and storage medium

Abstract

This application discloses a method, apparatus, device, and storage medium for generating verification code, belonging to the field of chip technology. The method includes: obtaining a verification description file for the design under test; the verification description file includes verification requirements for the design under test; revising the verification description file according to a design specification document and an interface protocol document to obtain a verification standard document; decomposing the verification objective corresponding to the verification standard document into multiple sub-tasks; the multiple sub-tasks having dependencies; and generating the verification code according to the task type and parameters corresponding to each sub-task. This application can solve the problem that existing verification environments still heavily rely on manual coding based on engineers' personal experience, resulting in low efficiency and poor consistency.

Description

Technical Field

[0001] This application belongs to the field of chips, and specifically relates to a method, apparatus, device and storage medium for generating verification code. Background Technology

[0002] With the dramatic increase in the complexity of integrated circuit design, chip verification has become a critical link restricting product development cycles. Universal Verification Methodology (UVM), as the industry's mainstream verification methodology, improves the reusability of verification components through its standardized framework. However, setting up a complete UVM verification environment remains a highly complex, repetitive, and time-consuming task. It requires generating all the source code needed for the entire verification environment, then compiling, linking, and instantiating the code before setting up the verification environment, demanding a high level of technical expertise from the personnel involved.

[0003] In the current technology, all the source code required for the UVM verification environment still relies heavily on manual coding based on the personal experience of engineers, resulting in low efficiency and poor consistency. Summary of the Invention

[0004] The purpose of this application is to provide a method, apparatus, device, and storage medium for generating verification code, which can solve the problem that the source code required by the existing verification environment still heavily relies on the personal experience of engineers for manual coding, resulting in low efficiency and poor consistency.

[0005] To solve the above-mentioned technical problems, this application is implemented as follows: In a first aspect, embodiments of this application provide a method for generating verification code, the method comprising: Obtain the verification description file of the design under test; the verification description file includes the verification requirements of the design under test. The description file to be verified is revised according to the design specification document and interface protocol document to obtain the verification standard document; The verification objective corresponding to the verification standard document is broken down into multiple sub-tasks; these multiple sub-tasks have dependencies on each other. The verification code is generated based on the task type and parameters corresponding to each subtask.

[0006] Secondly, embodiments of this application provide a verification code generation apparatus, the apparatus comprising: The acquisition module is used to acquire the verification description file of the design under test; the verification description file includes the verification requirements of the design under test. The correction module is used to correct the description file to be verified according to the design specification document and the interface protocol document to obtain the verification standard document; The decomposition module is used to decompose the verification target corresponding to the verification standard document into multiple sub-tasks; the multiple sub-tasks have dependencies. The generation module is used to generate the verification code based on the task type and parameters corresponding to each subtask.

[0007] Thirdly, embodiments of this application provide an electronic device, including: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement the method as described in the first aspect.

[0008] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0009] In this embodiment, the verification requirements of the design under test are revised based on the design specification document and interface protocol document to obtain the verification standard document. Compared with manually compiling and revising the design specification and interface protocol documents, this improves the efficiency of information extraction and revision, while avoiding omissions or misunderstandings caused by manual interpretation, thus solving the problems of low efficiency and poor consistency. Furthermore, the verification target is automatically decomposed into multiple sub-tasks, and verification code is generated according to each sub-task. Through task planning and automatic code generation, no manual writing is required, realizing end-to-end fully automatic conversion from natural language requirements to high-quality verification code, which greatly improves the verification efficiency. Attached Figure Description

[0010] Figure 1 This is a flowchart of a method for generating verification code provided in an embodiment of this application.

[0011] Figure 2 This is a flowchart illustrating the specific steps of a verification code generation method provided in an embodiment of this application.

[0012] Figure 3 This is a flowchart of another method for generating verification code provided in an embodiment of this application.

[0013] Figure 4 This is a schematic diagram of a verification code generation system provided in an embodiment of this application.

[0014] Figure 5 This is a schematic diagram of a demand definition domain standardization domain provided in an embodiment of this application.

[0015] Figure 6 This is a schematic diagram of a verification framework for normal operation and execution domain provided in an embodiment of this application.

[0016] Figure 7This is a schematic diagram of a verification process inspection and review domain provided in an embodiment of this application.

[0017] Figure 8 This is a block diagram of a verification code generation device provided in an embodiment of this application.

[0018] Figure 9 This is a block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0020] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0021] With the dramatic increase in the complexity of integrated circuit design, chip verification has become a critical link restricting product development cycles. Universal Verification Methodology (UVM), as the industry's mainstream verification methodology, improves the reusability of verification components through a standardized framework. However, building a complete UVM verification environment remains a highly complex, repetitive, and time-consuming task. It requires technical personnel to have a deep understanding of design specifications, verification plans, and UVM coding standards, and to manually write massive amounts of code, demanding a high level of skill. For example, the verification platform code for a top-level System-on-Chips (SoC) can reach millions of lines, making manual development and maintenance extremely costly.

[0022] Currently, the industry has explored using scripts and templates to assist in generating some verification code. However, these methods are often inflexible, unable to understand high-level verification intent, and struggle to handle complex requirement changes and the integration of heterogeneous modules. Furthermore, quality control in the verification process, such as checkpoint setting and standardization, still heavily relies on engineers' personal experience, lacking systematic automation. In existing technologies, UVM verification environments still heavily depend on engineers' manual coding based on their personal experience, resulting in low efficiency and a lack of systematic automation.

[0023] To address the aforementioned issues, this application provides a method, apparatus, device, and storage medium for generating verification codes. The method for generating verification codes provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0024] Figure 1 This is a flowchart of a verification code generation method provided in an embodiment of this application. The method includes the following steps.

[0025] Step 101: Obtain the verification description file of the design under test.

[0026] In this application embodiment, the description file to be verified includes a description of the verification requirements of the Design under Test (DUT).

[0027] In some embodiments, the design under test is received from the user through an interactive interface of an agent that integrates a Large Language Model (LLM).

[0028] In some embodiments, the description file to be verified includes the verification target, concerns, and scenarios described in natural language.

[0029] For example, the description file to be verified could be "to verify the read and write functions of the Advanced eXtensible Interface (AXI) main interface, especially burst transmissions", or "to test the data transmission and reception of the Serial Peripheral Interface (SPI) module in normal and loopback modes". The description file to be verified could also be "to focus on checking the priority response mechanism of the interrupt controller when multiple interrupt sources are triggered simultaneously".

[0030] In other embodiments, the description file to be verified also includes a verification plan entered as a mind map, which includes the organization and relationship of test points.

[0031] For example, the central node of the mind map is "SoC module verification", and the first-level branches may be "AXI bus verification", "SPI communication verification", "power management verification", etc. Each branch is further subdivided into specific functional points, test scenarios and points of concern.

[0032] Step 102: Revise the description file to be verified according to the design specification document and interface protocol document to obtain the verification standard document.

[0033] In this embodiment, the agent (LLMAgent) integrated with a large language model has a built-in dedicated knowledge base for UVM verification and chip interface protocols, which makes its understanding of technical terms and rules more accurate.

[0034] In some embodiments, the LLM Agent performs cross-comparison of the description file to be verified based on the design specification document and the interface protocol document to obtain the verification result; if the verification result is that the verification fails, the description file to be verified is corrected to obtain the verification standard document.

[0035] In some embodiments, the verification standard document adopts a lightweight data exchange format (JavaScript Object Notation, JSON) or a domain-specific language (DSL) format. The verification standard document includes a feature list, interface signal mapping relationships, test scenarios, coverage targets, and protocol version information.

[0036] In this embodiment of the application, the function list includes a list of all functions of the DUT that need to be verified, the interface signal mapping relationship includes the mapping relationship between the signals of the virtual interface in the verification environment and the physical signals of the DUT, the test scenario includes normal scenario and abnormal scenario, the coverage target is used to quantify the standard of verification completion, and the protocol version information includes the referenced interface protocol standard version.

[0037] For example, the feature list could include AXI burst write, SPI mode 0 communication, interrupt priority arbitration, etc. The interface signal mapping could be: the axi_if.awaddr signal in the verification environment should be connected to the u_dut.awaddr signal at the top level of the DUT. Test scenarios include: first sending 10 random AXI write transactions, then sending an invalid transaction of incorrect length, and checking if the DUT returns a correct error response. The coverage target could be that functional coverage must reach 100%, or code line coverage must be no less than 95%. Protocol version information could be AMBA AXI version 4.2.

[0038] In this way, the verification standard document adopts a specific format and contains multiple contents for quality assessment, which improves the efficiency of subsequent parsing and thus improves the efficiency of subsequent verification code generation.

[0039] In some embodiments, an agent integrating a large language model modifies the description file to be verified based on the design specification document and the interface protocol document to obtain a verification standard document.

[0040] Step 103: Decompose the verification objective corresponding to the verification standard document into multiple sub-tasks.

[0041] In the embodiments of this application, multiple subtasks are dependent on each other.

[0042] In some embodiments, step 103 may include: generating a task dependency graph comprising multiple subtasks based on a general verification methodology architecture and verification standard documents; wherein the task dependency graph comprises task nodes for generating various verification intellectual property core proxies, register models, test sequences and top-level test platforms, and the multiple subtasks have temporal and parallel relationships.

[0043] In one possible implementation, following the UVM hierarchy and validation standard documentation, the validation objective is broken down into independent first-level tasks; each first-level task is further broken down into subtasks of the smallest granularity; each subtask performs only one function and is functionally independent; based on the subtask dependencies within the same task group and the subtask dependencies between different task groups, the dependencies are transformed into a directed acyclic graph, resulting in a task dependency graph. In this graph, nodes represent subtasks, and directed edges represent dependencies.

[0044] In some embodiments, after step 103, the method for generating the verification code may further include: dynamically scheduling and executing each subtask according to the task dependency graph; and parallelizing the subtasks that do not have dependencies to optimize the generation efficiency.

[0045] For example, based on the task graph generated by the overall planning module, each subtask is dynamically scheduled and executed. The task queue is managed; dependencies between tasks are handled; and parallelizable tasks are executed concurrently, such as generating multiple agents with independent interfaces simultaneously to optimize generation efficiency.

[0046] Step 104: Generate verification code based on the task type and parameters corresponding to each subtask.

[0047] In some embodiments, a parameterized verification template is called from a preset code template library according to the type and parameters of the subtask, and the corresponding protocol details are queried from a protocol knowledge base; the template and protocol details are combined to generate verification code.

[0048] In some embodiments, after step 104, the above-mentioned method for generating verification code may further include: instantiating the verification code according to the hierarchical architecture of a general verification methodology, completing the transaction-level communication connection and signal interaction mapping between components, and obtaining a test platform file, a component packaging file, and a virtual interface mapping; the virtual interface mapping code is used to realize the signal connection between the verification component and the port of the design under test; and generating a verification project that can be used to call electronic design automation tools based on the test platform file, the packaging file, and the virtual interface mapping.

[0049] In summary, in this embodiment, the verification requirements of the design under test are revised based on the design specification document and interface protocol document to obtain the verification standard document. Compared with manually compiling and revising the design specification and interface protocol documents, this improves the efficiency of information extraction and revision, while avoiding omissions or misunderstandings caused by manual interpretation, thus solving the problems of low efficiency and poor consistency. Furthermore, the verification target is automatically decomposed into multiple sub-tasks, and verification code is generated according to each sub-task. Through task planning and automatic code generation, no manual writing is required, realizing end-to-end fully automatic conversion from natural language requirements to high-quality verification code, which greatly improves verification efficiency.

[0050] Figure 2 This is a flowchart illustrating the specific steps of a verification code generation method provided in an embodiment of this application. The method includes the following steps.

[0051] Step 201: Obtain the verification description file of the design under test.

[0052] The method for this step has been explained in step 101 above, and will not be repeated here.

[0053] Step 202: By integrating the large language model to parse the design specification document and interface protocol document, extract the function point list, interface signal list, timing rules and abnormal scenario descriptions, and generate a system verification checklist.

[0054] In this embodiment of the application, the design specification document and interface protocol document can be uploaded through the system interaction interface, supporting the uploading of design specification documents and interface protocol documents in formats such as Portable Document Format (PDF), plain text format (Word), and text document (TXT).

[0055] In some embodiments, a design specification document is used to describe the functionality, performance, and architecture of the DUT itself. The design specification document includes the DUT's internal architecture, register definitions, and performance metrics.

[0056] For example, for a Graphics Processing Unit (GPU), the design specification document describes which image formats the GPU supports for encoding and decoding, the supported resolutions, rendering features, etc.

[0057] In some embodiments, the interface protocol document is used to describe the rules for how the DUT communicates with other external components through input / output pins. The interface protocol document includes a signal list, timing diagram and timing rules, transaction types and processes, and error handling mechanisms, etc.

[0058] For example, the interface protocol document can be the high-speed serial computer extended bus standard (peripheral component interconnect express, PCIe), or it can be the AXI (Advanced deXtensible Interface) bus format.

[0059] In some embodiments, an agent integrated with a Large Language Model (LLM) parses the design specification document to extract a list of functional points, boundary conditions, and abnormal scenario descriptions of the design under test; an agent integrated with an LLMA agent parses the interface protocol document to extract a list of interface signals, timing rules, and protocol-level abnormal scenarios; and a system verification checklist is generated based on the list of functional points, boundary conditions, abnormal scenario descriptions, interface signal list, timing rules, and protocol-level abnormal scenarios of the design under test. The system verification checklist can be in JSON format.

[0060] For example, the list of functional points of the design under test includes core functions, sub-module functions, register configuration functions, etc.; the extracted boundary conditions include data bit width limits, transmission rate thresholds, voltage operating ranges, etc.; the extracted abnormal scenario descriptions include reset anomalies, communication timeouts, data verification errors, etc.; the extracted interface signal list includes attributes such as signal name, direction, bit width, and default value; the extracted timing rules include signal interaction order, setup time, hold time, handshake mechanism, etc.; and the extracted protocol-level abnormal scenarios include burst transmission length errors, bus arbitration conflicts, response error code definitions, etc.

[0061] Step 203: Cross-compare the description file to be verified with the system verification checklist to verify whether there are any missing functional points, defective boundary conditions, or incomplete abnormal scenarios in the description file to be verified.

[0062] In some embodiments, the LLM Agent converts user input in natural language or mind map format into structured data.

[0063] In some embodiments, the verification description file is checked to see if it covers all functionalities in the list and to identify any missing items; the verification description file is checked to see if it explicitly defines all boundary parameters and to identify any missing definitions; and the verification description file is checked to see if it contains all abnormal test scenarios in the list and to identify any incomplete items.

[0064] In one possible implementation, each function point in the system verification list is traversed, and each function point is checked to see if it appears in the function point list of the description file to be verified. If any function point does not appear in the function point list of the description file to be verified, that function point is treated as an omission.

[0065] In one possible implementation, the boundary parameter descriptions for the same functional point in the description file to be verified are compared with those in the system verification list; it is determined whether the description file to be verified has defined the boundary parameters mentioned in the list; if the boundary parameters mentioned in the list have been defined, it is determined whether the parameter values ​​conform to the protocol specification; if they do not conform to the protocol specification, there are missing definitions; if they conform to the protocol specification, there are no missing definitions.

[0066] In one possible implementation, each exception scenario in the system verification list is traversed, and each exception scenario is checked to see if it is mentioned in the description file to be verified. If any exception scenario is not mentioned in the description file to be verified, the exception scenario is treated as an incomplete item.

[0067] Step 204: If there are missing function points, defective boundary conditions, or incomplete abnormal scenarios in the description file to be verified, correct the description file to be verified to obtain the verification standard document.

[0068] In some embodiments, upon user confirmation or supplementary information, the agent automatically corrects the description file to be verified, filling in missing functional points, boundary conditions, and abnormal scenarios; and transforms the corrected description file to be verified into a standardized verification standard document.

[0069] In some embodiments, the verification standard document is in JSON or a domain-specific language format, and includes a feature list, interface signal mapping relationships, test scenarios, coverage targets, and protocol version information.

[0070] The above technical solution, through a large language model, quickly extracts key information from design specification documents and interface protocol documents, generating a structured system verification checklist. Compared to manually reading and organizing design specifications and interface protocol documents page by page, this improves the efficiency of information extraction and avoids omissions or misunderstandings caused by manual interpretation. Furthermore, through cross-comparison of functional points, boundary conditions, and abnormal scenarios, the system automatically identifies defects in the description documents to be verified and generates a difference report. Compared to manual comparison, this improves comparison efficiency and ensures the completeness of verification requirements.

[0071] In some embodiments, step 204 includes sub-steps 2041 to 2043.

[0072] Sub-step 2041: If there are missing function points, defective boundary conditions, or incomplete abnormal scenarios in the description file to be verified, identify the difference information between the description file to be verified and the system verification list.

[0073] Sub-step 2042: Generate and output a difference report based on the difference information; the difference report includes the difference type, the difference location, and the protocol basis for the difference.

[0074] Sub-step 2043: Receive user confirmation and supplementary information based on the difference report, revise the description file to be verified, and generate a structured verification standard document.

[0075] In one possible implementation, before sub-step 2041, the generation of the above verification code may also include: converting the description file to be verified into a JSON structured format consistent with the system verification list, wherein the description file to be verified includes three core fields: function_points, boundary_conditions, and exception_scenarios.

[0076] In one possible implementation, sub-step 2041 includes: checking whether the description file to be verified contains all the functional points in the system verification list, and marking any missing functional points; checking whether the boundary parameters of the description file to be verified are complete and whether their values ​​conform to the protocol specifications, and marking any missing or incorrect boundary conditions; checking whether the description file to be verified covers all the abnormal scenarios in the list, and marking any undefined abnormal test points; and generating discrepancy information based on the missing functional points, missing parameters, incorrect parameter boundary conditions, and abnormal test points.

[0077] In one possible implementation, sub-step 2042 includes: generating a difference report based on the heterogeneous type, the location of the difference, and the protocol basis for generating the difference; and displaying the difference report through a visual interface.

[0078] In one possible implementation, the discrepancy report is displayed through a visual interface, including: pushing the discrepancy report to the user interface and displaying multiple operation options; the multiple operation options include confirming the discrepancy, supplementing the requirements, and rejecting the discrepancy.

[0079] In one possible implementation, the system receives supplementary information from the user regarding any missing differences, or receives confirmation from the user that some differences are not necessary verification items.

[0080] In one possible implementation, sub-step 2043 includes: supplementing missing fields in the description file to be verified based on the supplementary information input by the user; generating and archiving notes for non-essential differences confirmed by the user; and generating the final verification standard document from the corrected description file to be verified according to a preset template.

[0081] Through the above technical solutions, when there are missing functional points, defective boundary conditions, or incomplete abnormal scenarios in the description file to be verified, the difference information is identified and a difference report is output, which improves the accuracy of difference identification and reduces omissions or misjudgments. Secondly, the introduction of a user confirmation mechanism not only improves the accuracy of the verification standard document, but also allows users to supplement their requirements only, greatly saving the understanding cost. Finally, the generation of a structured, machine-readable verification standard document is conducive to the subsequent automated generation of verification code, thereby improving code generation efficiency.

[0082] Step 205: Decompose the verification objective corresponding to the verification standard document into multiple sub-tasks.

[0083] In the embodiments of this application, multiple subtasks are dependent on each other.

[0084] The method for this step has been explained in step 103 above, and will not be repeated here.

[0085] Step 206: Based on the task type and parameters corresponding to each subtask, call the parameterized verification template from the preset code template library.

[0086] In some embodiments, the task type corresponding to each subtask determines which template to use, and the parameters corresponding to each subtask determine the specific values ​​and names that need to be filled in the template.

[0087] For example, task types include: AXIMasterAgent generation, SPISlaveMonitor generation, interrupt exception scenario sequence generation, etc., and task parameters include: AXI interface bit width 32bit, SPI clock frequency 50MHz, interrupt signal name irq_out, etc.

[0088] In some embodiments, the code template library stores parameterized templates such as UVMDriver, Monitor, Sequencer, and Agent, with reserved placeholders for protocol-related information in the templates.

[0089] For example, the task type corresponding to the subtask is to generate AXIMasterAgent, and the parameters corresponding to the subtask are AXI4 and 32-bit width. The AXIDriver parameterization template, AXIMonitor parameterization template, and AXIAgent parameterization template are matched and called from the code template library.

[0090] Step 207: Query the corresponding interface protocol details from the preset protocol knowledge base, fill the protocol details into the verification template, and generate verification code.

[0091] In this embodiment of the application, the interface protocol details include the signal list, timing logic, and abnormal scenario handling rules of the interface protocol.

[0092] In some embodiments, the protocol knowledge base stores signal lists, timing logic, and abnormal scenario handling rules for protocols such as AXI4, AHB, and APB.

[0093] In some embodiments, the signal list corresponding to the AXI4 protocol includes: the name, direction, and bit width of signals such as write address (AWADDR), write data channel (write data), and response valid (BVALID); the timing logic includes: after AWVALID is valid, it is necessary to wait for AWREADY to go high before sending the next address; the abnormal scenario handling rules include: when the AXI burst length exceeds the limit, the Driver needs to stop transmission and report an error.

[0094] In some embodiments, the corresponding interface protocol details are queried from a preset protocol knowledge base, and combined with the specific parameters of the current subtask, the protocol details are filled into the corresponding placeholders in the verification template; wherein, the specific parameters include interface bit width, clock frequency, etc.

[0095] For example, for the "Generate AXI Master Agent" subtask, the subtask parameter specifies a bit width of 32 bits. The system will then query the 32-bit signal list and timing rules of the AXI4 protocol from the protocol knowledge base and populate them into the field defining the data width in the uvm_driver template to generate complete executable code.

[0096] The above technical solution calls parameterized verification templates from a pre-set code template library and reuses a pre-built general UVM framework, eliminating the need to repeatedly write code corresponding to general logic and improving code generation efficiency. It also queries the corresponding interface protocol details from a pre-set protocol knowledge base. Since the signal list, timing logic, and exception handling rules in the protocol knowledge base are all from standardized protocol specifications, it reduces the deviation caused by manual interpretation of the protocol, improves the accuracy of the code, and significantly reduces the debugging cost of the simulation process.

[0097] Step 208: Following the hierarchical architecture of the general verification methodology, instantiate and connect the verification code to assemble the verification framework.

[0098] In some embodiments, the hierarchical component architecture of the Universal Verification Methodology (UVM) includes, from top to bottom: test, env, agent, driver / monitor / sequencer, and interface.

[0099] In some embodiments, the system creates instances for each component that needs to be used in the top-level test platform file. For example, if the DUT has an AXI master interface and an SPI slave interface, the system will create two instances: an axi_master_agent instance and an spi_slave_agent instance.

[0100] In this embodiment, the component instances do not work in isolation; they interact with each other for data and transactions through standard communication ports. Connection refers to interfacing these communication ports to ensure unimpeded data and control flow.

[0101] In some embodiments, UVM's Transaction-Level Modeling (TLM) mechanism is used to connect multiple component instances after the verification code is instantiated. For example, the sequencer connects the seq_item_export port of the sequencer to the seq_item_port port of the driver, so that test sequences can be sent from the sequencer to the driver.

[0102] In some embodiments, multiple component instances instantiated from the verification code are connected through a virtual interface. For example, the physical signal interface of the DUT (such as axi_if) is associated with the corresponding virtual interface in the verification environment, so that the driver can drive the signal and the monitor can monitor the signal.

[0103] In this embodiment, the assembled verification framework contains all the necessary components, and the correct relationships between the components have been established, forming an organic whole. At this point, the verification environment is structurally complete and ready to receive test sequences and begin simulation.

[0104] Step 209: Create a standardized project directory structure and automated execution scripts based on the verification framework to generate verification projects that can be used for simulation.

[0105] In some embodiments, the project directory structure is a standard folder structure used to categorize and place all generated and assembled code files into corresponding directories. For example: / tb / agents, / tb / tests, / tb / seq_lib, etc.

[0106] In some embodiments, a standardized project directory structure is constructed, which includes a component proxy directory, a sequence library directory, a test case directory, a top-level file directory, and a script directory; an automated execution script matching the project directory structure is generated; and a verification project delivery package that can be immediately used for simulation is packaged based on the project directory structure and the automated execution script.

[0107] It's important to note that the verification framework encompasses all components of the entire verification environment and the hierarchical relationships between them. Building a standardized project directory structure essentially maps the logical hierarchy of the verification framework to the physical directory hierarchy of the file system. Automated execution scripts are used to identify and drive the entire verification framework, achieving full automation from environment setup to simulation execution.

[0108] In this embodiment, the compilation script is generated based on the component dependencies of the verification framework. The compilation order of files in the script must correctly reflect the hierarchy of the verification framework. For example, the base package and interface definitions are compiled first, followed by the underlying components (driver, monitor), and finally the upper-level environment (env, test) and test cases. The script automatically traverses the project directory structure to find all source files that need to be compiled.

[0109] In this embodiment of the application, the simulation run script receives the test case name specified by the user, calls the simulator to load the compiled image of the entire verification framework, and specifies the test to be run through the +UVM_TESTNAME parameter of UVM, thereby starting the simulation of the verification framework; wherein, the test case name corresponds to a specific test class in the verification framework.

[0110] In this embodiment, the top-level encapsulation script is used to provide users with a single entry point to sequentially execute the compilation and simulation scripts contained in the verification framework, thereby driving the entire verification framework from a code state to an executable simulation task.

[0111] In one possible implementation, building a standardized project directory structure includes: creating a root directory that includes a verification platform directory, a script directory, a simulation directory, and a design under test directory; creating multiple subdirectories under the verification platform directory to store verification agents, test sequences, test cases, and reference models respectively; and storing the generated verification component code files in the multiple subdirectories according to their types.

[0112] In one possible implementation, generating automated run scripts that match the project directory structure includes: generating a compilation script that calls electronic design automation tools to compile the design under test code and all verification platform code in the correct dependency order; generating a simulation run script that calls the simulator, loads the compilation results, and specifies test cases to start the simulation; and generating a top-level encapsulation script that provides the user with a single command-line interface to execute the compilation and simulation operations sequentially.

[0113] In one possible implementation, based on the project directory structure and the automated execution scripts, a verification project delivery package that is ready to be used for simulation is generated. This package includes: an organized directory structure, all code files, automated scripts, and a brief README.md usage documentation, all packaged into a complete verification project package.

[0114] The above technical solution automatically completes component instantiation, parameter configuration, port connection, and interface mapping according to the UVM hierarchical architecture, eliminating the need for manual coding and significantly shortening the setup time of the verification environment. Furthermore, components in the standardized directory can be directly copied to other projects without modifying the core verification framework, enabling flexible expansion and adaptation to different application scenarios.

[0115] In some embodiments, after step 207, the method for generating the verification code described above may execute steps 208 to 209, see [link to relevant documentation]. Figure 3 The method for generating the above verification code can also be implemented by steps 301 to 303.

[0116] Step 301: Obtain the input custom check items and the check items generated according to the validation standard document.

[0117] In some embodiments, custom check items can be checkpoints, check targets, check tasks, and pass criteria that are manually entered by the user at key nodes.

[0118] In the embodiments of this application, a checkpoint represents a specific object or code location that needs to be checked; a check target represents the desired check purpose; a check task represents the specific operation required to achieve the check target; and a standard represents the criteria for judging whether the check is successful.

[0119] For example, a user-specified custom check item could be: after the AXI Master Agent is generated, check whether its built-in covergroup covers all AXI channel signals. The checkpoint is that the interface connection is complete; the check task traverses all virtual interfaces, and the standard is that all signals are bound.

[0120] For example, the check items generated according to the verification standard document include: based on the interface signals defined in the verification standard, the check item automatically generates a check to check whether the SPI Agent correctly models the cs_n signal as the output direction.

[0121] In some embodiments, after step 301, the method for generating the above verification code may further include: merging and deduplicating the custom check items and the check items generated according to the verification standard document to form a check standard list, for example, the check standard list is stored in a machine-readable format such as YAML.

[0122] Step 302: Schedule and execute each inspection item, obtain the inspection item execution results, and generate a verification review report.

[0123] In this embodiment of the application, the verification review report includes pass items, warning items, and error items.

[0124] In some embodiments, each entry in the checklist is broken down into a specific, independently executable task; where each entry represents a specific quality requirement standard. For example, checking whether all interface signals are connected is broken down into a task of iterating through and checking each virtual interface instance.

[0125] In some embodiments, scheduling and executing each check item can be done in parallel at critical nodes in code generation, such as checking the code style of an Agent immediately upon its lifetime achievement.

[0126] In other embodiments, scheduling and executing the individual checks can be a centralized, comprehensive check prior to final delivery.

[0127] In some embodiments, different tools are invoked to execute each check item, and the check item execution results are obtained.

[0128] In some embodiments, after each check item is executed, a corresponding check result is generated, which includes pass, warning, and error; based on the check result, each check item is classified as a pass item, a warning item, or an error item.

[0129] In one possible implementation, this is achieved by indicating compliance with the inspection criteria.

[0130] In one possible implementation, a warning indicates a potential problem or non-mandatory specification not being met, suggesting optimization, such as inconsistent code formatting.

[0131] In one possible implementation, an error indicates a serious problem that causes functional errors and must be fixed, such as a signal not being connected.

[0132] The above technical solutions enable real-time checks during code generation, preventing issues from lingering and reducing repair costs. Secondly, the combination of custom check items and verification standards reduces reliance on personal experience and ensures code and quality consistency. Finally, the verification review report provides feedback on the check item execution results, introducing a correction mechanism during code generation and significantly improving the reliability and trustworthiness of the final verification environment.

[0133] In some embodiments, step 302 includes sub-steps 3021 to 3023.

[0134] Sub-step 3021 involves using static code analysis tools, rule verification scripts, and formal verification tools to execute each check item, distinguish and record the pass items, warning items, and error items of the verification code.

[0135] Sub-step 3022: Mark the file location and repair suggestions for each error item.

[0136] Sub-step 3023: Organize the passed items, warning items, and error items according to the preset format to generate a structured verification review report.

[0137] In one possible implementation, each check item is executed using a static code analysis tool, a rule verification script, and a formal verification tool, including: selecting at least one check tool from the static code analysis tool, the rule verification script, and the formal verification tool based on the checkpoints, check objectives, check tasks, and pass criteria of each check item; and invoking the check tool to execute the check item.

[0138] In one possible implementation, static code analysis tools are used to check whether the code syntax and style conform to the specifications; custom rule verification scripts are used to verify the code naming conventions, comment completeness, virtual interface binding, and file structure compliance; and formal verification tools are used to verify the protocol timing compliance, exception handling logic validity, and to provide rigorous mathematical proofs for certain key properties.

[0139] For example, when the check item is to check the definition and syntax validity of variables, the checkpoint is to check whether all variables are defined before use; the check targets are axi4_master_driver.sv and axi4_transaction.sv; the check task is to perform syntax parsing and symbol table construction on System Verilog; the passing criterion is to output 0 Errors. A static analysis tool is selected as the check tool to execute the check item. That is, the static analysis tool is called to perform syntax parsing and symbol table construction on the System Verilog code, traversing all assignments and references to determine if variables are used without being defined; if the tool outputs 0 Errors, the check result is considered passed.

[0140] For example, when the check item is variable naming conventions, the checkpoint is to check whether the variable names conform to the convention of combining lowercase and underscores. The check target is all signals, member variables, and local variables in .sv files. The check tasks include matching identifiers and filtering keywords. The passing criterion is that the script outputs a violation count of 0. A rule validation script is selected as the checking tool to execute the check item. That is, the rule validation script is called to match identifiers using regular expressions, filter keywords, and check whether the name starts with an uppercase letter, contains camelCase, or violates the project naming convention. If the script outputs a violation count of 0, the check result is considered passed.

[0141] In one possible implementation, the static code analysis tool can be an Electronic Design Automation (EDA) tool. This tool can be invoked to perform code syntax checks, manage generated files using a version control system, or execute preprocessing commands using a script engine.

[0142] In one possible implementation, the verification code is distinguished and recorded as pass, warning, and error items, including: parsing the raw output of different tools and converting it into a unified format of check results; and classifying the check results of each check item into pass, warning, and error items according to preset classification rules.

[0143] In one possible implementation, the file path, file name, and line number of the error item are extracted by parsing the output information of static code analysis tools, rule verification scripts, and formal verification tools; the file path, file name, and line number are then labeled as the file location corresponding to the error item.

[0144] One possible implementation involves determining remedial recommendations based on the error type and context. For example, if a signal indicating a connection failure is detected, the recommendation could be: Check if the vif interface of axi_agent in the top-level test platform has been assigned a value.

[0145] In one possible implementation, the default format could be Hyper Text Markup Language (HTML), PDF, or Lightweight Markup Language (Markdown).

[0146] In one possible implementation, pass / fail, warning, and error items are populated into a pre-formatted report template; the populated report template is then rendered according to user configuration or default settings to obtain a verification review report.

[0147] In one possible implementation, the pass rate, error, and warning distribution are displayed in chart form in the validation review report; each error is categorized by severity or module in the validation review report, and includes a description, file location, and remediation suggestions.

[0148] Through the above technical solutions, different inspection tools are selected for different problems, making full use of the advantages of different inspection tools to improve the efficiency and accuracy of inspection; secondly, precise file locations and repair suggestions are provided, which is conducive to subsequent targeted adjustments based on file locations and repair suggestions, thus improving debugging efficiency; finally, the results of each inspection item are organized according to a preset format to generate a unified format review report, making the results of the inspection items visible and ensuring the objectivity and consistency of quality assessment.

[0149] Step 303: If there are errors in the inspection results, adjust the parameters of the subtasks and regenerate the verification code according to the verification review report until all inspection items pass.

[0150] In some embodiments, the error items in the report are parsed to locate the specific subtask that caused the error; the cause of the error is analyzed and the input parameters of the subtask are adjusted; the step of generating verification code according to the task type and parameters corresponding to each subtask is re-executed; the relevant check items are executed again to verify whether the problem has been resolved; the above steps are iterated until all check items pass.

[0151] For example, the error is that the AXI signal awaddr is not connected, which relates to the task in the "Output Assembly Layer" that connects to AXIAgent. The virtual interface mapping is corrected; then the subtask and its downstream dependent tasks are rescheduled and executed to generate the corrected code; finally, the relevant checks are executed again to verify that the problem has been resolved. This process is repeated until all checks pass.

[0152] In some embodiments, it is determined whether the root cause of the error is that the input parameters used when generating a certain subtask are inaccurate or incomplete; based on the adjusted parameters, the relevant subtask is rescheduled and executed.

[0153] For example, if the error is that a certain signal of the AXI Agent is not connected, it is located in the subtask of generating the AXI Master Agent, where an error occurred in the connection step of the output assembly layer.

[0154] For example, if the error is that a register is missing in the register model, it is determined that the omission occurred when parsing the design document, resulting in incomplete input parameters for generating the register model subtask.

[0155] In some embodiments, after the code is regenerated, the same checks are performed on the corrected code; a new report is generated, showing the corrected results and determining whether there are still errors in the new report; if there are still errors, the process returns to perform parameter adjustments for the subtasks based on the verification review report, and performs a new round of parameter adjustments and regeneration; if all checks pass, the loop terminates, and the verification project is obtained.

[0156] By introducing a feedback adjustment process into the code generation process through the above technical solution, when a serious problem occurs that leads to functional errors or simulation failure, the verification code is regenerated, which significantly reduces the workload of manual debugging and project risks.

[0157] In summary, in this embodiment, firstly, by using a large language model, key information in design specification documents and interface protocol documents is quickly extracted to generate a structured system verification checklist. Compared to manually reading and organizing design specifications and interface protocol documents page by page, this improves the efficiency of information extraction and avoids omissions or misunderstandings caused by manual interpretation. Secondly, parameterized verification templates are called from a preset code template library, and corresponding interface protocol details are queried from a preset protocol knowledge base. A pre-built general UVM framework is reused, eliminating the need to repeatedly write code corresponding to general logic, reducing deviations caused by manual protocol interpretation, and improving code generation efficiency. Thirdly, real-time checks are performed during the verification code generation process. A check mechanism combining custom check items and verification standards is adopted, reducing reliance on personal experience, preventing problems from being left over to later stages, and reducing repair costs. Finally, the verification review report provides feedback on the execution results of the check items, introducing a correction mechanism in the verification code generation process, which significantly improves the reliability and trustworthiness of the final verification environment.

[0158] Figure 4 This is a schematic diagram of a verification code generation system provided in an embodiment of this application. The verification code generation system consists of three main functional domains and a total of sixteen levels. For example... Figure 4As shown, the three functional domains include the requirements definition domain, the standardization domain, the verification framework normalization and execution domain, and the verification process inspection and review domain. The requirements definition and standardization domain generates an authoritative, structured verification standard document for the verification framework normalization and execution domain, based on the verification requirements and design specifications of the design under test. The verification framework normalization and execution domain receives the verification standard document, allocates resources from the code template library and protocol knowledge base, utilizes templates and protocol knowledge to automatically generate all verification code, assembles it into a complete environment, and outputs a verification project that can be used for simulation. The verification process inspection and review domain generates a verification review report and provides feedback on the verification results based on the task graph output by the verification framework normalization and execution domain and the initial input verification requirements of the design under test.

[0159] In some embodiments, see Figure 5 The standardization domain of the requirement definition domain includes: the verification requirement interaction layer, the proxy document parsing layer, the requirement alignment layer, and the verification standard output layer.

[0160] In some embodiments, the verification requirement interaction layer receives verification plans, scenario descriptions, and key functional points input by the user in natural language or mind map form. The proxy document parsing layer parses design specification documents and interface protocol documents using an integrated large language model, extracting a list of functional points, a list of interface signals, timing rules, and descriptions of abnormal scenarios to generate a system verification checklist. The requirement alignment layer cross-compares the description file to be verified with the system verification checklist to verify whether there are any missing functional points, boundary condition defects, or incomplete abnormal scenarios in the description file; if so, it identifies the differences between the description file and the system verification checklist. The report generation unit generates a difference report based on the difference information. The verification standard output layer outputs the difference report; receives requirement confirmation and supplementary information input by the user based on the difference report, corrects the description file to be verified, and generates a structured verification standard document.

[0161] In some embodiments, see Figure 6 The verification framework's normal operation and execution domain includes an overall planning module, a task scheduling module, a code generation module, a tool invocation module, an output assembly layer, and a delivery layer.

[0162] In some embodiments, the overall planning module is used to decompose the verification objective corresponding to the verification standard document into multiple sub-tasks. The task scheduling module is used to dynamically schedule and execute each sub-task according to the task dependency graph; to parallelize sub-tasks without dependencies to optimize generation efficiency; to manage the task queue, handle dependencies between tasks, and concurrently execute parallelizable tasks. The code generation module is used to generate verification code according to the task type and parameters corresponding to each sub-task. The tool invocation module is used to invoke EDA tools for code syntax checking, invoke the version control system to manage the generated files, or invoke the script engine to execute preprocessing commands. The output assembly layer is used to instantiate and connect the verification code according to the hierarchical architecture of the general verification methodology to assemble the verification framework. The delivery layer is used to create a standardized project directory structure and automated execution scripts according to the verification framework to generate a verification project that can be used for simulation.

[0163] In some embodiments, see Figure 7 The verification process inspection and review domain includes the verification inspection interaction layer, the proxy inspection parsing layer, the standardization layer, the inspection task decomposition layer, the inspection task execution layer, and the verification review layer.

[0164] In some embodiments, the verification check interaction layer is used to obtain custom check items as input; the proxy check parsing layer is used to generate check items based on the verification standard document. The standard unification layer is used to merge and deduplicate the custom check items and the check items generated based on the verification standard document to form a check standard list. The check task decomposition layer is used to schedule and execute each check item to obtain the check item execution results. The verification review layer is used to generate a verification review report; the verification review report includes pass items, warning items, and error items.

[0165] In some embodiments, each of the 16 layers contains at least one agent. For layers with more complex functions, sub-agents should also be included to process relatively independent tasks in parallel. Each sub-agent in the system is a functionally independent, independently executable atomic unit. Each agent is responsible for only a single core function, with no functional coupling, and can run independently of the cluster. At the same time, it supports the combination of multi-level agents into clusters and multiple clusters into a working domain.

[0166] In some embodiments, the agents establish standardized working and invocation rules for the agent cluster based on a unified interaction template. For example, different agents all receive instructions / data in the unified interaction template format; all generate feedback in the "unified interaction template" format, and the output file structure (such as JSON / DSL) is consistent; all communicate through fixed interaction_types such as "REQUEST / RESPONSE / FEEDBACK".

[0167] In summary, this application's embodiments, through a hierarchical, fully automated generation system and method based on LLM Agents, liberate verification engineers from tedious and repetitive code writing, saving over 96% of platform setup time and significantly reducing the amount of test code. Secondly, even teams with limited UVM experience can generate high-quality, standardized verification code that conforms to best practices, reducing human error. Thirdly, leveraging requirements understanding, intelligent planning, and self-checking capabilities, it can adapt to different designs and protocols and quickly adjust the generated verification environment according to specification changes, exhibiting strong flexibility and maintainability. Finally, by introducing independent inspection and review domains, quality control is embedded within the automated process, ensuring traceability and correctness from requirements to code, thereby improving the overall reliability of verification.

[0168] Figure 8 This is a block diagram of a verification code generation apparatus provided in an embodiment of this application, such as... Figure 8 As shown, the verification code generation device 500 includes the following modules.

[0169] The acquisition module 501 is used to acquire the verification description file of the design under test; the verification description file includes the verification requirements of the design under test. The correction module 502 is used to correct the description file to be verified according to the design specification document and the interface protocol document to obtain the verification standard document; The decomposition module 503 is used to decompose the verification target corresponding to the verification standard document into multiple sub-tasks; the multiple sub-tasks have dependencies. The generation module 504 is used to generate verification code based on the task type and parameters corresponding to each subtask.

[0170] Optionally, the correction module 502 includes: The document parsing submodule is used to parse design specification documents and interface protocol documents by integrating a large language model, extracting function point lists, interface signal lists, timing rules and abnormal scenario descriptions, and generating a system verification checklist. The comparison submodule is used to cross-compare the description file to be verified with the system verification checklist to verify whether there are any missing functional points, defective boundary conditions, or incomplete abnormal scenarios in the description file to be verified. The correction submodule is used to correct the description file to be verified to obtain the verification standard document when there are missing function points, defective boundary conditions, or incomplete abnormal scenarios in the description file to be verified.

[0171] Optional, the correction submodule includes: The difference identification unit is used to identify the difference information between the description file to be verified and the system verification checklist when there are missing function points, defective boundary conditions or incomplete abnormal scenarios in the description file to be verified. The report generation unit is used to generate and output a difference report based on the difference information; the difference report includes the difference type, the difference location, and the protocol basis for the difference. The document correction unit is used to receive user confirmation and supplementary information based on the difference report, correct the description file to be verified, and generate a structured verification standard document.

[0172] Optionally, the generation module 504 includes: The template call submodule is used to call parameterized verification templates from a preset code template library based on the task type and parameters corresponding to each subtask. The protocol filling submodule is used to query the corresponding interface protocol details from the preset protocol knowledge base, fill the protocol details into the verification template, and generate verification code; the interface protocol details include the signal list, timing logic and abnormal scenario handling rules of the interface protocol.

[0173] Optionally, the verification code generation device 500 further includes: Following the hierarchical architecture of general verification methodologies, the verification code is instantiated and connected to assemble the verification framework. Based on the verification framework, a standardized project directory structure and automated execution scripts are created to generate verification projects that can be used for simulation.

[0174] Optionally, the verification code generation device 500 further includes: The acquisition module is used to acquire the input custom check items and the check items generated based on the validation standard document; The inspection module is used to schedule and execute each inspection item, obtain the inspection item execution results, and generate a verification review report; the verification review report includes pass items, warning items, and error items.

[0175] Optional, the inspection module includes: The execution submodule is used to perform various checks using static code analysis tools, rule verification scripts, and formal verification tools, and to distinguish and record the pass items, warning items, and error items of the verification code. The error annotation submodule is used to annotate the file location and repair suggestions for each error item; The report generation submodule is used to organize the passed items, warning items, and error items according to a preset format to generate a structured verification review report.

[0176] Optionally, the verification code generation device 500 further includes: The regeneration module is used to adjust the parameters of subtasks and regenerate the verification code based on the verification review report when there are errors in the inspection results, until all inspection items pass.

[0177] Optionally, the verification standard document may be in a lightweight data exchange format or a domain-specific language format. The verification standard document may include a list of functions, interface signal mapping relationships, test scenarios, coverage targets, and protocol version information.

[0178] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0179] Figure 9 This is a structural block diagram of an electronic device according to an exemplary embodiment. For example... Figure 9 As shown, the electronic device includes: a processor, a memory, a communication interface, and a communication bus. The processor, the memory, and the communication interface communicate with each other through the communication bus. The memory is used to store at least one executable instruction, which causes the processor to execute the steps of the verification code generation method of the aforementioned embodiment.

[0180] This application also provides a system-on-a-chip, which includes the aforementioned verification code generation device, verification code generation device or electronic device, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0181] This application also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described verification code generation method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0182] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0183] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described verification code generation method embodiment and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0184] This application also provides a computer program product, including a computer program, and a method for generating verification code implemented when the computer program is executed by a processor.

[0185] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0186] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, embodiments of the present invention can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0187] Embodiments of the present invention are described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0188] These computer program instructions may also be stored in a computer-readable storage medium capable of directing a computer or other programmable data processing terminal device to operate in a predictive manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0189] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0190] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0191] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0192] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method of generating a verification code, characterized by, The method includes: Obtain the verification description file of the design under test; the verification description file includes the verification requirements of the design under test. The description file to be verified is revised according to the design specification document and interface protocol document to obtain the verification standard document; The verification objective corresponding to the verification standard document is broken down into multiple sub-tasks; these multiple sub-tasks have dependencies on each other. The verification code is generated based on the task type and parameters corresponding to each subtask.

2. The method of claim 1, wherein, The process involves revising the description file to be verified based on the design specification document and interface protocol document to obtain the verification standard document, including: By integrating a large language model to parse the design specification document and the interface protocol document, a list of function points, a list of interface signals, timing rules and abnormal scenario descriptions are extracted to generate a system verification checklist. The description file to be verified is cross-compared with the system verification checklist to verify whether there are any missing functional points, defective boundary conditions, or incomplete abnormal scenarios in the description file to be verified. If the description file to be verified contains missing functional points, defective boundary conditions, or incomplete abnormal scenarios, the description file to be verified is corrected to obtain the verification standard document.

3. The method of claim 2, wherein, In cases where the description file to be verified contains missing functional points, defective boundary conditions, or incomplete abnormal scenarios, the verification standard document is obtained by correcting the description file to be verified, including: If the description file to be verified contains missing functional points, defective boundary conditions, or incomplete abnormal scenarios, identify the differences between the description file to be verified and the system verification checklist. Based on the difference information, a difference report is generated and output; the difference report includes the difference type, the difference location, and the protocol basis for the difference. The system receives user confirmation and supplementary information based on the difference report, corrects the description file to be verified, and generates the structured verification standard document.

4. The method of claim 1, wherein, The step of generating the verification code based on the task type and parameters corresponding to each subtask includes: Based on the task type and parameters corresponding to each subtask, the parameterized verification template is called from the preset code template library; The corresponding interface protocol details are queried from the preset protocol knowledge base, and the protocol details are filled into the verification template to generate the verification code; the interface protocol details include the signal list, timing logic and abnormal scenario handling rules of the interface protocol.

5. The method of claim 1, wherein, After generating the verification code based on the task type and parameters corresponding to each subtask, the method further includes: Following the hierarchical architecture of general verification methodologies, the verification code is instantiated and connected to assemble a verification framework. Based on the verification framework, a standardized project directory structure and automated execution scripts are created to generate verification projects that can be used for simulation.

6. The method of claim 1, wherein, After generating the verification code based on the task type and parameters corresponding to each subtask, the method further includes: Obtain the input custom check items and the check items generated according to the verification standard document; Schedule and execute each inspection item, obtain the inspection item execution results, and generate a verification review report; the verification review report includes pass items, warning items, and error items.

7. The method of claim 6, wherein, The process of scheduling and executing each inspection item, obtaining the inspection item execution results, and generating a verification review report includes: By using static code analysis tools, rule-based validation scripts, and formal validation tools, the aforementioned checks are executed, and the pass, warning, and error items of the validation code are distinguished and recorded. Include the file location and suggested repairs for each error; Organize the passed items, warning items, and error items according to the preset format to generate a structured verification review report.

8. The method of claim 6, wherein, After scheduling and executing each inspection item, obtaining the inspection item execution results, and generating a verification review report, the method further includes: If errors are found in the inspection results, the parameters of the subtasks are adjusted and the verification code is regenerated based on the verification review report until all inspection items pass.

9. The method according to any one of claims 1 to 8, characterized in that, The verification standard document adopts a lightweight data exchange format or a domain-specific language format, and includes a function list, interface signal mapping relationship, test scenario, coverage target and protocol version information.

10. A verification code generation apparatus, characterized in that, The device package: The acquisition module is used to acquire the verification description file of the design under test; the verification description file includes the verification requirements of the design under test. The correction module is used to correct the description file to be verified according to the design specification document and the interface protocol document to obtain the verification standard document; The decomposition module is used to decompose the verification target corresponding to the verification standard document into multiple sub-tasks; The multiple subtasks are dependent on each other; The generation module is used to generate the verification code based on the task type and parameters corresponding to each subtask.

11. An electronic device, comprising: include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is enabled to perform the method as described in any one of claims 1 to 9.

Images