Sva automatic generation and scene-based ip construction method and system based on large model

CN122756684APending Publication Date: 2026-09-15XINHE SEMICON SHANGHAI
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202610788209.1
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-06-03
Publication Date
2026-09-15

AI Technical Summary

Technical Problem

手工编写的SVA对极端场景及跨模块交互场景的覆盖能力较弱,跨时钟域、复位异常等复杂场景的验证缺失,易导致芯片流片失败

Benefits of technology

提升SVA编写效率与验证IP复用率。本发明通过大模型自动生成SVA代码并构建场景化验证IP,缩短验证周期,降低重复开发成本,减轻用户使用负担。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122756684A_ABST
    Figure CN122756684A_ABST
Patent Text Reader

Abstract

The application discloses a method and system for automatically generating SVA and constructing a scenario-based IP based on a large model, generates SVA syntax rules through knowledge graph reasoning on multi-format input, generates an SVA draft by using a fine-tuned large model, generates a final SVA draft through coverage optimization processing, constructs an IP layered architecture and imports the final SVA draft, adjusts and generates a verification IP in the layered architecture, and finally generates a one-key integrated script through format conversion and script generation. The method and system drive the automatic generation of SVA and the construction of a scenario-based verification IP based on a large model, realize a full-process closed loop from requirement input, automatic generation of SVA, scenario-based verification IP adaptation to EDA tool integration, and are helpful to reducing user use cost, improving verification coverage and reducing chip tape-out failure risk.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of SVA automatic generation and scenario-based IP construction method and system based on large models. Background Technology

[0002] In the integrated circuit design process, verification is a crucial step that determines the chip development cycle and tape-out success rate. System Verilog Assertion (SVA), a hardware description language defined by the IEEE 1800-2017 standard, can accurately describe the logical constraints and behavioral expectations of a chip design, and is a core verification method to ensure the correctness of chip logic. Verification IP is a reusable module that encapsulates specific protocol or module verification logic; its proper application can significantly reduce repetitive development costs.

[0003] However, the existing integrated circuit verification process still has the following shortcomings: First, SVA is inefficient to write and has a low fault tolerance rate. SVA syntax is complex, and in the traditional way, it takes several senior engineers several months to complete the writing process. Moreover, during manual writing, it is easy to overlook boundary scenarios due to human error, resulting in verification vulnerabilities.

[0004] Secondly, the adaptability and reusability of verification IPs need to be improved. Existing verification IPs are mostly general templates, making it difficult to customize them for different chip design frameworks. Furthermore, the IP interfaces of different manufacturers are not standardized, resulting in low reusability across EDA tools, requiring users to repeatedly develop adaptation code.

[0005] Secondly, the verification coverage is limited. Manually written SVAs have weak coverage of extreme scenarios and cross-module interaction scenarios, and lack verification of complex scenarios such as cross-clock domains and reset anomalies, which can easily lead to chip tape-out failures.

[0006] Furthermore, the tools suffer from high integration costs and insufficient compatibility. Existing SVA generation tools have poor interface compatibility with mainstream EDA tools, and the generated SVA code usually requires additional manual modification before it can be integrated into the existing verification process, increasing the user's usage costs.

[0007] Currently, the application of large model technology in the field of chip verification is not yet sufficient. Existing solutions mostly use large models for simple code snippet generation, without specific optimization for SVA verification scenarios, and have not yet achieved full-process automation from requirements analysis, code generation, coverage optimization to IP packaging, making it difficult to fully leverage the advantages of large models in logical reasoning and scenario adaptation.

[0008] Therefore, there is an urgent need for an integrated solution that can automatically generate SVA and construct IP scenarios to solve the problems existing in the above-mentioned technologies. Summary of the Invention

[0009] To address at least one of the aforementioned problems in the existing technology, embodiments of the present invention provide a method and system for automatic SVA generation and scenario-based IP construction based on a large model.

[0010] The method for automatic SVA generation and scenario-based IP construction based on a large model proposed in this invention includes: Knowledge graph reasoning is performed on multi-format inputs to generate verification targets; the verification targets are then processed using a finely tuned large model to generate an initial SVA draft. The initial SVA draft is optimized for SVA code coverage to generate the final SVA draft; an IP layered architecture is constructed, and the final SVA draft is imported into the IP layered architecture. Within the IP layered architecture, the final SVA draft is adjusted according to specific scenarios to generate a verification IP; The verification IP is formatted and a script is generated to obtain a one-click integration script.

[0011] Optionally, knowledge graph reasoning is performed on multi-format input to generate verification targets; the verification targets are then processed using a fine-tuned large model to generate an initial SVA draft, including: Pre-construct SVA knowledge graph and ChainThink reasoning strategy; The verification requirements for multi-format inputs are pre-screened; wherein, the verification requirements include natural language descriptions, chip design documents, and SystemVerilog RTL code. Based on the SVA knowledge graph and the ChainThink reasoning strategy, the verification target is extracted from the verification requirement and mapped to the SVA syntax rules; The large model is fine-tuned using the SVA-specific training dataset; the fine-tuned large model is then used to process the SVA syntax rules to generate an initial SVA draft that meets preset standards, and the initial SVA draft is then repaired for syntax errors and / or logical vulnerabilities.

[0012] Optionally, the initial SVA draft undergoes SVA code-level coverage optimization to generate the final SVA draft; an IP layered architecture is constructed, and the final SVA draft is imported into the IP layered architecture, including: Identify the scenario coverage gaps in the initial SVA draft, supplement the initial SVA draft with assertion code based on the scenario coverage gaps; verify the logical consistency between the SVA code in the initial SVA draft and the subordinate code of the multi-format input, and adjust the assertion code supplementation operation based on the verification result to generate the final SVA draft. Construct an IP layered architecture that includes a basic functional layer, a boundary condition layer, a cross-module interaction layer, and a scenario adaptation layer; import the final SVA draft into the IP layered architecture for multimodal verification.

