Chip Verification System, Method and Verification Device Based on Generative Constraint Model

Abstract

The present application provides a chip verification system, method and verification device based on a generative constraint model. After the model generation module of the system obtains a test case in text form, it determines the generative constraint model by parsing the test case. The model includes constraint conditions for testing the to-be-tested functions of the chip and register configuration values of the registers for executing the to-be-tested functions. The register configuration module configures the register configuration values into the registers according to the constraint conditions so that the chip design module can execute the to-be-tested functions. The data transmission module receives the result after executing the to-be-tested functions and compares the result with the standard result for each sub-module. The entire simulation process runs on a hardware accelerator, and a simulation report is generated after the operation ends. Through the present application, the testing of the chip functions can be realized, and the test cases applied are in text form, so that the test cases can be obtained without compiling the code, improving the efficiency of obtaining the test cases and correspondingly improving the efficiency of chip verification.

Description

Technical Field

[0001] This application belongs to the field of chip verification, and particularly relates to a chip verification system, method and verification device based on a generative constraint model. Background Art

[0002] A test case is a set of register configuration schemes developed to detect the functional correctness of a chip design. Usually, a simulation environment needs to pass through test cases to achieve the test of the chip function.

[0003] Test cases usually come from manual development by test case engineers. Each test case is usually implemented by dozens of lines of code, and the large number of test cases leads to a large amount of test case code. For example, assuming that each test case includes 30 lines of code, if 30,000 test cases are required to test some functions of the chip, the corresponding test cases reach 900,000 lines of code. Further, due to the large amount of test case code, the compilation process of test cases takes a lot of time, greatly slowing down the compilation speed and reducing the efficiency of testing the chip function. Summary of the Invention

[0004] In the prior art, when testing the function of a chip, since the test case can only be executed after code compilation and the amount of test case code is large, the overall compilation process of the test case is time-consuming, greatly slowing down the compilation speed and reducing the efficiency of testing the chip function. To solve this technical problem, the embodiments of this application provide a chip verification system, method and verification device based on a generative constraint model.

[0005] In a first aspect, this application discloses a chip verification system based on a generative constraint model. The system runs in a hardware accelerator and includes:

[0006] A model generation module, a register configuration module, a data transmission module and a bisection module;

[0007] The model generation module is used to generate a generative constraint model corresponding to the test case by parsing the test case after obtaining the test case in text form. The generative constraint model includes the constraint conditions corresponding to testing the to-be-tested function of the chip and the register configuration values corresponding to the registers for executing the to-be-tested function;

[0008] The register configuration module is used to configure the register configuration values into the registers according to the constraint conditions so that the registers execute the to-be-tested function according to the register configuration values;

[0009] The data transmission module is used to receive the result after the register executes the to-be-tested function;

[0010] The bisection module is used to compare the result received by the data transmission module with the standard result, so that the hardware accelerator generates a simulation report according to the comparison result.

[0011] In a feasible design, the model generation module includes:

[0012] A test case parsing component, a model determination component, and a model activation component;

[0013] The test case parsing component is used to parse the test case in text form to obtain corresponding parsing information, where the parsing information includes the corresponding parameters of the generative constraint model and the register configuration value, and the corresponding parameters include the constraint conditions corresponding to each node in the generative constraint model;

[0014] The model determination component is used to determine the architecture of the generative constraint model according to the corresponding parameters of the generative constraint model;

[0015] The model activation component is used to configure the register value for the architecture, and determine the generative constraint model by performing a randomization process on the configured architecture.

[0016] In a feasible design, the model determination component includes: a model generation component and a model growth component;

[0017] The model generation component is used to generate an initialization model;

[0018] The model growth component is used to determine the architecture of the generative constraint model according to the corresponding parameters of the generative constraint model, and add the constraint conditions to the architecture of the generative constraint model.

[0019] In a feasible design, the model activation component includes: a node activation component and a randomization component;

[0020] The node activation component is used to configure each node in the architecture of the generative constraint model according to the register configuration value;

[0021] The randomization component is used to perform a randomization process on the architecture of the generative constraint model after configuring each node to determine the generative constraint model.

[0022] In a feasible design, the generative constraint model is a tree structure, and the tree structure includes at least two layers of nodes;

[0023] If the tree structure includes two layers of nodes, the tree structure includes an ordinary constraint layer and a core constraint layer located below the ordinary constraint layer;

[0024] If the tree structure includes three layers of nodes, the tree structure includes a general constraint layer, a core constraint layer located below the general constraint layer, and a sub-constraint layer located below the core constraint layer.

[0025] In a feasible design, the test case includes a first field, a second field, and a third field;

[0026] Wherein, the first field is used to indicate the main name of the test case;

[0027] The second field is used to indicate the corresponding parameters of the generative constraint model;

[0028] The third field is used to indicate the register configuration values corresponding to the nodes of each layer.

[0029] In a feasible design, if the generative constraint model is a tree structure, the corresponding parameters of the generative constraint model further include: the number of layers of the tree structure, the number of nodes in each layer, and the mapping relationship between the parent and child nodes in the tree structure.

[0030] In a second aspect, the present application provides a chip verification method based on a generative constraint model. This method is executed by the chip verification system based on the generative constraint model described in the first aspect. The method includes:

[0031] After the model generation module in the chip verification system based on the generative constraint model obtains the test case in text form, by parsing the test case, it generates a generative constraint model corresponding to the test case. The generative constraint model includes the constraint conditions corresponding to testing the to-be-tested function of the chip, and the register configuration values corresponding to the registers for executing the to-be-tested function;

