A chip verification method, apparatus and system

Abstract

This application provides a chip verification method, apparatus, and system. The method includes: obtaining a configuration file for the current test scenario; configuring constraint strategies involved in the current test scenario according to a set data structure in the configuration file; the constraint strategies are predefined constraints corresponding to test requirements; parsing the configuration file to obtain a parsing result; generating a hardware programming language simulation data structure corresponding to chip verification test cases based on the parsing result; and outputting the hardware programming language simulation data structure to a chip verification platform to verify chip functionality in a chip simulation environment. The automatic generation and configuration method for test cases in this application significantly improves the user-friendliness of the verification environment, thereby helping verification teams quickly master and efficiently utilize the verification environment.

Description

Technical Field

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

[0002] In chip verification, randomization is an important method for generating test data. In related technologies, verification engineers define random fields in extended classes such as uvm_sequence_item, set static constraints, and call random generation methods to generate data in order to construct complex test scenarios. Summary of the Invention

[0003] The purpose of this application is to provide a chip verification method, apparatus, and system. It aims to address the shortcomings of existing chip verification methods in terms of management, reusability, and flexibility.

[0004] According to a first aspect of this application, a chip verification method is provided, comprising:

[0005] Obtain the configuration file for the current test scenario; the configuration file contains the constraint strategies involved in the current test scenario according to the set data structure; the constraint strategies are predefined constraints corresponding to the test requirements;

[0006] The configuration file is parsed to obtain the parsing result;

[0007] Based on the analysis results, generate the hardware programming language simulation data structure corresponding to the chip verification test cases;

[0008] The hardware programming language simulation data structure is output to the chip verification platform to verify the chip's functionality in a chip simulation environment.

[0009] This application, through chip architecture specification-level design, configuration-based test case construction, and centralized constraint management strategies, enables the reuse of the same configurations and constraints across different test scenarios. This reduces code duplication, improves verification reusability, simplifies test case management, and enhances testing efficiency and scenario coverage. Furthermore, by separating configuration and constraints, this application simplifies the learning process for verification personnel. New team members can set up test scenarios using simple configuration files without needing to deeply understand the underlying constraint implementation. The automatic generation and configuration of test cases significantly improves the user-friendliness of the verification environment, thereby helping the verification team quickly master and efficiently utilize it.

[0010] In an optional implementation, the method further includes:

[0011] The constraints involved in different testing requirements are encapsulated into constraint strategies through strategy classes and added to the constraint strategy pool.

[0012] This implementation simplifies the management and maintenance of complex constraints by encapsulating the constraint logic within a policy pool. Verifiers only need to update the constraints in the policy pool without modifying the specific test case code, thus reducing maintenance workload.

[0013] In an optional implementation, the step of generating the hardware programming language simulation data structure corresponding to the chip verification test case based on the parsing results includes:

[0014] Based on the analysis results, a command word hardware programming language simulation data structure is generated;

[0015] Based on the analysis results, a command frame hardware programming language simulation data structure is generated based on the command word hardware programming language simulation data structure.

[0016] Based on the analysis results, a data dispersion and aggregation list hardware programming language simulation data structure is generated based on the command frame hardware programming language simulation data structure.

[0017] Based on the parsing results, a hardware programming language simulation data structure is generated from the data scattering and aggregation list hardware programming language simulation data structure. This implementation configures constraints via a YAML file and generates the hardware programming language simulation data structure after parsing the configured constraints. This approach is no longer entirely dependent on the hardware description language and is more flexible, no longer confined to chip architecture. Therefore, it can achieve dynamic adaptation of constraints, allowing the generator to cope with different chip architectures and testing requirements, thus improving the adaptability and flexibility of the chip verification platform.

[0018] In an optional implementation, the configuration file is a multi-level data structure defined using YAML, which includes the basic constraint strategy and auxiliary constraint strategy of the command to be tested in the current test scenario.

[0019] This implementation uses a multi-level data structure in YAML configuration files, which makes the test data structure clear, facilitates intuitive configuration and adjustment of test scenarios, and reduces maintenance difficulty.

[0020] In an optional implementation, a hardware programming language simulation data structure corresponding to the chip verification test case is generated based on the parsing results, including:

[0021] The test command and predefined structural elements for the test command are obtained from the parsing results. The structural elements include command words, command frames, data scattering and aggregation lists, and data. Each structural element is pre-configured with a corresponding basic constraint strategy and / or auxiliary constraint strategy.

[0022] For each of the structural elements, initial content is randomly generated based on the corresponding basic constraint strategy;

[0023] If the auxiliary constraint strategy corresponding to the structuring element is not empty and meets the randomization requirement, then the initial content is dynamically adjusted according to the auxiliary constraint strategy to obtain the updated content.