[0013] Optionally, within the IP layered architecture, the final SVA draft is modified to suit specific scenarios to generate a verification IP, including: A predefined custom rule library for multiple chip design scenarios is used to call the custom rule library to configure parameters and supplement logic for the final SVA draft that has completed multimodal verification within the IP layered architecture, thereby generating scenario-based verification IP.

[0014] Optionally, the verification IP is format-converted and a script is generated to obtain a one-click integration script, including: An interface adaptation engine for an EDA tool is built. The EDA tool is called through the interface adaptation engine to convert the verification IP into a script file that conforms to the format of the target EDA tool. The script file is integrated into the existing verification process to output a one-click integration script; wherein, the one-click integration script includes IP core code, integration script, and user manual.

[0015] As one aspect of the present invention, embodiments of the present invention also provide an SVA automatic generation and scenario-based IP construction system based on a large model, including: The input processing module is used to perform knowledge graph reasoning on multi-format inputs and generate verification targets; The initial draft generation module is used to process the verification target using a finely tuned large model to generate an SVA initial draft. The final draft generation module is used to perform SVA code-level coverage optimization on the initial SVA draft and generate the final SVA draft. The layered architecture processing module is used to build the IP layered architecture and import the final SVA draft into the IP layered architecture; The IP generation module is used to make scenario-based adjustments to the final SVA draft within the IP layered architecture to generate a verification IP. The script generation module is used to convert the verification IP into a format and generate a script to obtain a one-click integration script.

[0016] Optionally, the input processing module is used to perform knowledge graph reasoning on multi-format input to generate verification targets, including: Pre-construct SVA knowledge graph and ChainThink reasoning strategy; The verification requirements for multi-format inputs are pre-screened; wherein, the verification requirements include natural language descriptions, chip design documents, and SystemVerilog RTL code. Based on the SVA knowledge graph and the ChainThink reasoning strategy, the verification target is extracted from the verification requirement and mapped to the SVA syntax rules; The initial draft generation module is used to process the verification target using a fine-tuned large model to generate an SVA initial draft, including: The large model is fine-tuned using the SVA-specific training dataset; the fine-tuned large model is then used to process the SVA syntax rules to generate an initial SVA draft that meets preset standards, and the initial SVA draft is then repaired for syntax errors and / or logical vulnerabilities.

[0017] Optionally, the final draft generation module is used to perform SVA code-level coverage optimization on the initial SVA draft to generate the final SVA draft, including: Identify the scenario coverage gaps in the initial SVA draft, supplement the initial SVA draft with assertion code based on the scenario coverage gaps; verify the logical consistency between the SVA code in the initial SVA draft and the subordinate code of the multi-format input, and adjust the assertion code supplementation operation based on the verification result to generate the final SVA draft. The layered architecture processing module is used to construct the IP layered architecture and import the final SVA draft into the IP layered architecture, including: Construct an IP layered architecture that includes a basic functional layer, a boundary condition layer, a cross-module interaction layer, and a scenario adaptation layer; import the final SVA draft into the IP layered architecture for multimodal verification.

[0018] Optionally, the IP generation module is used to perform scenario-based adjustments to the final SVA draft within the IP layered architecture to generate a verification IP, including: A predefined custom rule library for multiple chip design scenarios is used to call the custom rule library to configure parameters and supplement logic for the final SVA draft that has completed multimodal verification within the IP layered architecture, thereby generating scenario-based verification IP.

[0019] Optionally, the script generation module is used to perform format conversion and script generation on the verification IP to obtain a one-click integration script, including: An interface adaptation engine for an EDA tool is built. The EDA tool is called through the interface adaptation engine to convert the verification IP into a script file that conforms to the format of the target EDA tool. The script file is integrated into the existing verification process to output a one-click integration script; wherein, the one-click integration script includes IP core code, integration script, and user manual.

[0020] The beneficial effects of the above-mentioned technical solutions provided in the embodiments of the present invention include at least the following: This invention provides a method and system for automatic SVA generation and scenario-based IP construction based on a large model. It generates SVA syntax rules through knowledge graph reasoning on multi-format inputs, generates an initial SVA draft using a fine-tuned large model, generates a final SVA draft after coverage optimization, constructs a layered IP architecture and imports the final SVA draft, performs scenario-based adjustments within the layered architecture to generate verification IPs, and finally obtains a one-click integration script through format conversion and script generation. By driving automatic SVA generation and scenario-based verification IP construction through a large model, a closed-loop process is achieved from requirement input, automated SVA generation, scenario-based verification IP adaptation to EDA tool integration, which helps reduce user costs, improve verification coverage, and reduce the risk of chip tape-out failures.

[0021] The method and system for automatic SVA generation and scenario-based IP construction based on a large model, as described in this invention, have the following advantages: This invention improves SVA writing efficiency and verification IP reuse rate. It automatically generates SVA code from large models and constructs scenario-based verification IPs, shortening the verification cycle, reducing repetitive development costs, and alleviating the burden on users.

[0022] This invention improves verification coverage and code correctness. By identifying gaps in scenario coverage and verifying logical consistency, it supplements assertion code for boundary conditions and cross-module interaction scenarios, ensuring that SVA code is consistent with chip design logic. This enhances verification sufficiency and reliability, helping to reduce the risk of chip tape-out failures.