[0032] The register configuration module in the chip verification system based on the generative constraint model configures the register configuration values into the registers according to the constraint conditions, so that the registers execute the to-be-tested function according to the register configuration values;

[0033] The data transmission module in the chip verification system based on the generative constraint model receives the result after the register executes the to-be-tested function;

[0034] The bisection module in the chip verification system based on the generative constraint model compares the result received by the data transmission module with the standard result, so that the hardware accelerator generates a simulation report according to the comparison result.

[0035] In a third aspect, the present application provides a chip verification device based on a generative constraint model, including:

[0036] The chip verification system based on the generative constraint model described in the first aspect;

[0037] The chip verification device based on the generative constraint model runs in a hardware accelerator.

[0038] In a feasible design, the register to be configured is located within a design module, and the design module communicates with a simulation environment for instruction and data interaction. The chip verification system based on the generative constraint model is located within the simulation environment.

[0039] Through the system provided by the embodiments of the present application, the testing of chip functions can be achieved. Moreover, the test cases applied during the testing of this system are in text form. Therefore, the test cases can be executed without compilation, reducing the workload of the compiler for compilation, and correspondingly improving the efficiency of testing the chip functions.

[0040] Furthermore, in the early stage of chip development, the simulation environment is not yet stable and may require frequent debugging. In the prior art, during debugging, it is often necessary to repeatedly compile the code of the test cases each time, thereby reducing the debugging efficiency. In the solution provided by the embodiments of the present application, the test cases are in text form. Therefore, during the debugging process, there is no need to compile the test cases, thereby improving the debugging efficiency.

[0041] In the prior art, the test cases and the simulation environment are highly coupled, and the codes of the two are interrelated and difficult to separate. Therefore, like the environment construction engineer, the test case engineer needs to master professional skills such as the system verilog language and the uvm framework to develop test cases, which places relatively high requirements on the test case engineer. In the chip verification system based on the generative constraint model provided by the embodiments of the present application, the test cases are in text form, and the test case engineer only needs to write text to develop test cases without programming language skills requirements. Therefore, it is possible to lower the technical threshold for the test case engineer. Correspondingly, this test system has a wide range of application prospects.

[0042] Chip design engineers are often more proficient in the verilog language and the procedural programming concept, but are not familiar with the development scheme of test cases and the object-oriented programming concept. In this case, if a chip design engineer hopes to temporarily modify some test cases for debugging, it is necessary to frequently communicate with the test case engineer about the method of modifying the test cases, increasing the communication cost within the team. However, through the chip verification system based on the generative constraint model provided by the embodiments of the present application, if it is necessary to modify the test cases, only the text corresponding to the test cases needs to be modified, and the difficulty of modifying the test cases is reduced, thereby being able to reduce the communication cost within the team and improve the efficiency of chip design. Brief Description of the Drawings

[0043] To more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0044] Figure 1 Schematic diagram of a chip verification system based on a generative constraint model provided by an embodiment of the present application;

[0045] Figure 2 Schematic diagram of another chip verification system based on a generative constraint model provided by an embodiment of the present application;

[0046] Figure 3 Schematic diagram of another chip verification system based on a generative constraint model provided by an embodiment of the present application;

[0047] Figure 4 Schematic diagram of a chip verification system based on a generative constraint model and a generative constraint model provided by an embodiment of the present application;

[0048] Figure 5 Schematic diagram of a generative constraint model for determining a tree structure of test cases in text form provided by an embodiment of the present application;

[0049] Figure 6 Schematic diagram of another generative constraint model for determining a tree structure of test cases in text form provided by an embodiment of the present application;

[0050] Figure 7 Schematic diagram of another generative constraint model for determining a tree structure of test cases in text form provided by an embodiment of the present application;

[0051] Figure 8 Schematic diagram of the working process of a chip verification method based on a generative constraint model provided by an embodiment of the present application. Detailed implementation manners

[0052] The following will describe the technical solutions in the embodiments of the present application with reference to the drawings in the embodiments of the present application.

[0053] The terms used in the following embodiments are only for the purpose of describing specific embodiments and are not intended to limit the present application. As used in the specification and appended claims of the present application, the singular forms "a", "an", "the", "above-mentioned", "said", and "this" are also intended to include expressions such as "one or more", unless the context clearly indicates otherwise. It should also be understood that in the following embodiments of the present application, "at least one" and "one or more" mean one, two, or more than two. The term "and / or" is used to describe the association relationship of associated objects and indicates that three relationships can exist; for example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the associated objects before and after are in an "or" relationship.

[0054] References in this specification to "one embodiment" or "some embodiments" or the like mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the present application. Thus, statements such as "in one embodiment", "in some embodiments", "in other some embodiments", "in still other embodiments" and the like that appear in different places in this specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in another way. The terms "comprising", "including", "having" and their variants all mean "including but not limited to", unless otherwise specifically emphasized in another way.

[0055] In the prior art, when testing the functions of a chip, since the test cases are implemented by code and the code volume of the test cases is large, the compilation process of the test cases is time-consuming, which greatly slows down the compilation speed and reduces the efficiency of testing the functions of the chip. To solve this technical problem, the embodiments of the present application provide a chip verification system, method, and verification device based on a generative constraint model.