[0024] Construct the command content or data generation structure corresponding to the structural element based on the initial content or updated content;

[0025] According to a predefined set structure, the command content and data generation structure corresponding to the structure elements are encapsulated into a hardware programming language simulation data structure corresponding to the command to be tested.

[0026] This implementation method supports multiple protocols and command combinations, enabling the simulation of more complex scenarios and achieving more comprehensive verification.

[0027] In an optional implementation, the method further includes:

[0028] In response to the modification operation of the configuration file, the modified configuration file is re-parsed to obtain the parsing result of the modified configuration file, and then the process jumps to the step of generating the hardware programming language simulation data structure corresponding to the chip verification test case based on the parsing result and is re-executed.

[0029] This implementation method supports dynamic adjustment of test configuration in the configuration file, quickly switching test scenarios, avoiding repeated compilation of the verification platform, and greatly improving verification efficiency.

[0030] According to a second aspect of this application, a chip verification apparatus is provided, comprising:

[0031] The acquisition module is configured to acquire the configuration file of the current test scenario; the configuration file contains the constraint strategies involved in the current test scenario according to the set data structure; the constraint strategies are predefined constraints corresponding to the test requirements.

[0032] The parsing module is configured to parse the configuration file and obtain the parsing result;

[0033] The generation module is configured to generate hardware programming language simulation data structures corresponding to chip verification test cases based on the parsing results.

[0034] The testing module is configured to output the hardware programming language simulation data structure to the chip verification platform to verify the chip's functionality in a chip simulation environment.

[0035] In an optional embodiment, the apparatus further includes:

[0036] The encapsulation module is configured to encapsulate the constraints involved in different testing requirements into constraint policies through policy classes and add them to the constraint policy pool.

[0037] In an optional implementation, the generation module is configured as follows:

[0038] Based on the analysis results, a command word hardware programming language simulation data structure is generated;

[0039] Based on the analysis results, a command frame hardware programming language simulation data structure is generated based on the command word hardware programming language simulation data structure.

[0040] Based on the analysis results, a data dispersion and aggregation list hardware programming language simulation data structure is generated based on the command frame hardware programming language simulation data structure.

[0041] Based on the analysis results, a data hardware programming language simulation data structure is generated based on the data dispersion and aggregation list hardware programming language simulation data structure.

[0042] In an optional implementation, the configuration file is a multi-level data structure defined using YAML, which includes the basic constraint strategy and auxiliary constraint strategy of the command to be tested in the current test scenario.

[0043] In an optional implementation, the generation module is configured as follows:

[0044] The test command and predefined structural elements for the test command are obtained from the parsing results. The structural elements include command words, command frames, data scattering and aggregation lists, and data. Each structural element is pre-configured with a corresponding basic constraint strategy and / or auxiliary constraint strategy.

[0045] For each of the structural elements, initial content is randomly generated based on the corresponding basic constraint strategy;

[0046] If the auxiliary constraint strategy corresponding to the structuring element is not empty and meets the randomization requirement, then the initial content is dynamically adjusted according to the auxiliary constraint strategy to obtain the updated content.

[0047] Construct the command content or data generation structure corresponding to the structural element based on the initial content or updated content;

[0048] According to a predefined set structure, the command content and data generation structure corresponding to the structure elements are encapsulated into a hardware programming language simulation data structure corresponding to the command to be tested.

[0049] In an optional embodiment, the apparatus further includes:

[0050] The response module is configured to respond to a modification operation on the configuration file by re-parseing the modified configuration file, obtaining the parsing result of the modified configuration file, and then jumping to the generation module for re-execution.

[0051] According to a third aspect of this application, a chip verification system is provided, comprising: a YMAL configuration system, a data generation system, and a chip verification platform;

[0052] The YMAL configuration system is used by testers to write configuration files for the current test scenario;

[0053] The data generation system is used to generate a hardware programming language simulation data structure according to the configuration file, and output the hardware programming language simulation data structure to the chip verification platform; the hardware programming language simulation data structure is obtained based on the method described in the first aspect.

[0054] The chip verification platform is used to verify chip functionality by simulating data structures based on the hardware programming language in a chip simulation environment.

[0055] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures and processes shown in the description and the accompanying drawings. Attached Figure Description

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

[0057] Figure 1 This is a schematic flowchart of a chip verification method according to an exemplary embodiment of this application.

[0058] Figure 2 This is a conceptual schematic diagram of a chip verification process according to an exemplary embodiment of this application.

[0059] Figure 3 This is a schematic diagram illustrating the data format definition of a YAML configuration file according to an exemplary embodiment of this application.

[0060] Figure 4 This is a schematic diagram of the IO command data structure definition according to an exemplary embodiment of this application.

[0061] Figure 5 This is a flowchart illustrating the implementation process of each generation module according to an exemplary embodiment of this application.