[0023] High adaptability to various scenarios. By constructing a layered IP architecture and combining it with a scenario-based rule base, this invention can flexibly adapt to various chip design frameworks such as automotive electronics, consumer electronics, and industrial control, meeting the customized needs of different application scenarios and expanding the applicability of the product.

[0024] Lowering the technical barrier to entry. This invention supports input in multiple formats, including natural language, reducing the professional requirements for users regarding SVA syntax and IP verification construction.

[0025] Excellent compatibility. This invention, by building an EDA tool interface adaptation engine, can generate script files that conform to mainstream EDA tool formats, achieving seamless integration with existing verification processes without requiring users to reconstruct the verification environment, thus reducing migration costs.

[0026] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description and the accompanying drawings.

[0027] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0028] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart illustrating the method for automatic SVA generation and scenario-based IP construction based on a large model provided in this embodiment of the invention. Figure 2 This is a schematic diagram of the structure of the SVA automatic generation and scenario-based IP construction system based on a large model provided in this embodiment of the invention. Detailed Implementation

[0029] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0030] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," "outer," "far," "near," "front," and "rear," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0031] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0032] For ease of understanding, some of the terms used in this invention are explained below: The Mind Chain Reasoning Strategy refers to a reasoning method that breaks down complex reasoning tasks into multiple intermediate steps, extracts verification targets from input requirements through step-by-step derivation, and maps them to SVA grammar rules.

[0033] Multi-level verification: refers to performing consistency checks and functional verifications on SVA code and the corresponding verification logic in the basic functional layer, boundary condition layer, cross-module interaction layer, and scenario adaptation layer of the IP layered architecture.

[0034] Scene coverage gaps: These refer to key chip design scenarios not covered in the initial SVA draft, including boundary conditions, cross-module interactions, reset anomalies, etc., which are identified through control flow graph analysis and data flow tracing techniques.

[0035] One-click integration script: This refers to packaging the verification IP and all the files required for its integration into an executable integration script. After execution, the user can automatically complete the deployment of the verification IP in the target EDA tool environment.

[0036] Interface adaptation engine: refers to an adaptation module that pre-stores the integration specifications and script templates of mainstream EDA tools (such as Synopsys VCS, Cadence Xcelium, Mentor Questa), and is used to convert the verification IP into a script file that conforms to the format of the target EDA tool.

[0037] Please see Figure 1 As shown, an embodiment of this application provides a method for automatic SVA generation and scenario-based IP construction based on a large model. This method includes: Knowledge graph reasoning is performed on multi-format inputs to generate SVA grammar rules; the SVA grammar rules are processed using a fine-tuned large model to generate an initial SVA draft; The initial SVA draft is optimized for SVA code coverage to generate the final SVA draft; an IP layered architecture is first constructed, and then the final SVA draft is imported into the IP layered architecture. Within the IP layered architecture, the final SVA draft is adjusted according to specific scenarios to generate a verification IP; The verification IP is formatted and a script is generated to obtain a one-click integration script.

[0038] The beneficial effects of the above embodiments are that the large model-based SVA automatic generation and scenario-based IP construction method drives the automatic generation of SVA and the construction of scenario-based verification IP through the large model, realizing a closed loop of the entire process of "requirement input - automatic generation of SVA - scenario-based verification IP adaptation - EDA tool integration", reducing user costs, improving verification coverage, and reducing chip tape-out failure rate.

[0039] In another embodiment, knowledge graph reasoning is performed on multi-format input to generate SVA grammar rules; the SVA grammar rules are then processed using a fine-tuned large model to generate an initial SVA draft, including: Pre-construct SVA knowledge graphs and thought chain reasoning strategies; The verification requirements for multi-format inputs are processed by format normalization and key information extraction; wherein, the verification requirements include natural language descriptions, chip design documents, and SystemVerilog RTL code; Based on the SVA knowledge graph and the thought chain reasoning strategy, the verification target is extracted from the verification requirement and mapped to the SVA syntax rules. The large model is fine-tuned using the SVA-specific training dataset; the fine-tuned large model is then used to process the SVA grammar rules to generate an initial SVA draft.

[0040] In practice, one can first extract relevant SVA knowledge elements and edge relationships based on the verification rules of mainstream chip interface protocols (such as AXI, PCIe, DDR, I2C, SPI, etc.), SVA syntax specifications, IEEE 1800-2017 standard constraints, and common verification error cases. Then, an SVA knowledge graph can be constructed based on these knowledge elements and edge relationships. Furthermore, a thought chain reasoning strategy can be constructed based on the SVA knowledge learning process and language rules.

[0041] This system receives verification requests from multiple input formats, including natural language descriptions, chip design documents, and SystemVerilog RTL code. Natural language descriptions may include, but are not limited to, verifying the AXI4 write address channel handshake timing. Chip design documents may include, but are not limited to, interface protocol specifications and module design manuals in PDF / Word format. The system performs format normalization and key information extraction on these inputs, removing invalid information and extracting key verification elements. Then, based on the SVA knowledge graph and thought chain reasoning strategy, verification targets are extracted from the verification requests. These targets may include, but are not limited to, signal interaction relationships, timing constraints, and boundary conditions. These verification targets are mapped to SVA syntax rules, which may include, but are not limited to, core instruction sets such as assertions, covers, assumptions, sequences, and properties. This process effectively integrates multiple input formats and standardizes the representation of different types of user input requirements.