[0056] Among them, the chip verification system based on the generative constraint model provided by the embodiments of the present application runs in a hardware accelerator. Refer to Figure 1 As shown in the structural schematic diagram, the chip verification system based on the generative constraint model includes: a model generation module 110, a register configuration module 120, a data transmission module 130, and a bisection module 140.

[0057] In a feasible design, the model generation module 110, the register configuration module 120, the data transmission module 130, and the bisection module 140 are located in a simulation environment, and a test case in text form can be loaded into the simulation environment so that the model generation module 110 can parse the test case in text form.

[0058] Among them, the model generation module 110 is used to generate a generative constraint model corresponding to the test case by parsing the test case after obtaining the test case in text form.

[0059] In the solution provided in the embodiments of the present application, the generative constraint model includes the constraint conditions corresponding to testing the to-be-tested function of the chip, and the register configuration values corresponding to the registers for executing the to-be-tested function.

[0060] When testing the to-be-tested function of the chip, the modules in the chip often need to cooperate with each other to implement the to-be-tested function. Among them, a module may include at least one register. In addition, the constraint conditions can be used to indicate which modules need to be in the enabled state and which modules need to be in the closed state during the process of testing the to-be-tested function of the chip. Moreover, the constraint conditions can also be used to indicate the range of the configuration value if the configuration value of the module in the enabled state is randomized. Exemplarily, the constraint condition for a certain module may be that during the process of testing the to-be-tested function of the chip, this module is in the enabled state, the configuration data of this module can be randomized, and the range of its configuration data is less than 5. In this case, according to this constraint condition, it can be determined that this module is in the enabled state during the test, and the configuration value of this module is configured to 4 or other values less than 5.

[0061] A register is a hardware device in the chip, and the functions executed by the chip usually need to be controlled by registers. The register value refers to the value that needs to be applied when the register executes the corresponding operation. For example, if the register is a register for controlling arithmetic operations, the register value may include the values required for performing addition, subtraction, multiplication, and division operations. Different register values represent different operations.

[0062] In addition, the model generation module 110 obtains the generative constraint model through the test case in text form, and this generative constraint model is used to implement the test of the to-be-tested function of the chip. Since the test case is in text form, when using the system provided in the embodiments of the present application for testing, there is no need to compile the test case.

[0063] The register configuration module 120 is used to configure the register configuration value into the register according to the constraint condition, so that the register executes the to-be-tested function according to the register configuration value.

[0064] In an embodiment of the present application, the register configuration module 120 can determine, according to the constraint conditions, which registers need to be in the enabled state when testing the function to be tested, and configure the corresponding register configuration values into the registers that need to be in the enabled state. In this case, after being configured, the registers can start and execute the corresponding function to be tested.

[0065] In a feasible design, each register can be located in the design module. In this case, the register configuration module 120 can perform corresponding configuration on the registers in the design module.

[0066] The data transmission module 130 is used to receive the results after the registers execute the function to be tested. After the registers execute the corresponding function, corresponding results are generated;

[0067] The bisection module 140 is used to compare the results received by the data transmission module with the standard results, so that the hardware accelerator can generate a simulation report according to the comparison results.

[0068] Among them, the standard result is the result obtained after executing the function to be tested when the function to be tested is in good condition. By comparing the results received by the data transmission module with the standard results, the bisection module 140 can detect the correctness of the function executed by the chip. For example, if a certain calculation function of the chip is tested this time, the result received by the data transmission module 130 is 3, while the standard result is 2, and the two are different, it can be determined that the calculation function of the chip is incorrect.

[0069] In addition, since the entire process runs on the hardware accelerator, after the operation is completed, the hardware accelerator can generate the simulation report corresponding to the result. Through this simulation report, the tester can understand the test results of the function to be tested of the chip.

[0070] In a feasible design, each register can be located in the design module. In this case, the data transmission module 130 can perform data interaction with the design module to obtain the results after each register in the design module executes the function to be tested.

[0071] Through the system provided by the embodiment of the present application, the function test of the chip can be realized. Moreover, the test cases applied when the system conducts the test are in text form. Therefore, there is no need to compile the test cases, which improves the overall compilation speed of the simulation system and correspondingly improves the efficiency of testing the chip function.

[0072] Furthermore, in the early stage of chip development, the simulation environment is still unstable and may require frequent debugging. In the prior art, when debugging, a large number of test cases often need to be recompiled, thereby reducing the debugging efficiency. In the solution provided by the embodiments of the present application, the test cases are in text form. Therefore, during the debugging process, it is not necessary to compile the test cases, thus improving the debugging efficiency.

[0073] In the prior art, the test cases and the simulation environment are highly coupled, and their codes are interrelated and difficult to separate. Therefore, like the environment construction engineer, the test case engineer needs to master professional skills such as the system verilog language and the uvm framework to develop test cases, which requires a high level of the test case engineer. In the chip verification system based on the generative constraint model provided by the embodiments of the present application, the test cases are in text form. Therefore, the technical threshold requirements for the test case engineer can be reduced. Correspondingly, the test system has a wide application prospect.

[0074] Chip design engineers are often more proficient in the verilog language and the procedural programming concept, but not familiar with the development scheme of test cases and the object-oriented programming concept. In this case, if a chip design engineer hopes to temporarily modify some test cases for debugging, they need to frequently communicate with the test case engineer about the method of modifying the test cases, increasing the communication cost within the team. However, through the chip verification system based on the generative constraint model provided by the embodiments of the present application, if the test cases need to be modified, only the text corresponding to the test cases needs to be modified, reducing the difficulty of modifying the test cases, thus reducing the communication cost within the team and improving the efficiency of chip design.