[0062] Figure 6 This is a structural block diagram of a chip verification apparatus according to an exemplary embodiment of this application.

[0063] Figure 7 This is a structural block diagram of a chip verification system according to an exemplary embodiment of this application. Detailed Implementation

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

[0065] The basic process of generating test data using randomization methods in related technologies is as follows:

[0066] 1. Define the uvm_sequence_item extension class for random fields: set the random field attributes to generate different data during simulation.

[0067] 2. Set static constraints: Control the range of random data through static constraints to ensure that the generated data meets specific requirements.

[0068] 3. Inline constraints: Constraints can be dynamically adjusted to adapt to different testing needs, but complex inline constraints are difficult to maintain.

[0069] In the verification of I / O commands for memory chips, randomization methods are used to generate a large number of test cases to verify the integrity of command sequences. The implementation steps of related technologies include: decomposing the command structure (such as CMDWORD, CMD_Frame, SGL, Data), constructing command sequences using Sequence objects, and dynamically adjusting constraints to generate specific commands. However, as the complexity of the scenario increases, these methods are prone to problems such as management difficulties, low code reusability, and high maintenance difficulty.

[0070] In chip verification methods, the randomization process and constraint strategies of related technologies generally suffer from the following main problems:

[0071] 1. Poor reusability

[0072] 1) Limitations of static constraints: The verification methods of related technologies mainly rely on static constraints, which are difficult to dynamically adapt across different scenarios and modules. Due to the lack of a strategy reuse mechanism, whenever test requirements change, verification engineers need to redefine or adjust constraints, making it impossible to share consistent constraint logic across multiple scenarios, resulting in poor code reusability.

[0073] 2) Difficulty in reusing strategies between modules: When multiple modules use similar IO command patterns, constraint strategies under the same verification scenario still need to be redefined, increasing the complexity of building the verification environment. This difficulty in reuse is not only time-consuming but also increases the workload of debugging.

[0074] 2. Code redundancy

[0075] 1) Too many derived classes: To meet specific testing needs, verification engineers often need to create derived classes for each new scenario and define specific constraints. This approach leads to a rapid increase in the number of derived classes of the uvm_sequence_item extension class and other verification components, resulting in high code duplication and difficulty in unified management.

[0076] 2) Multi-level code duplication: In large-scale chip verification projects, test cases for different modules often contain duplicate code snippets. Even simple sequence generation may result in redundant code, which affects both readability and maintenance.

[0077] 3. High maintenance difficulty

[0078] 1) Inline constraints with complex logic: In inline constraints, verifiers need to manually adjust specific random conditions for each sequence to generate test data that meets the requirements. However, as the constraints become more complex, the inline code becomes verbose, difficult to maintain, and prone to logical errors.

[0079] 2) Long test case construction path: Due to the lack of a unified configuration and management method, test case builders need to spend a lot of time learning and understanding the detailed implementation of each object, increasing the time cost of constructing test cases. This extended learning curve is particularly detrimental to new engineers getting started quickly and collaborating effectively.

[0080] 4. The verification platform has poor adaptability.

[0081] 1) Inefficient scenario switching: During the verification process, because the relevant technologies rely on static configuration, the verification platform often needs to be recompiled when the test scenario needs to be switched or the test conditions need to be changed. This not only increases the platform's runtime but also affects verification efficiency.

[0082] 2) Highly coupled constraint structure: In related technologies, constraint definition and command generation logic are often coupled together. Such a design increases the maintenance difficulty of the test platform and limits the applicability of the verification platform in different projects.

[0083] Policy-based constraints, proposed by John Dickol in 2015, provide a more flexible management approach by encapsulating constraints as policy classes. This method supports the reuse of constraints across different testing scenarios, reduces code redundancy, and makes the verification process more flexible and maintainable.

[0084] YAML, as a data serialization format, is characterized by its concise structure and high readability, making it suitable for use as a configuration file. Compared to XML and JSON, YAML is more intuitive, supports complex data structures, and is easier to manage. This application combines Policy-based Constraints and YAML configuration files to improve the reusability, flexibility, and maintainability of the validation process, making validation work more efficient.

[0085] Based on the above analysis, see Figure 1 The flowchart illustrates a chip verification method, which includes:

[0086] Step 101: Obtain the configuration file for the current test scenario; configure the constraint strategies involved in the current test scenario according to the set data structure in the configuration file; the constraint strategies are predefined constraints corresponding to the test requirements;

[0087] Step 102: Parse the configuration file to obtain the parsing results;

[0088] Step 103: Generate the hardware programming language simulation data structure corresponding to the chip verification test case based on the parsing results;

[0089] Step 104: Output the hardware programming language simulation data structure to the chip verification platform to verify the chip function in the chip simulation environment.