[0042] In practice, a large language model with hundreds of billions of parameters is used as the base model. This model is then fine-tuned using a dedicated SVA training dataset to obtain a large SVA-specific model. This SVA training dataset may include, but is not limited to, over 100,000 high-quality SVA verification cases (covering different protocols, chips, and verification scenarios), over 50,000 chip design documents with corresponding SVA code, and over 20,000 SVA error cases and correction schemes. This dedicated SVA model receives and processes the aforementioned SVA syntax rules (i.e., verification targets), generating an initial SVA draft conforming to the IEEE 1800-2017 standard. Furthermore, a dynamic iterative prompting strategy is used to perform syntax correction and logic optimization on the initial SVA draft, automatically optimizing syntax errors (such as misuse of timing operators, missing signal definitions, etc.) and logical flaws (such as incomplete constraints), ensuring the syntactic correctness of the SVA code.

[0043] In another embodiment, the initial SVA draft undergoes SVA code-level coverage optimization to generate the final SVA draft; first, an IP layered architecture is constructed, and then the final SVA draft is imported into the IP layered architecture, including: Identify the scenario coverage gaps in the initial SVA draft, and supplement the initial SVA draft with assertion code based on the scenario coverage gaps; verify the logical consistency between the SVA code in the initial SVA draft and the subordinate code of the multi-format input; if the verification fails, revert to the step of supplementing assertion code and adjust the supplementation method until the logical consistency verification passes, thereby generating the final SVA draft. Construct an IP layered architecture that includes a basic function layer, a boundary condition layer, a cross-module interaction layer, and a scenario adaptation layer; import the final SVA draft into the IP layered architecture, and perform multi-level verification of the final SVA draft in each layer of the IP layered architecture.

[0044] In practice, a verification coverage analysis engine is first built, combining Control Flow Graph (CFG) analysis and data flow tracing techniques to identify scenario coverage gaps in the initial SVA draft (such as uncovered boundary scenarios, cross-module interaction scenarios, etc.). Then, assertion code is automatically supplemented based on these gaps (such as counter overflow assertions, illegal state machine transition constraints, cross-clock domain synchronization assertions, etc.) to maximize the completion of currently uncovered scenario information. Furthermore, a Binary Decision Diagram (BDD) is used to prove the logical equivalence between the SVA code in the initial SVA draft and the SystemVerilog RTL code with multiple input formats, ensuring consistency between the SVA code and the chip design logic. If verification fails, the process reverts to the assertion code supplementation step, adjusting the supplementation strategy (such as modifying assertion conditions, increasing constraint range, etc.) until logical consistency verification passes. Finally, a high-coverage, high-correctness final SVA draft is output, providing a reliable foundation for subsequent scenario-based verification IP construction.

[0045] Understandably, the SVA automatic generation process mainly includes three different processing sub-processes: the requirement parsing layer, the large model fine-tuning layer, and the coverage optimization layer. It can effectively and accurately complete the automated process from multi-format requirement input to high-coverage SVA code output.

[0046] The process of building scenario-based verification IP mainly includes three sub-processes: IP layered architecture, scenario-based customization, and EDA tool adaptation, which can realize the encapsulation and adaptation of SVA code into scenario-based verification IP.

[0047] In the sub-processes of the IP layered architecture, a four-layer architecture of "basic function layer - boundary condition layer - cross-module interaction layer - scenario adaptation layer" is adopted to design the verification IP. The basic function layer encapsulates the basic verification logic of core protocols or modules (such as the handshake timing verification logic of AXI4); the boundary condition layer encapsulates extreme scenario verification logic (such as FIFO overflow / underflow, address out-of-bounds, reset exceptions, etc.); the cross-module interaction layer encapsulates the verification logic for multi-IP collaborative work (such as the collaborative constraints between SVA and data / control channels); and the scenario adaptation layer reserves customized interfaces to adapt to the special needs of different chip design frameworks. The final SVA draft is imported into the IP layered architecture, and multi-level verification is performed on the final SVA draft in each layer of the IP layered architecture. That is, corresponding verification checks are performed in the basic function layer, boundary condition layer, and cross-module interaction layer, respectively. The verified SVA code is then connected to the adapted scenario-specific interface through the scenario adaptation layer, facilitating accurate entry into subsequent scenario-specific customization sub-processes.

[0048] In a preferred embodiment, supplementing the SVA draft with assertion code based on the scenario coverage gap specifically includes the following steps: Step S41: For each identified scene coverage gap, determine the priority score of each gap based on the code complexity, frequency of occurrence, and design criticality of the module to which it belongs. Specifically, it can be calculated using the following formula: in, Indicates the first The priority score for each scenario coverage gap is used to quantify the urgency of filling each gap; Indicates the first The code complexity corresponding to each gap is obtained by analyzing the code structure involved in the gap. Specifically, it involves counting the number of basic logic units contained in the hardware logic path verified by the assertion corresponding to the gap. The basic logic units include state nodes, branch judgment nodes, data operation nodes, etc. This count is obtained by parsing the SystemVerilogRTL code associated with the gap using a static code analysis tool, and the unit is the number of units. This represents the maximum code complexity corresponding to all current scenario coverage gaps, in units of 1 and 2. Consistent; when hour, The item value is ; Indicates the first Each gap corresponds to a scenario that is triggered by the simulation tool during the current chip design verification process. The number of times the scenario is triggered is counted in the unit of time. This number is obtained by analyzing simulation logs or coverage databases and takes the value as a positive integer or zero. This represents the maximum number of scene triggers corresponding to the current scene coverage gaps, in units of 1 and 2. Consistent; when hour, The item value is ; Indicates the first The design criticality of the chip design module associated with each gap ranges from [value range missing]. The higher the value, the more critical the module is to the overall chip functionality; the chip design module refers to the hardware functional unit verified by the assertion code corresponding to the notch; the design criticality is pre-configured by the verification engineer based on the module's functional importance and security level requirements in the chip design document; This is the keyity bias coefficient, used to adjust the center point of the Sigmoid function, and its value ranges from [value range missing]. ; This is the key sensitivity coefficient, used to control the steepness of the Sigmoid function, with a value range of [value missing]. Typical value ; , , The first, second, and third weighting coefficients are preset and used to adjust the influence of code complexity, frequency of occurrence, and design criticality on priority scoring, respectively. All three are positive numbers and are set by the user according to the verification target. Step S42: Score according to the priority of each gap. Sort the data from highest to lowest, and fill in the corresponding gaps with assertion code in turn.