[0075] See Figure 2 In the schematic diagram shown, in a feasible design, the model generation module 110 includes: a test case parsing component 111, a model determination component 112, and a model activation component 113.

[0076] Among them, the test case parsing component 111 is used to parse the test cases in text form to obtain corresponding parsing information, and the parsing information includes the corresponding parameters of the generative constraint model and the register configuration values.

[0077] The model determination component 112 is used to determine the architecture of the generative constraint model according to the corresponding parameters of the generative constraint model.

[0078] Among them, the corresponding parameters include the constraint conditions corresponding to each node in the generative constraint model. Moreover, the corresponding parameters may further include parameters indicating the architecture of the generative constraint model. In a feasible design, if the generative constraint model is a tree structure, the generative constraint model can also be referred to as a constraint tree model. In this case, the corresponding parameters can be used to indicate the architecture of the generative constraint model in the form of a tree structure. Exemplarily, in this case, the corresponding parameters of the generative constraint model include: the number of layers of the tree structure, the number of nodes in each layer, the constraint conditions corresponding to each node, and the mapping relationship between the parent and child nodes in the tree structure. Correspondingly, based on the corresponding parameters of the generative constraint model, the architecture of the tree structure can be determined.

[0079] The model activation component 113 is used to configure the register values for the architecture and determine the generative constraint model by performing a randomization process on the configured architecture.

[0080] In the solution provided in the embodiments of the present application, the model determination component 112 can be implemented in various forms. In a feasible design, referring to Figure 3 the schematic diagram shown, the model determination component 112 includes: a model generation component 1121 and a model growth component 1122.

[0081] Among them, the model generation component 1121 is used to generate an initialization model.

[0082] This initialization model generally does not reflect the shape of the model and does not include the constraint conditions corresponding to each module. Exemplarily, if the generative constraint model is a tree structure, the initialization model can be an empty tree.

[0083] In addition, the model generation component 1121 can define the relevant information of the initialization model. For example, methods for adding nodes to the initialization model, methods for adding constraint conditions to the corresponding nodes, methods for traversing the generative constraint model, methods for finding specific nodes in the generative constraint model, and methods for obtaining the corresponding constraint conditions of the node from the node, etc.

[0084] In this case, the register configuration module can traverse the generative constraint model based on the relevant information of the initialization model to determine the constraint conditions corresponding to each node.

[0085] In one example, the generative constraint model is a tree structure, and the generative constraint model can be referred to as a constraint tree model. Each node therein can be referred to as a tree node. In this case, the relevant information of the initialization model defined by the model generation component 1121 may include: a method for adding tree nodes, a method for adding constraint conditions to corresponding data nodes, a method for traversing the constraint tree model, a method for finding specific tree nodes in the constraint tree model, and a method for obtaining the corresponding constraint conditions of tree nodes.

[0086] The model growth component 1122 is configured to determine the architecture of the generative constraint model according to the corresponding parameters of the generative constraint model, and add the constraint conditions to the architecture of the generative constraint model.

[0087] Since the model generation component 1121 defines the relevant information of the initialization model, the model growth component 1122 can determine the architecture of the generative constraint model according to the method of adding nodes to the initialization model indicated by the relevant information, and add the constraint conditions to the architecture of the generative constraint model according to the method of adding constraint conditions to the corresponding nodes indicated by the relevant information. In addition, the subsequent register configuration module can also determine the constraint conditions corresponding to the registers according to the method of traversing the constraint tree model, the method of finding specific tree nodes in the constraint tree model, and the method of obtaining the corresponding constraint conditions of tree nodes indicated in the relevant information, so as to configure the register configuration values into the registers according to the constraint conditions.

[0088] Exemplarily, if the generative constraint model is a tree structure, the corresponding parameters of the generative constraint model include: the number of layers of the tree structure, the number of nodes in each layer, the constraint conditions corresponding to each node, and the mapping relationship between the parent and child nodes in the tree structure. Based on the corresponding parameters, the architecture of the tree structure can be determined, and the constraint relationships corresponding to each node can be determined, so as to obtain the architecture of the generative constraint model with constraint conditions added.

[0089] In the solution provided in the embodiments of the present application, the model activation component 113 can be implemented in various forms. In a feasible design, referring to Figure 3 the schematic diagram shown, the model activation component 113 may include: a node activation component 1131 and a randomization component 1132.

[0090] Among them, the node activation component 1131 is configured to configure each node in the architecture of the generative constraint model according to the register configuration value.

[0091] Exemplarily, if the generative constraint model is a tree structure, in this case, the node activation component 1131 usually needs to configure corresponding register configuration values for the registers corresponding to the nodes (such as the nodes at the lowest layer) in this tree structure.

[0092] The randomization component 1132 is used to perform a randomization process on the architecture of the generative constraint model after configuring each of the nodes, and determine the generative constraint model.

[0093] Through the node activation component 1131 and the randomization component 1132 disclosed in the embodiments of the present application, a generative constraint model can be obtained.

[0094] In a feasible design provided by the embodiments of the present application, the generative constraint model is a tree structure, and the tree structure includes at least two layers of nodes. Among them, the node can also be called a module, a module can include at least one register, and the nodes at the lowest layer of the tree structure can be called child nodes.

[0095] If the tree structure includes two layers of nodes, the tree structure includes a general constraint layer and a core constraint layer located below the general constraint layer, that is, the core constraint layer is a child node of the general constraint layer.

