Chip verification method, device and system

Abstract

The invention provides a chip verification method, device and system. The method comprises the following steps: acquiring a configuration file of a current test scene; a constraint strategy involved in the current test scene is configured in the configuration file according to a set data structure; the constraint strategy is a predefined constraint condition corresponding to the test requirement; analyzing the configuration file to obtain an analysis result; generating a hardware programming language simulation data structure corresponding to the chip verification case based on the analysis result; and outputting the hardware programming language simulation data structure to a chip verification platform so as to perform chip function verification in a chip simulation environment. According to the automatic generation and configuration method of the test case in the technical scheme of the invention, the user friendliness of the verification environment is remarkably improved, so that a verification team is assisted to quickly master and efficiently utilize the verification environment.

Description

Technical Field

[0001] The present application belongs to the field of chip technology, and in particular relates to a chip verification method, device and system. Background Art

[0002] In chip verification, randomization is an important means of generating test data. In related technologies, verification engineers generate data by defining random fields of related extension classes such as uvm_sequence_item, setting static constraints, and calling random generation methods to build complex test scenarios. Summary of the invention

[0003] The purpose of this application is to provide a chip verification method, device and system, aiming to solve the problems of insufficient management, reuse and flexibility of chip verification methods in related technologies.

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

[0005] Obtaining a configuration file of the current test scenario; in the configuration file, the constraint strategy involved in the current test scenario is configured according to a set data structure; the constraint strategy is a predefined constraint condition corresponding to the test requirement;

[0006] Parsing the configuration file to obtain a parsing result;

[0007] Generate a hardware programming language simulation data structure corresponding to the chip verification use case based on the analysis results;

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

[0009] This application can reuse the same configuration and constraints in different test scenarios through chip architecture Spec level design, configuration-based test case construction, and centrally managed constraint strategies, thereby reducing code duplication, improving verification reusability, simplifying the management of verification test cases, and improving test efficiency and scenario coverage; in addition, this application simplifies the learning process for verifiers by separating configuration and constraints. New team members can set up test scenarios through simple configuration files without having to deeply understand the underlying constraint implementation. The automatic generation and configuration method of test cases significantly improves the user-friendliness of the verification environment, thereby helping the verification team to quickly master and efficiently use the verification environment.

[0010] In an optional embodiment, the method further comprises:

[0011] The constraints involved in different test 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 constraint logic in a policy pool. Verifiers only need to update constraints in the policy pool without modifying specific test case codes, thus reducing maintenance workload.

[0013] In an optional implementation, the step of generating a hardware programming language simulation data structure corresponding to a chip verification use case based on the analysis result includes:

[0014] Based on the analysis result, generating a command word hardware programming language simulation data structure;

[0015] Based on the analysis result, on the basis of the command word hardware programming language simulation data structure, a command frame hardware programming language simulation data structure is generated;

[0016] Based on the analysis result, on the basis of the command frame hardware programming language simulation data structure, generating a data scatter-gather list hardware programming language simulation data structure;

[0017] Based on the analysis result, a data hardware programming language simulation data structure is generated on the basis of the data scatter-gather list hardware programming language simulation data structure. This implementation configures constraints through a YAML file, and generates a hardware programming language simulation data structure after parsing the configured constraints. This method is no longer completely dependent on the hardware description language, and is more flexible in form and no longer restricted to the content of the chip architecture. Therefore, dynamic adaptation of constraints can be achieved, so that the generator can respond to different chip architectures and test requirements, 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, and the multi-level data structure includes a basic constraint strategy and an auxiliary constraint strategy for the command to be tested in the current test scenario.

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

[0020] In an optional implementation, generating a hardware programming language simulation data structure corresponding to a chip verification use case based on the analysis result includes:

[0021] Acquire the command to be tested in the analysis result and the structural elements pre-defined for the command to be tested; the structural elements include command words, command frames, data scattering and gathering lists and data; each of the structural elements is pre-configured with a corresponding basic constraint strategy and / or auxiliary constraint strategy;

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

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

[0024] Constructing command content or data generation structure corresponding to the structural element according to the initial content or the updated content;

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

[0026] This implementation method can simulate more complex scenarios and achieve more comprehensive verification by supporting multiple protocols and command combinations.

[0027] In an optional embodiment, the method further comprises:

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