[0049] The aforementioned technical solution calculates a weighted normalized score for each scenario coverage gap based on code complexity, frequency of occurrence, and module criticality. Assertion code is then added sequentially from highest to lowest score. This prioritizes limited verification resources to the most pressing gaps, avoiding randomness and blindness in the addition order, thus improving the overall targeting and efficiency of assertion addition. Furthermore, since gaps with high code complexity, high frequency of occurrence, and critical modules often represent boundary conditions and complex interaction scenarios easily overlooked in traditional manual coding, prioritizing the addition of such gaps improves verification coverage and reduces the risk of chip fabrication failure due to insufficient verification. Correspondingly, this solution transforms the decision-making process for the addition order from relying on the experience of senior engineers to quantitative calculation, improving the controllability and reproducibility of the verification process. This helps address the problems of low SVA writing efficiency, insufficient verification coverage, and excessive reliance on human experience in existing technologies.

[0050] In a preferred embodiment, the adjustment and supplementation method specifically includes the following steps: Step S51: When the logical consistency verification fails, for the assertion code that has been supplemented in the current round, determine the validity score of each assertion based on the coverage improvement value of each assertion, the verification importance of the covered scenarios, and the number of lines of assertion code. Specifically, the validity score of each assertion is determined according to the in-play formula: in, Indicates the first The validity score of the assertion has been supplemented, which is used to quantify the balance between the assertion's contribution to verification coverage and its code complexity. Indicates the first The coverage improvement resulting from the addition of assertions was obtained by comparing the simulation coverage reports before and after the addition, and the value range is [value missing]. ; Indicates the first The verification importance level of the scenarios covered by each assertion, with a value range of [value range missing]. A higher value indicates that the scenario is more critical to the adequacy of the verification. The verification importance level is obtained as follows: First, based on the functional description in the chip design document, identify the scenario type verified by the assertion. The scenario types include basic function scenarios, boundary condition scenarios, cross-module interaction scenarios, reset exception scenarios, cross-clock domain scenarios, etc. Then, determine the level value according to a preset scenario importance mapping rule. For example, basic function scenarios are mapped as follows: Boundary condition scene mapping is Cross-module interaction scenarios are mapped as Reset abnormal scenarios are mapped as Cross-clock domain scene mapping as Finally, the verification engineer fine-tunes the mapping range based on the criticality of the scenario in the actual application of the chip, thus obtaining the final verification importance level. ; This is the importance bias coefficient, used to adjust the center point of the Sigmoid function, and its value ranges from [value missing]. ; This is an importance sensitivity coefficient used to control the steepness of the Sigmoid function, with a value range of [value missing]. Typical value ; Indicates the first Number of lines of code for each assertion; , , The preset fourth, fifth, and sixth weighting coefficients are used to adjust the influence of coverage increment, verification importance, and code complexity on the validity score, respectively. All three are positive numbers and are set by the user according to the verification objectives. This represents the average number of lines of code added to all assertions in the current iteration during the iteration process of "rolling back to the step of supplementing assertion code and adjusting the supplementation method"; when hour, The item value is If no supplemented assertions exist in the current iteration, steps S51 to S52 are not executed, and the current adjustment ends directly. Step S52: For each assertion added in the current round, calculate its validity score. And compare each validity score with a preset validity threshold: When one or more assertions have a validity score lower than the threshold, delete or modify these inefficient assertions, and retain assertions with a validity score not lower than the threshold. After completing the above processing of all supplementary assertions, return to the step of "supplementing assertion code to the SVA draft according to the scenario coverage gap". When the validity scores of all assertions are not lower than the threshold, all supplementary assertions are retained, and the process returns to the step of "verifying the logical consistency between the SVA code of the initial SVA draft and the subordinate code of the multi-format input".

[0051] When the above technical solution fails logic consistency verification, it calculates a weighted score of the coverage improvement value, verification importance, and code lines of each supplementary assertion, and compares it with a preset threshold. Inefficient assertions are then deleted or modified, while efficient assertions are retained. This eliminates redundant or overly costly assertions while ensuring coverage contribution, thereby optimizing the overall quality of the assertion set, reducing the number of invalid verifications in subsequent iterations, and accelerating the convergence speed of the supplementation, verification, and adjustment loop. Simultaneously, through configurable weight coefficients and scenario importance mapping rules, this solution supports flexible adjustment of evaluation criteria based on different chip types and verification objectives. This makes the generated assertion set more closely match the verification needs of the target application scenario, improving the reusability and adaptability of the verification IP across different projects. Therefore, this solution helps alleviate the problems of long verification cycles, the difficulty in adapting generalized verification IP templates to different design frameworks, and strong reliance on human experience in existing technologies.

[0052] In another embodiment, the final SVA draft is adapted to specific scenarios within the IP layered architecture to generate a verification IP, including: A predefined custom rule library for multiple chip design scenarios is used to call the custom rule library to configure parameters and supplement logic for the final SVA draft that has completed multi-level verification within the IP layered architecture, thereby generating scenario-based verification IP.