[0096] Among them, the general constraint layer is usually the root node, and the general constraint layer can also be called a general module, which is usually used to perform operations corresponding to the common environment; the core constraint layer can also be called a core module, which is used to perform core operations corresponding to the function to be tested this time. For example, if this test is to test a certain computing function of a chip, the general module can be a module for reading data, and the core module can be a module for calculating the read data.

[0097] If the tree structure includes three layers of nodes, the tree structure includes a general constraint layer, a core constraint layer located below the general constraint layer, and a sub-constraint layer located below the core constraint layer. That is to say, the core constraint layer is a child node of the general constraint layer, and the sub-constraint layer is a child node of the core constraint layer. For example, if this test is to test a certain computing function of a chip, the general module can be a module for reading data, the core module can be a module for performing intermediate calculations on the read data, and the child node can be a module for further calculating the result of the intermediate calculation.

[0098] In the embodiments of the present application, the test case is in text form. In a feasible design, the test case may include: the test case includes a first field, a second field, and a third field. Among them, the first field is used to indicate the main name of the test case; the second field is used to indicate the corresponding parameters in the generative constraint model; the third field is used to indicate the register configuration values corresponding to the nodes of each layer.

[0099] Among them, the first field, the second field, and the third field can be connected by a specific symbol. Exemplarily, the specific symbol can be a hyphen. Additionally, the third field can also be referred to as the leaf activation code.

[0100] The above embodiment provides a chip verification system based on a generative constraint model, which can implement the test of chip functions through test cases in text form. To clarify the advantages of this application, the following further illustrates this test system through another embodiment.

[0101] In this embodiment, the generative constraint model is set as a tree structure, and this tree structure includes three layers. The first layer is the ordinary module layer, including ordinary module 1, ordinary module 2, and ordinary module 3. The core modules include core module 4, core module 5, core module 6, and core module 7. The child nodes of core module 5 include sub-module a, sub-module b, sub-module c, and sub-module d. And, referring to Figure 4 the schematic diagram shown, the chip verification system based on the generative constraint model includes: a model generation module 110, a register configuration module 120, a data transmission module 130, and a bisection module 140. Among them, the model generation module 110 includes: a test case parsing component 111, a model generation component 1121, a model growth component 1122, a node activation component 1131, and a randomization component 1132. The model generation module 110, the register configuration module 120, the data transmission module 130, and the bisection module 140 can be located in a simulation environment.

[0102] The test case parsing component 111 is used to parse the test cases in text form to obtain corresponding parsing information, and the parsing information includes the corresponding parameters of the generative constraint model and the register configuration values. Among them, since the generative constraint model is a tree structure, the corresponding parameters of the generative constraint model include: the number of layers of the tree structure, the number of nodes in each layer, the mapping relationship between the parent and child nodes in the tree structure, and the constraint conditions corresponding to each node.

[0103] In this example, the corresponding parameters of the generative constraint model can indicate that the number of layers of the tree structure is three; the number of nodes in the ordinary module layer of the first layer is 3, the number of nodes in the core module layer of the second layer is 4, and the number of nodes in the sub-module layer of the third layer is 4; each node in the core module layer is a child node of the ordinary module layer, and each node in the sub-module layer is a child node of core module 5; and, the corresponding parameters also include the constraint conditions corresponding to each node.

[0104] The model generation component 1121 is used to generate an initial model. Since the generative constraint model is a tree structure, the initial model generated by the model generation component 1121 is a constraint tree, which is an empty tree with an undetermined shape and without any attached constraint conditions.

[0105] In addition, the model growth component 1122 is used to determine the architecture of the generative constraint model according to the corresponding parameters of the generative constraint model, and add the constraint conditions to the architecture of the generative constraint model. Among them, since the corresponding parameters of the generative constraint model include: the number of layers of the tree structure, the number of nodes in each layer, and the mapping relationship between the parent and child nodes in the tree structure, based on these corresponding parameters, the model growth component 1122 can determine the architecture of the generative constraint model, and then add the constraint conditions to the architecture of the generative constraint model.

[0106] In the corresponding example of this application, the model growth component 1122 can add the constraint conditions corresponding to the ordinary modules to the corresponding ordinary modules, add the constraint conditions corresponding to the core modules to the corresponding core modules, and add the constraint conditions corresponding to the sub-modules to the corresponding sub-modules.

[0107] The node activation component 1131 configures each node in the architecture of the generative constraint model according to the register configuration value, so as to configure some or all of the registers to specific register values.

[0108] The randomization component 1132 is used to perform a randomization process on the architecture of the generative constraint model after configuring each node to determine the generative constraint model. In this example, since the generative constraint model is a tree structure, after the randomization process of the randomization component 1132, a generative constraint model in the form of a constraint tree can be obtained.

[0109] The register configuration module 120 configures the register configuration value to the corresponding register according to the constraint conditions. In this example, since the generative constraint model is a tree structure, the register configuration value is usually configured to the nodes at the bottom layer of the tree structure. The constraint conditions can indicate whether each node needs to be in the enabled state during the test. Therefore, the register configuration module 120 can configure the register value to the nodes at the bottom layer that are in the enabled state.

[0110] After the register in the enabled state is configured with the corresponding value, it will start working and execute the corresponding operation indicated by the function to be tested. In this case, the data transmission module 130 receives the result after the register executes the function to be tested, and the sub-module 140 compares the result received by the data transmission module 130 with the standard result. In addition, the entire simulation process runs on the hardware accelerator device, and after the operation is completed, the hardware accelerator can generate a corresponding simulation report according to the comparison result.