[0029] This implementation supports dynamic adjustment of test configuration in the configuration file, quickly switches test scenarios, avoids repeated compilation of the verification platform, and greatly improves verification efficiency.

[0030] According to a second aspect of the present application, a chip verification device is provided, including:

[0031] An acquisition module is configured to acquire a configuration file of a current test scenario; the configuration file configures a constraint strategy involved in the current test scenario according to a set data structure; the constraint strategy is a predefined constraint condition corresponding to the test requirement;

[0032] A parsing module is configured to parse the configuration file to obtain a parsing result;

[0033] A generation module is configured to generate a hardware programming language simulation data structure corresponding to the chip verification case based on the analysis result;

[0034] The test module is configured to output the hardware programming language simulation data structure to a chip verification platform so as to verify the chip function in a chip simulation environment.

[0035] In an optional embodiment, the device further comprises:

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

[0037] In an optional implementation manner, the generating module is implemented as follows:

[0038] Based on the analysis result, generating a command word hardware programming language simulation data structure;

[0039] Based on the analysis result, on the basis of the command word hardware programming language simulation data structure, a command frame hardware programming language simulation data structure is generated;

[0040] Based on the analysis result, on the basis of the command frame hardware programming language simulation data structure, generating a data scatter-gather list hardware programming language simulation data structure;

[0041] Based on the analysis result, a data hardware programming language simulation data structure is generated on the basis of the data scatter-gather list hardware programming language simulation data structure.

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

[0043] In an optional implementation manner, the generating module is implemented as follows:

[0044] Acquire the command to be tested in the analysis result and the structural elements pre-defined for the command to be tested; the structural elements include command words, command frames, data scattering and gathering lists and data; each of the structural elements is pre-configured with a corresponding basic constraint strategy and / or auxiliary constraint strategy;

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

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

[0047] Constructing command content or data generation structure corresponding to the structural element according to the initial content or the updated content;

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

[0049] In an optional embodiment, the device further comprises:

[0050] The response module is configured to, in response to the modification operation on the configuration file, re-parse the modified configuration file, obtain the parsing result of the modified configuration file, and jump to the generation module for re-execution.

[0051] According to a third aspect of the present 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 for 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 functions based on the hardware programming language simulation data structure in a chip simulation environment.

[0055] Other features and advantages of the present application will be described in the following description, and partly become apparent from the description, or be understood by practicing the present application. The purpose and other advantages of the present application can be realized and obtained through the structures and processes indicated in the description and the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related technologies, the drawings required for use in the embodiments or the related technical descriptions are briefly introduced below. It is obvious that the drawings described below are certain embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0057] Figure 1 It is a flowchart of a chip verification method according to an exemplary embodiment of the present application.

[0058] Figure 2 It is a conceptual diagram of a chip verification process according to an exemplary embodiment of the present application.

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

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

[0061] Figure 5 It is a framework diagram of the implementation process of each generation module according to the exemplary embodiment of the present application.

[0062] Figure 6 is a structural block diagram of a chip verification device according to an exemplary embodiment of the present application.

[0063] Figure 7 is a structural block diagram of a chip verification system according to an exemplary embodiment of the present application. DETAILED DESCRIPTION

[0064] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

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

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

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

[0068] 3. Inline constraints: Dynamically adjust constraints to adapt to different testing requirements, but complex inline constraints are difficult to maintain.

[0069] In the IO command verification of storage chips, randomization methods are used to generate a large number of test cases to verify the integrity of the command sequence. The implementation steps of the relevant technology include: decomposing the command structure (such as CMDWORD, CMD_Frame, SGL, Data), using Sequence objects to build command sequences, and dynamically adjusting constraints to generate specific commands. However, as the complexity of the scene increases, these methods are prone to problems such as difficult management, low code reusability, and difficult maintenance.

[0070] In chip verification methods, the randomization process and constraint strategy of related technologies generally have the following major 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 between different scenarios and modules. Due to the lack of a strategy reuse mechanism, verification engineers need to redefine or adjust constraints whenever test requirements change, and cannot share consistent constraint logic in multiple scenarios, resulting in poor code reusability.

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

[0074] 2. Code redundancy

[0075] 1) Too many derived classes: In order to meet specific test requirements, verification engineers usually need to create derived classes for each new scenario and define specialized 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, high code duplication, and difficulty in unified management.