[0053] In the scenario-based customization process, a predefined custom rule library is established for multiple typical chip design scenarios. These typical chip design scenarios may include, but are not limited to, automotive electronics scenarios (e.g., adapting to the ISO 26262 functional safety standard, adding error injection, and safety monitoring assertions), consumer electronics scenarios (adapting to low power consumption requirements and adding power management timing assertions), industrial control scenarios (adapting to high reliability requirements and adding anti-interference timing constraints), and high-end chip scenarios (adapting to high-speed interface protocols and adding signal integrity verification assertions). Users can select the target scenario, and the system will automatically call upon the aforementioned custom rule library to configure parameters and supplement logic for the IP layered architecture, generating scenario-based verification IPs.

[0054] In another embodiment, the verification IP is format-converted and a script is generated to obtain a one-click integration script, including: Build an interface adaptation engine for EDA tools, and generate script files that adapt to the target EDA tool format through the interface adaptation engine; Integrate the script file into the existing verification process to output a one-click integration script.

[0055] In practice, an interface adaptation engine with built-in mainstream EDA tools is constructed. This engine pre-stores integration specifications and script templates for tools such as Synopsys VCS, Cadence Xcelium, and Mentor Questa. Instead of directly calling the EDA tools, the engine generates script files (e.g., .v, .sv, .do) adapted to the target EDA tool's format. After the user executes the script, the verification IP can be seamlessly integrated into the existing verification process (e.g., the Synopsys VCS verification process, with an integration cycle of ≤2 days), meeting the verification IP construction needs of different scenarios.

[0056] This invention uses "Automatic generation of SVA and construction of Verification IP for AXI4-Lite protocol in automotive electronics scenario" as an example for specific illustration. The mainstream EDA tool used is Synopsys VCS, and the basic large model is GPT-4.

[0057] The automatic generation process of SVA determined by the large model is as follows: Step 1: Input requirements in multiple formats. The user inputs the corresponding requirements; among them, the natural language description is: "Verify the AXI4-Lite write address channel in the automotive electronics scenario: when awvalid is high, keep it high until awready is high, during which time awaddr and awprot are stable; awaddr must be in the address range of 0x000_0000-0xffff_FFFF; when a reset abnormality occurs, awvalid should not be set high"; automotive electronics AXI4-Lite protocol design document (e.g., PDF format); SystemVerilog RTL code for the AXI4-Lite write address channel.

[0058] Step 2: Requirement parsing layer processing, based on SVA knowledge graph and thought chain reasoning strategy, extracts the verification targets: a) handshake sequence constraints of awvalid and awready; b) stability constraints of awaddr and awprot; c) address range constraints of awaddr; d) prohibition constraints for reset exception scenarios; map the above verification targets a) to d) to SVA syntax rules 'sequence' to define the handshake sequence, 'property' to define stability and range constraints, and 'disable iff' to define reset exception conditions.

[0059] Step 3: Large model fine-tuning layer processing. The GPT-4 model, fine-tuned using the SVA-specific training dataset, is called, and the parsed SVA syntax rules are input to generate the initial SVA draft. The process is as follows: / / AXI4-Lite address writing channel SVA initial draft sequence aw_handshake_seq; @(posedge clk) awvalid ##1 (awvalid && !awready)[*0:$] ##1 awready; endsequence property aw_addr_stable_prop; @(posedge clk) disable iff (!rst_n) aw_handshake_seq |-> $stable(awaddr); endproperty assert property(aw_addr_stable_prop) else $error("awaddr unstableduring handshake"); property aw_prot_stable_prop; @(posedge clk) disable iff (!rst_n) aw_handshake_seq |-> $stable(awprot); endproperty assert property(aw_prot_stable_prop) else $error("awprot unstableduring handshake"); / / Supplementing address range constraints (customized for automotive electronics scenarios) property aw_addr_range_prop; @(posedge clk) disable iff (!rst_n) awvalid |-> (awaddr >= 32'h0000_0000) && (awaddr <= 32'hFFFF_FFFF); endproperty assert property(aw_addr_range_prop) else $error("awaddr out ofrange"); / / Supplementing reset exception constraints (customized for automotive electronics scenarios) property rst_awvalid_forbid_prop; @(posedge clk) !rst_n |-> !awvalid; endproperty assert property(rst_awvalid_forbid_prop) else $error("awvalid highduring reset error"); / / Supplemental coverage points cover property(aw_handshake_seq) $display("aw handshake covered"); cover property(aw_addr_range_prop) $display("awaddr range covered"); The process of constructing a scenario-based verification IP is as follows: Step 1: IP Layered Architecture Processing. Import the final SVA draft into a four-layer IP architecture. This includes: a basic functional layer integrating basic handshake and stability constraints such as aw_handshake_seq and aw_addr_stable_prop; a boundary condition layer integrating boundary constraints such as aw_addr_range_prop (address out of bounds) and rst_awvalid_forbid_prop (reset exception); a cross-module interaction layer adding coordination constraints with the AXI4-Lite data channel (e.g., "after awvalid goes high, wvalid must go high within 3 clock cycles"); and a scenario adaptation layer reserving interfaces for automotive electronic functional safety monitoring.

[0060] Step 2: Scenario-based customization. Select "Automotive Electronics Scenario", call the ISO 26262 functional safety rule library, and automatically add customized logic, including: error injection, supporting manual injection of awaddr out-of-bounds errors for safety testing; safety alarms, including: automatically triggering automotive electronic safety level alarm signals (such as ASIL-B level alarms) when assert assertion fails.

[0061] Step 3: EDA tool adaptation processing. The Synopsys VCS adaptation engine is invoked to generate script files (such as .v format files or compilation command scripts) adapted to the Synopsys VCS format. These script files contain IP compilation commands, simulation parameter configurations, and coverage statistics commands. After executing the script, the user can integrate the verification IP into the Synopsys VCS verification process without manual code modification. The integration cycle is 1 day.