[0090] For example, the configuration file can be pre-configured by testers according to the current test scenario, and can be configured via YAML files on the YAML configuration system. The configuration file is configured according to a set data structure, including configuring constraint policies. Constraint policies can be understood as various functional characteristics of the requirements to be verified in the current test scenario, that is, the constraints corresponding to the test requirements. In some embodiments, in the data generation system, resource mapping can be performed based on the chip architecture specification layer (including HAS and MAS specifications), that is, first constructing a constraint policy pool through data structures (such as cmdword, cmdFrame, SGL scatter-cluster list, etc.), and providing flexible constraint reuse methods through policy class encapsulation. The policy pool contains various constraint policies representing the functional characteristics of the verification requirements.

[0091] For example, this application constructs a centrally managed constraint policy pool, which allows multiple verification scenarios to reuse the same constraint policies, reducing code redundancy. Through the constraint policy pool, different constraint policies can be flexibly combined to meet different test conditions, improving the reusability and maintainability of constraint definitions.

[0092] For example, a YAML file is used to define the test configuration file, mapping and organizing the basic structure and constraint policies of each test scenario. The YAML file lists various constraint policies (such as base_policy, cmdFrame_policy, etc.) and operations (such as cmd_send_abort, cmd_do_write, etc.), each constraint policy corresponding to different test requirements. Test cases can directly call these constraint policies through the configuration file, forming multi-level scenario control and supporting the construction of complex IO verification scenarios.

[0093] For example, in the data generation system, this application can pre-build a YAML language parser using SV (system verilog, hardware programming language) to convert YAML configuration files into SV simulation data structures.

[0094] For example, multiple test pattern generators can be pre-built in the data generation system. Each test pattern generator consists of multiple generation modules, including Cmdword Gen (command word generation module), CmdFrame Gen (command frame generation module), SGL Gen (scatter-cluster list generation module), and Data Gen (data generation module). Each generation module works together in different test scenarios to generate IO test cases that meet the test requirements based on the YAML configuration file.

[0095] For example, each generation module is responsible for generating specific data to support multiple protocols and operational requirements. In complex testing, the generator automatically generates data streams for various test cases by combining various configurations and constraints, ensuring comprehensive verification and scenario coverage. The finally generated test cases are transmitted to the TestBench (chip verification platform) environment through the test pattern generator for various verifications. After receiving the test cases, TestBench can execute various operations within the test cases, verifying different I / O commands and their behaviors, ensuring the correctness of chip functionality under various conditions.

[0096] This application achieves high flexibility and reusability of verification scenarios through chip architecture specification-level design, YAML-configured test case construction, a centrally managed constraint policy pool, and a modular test pattern generator. By reusing YAML file configurations and the policy pool, the management of verification test cases is simplified, duplicate code is reduced, and testing efficiency and scenario coverage are improved.

[0097] In some optional implementations, the method further includes:

[0098] The constraints involved in different testing requirements are encapsulated into constraint policies through policy classes and added to the constraint policy pool.

[0099] For example, as described above, constraint policies need to be predefined and added to the constraint policy pool after being encapsulated by a policy class. Testers configure the pre-encapsulated constraint policies in the policy pool according to test requirements. This application simplifies the management and maintenance of complex constraints by encapsulating constraint logic in the policy pool. Verifiers only need to update the constraints in the policy pool without modifying the specific test case code, thereby reducing maintenance workload.

[0100] For example, this application designs specific constraints for each element (various concepts defined in the chip architecture) used in the test requirements according to the chip architecture specifications in the data generation system. Through a reasonable abstraction hierarchy, highly correlated constraints are handled uniformly, while unrelated constraints are separated and encapsulated into different constraint strategies to ensure flexibility in random combinations. This design decomposes complex constraints into a simple hierarchical structure, facilitating subsequent maintenance and reuse. Finally, a strategy constraint pool corresponding to the chip's characteristics is formed in the SV simulation database, used for mapping and selection with the constraint strategies in the YAML input configuration file.

[0101] In some optional implementations, the step of generating the hardware programming language simulation data structure corresponding to the chip verification test case based on the parsing results includes:

[0102] Based on the parsing results, generate the command word hardware programming language simulation data structure;

[0103] Based on the parsing results, a command frame hardware programming language simulation data structure is generated on the basis of the command word hardware programming language simulation data structure.

[0104] Based on the parsing results, a data scattering and aggregation list hardware programming language simulation data structure is generated on the basis of the command frame hardware programming language simulation data structure.

[0105] Based on the analysis results, a data hardware programming language simulation data structure is generated based on the data dispersion and aggregation list hardware programming language simulation data structure.