[0076] 2) Multi-level duplicate code: In large chip verification projects, test cases in different modules often contain duplicate code fragments. Even simple sequence generation may contain redundant code, which affects the readability of the code and has an adverse impact on maintenance.

[0077] 3. Difficulty in maintenance

[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 lengthy, 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 constructors need to spend a lot of time learning and understanding the detailed implementation of each object, which increases the time cost of constructing test cases. This extended learning curve is particularly detrimental to new engineers' rapid start-up and collaboration.

[0080] 4. Poor adaptability of verification platform

[0081] 1) Inefficient scene switching: During the verification process, since related technologies rely on static configuration, when the test scene needs to be switched or the test conditions change, the verification platform often needs to be compiled repeatedly. This mode not only increases the platform's running time, but also affects the 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 difficulty of maintaining the test platform and limits the applicability of the verification platform in different projects.

[0083] Policy-based Constraints was proposed by John Dickol in 2015. It provides a more flexible management method by encapsulating constraints as policy classes. This method supports the reuse of constraints in different test scenarios, reduces code redundancy, and makes the verification process more flexible and easier to maintain.

[0084] As a data serialization format, YAML has the characteristics of concise structure and strong readability, and is suitable for use as a configuration file. Compared with XML and JSON, YAML is more intuitive, supports complex data structures, and is easy to manage. This application combines Policy-based Constraints and YAML configuration files to improve the reusability, flexibility, and maintainability of the verification process, making the verification work more efficient.

[0085] Based on the above analysis, see Figure 1 , the present application exemplarily proposes a chip verification method, including:

[0086] Step 101: Obtain a configuration file of the current test scenario; in the configuration file, configure the constraint strategy involved in the current test scenario according to a set data structure; the constraint strategy is a predefined constraint condition corresponding to the test requirement;

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

[0088] Step 103: Generate a hardware programming language simulation data structure corresponding to the chip verification use case based on the analysis result;

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

[0090] Exemplarily, the configuration file can be configured by the tester in advance according to the current test scenario, and can be configured through a YAML file on the YMAL configuration system. The configuration file is configured according to the set data structure, including configuring the constraint strategy. The constraint strategy can be understood as the various functional characteristics of the verification requirements 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 specification layer of the chip architecture (including HAS and MAS specifications), that is, first constructing a constraint strategy pool (Constraints Po1icy Pool) through a data structure (such as cmdword command word, cmdFrame command frame, SGL scatter-gather list, etc.), and providing a flexible constraint reuse method through the encapsulation of the strategy class. Among them, the strategy pool contains various constraint strategies that represent the functional characteristics of the verification requirements.

[0091] For example, this application builds a centrally managed constraint strategy pool, which allows multiple verification scenarios to reuse the same constraint strategy, reducing code redundancy. Through the constraint strategy pool, different constraint strategies 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, organizing the basic structure of each test scenario and the constraint strategy mapping. The YAML file lists various constraint strategies (such as base_policy basic constraint strategy, cmdFrame_policy command frame strategy, etc.) and operations (such as cmd_send_abort, cmd_do_write, etc.), and each constraint strategy corresponds to different test requirements. Test cases can directly call these constraint strategies through configuration files to form multi-level scenario control and support complex IO verification scenario construction.

[0093] Exemplarily, the present application may use SV (system verilog, a hardware programming language) to construct a YAML language parser in advance in the data generation system so as to convert the YAML configuration file into an SV simulation data structure.

[0094] Exemplarily, multiple test pattern generators can be pre-constructed in the data generation system, and each test pattern generator is composed of multiple generation modules, including Cmdword Gen (command word generation module), CmdFrame Gen (command frame generation module), SGL Gen (scatter-gather 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] Exemplarily, each generation module is responsible for the generation of specific data to support multiple protocols and operational requirements. In complex tests, the generator automatically generates data streams for multiple test cases by combining various configurations and constraints to ensure comprehensive verification and scenario coverage. The final generated test cases are transmitted to the TestBench (chip verification platform) environment through the test pattern generator to perform various verifications. After receiving the test cases, TestBench can execute various operations in the test cases, verify different IO commands and their behaviors, and ensure the correctness of chip functions under various conditions.

[0096] This application achieves high flexibility and reusability of verification scenarios through chip architecture Spec level design, YAML-configured test case construction, centrally managed constraint strategy pool, modular test pattern generator, etc. Through YAML file configuration and strategy pool reuse, the management of verification test cases is simplified, duplicate code is reduced, and test efficiency and scenario coverage are improved.