[0062] Step 4: Output scenario-based verification IP. The final output is the verification IP for the AXI4-Lite protocol in the automotive electronics scenario. It includes the core IP code and integration script. The integration cycle is 1 day. The IP reuse rate is greatly improved and it can be directly applied to other automotive electronics AXI4-Lite interface verification scenarios.

[0063] The SVA code and verification IP generated by the above embodiments have been tested and verified by automotive electronic chip companies. The SVA writing efficiency is improved by 82% (traditional manual writing takes 18 days, while this embodiment only takes 3 days); the coverage of extreme scenarios is improved by 36% (from 61% to 97%); the Synopsys VCS integration cycle is 1 day, and no manual modification is required; when the IP is reused in another automotive electronic chip project, only 3 parameters need to be adjusted, the adaptation cycle is 2 days, and the reuse rate reaches 85%, which is better than the existing technology.

[0064] Please see Figure 2As shown, an embodiment of this application provides a system for automatic SVA generation and scenario-based IP construction based on a large model. This system includes: The input processing module is used to perform knowledge graph reasoning on multi-format inputs and generate SVA syntax rules; The draft generation module is used to process the SVA syntax rules using a fine-tuned large model to generate an SVA draft. The final draft generation module is used to perform SVA code-level coverage optimization on the initial SVA draft and generate the final SVA draft. The layered architecture processing module is used to first construct the IP layered architecture and then import the final SVA draft into the IP layered architecture. The IP generation module is used to make scenario-based adjustments to the final SVA draft within the IP layered architecture to generate a verification IP. The script generation module is used to convert the verification IP into a format and generate a script to obtain a one-click integration script.

[0065] The beneficial effects of the above embodiments are that the large model-based SVA automatic generation and scenario-based IP construction system drives the automatic generation of SVA and the construction of scenario-based verification IP through the large model, realizing a closed loop of the entire process of requirement input, automatic generation of SVA, scenario-based verification IP adaptation, and EDA tool integration, reducing user costs, improving verification coverage, and reducing chip tape-out failure rate.

[0066] In another embodiment, the input processing module is used to perform knowledge graph reasoning on multi-format input to generate SVA grammar rules, including: Pre-construct SVA knowledge graphs and thought chain reasoning strategies; The verification requirements for multi-format inputs are processed by format normalization and key information extraction; wherein, the verification requirements include natural language descriptions, chip design documents, and SystemVerilog RTL code; Based on the SVA knowledge graph and the thought chain reasoning strategy, the verification target is extracted from the verification requirement and mapped to the SVA syntax rules. The draft generation module is used to process the SVA syntax rules using a fine-tuned large model to generate an SVA draft, including: The large model is fine-tuned using the SVA-specific training dataset; the fine-tuned large model is then used to process the SVA grammar rules to generate an initial SVA draft.

[0067] In another embodiment, the final draft generation module is used to perform SVA code-level coverage optimization on the initial SVA draft to generate the final SVA draft, including: Identify the scenario coverage gaps in the initial SVA draft, and supplement the initial SVA draft with assertion code based on the scenario coverage gaps; verify the logical consistency between the SVA code in the initial SVA draft and the subordinate code of the multi-format input; if the verification fails, revert to the step of supplementing assertion code and adjust the supplementation method until the logical consistency verification passes, thereby generating the final SVA draft. The layered architecture processing module is used to first construct the IP layered architecture, and then import the final SVA draft into the IP layered architecture, including: Construct an IP layered architecture that includes a basic function layer, a boundary condition layer, a cross-module interaction layer, and a scenario adaptation layer; import the final SVA draft into the IP layered architecture, and perform multi-level verification of the final SVA draft in each layer of the IP layered architecture.

[0068] In another embodiment, the IP generation module is used to perform scenario-based adjustments to the final SVA draft within the IP layered architecture to generate a verification IP, including: A predefined custom rule library for multiple chip design scenarios is used to call the custom rule library to configure parameters and supplement logic for the final SVA draft that has completed multi-level verification within the IP layered architecture, thereby generating scenario-based verification IP.

[0069] In another embodiment, the script generation module is used to perform format conversion and script generation on the verification IP to obtain a one-click integration script, including: Build an interface adaptation engine for EDA tools, and generate script files that adapt to the target EDA tool format through the interface adaptation engine; Integrate the script file into the existing verification process to output a one-click integration script.

[0070] The operation and effect of the large-scale model SVA automatic generation and scenario-based IP construction system of the present invention are consistent with the above-mentioned large-scale model SVA automatic generation and scenario-based IP construction method, and the description of the large-scale model SVA automatic generation and scenario-based IP construction system will not be repeated here.

[0071] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. This disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims. Thus, if these modifications and variations of the invention fall within the scope of the claims of the invention and their equivalents, the invention is also intended to include these modifications and variations.

Claims

1. A method for automatically generating SVA based on a large model and constructing a scenario IP, characterized in that, include: Perform knowledge graph reasoning on multi-format inputs to generate SVA syntax rules; The SVA syntax rules are processed using a fine-tuned large model to generate an initial SVA draft. The initial SVA draft is optimized for SVA code coverage to generate the final SVA draft; an IP layered architecture is first constructed, and then the final SVA draft is imported into the IP layered architecture. Within the IP layered architecture, the final SVA draft is adjusted according to specific scenarios to generate a verification IP; The verification IP is formatted and a script is generated to obtain a one-click integration script.