[0111] Through the above embodiments, the chip verification system based on the generative constraint model provided by the embodiments of the present application is introduced. In order to clarify how to parse test cases in text form, the corresponding examples are disclosed below. And in each of the following examples, it is assumed that the generative constraint model is a tree structure, it is assumed that R in the test case represents that the register configuration value of the node is a random value (i.e., rand), and it is assumed that 1 in the second field indicates that the corresponding node is in the enabled state during the test process, and 0 in the second field indicates that the corresponding node is in the closed state during the test process.

[0112] In the first example, it is assumed that the test case in text form is: decodeEncode-101-1001-R53-12345. Refer to Figure 5 As shown in the example diagram, after the test case in text form is transmitted to the chip verification system based on the generative constraint model, the chip verification system based on the generative constraint model can determine that decodeEncode is the first field, which is used to indicate the main name of the test case, 101 and 1001 are the second fields, which are used to indicate the corresponding parameters of the generative constraint model, and R53 and 12345 are the third fields, which are used to indicate the register configuration values corresponding to the nodes at each layer. In addition, R53 and 12345 can also be called leaf activation codes. In this example, R53 and 12345 are the leaf activation codes of different core modules, corresponding to the register configuration values of each register in the core module.

[0113] In addition, according to 101 in the second field, it can be determined that the root node of the generative constraint model includes two layers. The first layer is three ordinary modules, namely ordinary module 1, ordinary module 2, and ordinary module 3. Since the first character and the third character in the 101 field are both 1, it indicates that the constraint conditions corresponding to ordinary module 1 and ordinary module 3 are in the enabled state during the test process. Since the second character in the 101 field is 0, it indicates that the constraint condition corresponding to ordinary module 2 is in the closed state during the test process.

[0114] According to 1001 in the second field, it can be determined that the child nodes of the general module of the generative constraint model include four, namely Core Module 1, Core Module 2, Core Module 3, and Core Module 4. Since the first and fourth characters in the 1001 field are both 1, it indicates that the constraint conditions corresponding to Core Module 1 and Core Module 4 are in the enabled state during the test. Since the second and third characters in the 1001 field are both 0, it indicates that the constraint conditions corresponding to Core Module 2 and Core Module 3 are in the disabled state during the test.

[0115] In addition, R53 in the third field is the register configuration value corresponding to the first core module (i.e., Core Module 1) in the enabled state. Based on this field, it can be determined that the register configuration value of the first register (i.e., Register a) corresponding to Core Module 1 is a random value (i.e., R), the register configuration value of the second register (i.e., Register b) corresponding to Core Module 1 is 5, and the register configuration value of the third register (i.e., Register c) corresponding to Core Module 1 is 3.

[0116] 12345 in the third field is the register configuration value corresponding to the second core module (i.e., Core Module 4) in the enabled state. Based on this field, it can be determined that the register configuration value of the first register (i.e., Register d) corresponding to Core Module 4 is 1, the register configuration value of the second register (i.e., Register e) corresponding to Core Module 4 is 2, the register configuration value of the third register (i.e., Register f) corresponding to Core Module 4 is 3, the register configuration value of the fourth register (i.e., Register g) corresponding to Core Module 4 is 4, and the register configuration value of the fifth register (i.e., Register h) corresponding to Core Module 4 is 5.

[0117] Based on this test case, the model generation module can generate Figure 5 the generative constraint model (i.e., the constraint tree model) in the form of a tree structure shown on the right, and configure the corresponding register configuration values for the registers through the register configuration module so that the configured registers perform corresponding operations. Then, the data transmission module receives the execution results of each register so that the hardware accelerator generates a corresponding simulation report.

[0118] In the second example, the test case in text form is set as: decodeEncode-11-1000-010-3R5. See Figure 6In the example diagram shown, after transmitting the test case in text form to the chip verification system based on the generative constraint model, the chip verification system based on the generative constraint model can determine that decodeEncode is the first field, which is used to indicate the main name of the test case, 11, 1000, and 010 are the second fields, which are used to indicate the corresponding parameters of the generative constraint model, and 3R5 is the third field, which is used to indicate the register configuration values corresponding to each layer of the nodes. Additionally, 3R5 can also be referred to as the leaf activation code. In this example, 3R5 corresponds to the register configuration values of each register in the sub-module.

[0119] Based on this test case, it can be determined that the generative constraint model includes three layers. Among them, the root node of the generative constraint model includes two ordinary modules, namely ordinary module 1 and ordinary module 2. Since both characters in the field of 11 are 1, it indicates that the constraint conditions corresponding to ordinary module 1 and ordinary module 2 are in the enabled state during the test process.

[0120] According to 1000 in the second field, it can be determined that the sub-nodes of the ordinary module of the generative constraint model include four, namely core module 1, core module 2, core module 3, and core module 4. Since the first character in the field of 1000 is 1, it indicates that the constraint condition corresponding to core module 1 is in the enabled state during the test process. Since the second to fourth characters in the field of 1000 are all 0, it indicates that the constraint conditions corresponding to core module 2, core module 3, and core module 4 are in the disabled state during the test process.

[0121] According to 010 in the second field, it can be determined that the sub-nodes of the core module of the generative constraint model include three, namely leaf node a, leaf node b, and leaf node c. Since the first and third characters in the field of 010 are both 0, it indicates that the constraint conditions corresponding to leaf node a and leaf node c are in the disabled state during the test process. Since the second character in the field of 010 is 1, it indicates that the constraint condition corresponding to leaf node b is in the enabled state during the test process.