[0106] For example, such as Figure 2 As shown, the data generation system of this application pre-maps the features defined in the HAS (Hardware Abstraction Layer) specification and MAS (Micro-Architecture Specification) of the chip architecture to data structures implemented in the hardware programming language SV. These include a command word hardware programming language simulation data structure corresponding to the command word Cmdwordword, a command frame hardware programming language simulation data structure corresponding to the command word Cmdwordframe, a data scatter-cluster list hardware programming language simulation data structure corresponding to the scatter-cluster list SGL, and a data hardware programming language simulation data structure corresponding to the data generated by Data. This mapping can be understood as a mapping from natural language to machine language.

[0107] As mentioned above, constraint policies are organized according to a constraint policy pool. Test scenarios can be built in YAML configuration files, with one configuration file capable of configuring one or more test scenarios. Each test scenario can generate and configure corresponding constraint policies (including basic and auxiliary constraint policies) for command words, command frames, scatter-cluster lists (SGLs), and data, as well as other related elements such as the number of command frames and the definition of other relevant subdivisions (i.e., other features defined in the specification). The constraint policies configured in the configuration file are pre-encapsulated into classes and managed and maintained by the constraint policy pool. The constraint policy pool is designed as a module for configuration and invocation within the configuration file. Different test scenarios can combine different constraint policies from the constraint policy pool, thus reusing these constraint policies. This reduces code duplication and improves verification reusability. The modular design of the constraint policy pool allows for flexible combination and invocation of constraint policies, supporting multi-scenario testing needs. Furthermore, through the flexible policy pool and configuration files, it supports multiple protocol and command combinations, enabling the simulation of more complex scenarios and achieving more comprehensive verification. Furthermore, the constraints in the policy pool are configured through YAML files, no longer entirely dependent on hardware description languages ​​such as SV, and are more flexible in form, no longer bound by chip architecture. Therefore, dynamic adaptation of constraints can be achieved, enabling the generator to cope with different chip architectures and testing requirements, thus improving the adaptability and flexibility of the chip verification platform.

[0108] During the specific testing process, the data generation system can obtain a configuration file from the YAML configuration system and provide it to the pre-generated Test Pattern Generator. The Generator parses the test scenarios in the configuration file and provides the parsing results to the command word generation module, command frame generation module, SGL generation module, and Data generation module. The command word generation module first generates a command word hardware programming language simulation data structure based on the constraint strategies and other relevant elements in the parsing results. This data structure is then provided to the command frame generation module. Based on this data structure, the command frame generation module generates its own command frame simulation data structure, which is further provided to the SGL generation module. Based on this data structure, the SGL generation module generates a data scatter-aggregate list simulation data structure, which is then provided to the Data generation module. Finally, based on this data scatter-aggregate list simulation data structure, the Data generation module generates its own data simulation data structure. The generated hardware programming language simulation data structures are pushed into the IO_INFOQueue for queuing, awaiting transmission to the chip verification platform TestBench for verification. The IO_INFO Queue is a command buffer that ensures all generated commands enter the verification environment in a specific order, facilitating subsequent testing and data analysis. The design of the IO command queue ensures that generated test patterns are delivered to the TestBench on demand, reducing waiting time in the testing process.

[0109] For example, such as Figure 3 As shown, this application can also predefine the data format of a YAML configuration file as input to the generation module: a multi-level data structure is defined using the YAML configuration file, and this configuration file is used as input to constrain the behavior of the generation module. Key parameters are set in the YAML configuration file, including base_policy (corresponding to the basic constraint policy), aux_policy (corresponding to the auxiliary constraint policy), and policy selection weights, to control the constraints and data generation of the generation module. For example, a unified IO command control container can also be created to centrally manage all configuration data.

[0110] In some optional implementations, the configuration file is a multi-level data structure defined using YAML. The multi-level data structure includes the basic constraint strategy and auxiliary constraint strategy of the command to be tested in the current test scenario.

[0111] For example, such as Figure 2 As shown, the YAML configuration file can be configured into a multi-level data structure. Within the same test scenario, different constraint strategies and other related elements can be configured for different structural elements. The constraint strategies include the basic constraint strategy and auxiliary constraint strategy for the command to be tested under that test scenario. The YAML configuration file structure in this application is clear, facilitating intuitive configuration and adjustment of test scenarios and reducing maintenance difficulty.

[0112] In some optional implementations, the step of generating the hardware programming language simulation data structure corresponding to the chip verification test case based on the parsing results includes:

[0113] The test command and predefined structural elements for the test command are obtained from the parsing results. The structural elements include command words, command frames, data scatter aggregation lists, and data. Each structural element is pre-configured with corresponding basic constraint strategies and / or auxiliary constraint strategies.

[0114] For each structural element, initial content is randomly generated based on the corresponding basic constraint strategy;

[0115] If the auxiliary constraint strategy corresponding to the structural element is not empty and meets the randomization requirement, the initial content is dynamically adjusted according to the auxiliary constraint strategy to obtain the updated content.