2. The method for automatic SVA generation and scenario-based IP construction based on a large model as described in claim 1, characterized in that: Knowledge graph reasoning is performed on multi-format inputs to generate SVA grammar rules; the SVA grammar rules are then processed using a fine-tuned large model to generate an initial SVA draft, including: Pre-construct SVA knowledge graphs and thought chain reasoning strategies; The verification requirements for multi-format inputs are processed by format normalization and key information extraction; wherein, the verification requirements include natural language descriptions, chip design documents, and SystemVerilog RTL code; Based on the SVA knowledge graph and the thought chain reasoning strategy, the verification target is extracted from the verification requirement and mapped to the SVA syntax rules. The large model is fine-tuned using the SVA-specific training dataset; the fine-tuned large model is then used to process the SVA grammar rules to generate an initial SVA draft.

3. The method for automatic SVA generation and scenario-based IP construction based on a large model as described in claim 1, characterized in that: The initial SVA draft undergoes SVA code-level coverage optimization to generate the final SVA draft; an IP layered architecture is first constructed, and then the final SVA draft is imported into the IP layered architecture, including: Identify the scenario coverage gaps in the initial SVA draft, and supplement the initial SVA draft with assertion code based on the scenario coverage gaps; verify the logical consistency between the SVA code in the initial SVA draft and the subordinate code of the multi-format input; if the verification fails, revert to the step of supplementing assertion code and adjust the supplementation method until the logical consistency verification passes, thereby generating the final SVA draft. Construct an IP layered architecture that includes a basic function layer, a boundary condition layer, a cross-module interaction layer, and a scenario adaptation layer; import the final SVA draft into the IP layered architecture, and perform multi-level verification of the final SVA draft in each layer of the IP layered architecture.

4. The method for automatic SVA generation and scenario-based IP construction based on a large model as described in claim 1, characterized in that: Within the IP layered architecture, the final SVA draft is modified to suit specific scenarios to generate a verification IP, including: A predefined custom rule library for multiple chip design scenarios is used to call the custom rule library to configure parameters and supplement logic for the final SVA draft that has completed multi-level verification within the IP layered architecture, thereby generating scenario-based verification IP.

5. The method for automatic SVA generation and scenario-based IP construction based on a large model as described in claim 1, characterized in that: The verification IP is formatted and a script is generated to obtain a one-click integration script, including: Build an interface adaptation engine for EDA tools, and generate script files that adapt to the target EDA tool format through the interface adaptation engine; Integrate the script file into the existing verification process to output a one-click integration script.

6. A large model-based SVA automatic generation and scenario-based IP construction system, characterized in that, include: The input processing module is used to perform knowledge graph reasoning on multi-format inputs and generate SVA syntax rules; The draft generation module is used to process the SVA syntax rules using a fine-tuned large model to generate an SVA draft. The final draft generation module is used to perform SVA code-level coverage optimization on the initial SVA draft and generate the final SVA draft. The layered architecture processing module is used to first construct the IP layered architecture and then import the final SVA draft into the IP layered architecture. The IP generation module is used to make scenario-based adjustments to the final SVA draft within the IP layered architecture to generate a verification IP. The script generation module is used to convert the verification IP in a specific format and generate a script to obtain a one-click integration script.

7. The SVA automatic generation and scenario-based IP construction system based on a large model as described in claim 6, characterized in that: The input processing module is used to perform knowledge graph reasoning on multi-format inputs and generate SVA grammar rules, including: Pre-construct SVA knowledge graphs and thought chain reasoning strategies; The verification requirements for multi-format inputs are processed by format normalization and key information extraction; wherein, the verification requirements include natural language descriptions, chip design documents, and SystemVerilog RTL code; Based on the SVA knowledge graph and the thought chain reasoning strategy, the verification target is extracted from the verification requirement and mapped to the SVA syntax rules. The initial draft generation module is used to process the SVA syntax rules using a fine-tuned large model to generate an initial SVA draft, including: The large model is fine-tuned using the SVA-specific training dataset; the fine-tuned large model is then used to process the SVA grammar rules to generate an initial SVA draft.

8. The SVA automatic generation and scenario-based IP construction system based on a large model as described in claim 6, characterized in that: The final draft generation module is used to perform SVA code-level coverage optimization on the initial SVA draft to generate the final SVA draft, including: Identify the scenario coverage gaps in the initial SVA draft, and supplement the initial SVA draft with assertion code based on the scenario coverage gaps; verify the logical consistency between the SVA code in the initial SVA draft and the subordinate code of the multi-format input; if the verification fails, revert to the step of supplementing assertion code and adjust the supplementation method until the logical consistency verification passes, thereby generating the final SVA draft. The layered architecture processing module is used to first construct the IP layered architecture, and then import the final SVA draft into the IP layered architecture, including: Construct an IP layered architecture that includes a basic function layer, a boundary condition layer, a cross-module interaction layer, and a scenario adaptation layer; import the final SVA draft into the IP layered architecture, and perform multi-level verification of the final SVA draft in each layer of the IP layered architecture.

9. The SVA automatic generation and scenario-based IP construction system based on a large model as described in claim 6, characterized in that: The IP generation module is used to perform scenario-based adjustments to the final SVA draft within the IP layered architecture to generate a verification IP, including: A predefined custom rule library for multiple chip design scenarios is used to call the custom rule library to configure parameters and supplement logic for the final SVA draft that has completed multi-level verification within the IP layered architecture, thereby generating scenario-based verification IP.

10. The SVA automatic generation and scenario-based IP construction system based on a large model as described in claim 6, characterized in that: The script generation module is used to perform format conversion and script generation on the verification IP to obtain a one-click integration script, including: Build an interface adaptation engine for EDA tools, and generate script files that adapt to the target EDA tool format through the interface adaptation engine; Integrate the script file into the existing verification process to output a one-click integration script.