[0097] In some optional embodiments, the method further comprises:

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

[0099] Exemplarily, as described above, constraint policies need to be predefined and added to the constraint policy pool after being encapsulated by the policy class. Testers configure the encapsulated constraint policies in the policy pool in the configuration file to meet the test requirements according to the test requirements. This application simplifies the management and maintenance of complex constraints by encapsulating the 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 the maintenance workload.

[0100] Exemplarily, the present application designs specific constraints for each element (various concepts defined in the chip architecture) that will be used in the test requirements in the data generation system according to the specifications of the chip architecture. Through a reasonable abstraction level, the constraints with greater relevance are uniformly processed, and the irrelevant constraints are separated, thereby encapsulating them into different constraint strategies to ensure the flexibility of random combinations. Through this design, complex constraints are decomposed into a simple hierarchical structure for subsequent maintenance and reuse. Finally, a policy constraint pool of the characteristics corresponding to the chip is formed in the simulation database of SV, which is used to map and select the constraint strategies in the configuration file input by YAML.

[0101] In some optional implementations, the step of generating a hardware programming language simulation data structure corresponding to the chip verification use case based on the analysis result includes:

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

[0103] Based on the analysis result, 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 result, generating a data scatter-gather list hardware programming language simulation data structure on the basis of the command frame hardware programming language simulation data structure;

[0105] Based on the parsing result, a data hardware programming language simulation data structure is generated on the basis of the data scatter gather list hardware programming language simulation data structure.

[0106] For example, Figure 2 As shown, the data generation system of the present application pre-maps the feature feature defined in the HAS (Hardware Abstraction Layer) specification and MAS (Micro-Architecture Specification) of the chip architecture to the data structure implemented by the hardware programming language SV, including 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-gather list hardware programming language simulation data structure corresponding to the scatter-gather list SGL, and a data hardware programming language simulation data structure corresponding to the data Data generated. The mapping can be understood as a mapping from natural language to machine language.

[0107] As mentioned above, constraint strategies are organized according to constraint strategy pools. In a YAML configuration file, test scenarios can be constructed. One configuration file can configure one or more test scenarios. In each test scenario, corresponding constraint strategies (including basic constraint strategies and auxiliary constraint strategies) can be generated and configured for command words, command frames, scatter-gather lists SGL, and data Data, as well as other related elements, such as the number of command frames, the definition of other related elements of subdivision (that is, other features defined in the specification). The constraint strategies configured in the configuration file are constraint strategies that are pre-encapsulated into classes and managed and maintained by the constraint strategy pool. The constraint strategy pool is designed in the form of modules for configuration and calling in the configuration file. Different test scenarios can combine different constraint strategies in the constraint strategy pool, so that these constraint strategies can be reused. Code duplication is reduced and the reusability of verification is improved. The modular design of the constraint strategy pool enables constraint strategies to be flexibly combined and called to support multi-scenario testing requirements. At the same time, through flexible strategy pools and configuration files, multiple protocols and command combinations are supported, which can simulate more complex scenarios and achieve more comprehensive verification. In addition, the constraints in the strategy pool are configured through YAML files and are no longer completely dependent on hardware description languages, such as SV language. They are more flexible in form and are no longer restricted to the content of the chip architecture. Therefore, dynamic adaptation of constraints can be achieved, allowing the generator to cope with different chip architectures and testing requirements, thereby improving the adaptability and flexibility of the chip verification platform.

[0108] In a specific test process, the data generation system can obtain a configuration file from the YAML configuration system and provide the configuration file to a pre-generated test pattern generator (Test pattern Generator), which parses the test scenarios in the above configuration file and provides the parsing results to the command word generation module, the command frame generation module, the SGL generation module and the Data generation module. The command word generation module first generates a command word hardware programming language simulation data structure based on the constraint strategy and other related elements in the parsing results, and then provides the command word hardware programming language simulation data structure to the command frame generation module. The command frame generation module generates a command frame hardware programming language simulation data structure based on the parsing results based on the command word hardware programming language simulation data structure. The command frame generation module further provides the command frame hardware programming language simulation data structure to the SGL generation module. The SGL generation module further generates a data dispersion aggregation list hardware programming language simulation data structure based on the parsing results based on the command frame hardware programming language simulation data structure, and provides the data dispersion aggregation list hardware programming language simulation data structure to the Data generation module. The Data generation module generates a data hardware programming language simulation data structure based on the parsing results based on the data dispersion aggregation list hardware programming language simulation data structure. The hardware programming language simulation data structure generated above is pushed to the IO_INFOQueue for queuing, waiting to be passed to the chip verification platform TestBench for verification. The IO_INFO Queue is a command buffer that ensures that all generated commands can enter the verification environment in a certain order, which is convenient for subsequent testing and data analysis. The design of the IO command queue ensures that the generated test pattern is passed to the TestBench on demand, reducing the waiting time in the test process.