[0116] Generate a structure by constructing the command content or data corresponding to the structural elements based on the initial or updated content;

[0117] According to the predefined structure, the command content and data generation structure corresponding to the structural elements are encapsulated into a hardware programming language simulation data structure corresponding to the command to be tested.

[0118] For example, the hardware programming language simulation data structure corresponding to the chip verification test case can be as follows: Figure 4 As shown, the structure includes configuration command words, command frames, data scatter aggregation lists (SGL), and data elements such as Data. Each structure element can define a corresponding constraint policy pool according to a multi-level structure, as well as basic and auxiliary constraint policies within that pool. In the current test scenario, the basic and auxiliary constraint policies for each structure element are configured in the configuration file.

[0119] For example, the command word generation module, command frame generation module, SGL generation module, and Data generation module described above all follow the... Figure 5 The process shown generates the corresponding command content or data generation structure, specifically including:

[0120] 1. Base Random (basic random generation):

[0121] The Base Random module is the starting point for all generation modules, used to generate initial content based on the randomization conditions of the configured basic constraint strategy. In this step, initial content is created according to a set command template through a basic random generation mechanism, serving as the basis for processing by the next generation module. This initial content consists of command content or data generation structures; command content is created for command words, command frames, and SGL, while data generation structures are created for Data.

[0122] 2. Out Constraints random:

[0123] This module checks whether the external constraints of the aux_policy (auxiliary constraint policy) need to be randomly selected, and decides whether to update the initial content accordingly. If the external constraints meet the randomization requirements, the Content_update module below is executed to further adjust the generated command content.

[0124] 3. Content_update:

[0125] The Content_update module dynamically updates the initial content generated in the previous step based on external constraints. This process ensures that the generated data conforms to the specific constraints of the test cases. This module can adjust the generated command content or data in real time based on constraint policies defined in the policy pool or specific YAML configurations to meet specific test requirements.

[0126] 4. Content Generation: After the initial content is created (if the auxiliary constraint strategy is not configured, or if the initial content does not need to be updated according to the auxiliary constraint strategy) or after the content is updated, the Content module generates the final command content or data generation structure. This module constructs the complete command content or data generation structure of the IO command to be tested based on the randomly generated initial content or updated content, ensuring that the generated command content or data generation structure meets the requirements of the test scenario.

[0127] 5. IO_Info (IO information processing):

[0128] The IO_Info module collects and organizes the generated command content or data structure, encapsulating it into a complete IO command structure, such as... Figure 3 The command structure shown is a direct result of this test. This command structure contains the necessary IO command elements, such as Cmdword, CmdFrame, SGL, and Data, enabling the command to be tested to be directly used in subsequent test procedures.

[0129] 6. Next_Gen (Next step generation):

[0130] The Next_Gen module is the post-generation processing part, preparing to send the generated command structure to the queue. At this stage, the generated IO command data structure is further formatted or validated to ensure its integrity and consistency.

[0131] 7. IO_INFO Queue (IO command queue):

[0132] The final generated IO command structure is pushed into the IO_INFO Queue for queuing, awaiting transmission to the chip verification platform TestBench for verification. This IO command queue design ensures that the generated test patterns are delivered to TestBench on demand, reducing waiting time in the testing process.

[0133] In some alternative implementations, the method further includes:

[0134] In response to the modification operation of the configuration file, the modified configuration file is re-parsed to obtain the parsing result of the modified configuration file, and then the process jumps to the step of generating the hardware programming language simulation data structure corresponding to the chip verification test case based on the parsing result, and is re-executed.

[0135] For example, testers can also switch test scenarios by modifying YAML configuration files on the YAML configuration system: different test scenarios are generated by changing the YAML file configuration, without needing to repeatedly compile the chip verification platform and test cases. This method allows for rapid switching of test scenarios without changing the underlying code, improving verification efficiency. This scenario switching method not only saves compilation time but also significantly improves the flexibility and adaptability of the verification platform. This application simplifies the learning process for verification personnel by separating configuration and constraints. New team members can set up test scenarios through simple YAML configuration files without needing to deeply understand the underlying constraint implementation. The automatic generation and configuration of test cases makes the verification environment more user-friendly, helping the verification team get started more quickly.

[0136] The test cases generated through the embodiments of this application allow users to easily organize test cases without needing to understand the specific underlying constraints and configurations. The final test cases are based on a unified IO generator, combined with YAML configuration and strategy pool to form a complete verification system, which improves the reusability and ease of use of test cases.

[0137] Accordingly, such as Figure 6 As shown, this application exemplarily provides a chip verification apparatus, including:

[0138] The acquisition module 601 is configured to acquire the configuration file of the current test scenario; the configuration file configures the constraint strategies involved in the current test scenario according to the set data structure; the constraint strategies are predefined constraints corresponding to the test requirements.

[0139] Parsing module 602 is configured to parse the configuration file and obtain the parsing result;

[0140] The generation module 603 is configured to generate hardware programming language simulation data structures corresponding to chip verification test cases based on the parsing results.

[0141] Test module 604 is configured to output hardware programming language simulation data structures to the chip verification platform to verify chip functionality in a chip simulation environment.

[0142] In some alternative implementations, the apparatus further includes:

[0143] The encapsulation module is configured to encapsulate the constraints involved in different testing requirements into constraint policies through policy classes and add them to the constraint policy pool.

[0144] In some alternative implementations, the generation module is implemented as follows:

[0145] Based on the parsing results, generate the command word hardware programming language simulation data structure;

[0146] Based on the parsing results, and building upon the command word hardware programming language simulation data structure, a command frame hardware programming language simulation data structure is generated:

[0147] Based on the parsing results, a data scattering and aggregation list hardware programming language simulation data structure is generated on the basis of the command frame hardware programming language simulation data structure.

[0148] Based on the analysis results, a data hardware programming language simulation data structure is generated based on the data dispersion and aggregation list hardware programming language simulation data structure.

[0149] In some optional implementations, the configuration file is a multi-level data structure defined using YAML. The multi-level data structure includes the basic constraint strategy and auxiliary constraint strategy of the command to be tested in the current test scenario.

[0150] In some alternative implementations, the generation module is implemented as follows:

[0151] The test command and predefined structural elements for the test command are obtained from the parsing results. The structural elements include command words, command frames, data scatter aggregation lists, and data. Each structural element is pre-configured with corresponding basic constraint strategies and / or auxiliary constraint strategies.

[0152] For each structural element, initial content is randomly generated based on the corresponding basic constraint strategy;

[0153] If the auxiliary constraint strategy corresponding to the structural element is not empty and meets the randomization requirement, the initial content is dynamically adjusted according to the auxiliary constraint strategy to obtain the updated content.

[0154] Generate a structure by constructing the command content or data corresponding to the structural elements based on the initial or updated content;

[0155] According to the predefined structure, the command content and data generation structure corresponding to the structural elements are encapsulated into a hardware programming language simulation data structure corresponding to the command to be tested.

[0156] In some alternative implementations, the apparatus further includes:

[0157] The response module is configured to respond to modifications to the configuration file, re-parse the modified configuration file, obtain the parsing result of the modified configuration file, and then jump to the generation module to re-execute.

[0158] The above-described device corresponds to the chip verification method provided in the above embodiments. For specific details, please refer to the description of the chip verification method in the above embodiments, which will not be repeated here.

[0159] Accordingly, such as Figure 7 As shown, this application provides an exemplary chip verification system, including: a YMAL configuration system 701, a data generation system 702, and a chip verification platform 703;

[0160] The YMAL configuration system is used by testers to write configuration files for the current test scenario;

[0161] The data generation system is used to generate hardware programming language simulation data structures according to configuration files and output the hardware programming language simulation data structures to the chip verification platform; the hardware programming language simulation data structures are obtained based on the chip verification method described above.

[0162] Chip verification platforms are used to verify chip functionality by simulating data structures based on hardware programming languages ​​in a chip simulation environment.

[0163] The chip verification system described above is used to execute the chip verification method provided in the above embodiments. For specific implementation details, please refer to the description of the chip verification method in the above embodiments, which will not be repeated here.

[0164] It is understood that the circuit structures, names, and elements described in the above embodiments are merely examples. Those skilled in the art can also make readily conceived combinations and adjustments to the structural features of the above embodiments according to their needs, and the concept of this application should not be limited to the specific details of the above examples.

[0165] Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A chip verification method, characterized in that, include: Obtain the configuration file for the current test scenario; the configuration file contains the constraint strategies involved in the current test scenario according to the set data structure; The constraint strategy is a predefined constraint condition that corresponds to the test requirements. The configuration file is parsed to obtain the parsing result; Based on the analysis results, generate the hardware programming language simulation data structure corresponding to the chip verification test cases; The hardware programming language simulation data structure is output to the chip verification platform to verify the chip function in the chip simulation environment. Specifically, the hardware programming language simulation data structure for generating chip verification test cases based on the parsing results includes: Based on the analysis results, a command word hardware programming language simulation data structure is generated; Based on the analysis results, a command frame hardware programming language simulation data structure is generated based on the command word hardware programming language simulation data structure. Based on the analysis results, a data dispersion and aggregation list hardware programming language simulation data structure is generated based on the command frame hardware programming language simulation data structure. Based on the analysis results, a data hardware programming language simulation data structure is generated based on the data dispersion and aggregation list hardware programming language simulation data structure.