[0122] Since only leaf node b is in the enabled state during the test process, therefore, the 3R5 field is used to indicate the register configuration value corresponding to leaf node b. Based on this field, it can be determined that the register configuration value of the first register corresponding to leaf node b is 3, the register configuration value of the second register is R, and the register configuration value of the third register is 5.

[0123] Based on this test case, the model generation module can generate Figure 6The generative constraint model of the tree structure shown on the right (i.e., the constraint tree model), and the register configuration module configures the corresponding register configuration values for the registers so that the configured registers perform corresponding operations. After that, the data transmission module receives the execution result of the chip design module, compares the results of the sub-modules, and after the operation is completed, the hardware accelerator generates a corresponding simulation report.

[0124] In another example, the test case in text form is set as: decodeEncode-011-11-40-32. See Figure 7 the example diagram shown. After transmitting the test case in text form to the chip verification system based on the generative constraint model, the chip verification system based on the generative constraint model can determine that decodeEncode is the first field, used to indicate the main name of the test case, 011 and then 11 is the second field, used to indicate the corresponding parameters of the generative constraint model, and 40 and 32 are the third field, used to indicate the register configuration values corresponding to each layer of the nodes. In addition, 40 and 32 can also be called leaf activation codes. In this example, 40 and 32 are the leaf activation codes of different core modules, corresponding to the register configuration values of each register in the core module.

[0125] Based on this test case, it can be determined that the generative constraint model includes two layers. Among them, the root node of the generative constraint model includes three ordinary modules, namely ordinary module 1, ordinary module 2, and ordinary module 3. Since the first character in the field 011 is 0, it indicates that the constraint condition corresponding to ordinary module 1 is in the off state during the test. Since the second and third characters in the field 011 are both 1, it indicates that the constraint conditions corresponding to ordinary module 2 and ordinary module 3 are in the enabled state during the test.

[0126] According to 11 in the second field, it can be determined that the sub-nodes of the ordinary modules of the generative constraint model include two, namely core module 1 and core module 2. Since both characters in the field 11 are 1, it indicates that the constraint conditions corresponding to core module 1 and core module 2 are in the enabled state during the test.

[0127] Since there are two core modules in the enabled state, the two fields 40 and 32 respectively correspond to the register configuration values of one of the core modules. Among them, 40 in the third field is the register configuration value corresponding to the first core module (i.e., core module 1) in the enabled state. Based on this field, it can be determined that the register configuration value of the first register (i.e., register a) corresponding to core module 1 is 4, and the register configuration value of the second register (i.e., register b) corresponding to core module 2 is 0.

[0128] The 32 in the third field is the register configuration value corresponding to the second core module (i.e., core module 2) in the enabled state. Based on this field, it can be determined that the register configuration value of the first register (i.e., register c) corresponding to core module 2 is 3, and the register configuration value of the second register (i.e., register d) is 2.

[0129] Based on this test case, the model generation module can generate Figure 7 the generative constraint model (i.e., the constraint tree model) of the tree structure shown on the right, and the register configuration module configures the corresponding register configuration values for the registers so that the configured registers perform corresponding operations. After that, the data transmission module receives the execution result of the chip design module, compares the results of the sub-modules, and the hardware accelerator generates a corresponding simulation report after the operation is completed.

[0130] Corresponding to the above embodiments, the present application discloses, through another embodiment, a chip verification method based on a generative constraint model, which can be executed by the chip verification system based on the generative constraint model disclosed in each of the above embodiments. Refer to Figure 8 the schematic diagram of the workflow shown, and this method includes the following steps:

[0131] Step S100: After the model generation module in the chip verification system based on the generative constraint model obtains the test case in text form, it generates the generative constraint model corresponding to the test case by parsing the test case. The generative constraint model includes the constraint conditions corresponding to testing the to-be-tested function of the chip and the register configuration values corresponding to the registers for executing the to-be-tested function;

[0132] Step S200: The register configuration module in the chip verification system based on the generative constraint model configures the register configuration values into the registers according to the constraint conditions so that the registers execute the to-be-tested function according to the register configuration values;

[0133] Step S300: The data transmission module in the chip verification system based on the generative constraint model receives the result after executing the to-be-tested function;

[0134] Step S400: The sub-module in the chip verification system based on the generative constraint model compares the result received by the data transmission module with the standard result so that the hardware accelerator generates a simulation report according to the comparison result.

[0135] The chip verification system based on the generative constraint model can implement the test of the chip function by executing the method provided in the embodiments of the present application. Moreover, the test cases applied during the test of this system are in text form. Therefore, there is no need to compile the test cases, which improves the overall compilation efficiency of the simulation environment and correspondingly improves the efficiency of testing the chip function.

[0136] Corresponding to the above embodiments, the present application discloses, through another embodiment, a chip verification device based on the generative constraint model. This device includes the chip verification systems provided in each of the above embodiments. Moreover, this chip verification device based on the generative constraint model can also run in a hardware accelerator.

[0137] Among them, the chip verification system based on the generative constraint model runs in a hardware accelerator, and the register to be configured is located in the design module, and the design module is connected to the simulation environment. In this case, after the chip verification system based on the generative constraint model obtains the test cases in text form, it can generate a corresponding generative constraint model based on the test cases and configure corresponding register configuration values for the registers in the design module, so that the registers in the design module start to work and execute the function to be tested. Moreover, this device can also receive the results of the registers executing the function to be tested, and the result comparison is performed by the bisection module in the chip verification system, so that the hardware accelerator generates a corresponding simulation report according to the comparison results.