[0109] For example, Figure 3 As shown, the data format of the YAML configuration file can also be pre-defined in this application as the input of the generation module: use the YAML configuration file to define a multi-level data structure, and use the configuration file as input to constrain the behavior of the generation module. Set key parameters 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 and other information to control the constraints and data generation of the generation module. Exemplarily, 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, and the multi-level data structure includes a basic constraint strategy and an auxiliary constraint strategy for the command to be tested in the current test scenario.

[0111] For example, Figure 2 As shown, the YAML configuration file can be configured into a multi-level data structure. The data structure corresponding to the same test scenario can be configured with constraint strategies configured for different structural elements, other related elements, etc. The constraint strategy includes the basic constraint strategy and auxiliary constraint strategy for the command to be tested in the test scenario. The YAML configuration file in this application has a clear structure, which is convenient for intuitive configuration and adjustment of test scenarios, and reduces the difficulty of maintenance.

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

[0113] Obtain the command to be tested in the parsing result and the structural elements pre-defined for the command to be tested; the structural elements include command words, command frames, data scattering and gathering lists and data; each structural element is pre-configured with a corresponding basic constraint strategy and / or auxiliary constraint strategy;

[0114] For each structural element, the 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 requirements, the initial content is dynamically adjusted according to the auxiliary constraint strategy to obtain the updated content;

[0116] Construct command content or data generation structure corresponding to the structural element according to the initial content or updated content;

[0117] According to the predefined setting 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] Exemplarily, the hardware programming language simulation data structure corresponding to the chip verification use case can be as follows: Figure 4 As shown, it includes the configured command words, command frames, data scatter-gather list SGL and data Data and other structural elements. Each structural element can define the corresponding constraint strategy pool according to the multi-level structure, as well as the basic constraint strategy and auxiliary constraint strategy in the constraint strategy pool. The basic constraint strategy and auxiliary constraint strategy of each structural element in the current test scenario are configured in the configuration file.

[0119] Exemplarily, the command word generation module, command frame generation module, SGL generation module and Data generation module are all based on Figure 5 The process shown generates the corresponding command content or data generation structure, including:

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

[0121] The Base Random module is the starting point of each generation module and is used to generate initial content according to the randomization conditions of the configured basic constraint strategy. In this step, the initial content is created according to the set command template through the basic random generation mechanism as the basis for the next generation module processing. Among them, the initial content is the command content or data generation structure. The command content is created for the command word, command frame and SGL, and the data generation structure is created for Data.

[0122] 2. Out Constraints random (external constraints random selection):

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

[0124] 3. Content_update (content update):

[0125] The content_update module is used to dynamically update the initial content generated in the previous step according to the requirements of external constraints. This process ensures that the generated data meets the specific constraints of the test case. This module can adjust the generated command content or data in real time to meet specific test requirements based on the constraint strategy defined in the strategy pool or a specific YAML configuration.

[0126] 4. Content (content generation): After the initial content is created (the auxiliary constraint policy is not configured, or the initial content does not need to be updated according to the auxiliary constraint policy) or the content is updated, the Content module generates the final command content or data generation structure. This module builds the command content or data generation structure of the complete 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 generation structure and encapsulates it into a complete IO command structure, such as Figure 3 The command structure shown in FIG. This command structure contains necessary IO command elements, such as Cmdword, CmdFrame, SGL, and Data, so that the command to be tested can be directly used in the subsequent test process.

[0129] 6. Next_Gen (next generation):

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

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

[0132] The final generated IO command structure is pushed to the IO_INFO Queue for queuing, waiting to be passed to the chip verification platform TestBench for verification. This IO command queue design ensures that the generated test pattern is passed to the TestBench on demand, reducing the waiting time in the test process.

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

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