2. The chip verification method according to claim 1, characterized in that, The method further includes: The constraints involved in different testing requirements are encapsulated into constraint strategies through strategy classes and added to the constraint strategy pool.

3. The chip verification method according to claim 1, characterized in that, The configuration file is a multi-level data structure defined using YAML. The multi-level data structure includes the basic constraint strategy and auxiliary constraint strategy of the command to be tested in the current test scenario.

4. The chip verification method according to any one of claims 1-3, characterized in that, The hardware programming language simulation data structure for generating chip verification test cases based on the parsing results includes: The test command and predefined structural elements for the test command are obtained from the parsing results. The structural elements include command words, command frames, data scattering and aggregation lists, and data. Each structural element is pre-configured with a corresponding basic constraint strategy and / or auxiliary constraint strategy. For each of the structural elements, initial content is randomly generated based on the corresponding basic constraint strategy; If the auxiliary constraint strategy corresponding to the structuring element is not empty and meets the randomization requirement, then the initial content is dynamically adjusted according to the auxiliary constraint strategy to obtain the updated content. Construct the command content or data generation structure corresponding to the structural element based on the initial content or updated content; According to a predefined set structure, the command content and data generation structure corresponding to the structure elements are encapsulated into a hardware programming language simulation data structure corresponding to the command to be tested.

5. The chip verification method according to any one of claims 1-3, characterized in that, The method further includes: In response to the modification operation of the configuration file, the modified configuration file is re-parsed to obtain the parsing result of the modified configuration file, and then the process jumps to the step of generating the hardware programming language simulation data structure corresponding to the chip verification test case based on the parsing result and is re-executed.

6. A chip verification device, characterized in that, include: The acquisition module is configured to acquire the configuration file of the current test scenario; the configuration file contains the constraint strategies involved in the current test scenario according to the set data structure. The constraint strategy is a predefined constraint condition that corresponds to the test requirements. The parsing module is configured to parse the configuration file and obtain the parsing result; The generation module is configured to generate hardware programming language simulation data structures corresponding to chip verification test cases based on the parsing results. The test module is configured to output the hardware programming language simulation data structure to the chip verification platform to verify the chip function in the chip simulation environment. Specifically, the generation module is implemented as follows: Based on the analysis results, a command word hardware programming language simulation data structure is generated; Based on the analysis results, a command frame hardware programming language simulation data structure is generated based on the command word hardware programming language simulation data structure. Based on the analysis results, a data dispersion and aggregation list hardware programming language simulation data structure is generated based on the command frame hardware programming language simulation data structure. Based on the analysis results, a data hardware programming language simulation data structure is generated based on the data dispersion and aggregation list hardware programming language simulation data structure.

7. The chip verification apparatus according to claim 6, characterized in that, The device further includes: The encapsulation module is configured to encapsulate the constraints involved in different testing requirements into constraint policies through policy classes and add them to the constraint policy pool.

8. The chip verification apparatus according to claim 6, characterized in that, The configuration file is a multi-level data structure defined using YAML. The multi-level data structure includes the basic constraint strategy and auxiliary constraint strategy of the command to be tested in the current test scenario.

9. The chip verification apparatus according to any one of claims 6-8, characterized in that, The generation module is implemented as follows: The test command and predefined structural elements for the test command are obtained from the parsing results. The structural elements include command words, command frames, data scattering and aggregation lists, and data. Each structural element is pre-configured with a corresponding basic constraint strategy and / or auxiliary constraint strategy. For each of the structural elements, initial content is randomly generated based on the corresponding basic constraint strategy; If the auxiliary constraint strategy corresponding to the structuring element is not empty and meets the randomization requirement, then the initial content is dynamically adjusted according to the auxiliary constraint strategy to obtain the updated content. Construct the command content or data generation structure corresponding to the structural element based on the initial content or updated content; According to a predefined set structure, the command content and data generation structure corresponding to the structure elements are encapsulated into a hardware programming language simulation data structure corresponding to the command to be tested.

10. The chip verification apparatus according to any one of claims 6-8, characterized in that, The device further includes: The response module is configured to respond to a modification operation on the configuration file by re-parseing the modified configuration file, obtaining the parsing result of the modified configuration file, and then jumping to the generation module for re-execution.

11. A chip verification system, characterized in that, include: YMAL configuration system, data generation system, and chip verification platform; The YMAL configuration system is used by testers to write configuration files for the current test scenario; The data generation system is used to generate a hardware programming language simulation data structure according to the configuration file, and output the hardware programming language simulation data structure to the chip verification platform; the hardware programming language simulation data structure is obtained based on the method described in any one of claims 1-5; The chip verification platform is used to verify chip functionality by simulating data structures based on the hardware programming language in a chip simulation environment.

Images