[0138] For the same or similar parts among the embodiments of this specification, reference can be made to each other. Each embodiment focuses on the differences from other embodiments, and the relevant parts can be referred to each other.

[0139] Those skilled in the art can clearly understand that the technology in the embodiments of the present application can be implemented by means of software plus a necessary general hardware platform. Based on such an understanding, the technical solutions in the embodiments of the present application, in essence, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments of the present application.

[0140] The above-described embodiments of the present application do not constitute a limitation on the protection scope of the present application.

Claims

1. A chip verification system based on a generative constraint model, characterized in that The system runs in a hardware accelerator, and the system includes: a model generation module, a register configuration module, a data transmission module, and a bisection module; The model generation module is configured to generate a generative constraint model corresponding to the test case by parsing the test case after obtaining the test case in text form. The generative constraint model includes constraint conditions corresponding to the functions to be tested of the chip and register configuration values corresponding to the registers for executing the functions to be tested; The register configuration module is configured to configure the register configuration values into the registers according to the constraint conditions, so that the registers execute the functions to be tested according to the register configuration values; The data transmission module is configured to receive the results after the registers execute the functions to be tested; The bisection module is configured to compare the results received by the data transmission module with the standard results, so that the hardware accelerator generates a simulation report according to the comparison results; Wherein, the model generation module includes: a test case parsing component, a model determination component, and a model activation component; The test case parsing component is configured to parse the test case in text form to obtain corresponding parsing information. The parsing information includes corresponding parameters of the generative constraint model and register configuration values. The corresponding parameters include constraint conditions corresponding to each node in the generative constraint model; The model determination component is configured to determine the architecture of the generative constraint model according to the corresponding parameters of the generative constraint model; The model activation component is configured to configure the register values for the architecture, and determine the generative constraint model by performing a randomization process on the configured architecture.

2. The system according to claim 1, wherein The model determination component includes: a model generation component and a model growth component; The model generation component is configured to generate an initialization model; The model growth component is configured to determine the architecture of the generative constraint model according to the corresponding parameters of the generative constraint model, and add the constraint conditions to the architecture of the generative constraint model.

3. The system according to claim 1, wherein The model activation component includes: a node activation component and a randomization component; The node activation component is configured to configure each node in the architecture of the generative constraint model according to the register configuration values; The randomization component is configured to perform a randomization process on the architecture of the generative constraint model after configuring each node to determine the generative constraint model.

4. The system according to any one of claims 1 to 3, wherein the generative constraint model is a tree structure, and the tree structure includes at least two layers of nodes; if the tree structure includes two layers of nodes, the tree structure includes an ordinary constraint layer and a core constraint layer located below the ordinary constraint layer; if the tree structure includes three layers of nodes, the tree structure includes an ordinary constraint layer, a core constraint layer located below the ordinary constraint layer, and a sub-constraint layer located below the core constraint layer.

5. The system according to claim 4, wherein the test case includes a first field, a second field, and a third field; Among them, the first field is used to indicate the main name of the test case; The second field is used to indicate the corresponding parameters of the generative constraint model; The third field is used to indicate the register configuration values corresponding to the nodes in each layer.

6. The system according to claim 1, wherein If the generative constraint model is a tree structure, the corresponding parameters of the generative constraint model further include: the number of layers of the tree structure, the number of nodes in each layer, and the mapping relationship between the parent and child nodes in the tree structure.

7. A chip verification method based on a generative constraint model, characterized in that, This method is executed by the chip verification system based on the generative constraint model according to any one of claims 1 to 6, and the method includes: After the model generation module in the chip verification system based on the generative constraint model obtains the test case in text form, by parsing the test case, it generates a generative constraint model corresponding to the test case. The generative constraint model includes the constraint conditions corresponding to the functions to be tested of the chip and the register configuration values corresponding to the registers for executing the functions to be tested; The register configuration module in the chip verification system based on the generative constraint model configures the register configuration values into the registers according to the constraint conditions, so that the registers execute the functions to be tested according to the register configuration values; The data transmission module in the chip verification system based on the generative constraint model receives the result after the register executes the function to be tested; The bisection module in the chip verification system based on the generative constraint model compares the result received by the data transmission module with the standard result, so that the hardware accelerator generates a simulation report according to the comparison result; Among them, the model generation module generates the generative constraint model corresponding to the test case by parsing the test case, including: The test case parsing component in the model generation module is used to parse the test case in text form to obtain corresponding parsing information. The parsing information includes the corresponding parameters of the generative constraint model and the register configuration values. The corresponding parameters include the constraint conditions corresponding to each node in the generative constraint model; The model determination component in the model generation module determines the architecture of the generative constraint model according to the corresponding parameters of the generative constraint model; The model activation component in the model generation module configures the register values for the architecture and determines the generative constraint model by performing a randomization process on the configured architecture.

8. A chip verification device based on a generative constraint model, characterized in that, Including: The chip verification system based on the generative constraint model according to any one of claims 1 to 6; The chip verification device based on the generative constraint model runs in the hardware accelerator.

9. The device according to claim 8, wherein The register to be configured is located in the design module. The design module is connected to the simulation environment for instruction and data interaction. The chip verification system based on the generative constraint model is located in the simulation environment.

Images