[0135] Exemplarily, testers can also implement scene switching by modifying the YAML configuration file on the YMAL configuration system: different test scenarios are generated by changing the YAML file configuration, without the need to repeatedly compile the chip verification platform and test cases. This method allows for quick switching of test scenarios without changing the underlying code, thereby improving verification efficiency. This method of scene switching not only saves compilation time, but also greatly improves the flexibility and adaptability of the verification platform. This application simplifies the learning process for verifiers by separating configuration and constraints. New team members can set up test scenarios through simple YAML configuration files without having to deeply understand the underlying constraint implementation. The automatic generation and configuration of test cases makes the verification environment easier to use, helping the verification team get started faster.

[0136] The test cases generated by the embodiments of the present application allow users to easily organize test cases without having to understand the specific underlying constraints and configurations. The final test cases are centered on a unified IO generator, combined with YAML configuration and policy pool to form a complete verification system, thereby improving the reusability and ease of use of the test cases.

[0137] Accordingly, if Figure 6 As shown, the present application exemplarily provides a chip verification device, including:

[0138] The acquisition module 601 is configured to acquire a configuration file of the current test scenario; the configuration file configures the constraint strategy involved in the current test scenario according to a set data structure; the constraint strategy is a predefined constraint condition corresponding to the test requirement;

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

[0140] A generating module 603 is configured to generate a hardware programming language simulation data structure corresponding to the chip verification use case based on the parsing result;

[0141] The testing module 604 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.

[0142] In some optional implementations, the device further includes:

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

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

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

[0146] Based on the analysis results, the command frame hardware programming language simulation data structure is generated on the basis of the command word hardware programming language simulation data structure:

[0147] Based on the parsing result, generating a data scatter-gather list hardware programming language simulation data structure on the basis of the command frame hardware programming language simulation data structure;

[0148] Based on the parsing result, a data hardware programming language simulation data structure is generated on the basis of the data scatter gather list hardware programming language simulation data structure.

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

[0150] In some optional implementations, the generating module is implemented as follows:

[0151] Obtain the command to be tested in the parsing result and the structural elements pre-defined for the command to be tested; the structural elements include command words, command frames, data scattering and gathering lists and data; each structural element is pre-configured with a corresponding basic constraint strategy and / or auxiliary constraint strategy;

[0152] For each structural element, the 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 requirements, the initial content is dynamically adjusted according to the auxiliary constraint strategy to obtain the updated content;

[0154] Construct command content or data generation structure corresponding to the structural element according to the initial content or updated content;

[0155] According to the predefined setting 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 optional implementations, the device further includes:

[0157] The response module is configured to respond to the modification operation on the configuration file, re-parse the modified configuration file, obtain the parsing result of the modified configuration file, and jump to the generation module for re-execution.

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

[0159] Accordingly, if Figure 7 As shown, the present application exemplarily provides a 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 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 above chip verification method;

[0162] The chip verification platform is used to verify chip functions based on hardware programming language simulation data structure in a chip simulation environment.

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

[0164] It is understood that the circuit structures, names and elements described in the above embodiments are only examples. Those skilled in the art can also easily combine and adjust the structural features of the above embodiments according to the use requirements, and should not limit the concept of the present application to the specific details of the above examples.

[0165] Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that he or she may still modify the technical solutions described in the aforementioned embodiments, or make equivalent substitutions for some of the technical features therein; 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 the present application.

Claims

1. A chip verification method, characterized in that: include: Obtaining a configuration file for the current test scenario; configuring the constraint strategy involved in the current test scenario in the configuration file according to a set data structure; The constraint strategy is a predefined constraint condition corresponding to the test requirements; Parsing the configuration file to obtain a parsing result; Generate a hardware programming language simulation data structure corresponding to the chip verification use case based on the analysis results; The hardware programming language simulation data structure is output to a chip verification platform to verify the chip function in a chip simulation environment.

2. The chip verification method according to claim 1, characterized in that: The method further comprises: The constraints involved in different test 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 generating of a hardware programming language simulation data structure corresponding to the chip verification use case based on the analysis result includes: Based on the analysis result, generating a command word hardware programming language simulation data structure; Based on the analysis result, on the basis of the command word hardware programming language simulation data structure, a command frame hardware programming language simulation data structure is generated; Based on the analysis result, on the basis of the command frame hardware programming language simulation data structure, generating a data scatter-gather list hardware programming language simulation data structure; Based on the analysis result, a data hardware programming language simulation data structure is generated on the basis of the data scatter-gather list hardware programming language simulation data structure.

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

5. The chip verification method according to any one of claims 1 to 4, characterized in that: The generating of a hardware programming language simulation data structure corresponding to the chip verification use case based on the analysis result includes: Acquire the command to be tested in the analysis result and the structural elements pre-defined for the command to be tested; the structural elements include command words, command frames, data scattering and gathering lists and data; each of the structural elements is pre-configured with a corresponding basic constraint strategy and / or auxiliary constraint strategy; For each of the structural elements, randomly generating initial content based on the corresponding basic constraint strategy; If the auxiliary constraint strategy corresponding to the structural element is not empty and meets the randomization requirement, dynamically adjusting the initial content according to the auxiliary constraint strategy to obtain updated content; Constructing command content or data generation structure corresponding to the structural element according to the initial content or the updated content; According to a predefined setting structure, the command content and the data generation structure corresponding to the structural element are encapsulated into a hardware programming language simulation data structure corresponding to the command to be tested.

6. The chip verification method according to any one of claims 1 to 4, characterized in that: The method further comprises: In response to the modification operation on the configuration file, the modified configuration file is re-parsed to obtain the parsing result of the modified configuration file, and the step of generating a hardware programming language simulation data structure corresponding to the chip verification use case based on the parsing result is jumped to and re-executed.

7. A chip verification device, characterized in that: include: An acquisition module is configured to acquire a configuration file of a current test scenario; the configuration file configures the constraint strategy involved in the current test scenario according to a set data structure; The constraint strategy is a predefined constraint condition corresponding to the test requirements; A parsing module is configured to parse the configuration file to obtain a parsing result; A generation module is configured to generate a hardware programming language simulation data structure corresponding to the chip verification case based on the analysis result; The test module is configured to output the hardware programming language simulation data structure to a chip verification platform so as to verify the chip function in a chip simulation environment.

8. The chip authentication device according to claim 7, characterized in that: The device also includes: The encapsulation module is configured to encapsulate the constraints involved in different test requirements into constraint policies through policy classes and add them to the constraint policy pool.

9. The chip authentication device according to claim 7, characterized in that: The generation module is implemented as follows: Based on the analysis result, generating a command word hardware programming language simulation data structure; Based on the analysis result, on the basis of the command word hardware programming language simulation data structure, a command frame hardware programming language simulation data structure is generated; Based on the analysis result, on the basis of the command frame hardware programming language simulation data structure, generating a data scatter-gather list hardware programming language simulation data structure; Based on the analysis result, a data hardware programming language simulation data structure is generated on the basis of the data scatter-gather list hardware programming language simulation data structure.

10. The chip authentication device according to claim 7, characterized in that: The configuration file is a multi-level data structure defined using YAML, and the multi-level data structure includes a basic constraint strategy and an auxiliary constraint strategy for the command to be tested in the current test scenario.

11. The chip verification device according to any one of claims 7 to 10, characterized in that: The generation module is implemented as follows: Acquire the command to be tested in the analysis result and the structural elements pre-defined for the command to be tested; the structural elements include command words, command frames, data scattering and gathering lists and data; each of the structural elements is pre-configured with a corresponding basic constraint strategy and / or auxiliary constraint strategy; For each of the structural elements, randomly generating initial content based on the corresponding basic constraint strategy; If the auxiliary constraint strategy corresponding to the structural element is not empty and meets the randomization requirement, dynamically adjusting the initial content according to the auxiliary constraint strategy to obtain updated content; Constructing command content or data generation structure corresponding to the structural element according to the initial content or the updated content; According to a predefined setting structure, the command content and the data generation structure corresponding to the structural element are encapsulated into a hardware programming language simulation data structure corresponding to the command to be tested.

12. The chip verification device according to any one of claims 7 to 10, characterized in that: The device also includes: The response module is configured to, in response to the modification operation on the configuration file, re-parse the modified configuration file, obtain the parsing result of the modified configuration file, and jump to the generation module for re-execution.

13. A chip verification system, characterized in that: include: YMAL configuration system, data generation system and chip verification platform; The YMAL configuration system is used for 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 to 6; The chip verification platform is used to verify chip functions based on the hardware programming language simulation data structure in a chip simulation environment.

Images