Test stimulus generation method and system based on uvm and c language

Abstract

A test stimulus generation method and system based on UVM and C, the method comprising: S1: template file construction, constructing YMAL, TMPL and other template files; S2: generating functional code through a jinja2 template engine; S3: test environment construction; S4: test stimulus generation and constraint discrimination; S5: test stimulus storage; S6: test stimulus transmission; S7: reuse of the test stimulus generation method; the application also comprises a test stimulus generation method system based on UVM and C, which is composed of a template file module, a user input module, an input constraint module, a storage module, a transmission module and a test environment module.The application has the following advantages: a user only needs to provide a series of template files to generate a complete test stimulus generation framework, and the application has a certain reusability; the template files are also more convenient for the user to manage uniformly, which also facilitates the improvement of verification efficiency.

Description

Technical Field

[0001] This invention relates to the field of chip verification technology, and mainly to a test stimulus generation method and system based on UVM and C language. Background Technology

[0002] Functional verification is crucial in chip development. As chips become increasingly smaller, lighter, and thinner, their complexity also rises, posing significant challenges to functional verification. How to perform functional verification more efficiently has always been a hot topic in the R&D field.

[0003] Early verification methods typically built verification platforms using the Verilog language. However, these were limited by static instantiation and the low level of abstraction in the constructed test stimulus sequences, resulting in poor reusability. To meet increasingly complex testing needs, Accellera launched UVM (Universal Verification Methodology) in February 2011. UVM, implemented in System Verilog, incorporates the advantages of various verification methodologies such as ERM, AVM, VMM, and OVM. The introduction of UVM helped verifiers reduce the time required to build the environment, allowing them to focus more on developing verification plans and creating test stimulus sequences.

[0004] During the verification process, test environments and test stimulus sequences are typically built according to the needs of different projects and tests. In some large projects, the tests often require hundreds or even thousands of stimuli, making the efficient management and construction of test stimulus sequences crucial for improving testing efficiency.

[0005] A search revealed CN202210443652.7, "A Method, Apparatus, and Verification Platform for Generating Excitation Sequences for a CAN Controller Based on UVM," which creates and instantiates TLM interface data classes and frame parameter data classes into objects, then encapsulates them into functions and tasks for CAN controller verification. During subsequent testing of the CAN controller's functionality, these pre-encapsulated functions and tasks are called to constrain and control the timing of the TLM interface data objects, generating the desired excitation sequence to meet verification requirements. CN202211545309.X describes a UVM and C co-verification method and system. Users log in to the server with a unique ID to write C-language test cases, which are then compiled into binary files. These binary files are then loaded into the UVM verification platform via an RTL backend to drive testing and print test reports. While these technical solutions improve the existing testing environment and increase testing efficiency to some extent, they still suffer from issues such as poor code reusability, lack of flexibility, and difficulty in managing test cases. Summary of the Invention

[0006] The present invention aims to overcome the above-mentioned shortcomings of the prior art and provides a test stimulus generation method and system based on UVM and C language, which can help verifiers manage and build test stimulus sequences more efficiently, thereby improving testing efficiency.

[0007] This invention utilizes various template files written according to testing protocols and the fully functional template engine Jinja2, developed in Python, to automatically generate functional code. Users only need to manage and add these template files. This invention improves testing efficiency to a certain extent and facilitates the management of test cases.

[0008] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0009] A test stimulus generation method based on UVM and C language, characterized by the following steps:

[0010] S1: Template file construction: The user constructs a data packet class (Transaction class) to drive the test according to the test protocol specifications, and writes YMAL and TMPL files according to the parameters in the constructed Transaction class;

[0011] S2: Generate functional code: Automatically generate code modules with user input processing, input constraint discrimination, storage and transmission functions using the Jinja2 template engine and YMAL and TMPL files written according to the parameters in the Transaction class;

[0012] S3: Test Environment Setup: The test environment consists of two domains: the System Verilog domain and the C domain. The C domain is used to generate, store, and transmit test stimuli, while the System Verilog domain is used to receive test stimuli from the C domain and drive the test to start.

[0013] S4: Test stimulus generation and constraint judgment: Instantiate a Transaction class object in the C domain, and call the relevant code for user input processing according to the test requirements, assign values ​​to each parameter of the Transaction class object, and perform constraint judgment to determine whether the assigned values ​​of its parameters meet the pre-set constraint conditions;

[0014] S5: Storage of test incentives: Transaction class instances that meet the constraints will be stored in a first-in-first-out queue in order;

[0015] S6: Transmission of test stimulus: Retrieve a Transaction class instance from the queue storing Transaction class instances and transmit it from the C domain to the System Verilog domain to drive the device under test (DUT) to complete the test;

[0016] S7: Reuse of test stimulus generation method: By providing new YMAL and TMPL files to the Jinja2 template engine, a new test environment can be generated, thus achieving the reuse of the test stimulus generation method.

[0017] Preferably, in step S1:

[0018] S1.1: Construct a data packet class (Transaction class) to drive the test according to the test protocol specification. The Transaction class contains the parameters required by the test protocol and the access methods for the parameters.

[0019] S1.2: The specific process of writing template files such as YMAL and TMPL based on the constructed Transaction class is as follows:

[0020] First, set constraints for each parameter according to the test protocol specifications, and generate a constraint template file based on the constraints.

[0021] Secondly, the parameters in the Transaction class are divided into several categories, and a structure information is created for each parameter. The structure information specifically includes the parameter name, parameter category, and class in the Transaction class. A parameter category template file is written based on the structure information of each parameter.

[0022] Finally, based on the parameter categories, a unified DPI function template file and parameter access template file are written for each category.

[0023] Preferably, in step S2:

[0024] S2.1: Using the Jinja2 template engine, the parameter access template file generates a set_variable_name() function for assigning values ​​to variables and a get_variable_name() function for retrieving variable values ​​for each parameter, and a user input class is built to encapsulate the above functions;

[0025] S2.2: Using the Jinja2 template engine, a constraint template file is used to generate a bool constraint_variable_name() function for each parameter to determine whether it meets the constraint conditions. Then, the constraint methods of all parameters are encapsulated in the bool constraint_transaction() function, and an input constraint condition discrimination class is constructed to encapsulate the above function.

[0026] S2.3: Using the Jinja2 template engine and parameter category template files, construct a test incentive storage class with a first-in-first-out queue (Translist_fifo) to store Transaction class instances during testing. Construct Translist_pop() and Translist_push() methods in this class so that other modules can perform dequeue and enqueue operations on Translist_fifo.

[0027] S2.4: Using Jinja2 and the DPI function template file, construct the test stimulus transport class (trans_process class). This class contains two parts: one is the C part of the trans_process class, in which the DPI function template file generates the assignment function set_variable_name_dpi() for each parameter in the Transaction class and the get_variable_name_dpi() function to get the parameter value.

[0028] Another is the `trans_process` class in the SV (System Verilog) part. The main function of this class is to declare the numerous `set_variable_name_dpi()` and `get_variable_name_dpi()` functions from the C side on the SV side, and then encapsulate them into `set_trans()` and `get_trans()` functions, so that the driver in the UVM verification environment can modify and obtain the `Transaction` class instance on the C side. At the same time, the `trans_process` class on the SV side implements a `boolquery_trans()` function, which is mainly used by the driver in the UVM verification environment to determine whether the `Translist_fifo` on the C side is empty.

[0029] Preferably, in step S3:

[0030] S3.1: The test environment consists of two domains: the System Verilog domain and the C domain. The two domains use the DPI function defined in the trans_process class to realize the mutual transfer of Transaction class instances between the C domain and the System Verilog domain.

[0031] S3.2: The C domain consists of user input class instances, constraint condition discrimination class instances, test stimulus storage class instances, and test stimulus transmission class instances automatically generated by the Jinja2 template engine and YMAL and TMPL files, and has the function of generating, storing, and transmitting test stimuli;

[0032] S3.3: A UVM-based verification framework was built in the System Verilog domain, which can receive test stimuli from the C domain and drive the start of tests.

[0033] Preferably, in step S4:

[0034] S4.1: There are two ways to instantiate a Transaction class object: one way is to generate it randomly, which will assign values ​​to the various parameters of the Transaction class instance through the rand() method when instantiating a Transaction class object; the other way is to generate it manually, which requires the user to provide the values ​​of the various parameters of the Transaction class object.

[0035] S4.2: After assigning a value to a newly created Transaction class instance, various methods in the constraint condition judgment class instance will be called to determine whether the newly created Transaction class instance meets the constraints. If it does, it will be stored in the queue of test stimulus storage class instances. If it does not meet the constraints, a new Transaction class instance will be required to be created.

[0036] Preferably, in step S5:

[0037] The test incentive storage class instance provides other class instances with operations such as enqueueing (pop), dequeueing (push), and emptying of the Translist_fifo queue. After receiving a Transaction class instance, it will store it in its own first-in-first-out queue (Translist_fifo) and wait for the test incentive transport class instance to access it.

[0038] Preferably, in step S6:

[0039] The test stimulus transport consists of two parts: a test stimulus transport class instance in the C domain and a test stimulus transport class instance in the System Verilog domain.

[0040] S6.1: In the C domain, the test stimulus transport class instance checks its queue for emptiness by calling the empty operation provided by the test stimulus storage class instance. If it is not empty, it obtains a Transaction class instance through the dequeue operation and passes it to the test stimulus transport class instance in the System Verilog domain through the encapsulated DPI function. If it is empty, the test ends.

[0041] S6.2: In the System Verilog domain, the test stimulus transport class instance receives the Transaction class instance from the C domain and hands it over to the driver to drive the device under test to complete the test.

[0042] Preferably, in step S7:

[0043] S7.1: Construct the parameters and their categories in the Transaction class according to the new requirements for testing the protocol, and write the YMAL and TMPL files;

[0044] S7.2: Automatically generates the above-mentioned functional code using the Jinja2 template engine and newly written YMAL and TMPL files, overwriting the original functional code to form a new testing environment;

[0045] S7.3: Provide input that meets the constraints for the new test environment and start the test.

[0046] A system for implementing a test stimulus generation method based on UVM and C language according to the present invention includes: a template file module, a user input module, an input constraint module, a storage module, a transmission module, and a test environment module;

[0047] The template file module has the function of managing YMAL and TMPL files created by users according to the protocol and generating other modules;

[0048] The user input module has the function of receiving user input parameters and randomly generating input parameters;

[0049] The input constraint module has the function of detecting whether the parameters transmitted by the user input module meet the requirements;

[0050] The storage module is mainly used to store data passed through the input constraint module and to provide access functions for other modules to access.

[0051] The transmission module has two different domains, System Verilog domain and C domain, which are used to realize the mutual transmission of data packet class instances (Transaction class) between the SV (System Verilog) domain and the C domain;

[0052] The test environment module has two different domains: the System Verilog domain and the C domain. The C domain contains various functional modules that generate, store, and transmit test stimulus data packet instances (Transaction class). The System Verilog domain contains a UVM-based verification environment that has the function of receiving test stimuli from the C domain and driving tests.

[0053] This invention provides a test stimulus generation method based on UVM and C language, and uses Jinja2 to generate some functional modules when building various modules of the component. The main advantages are reflected in the following aspects:

[0054] 1) When users use it for the first time, they only need to provide relatively simple template files, and Jinja2 will generate a complete test incentive framework. These template files are easier to manage in a unified manner compared to the traditional method.

[0055] 2) In subsequent use, users only need to input through the user input module to generate the stimulus sequence, which is more convenient than the traditional method.

[0056] 3) Reusability and scalability: When users conduct a new test, some template files may not need to be replaced, such as DPI interface function template files and parameter access template files. This greatly facilitates user use and provides a certain degree of reusability. When users add new parameter categories, they can directly add them to the corresponding template files and retain the original parameter categories, which provides a certain degree of scalability.

[0057] The advantages of this invention are: users only need to provide a series of template files to generate a complete test stimulus generation framework, which has a certain degree of reusability; the template files are also more convenient for users to manage uniformly, which also brings convenience to improve verification efficiency. Attached Figure Description

[0058] To more clearly illustrate the content of the present invention, the present invention will be further described below with reference to specific embodiments and accompanying drawings.

[0059] Figure 1 This is a flowchart illustrating the structure of the present invention;

[0060] Figure 2 This is a diagram illustrating the creation process of each template file in this invention;

[0061] Figure 3 This is a framework diagram of the verification platform of the present invention;

[0062] Figure 4 This is a functional diagram of the various modules of the system of the present invention;

[0063] Figure 5 This is a diagram showing the relationship between the various modules of the system of the present invention;

[0064] Figure 6 This is a flowchart illustrating the verification process of the test stimulus generation method and system proposed in this invention. Detailed Implementation

[0065] This invention provides a test stimulus generation method and system based on UVM and C language, which can help verifiers manage and build test stimulus sequences more efficiently, thereby improving testing efficiency.

[0066] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0067] A test stimulus generation method based on UVM and C language, characterized by the following steps:

[0068] S1: Template file construction: The user constructs a data packet class (Transaction class) to drive the test according to the test protocol specifications, and writes YMAL and TMPL files according to the parameters in the constructed Transaction class;

[0069] S2: Generate functional code: Automatically generate code modules with user input processing, input constraint discrimination, storage and transmission functions using the Jinja2 template engine and YMAL and TMPL files written according to the parameters in the Transaction class;

[0070] S3: Test Environment Setup: The test environment consists of two domains: the System Verilog domain and the C domain. The C domain is used to generate, store, and transmit test stimuli, while the System Verilog domain is used to receive test stimuli from the C domain and drive the test to start.

[0071] S4: Test stimulus generation and constraint judgment: Instantiate a Transaction class object in the C domain, and call the relevant code for user input processing according to the test requirements, assign values ​​to each parameter of the Transaction class object, and perform constraint judgment to determine whether the assigned values ​​of its parameters meet the pre-set constraint conditions;

[0072] S5: Storage of test incentives: Transaction class instances that meet the constraints will be stored in a first-in-first-out queue in order;

[0073] S6: Transmission of test stimulus: Retrieve a Transaction class instance from the queue storing Transaction class instances and transmit it from the C domain to the System Verilog domain to drive the device under test (DUT) to complete the test;

[0074] S7: Reuse of test stimulus generation method: By providing new YMAL and TMPL files to the Jinja2 template engine, a new test environment can be generated, thus achieving the reuse of the test stimulus generation method.

[0075] In step S1:

[0076] S1.1: Construct a data packet class (Transaction class) to drive the test according to the test protocol specification. The Transaction class contains the parameters required by the test protocol and the parameter access methods. The parameters include, but are not limited to, operation type (read / write operation), destination address, destination address type, data length, data and data transmission mode, etc. The parameter access methods include the set_variable_name(value) method for assigning values ​​to parameters and the get_variable_name(value) method for getting parameter values.

[0077] S1.2: The relationship and creation process of each template file are as follows: Figure 1 As shown, the specific process of writing template files such as YMAL and TMPL based on the constructed Transaction class is as follows:

[0078] First, set constraints for each parameter according to the test protocol specifications, and generate a constraint template file based on the constraints. The constraint objects are parameters in the Transaction class, such as constraints that the data length cannot exceed 10 or the data length of a read operation cannot be less than 1.

[0079] Secondly, the parameters in the Transaction class are divided into several categories, and a structure information is created for each parameter. The structure information specifically includes the parameter name, parameter category, and category in the Transaction class. Based on the structure information of each parameter, a parameter category template file is written. The parameter category is the category required when the parameter is declared in the Transaction class, and the category is the distinction between parameter categories.

[0080] Finally, based on the parameter categories, a unified DPI function template and parameter access function template are written for each category. The DPI functions are based on the DPI provided by System Verilog and are used to implement data transfer between the SystemVerilog domain and the C domain. The DPI function template is a collection of DPI functions for each category. The parameter access function template is a collection of the set_variable_name(value) method for assigning values ​​to parameters in the Transaction class as described in S1.1 for each category and the get_variable_name(value) method for retrieving parameter values.

[0081] In step S2:

[0082] S2.1: Using the Jinja2 template engine, the parameter access template file generates a set_variable_name(value) function for assigning values ​​to variables and a get_variable_name(value) function for retrieving values ​​from variables for each parameter, and a user input class is built to encapsulate the above functions;

[0083] S2.2: Using the Jinja2 template engine, a constraint template file is used to generate a bool constraint_variable_name() function for each parameter to determine whether it meets the constraint conditions. Then, the constraint methods of all parameters are encapsulated in the bool constraint_transaction() function, and an input constraint condition discrimination class is constructed to encapsulate the above function.

[0084] S2.3: Using the Jinja2 template engine and parameter category template files, construct a test incentive storage class with a first-in-first-out queue (Translist_fifo) to store Transaction class instances during testing. Construct Translist_pop() and Translist_push() methods in this class so that other modules can perform dequeue and enqueue operations on Translist_fifo.

[0085] S2.4: Using the DPI function template file in Jinja2, construct the test stimulus transport class (trans_process class). This class contains two parts: one is the C part of the trans_process class, in which the set_variable_name_dpi() function to assign values ​​to each parameter in the Transaction class and the get_variable_name_dpi() function to get the parameter values ​​are generated through the DPI function template file.

[0086] Another is the `trans_process` class in the SV (System Verilog) part. The main function of this class is to declare the numerous `set_variable_name_dpi()` and `get_variable_name_dpi()` functions from the C side on the SV side, and then encapsulate them into the `set_trans()` and `get_trans()` methods, so that the driver in the UVM verification environment can modify and obtain the `Transaction` class instance on the C side. At the same time, the `trans_process` class on the SV side implements a `boolquery_trans()` function, which is mainly used by the driver in the UVM verification environment to determine whether the `Translist_fifo` on the C side is empty.

[0087] In step S3:

[0088] The test environment framework built with S3 is as follows: Figure 3 As shown;

[0089] S3.1: The test environment consists of two domains: the System Verilog domain and the C domain. The two domains use the DPI function defined in the trans_process class to realize the mutual transfer of Transaction class instances between the C domain and the System Verilog domain.

[0090] S3.2: The C domain consists of user input class instances, constraint condition discrimination class instances, test stimulus storage class instances, and test stimulus transmission class instances automatically generated by the jinja2 template engine and YMAL and TMPL files, and has the function of generating, storing, and transmitting test stimuli;

[0091] S3.3: A UVM-based verification framework was built in the System Verilog domain, which can receive test stimuli from the C domain and drive the start of tests.

[0092] In step S4:

[0093] S4.1: There are two ways to instantiate a Transaction class object: one way is to generate it randomly, which will assign values ​​to the various parameters of the Transaction class instance through the rand() method when instantiating a Transaction class object; the other way is to generate it manually, which requires the user to provide the values ​​of the various parameters of the Transaction class object.

[0094] S4.2: After assigning a value to a newly created Transaction class instance, various methods in the constraint condition judgment class instance will be called to determine whether the newly created Transaction class instance meets the constraints. If it does, it will be stored in the queue of test stimulus storage class instances. If it does not meet the constraints, a new Transaction class instance will be required to be created.

[0095] In step S5:

[0096] The test incentive storage class instance provides other class instances with operations such as enqueueing (pop), dequeueing (push), and emptying of the Translist_fifo queue. After receiving a Transaction class instance, it will store it in its own first-in-first-out queue (Translist_fifo) and wait for the test incentive transport class instance to access it.

[0097] In step S6:

[0098] The test stimulus transport consists of two parts: a test stimulus transport class instance in the C domain and a test stimulus transport class instance in the System Verilog domain.

[0099] S6.1: In the C domain, the test stimulus transport class instance checks its queue for emptiness by calling the empty operation provided by the test stimulus storage class instance. If it is not empty, it obtains a Transaction class instance through the dequeue operation and passes it to the test stimulus transport class instance in the System Verilog domain through the encapsulated DPI function. If it is empty, the test ends.

[0100] S6.2: In the System Verilog domain, the test stimulus transport class instance receives the Transaction class instance from the C domain and hands it over to the driver to drive the device under test to complete the test.

[0101] In step S7:

[0102] S7.1: Construct the parameters and their categories in the Transaction class according to the new requirements for testing the protocol, and write the YMAL and TMPL files;

[0103] S7.2: Automatically generates the above-mentioned functional code using the Jinja2 template engine and newly written YMAL and TMPL files, overwriting the original functional code to form a new testing environment;

[0104] S7.3: Provide input that meets the constraints for the new test environment and start the test.

[0105] A system for implementing a test stimulus generation method based on UVM and C language according to the present invention includes a template file module, a user input module, an input constraint module, a storage module, a transmission module, and a test environment module;

[0106] The functions of each module are as follows: Figure 4 As shown, the relationships between the modules are as follows: Figure 5 As shown, more specifically:

[0107] The template file module has the function of managing YMAL and TMPL files created by users according to the protocol and generating other modules, specifically including:

[0108] S1.1: Based on the Transaction class, write parameter access templates, constraint templates, parameter category templates, and DPI function templates;

[0109] S1.2: Generates user input modules, input constraint modules, storage modules, and transmission modules using various template files written in S1.1 through the Jinja2 template engine.

[0110] The user input module has the function of receiving user input parameters and randomly generating input parameters, specifically including:

[0111] S2.1: Method for receiving user input;

[0112] S2.2: If it is user input, then it will receive the values ​​of each parameter in the Transaction class provided by the user; if it is random input, then it will call the random function to generate a Transaction class instance.

[0113] S2.3: Send the Transaction class instance generated in step S2.2 into the input constraint module.

[0114] The input constraint module has the function of detecting whether the parameters transmitted by the user input module meet the requirements, specifically including:

[0115] S3.1: Receive input from the user input module;

[0116] S3.2: Determine whether the input Transaction class instance meets the preset constraints;

[0117] S3.3: If it meets the requirements, it will be sent to the storage module.

[0118] The storage module is mainly used to store data passed through the input constraint module and provides access functions for other modules to access it, specifically including:

[0119] S4.1: Receive a Transaction class instance from the input constraint module and store it in its own first-in-first-out queue (Translist_fifo), waiting for the transmission module to retrieve it;

[0120] S4.2: After the transmission module obtains a Transaction class instance from the first-in-first-out queue (Translist_fifo), it performs a push() operation to dequeue it.

[0121] The transmission module has two different domains: the System Verilog domain and the C domain. It is used to implement the mutual transmission of data packet class instances (Transaction class) between the SV (System Verilog) domain and the C domain, specifically including:

[0122] S5.1: Obtain a Transaction class instance to be processed from the storage module;

[0123] S5.2: The obtained Transaction class instance is transferred from the C domain to the System Verilog domain through the pre-written DPI function, and then handed over to the driver of the UVM verification environment to start the test.

[0124] The test environment module has two different domains: the System Verilog domain and the C domain. The C domain contains various functional modules that generate, store, and transmit test stimulus data packet instances (Transaction class). The System Verilog domain contains a UVM-based verification environment that has the function of receiving test stimuli from the C domain and driving tests.

[0125] See Figure 5The user input module, input constraint module, storage module, and transmission module together constitute the test environment module, while the template file module automatically generates other modules through various template files.

[0126] See Figure 6 The specific process for verification based on the test stimulus generation method proposed in this invention is given.

[0127] First, when testing requires creating a new Transaction class, users need to categorize the various parameters in the Transaction class and write the constraint template file, DPI function template file, parameter category template file, and parameter access template file mentioned above. Then, the template files are used to generate the functional code for the user input module, input constraint module, storage module, and transmission module in this invention.

[0128] If the user does not need to create a new Transaction class, they can skip the above steps and proceed to the next step.

[0129] If it is necessary to add or modify parameters to the Transaction class, the template file needs to be modified, and then the functional code of other modules in this invention needs to be regenerated.

[0130] Once all modules have been generated, users need to select either random or manual input of the values ​​of each parameter in the Transaction class instance object in the user input module and then transmit them to the input constraint module.

[0131] In the input constraint module, each parameter in the input Transaction class instance object is checked to see if it meets the pre-set constraints for each parameter. If it does not meet the constraints, it will return to the user input module and ask the user to re-enter the information. If it meets the constraints, it will be stored in the Translist_fifo of the storage module.

[0132] Next, users need to set up a verification environment with the trans_process component and drive UVM to start testing. The specific verification platform framework is as follows: Figure 3 As shown.

[0133] In the UVM environment, the driver in the Agent calls the query_trans() function provided by the trans_process component to check if there is a transaction to be processed in the storage module. If not, it returns the test result and ends the test. If there is, it will further call the get_trans() function provided by trans_process to obtain the transaction class instance to be processed and process it. After processing, it will return to continue to obtain the transaction class instance to be processed until Translist_fifo is empty.

[0134] Above, refer to Figures 1-6 This paper describes an embodiment of a test stimulus generation method and system based on UVM and C language according to an embodiment of the present invention. It has reusability and scalability, provides convenience for verification personnel to efficiently manage test cases, and improves the verification efficiency of projects.

[0135] The embodiments described above are only for the purpose of providing a more detailed description of the present invention and are not intended to limit the scope of the present invention. Various modifications and improvements made by those skilled in the art to the technical solutions of the present invention without departing from the spirit of the present invention should fall within the protection scope defined by the claims of the present invention.

Claims

1. A test stimulus generation method based on UVM and C language, characterized in that, Includes the following steps: S1: Template file construction: The user constructs a data packet class to drive the test according to the test protocol specifications. The data packet class adopts the Transaction class, and writes YAML and TMPL files according to the parameters in the constructed Transaction class. S2: Generate functional code: Automatically generate code modules with user input processing, input constraint discrimination, storage and transmission functions using the Jinja2 template engine and YAML and TMPL files written according to the parameters in the Transaction class; S3: Test Environment Setup: The test environment consists of two domains: the System Verilog domain and the C domain. The C domain is used to generate, store, and transmit test stimuli, while the System Verilog domain is used to receive test stimuli from the C domain and drive the test to start. S4: Test stimulus generation and constraint judgment: Instantiate a Transaction class object in the C domain, and call the relevant code for user input processing according to the test requirements, assign values ​​to each parameter of the Transaction class object, and perform constraint judgment to determine whether the assigned values ​​of its parameters meet the pre-set constraint conditions; S5: Storage of test incentives: Transaction class instances that meet the constraints will be stored in a first-in-first-out queue in order; S6: Transmission of test stimulus: Retrieve a Transaction class instance from the queue storing Transaction class instances and transmit it from the C domain to the System Verilog domain to drive the device under test (DUT) to complete the test; S7: Reuse of test stimulus generation methods: By providing new YAML and TMPL files to the Jinja2 template engine, a new test environment can be generated, thus enabling the reuse of test stimulus generation methods.

2. The test stimulus generation method based on UVM and C language according to claim 1, characterized in that, Step S1 specifically includes: S1.1: Construct a data packet class to drive the test according to the test protocol specification. The Transaction class contains the parameters required by the test protocol and the access methods for those parameters. S1.2: The specific process of writing YAML and TMPL template files based on the constructed Transaction class is as follows: First, set constraints for each parameter according to the test protocol specifications, and generate a constraint template file based on the constraints. Secondly, the parameters in the Transaction class are divided into several categories, and a structure information is created for each parameter. The structure information specifically includes the parameter name, parameter category, and class in the Transaction class. A parameter category template file is written based on the structure information of each parameter. The parameter category is the category required when the parameter is declared in the Transaction class, and the class is the distinction between parameter categories. Finally, based on the parameter categories, a unified DPI function template file and parameter access template file are written for each category.

3. The test stimulus generation method based on UVM and C language according to claim 1, characterized in that, Step S2 specifically includes: S2.1: Using the Jinja2 template engine, the parameter access template file generates a set_variable_name() function for assigning values ​​to variables and a get_variable_name() function for retrieving variable values ​​for each parameter, and a user input class is built to encapsulate the above functions; S2.2: Using the Jinja2 template engine, a constraint template file is used to generate a bool constraint_variable_name() function for each parameter to determine whether it meets the constraint conditions. Then, the constraint methods of all parameters are encapsulated in the bool constraint_transaction() function, and an input constraint condition discrimination class is constructed to encapsulate the above function. S2.3: Using the Jinja2 template engine and parameter category template files, construct a test incentive storage class with a first-in-first-out queue Translist_fifo to store Transaction class instances during testing. In this class, construct the Translist_pop() and Translist_push() methods so that other modules can dequeue and enqueue Translist_fifo. S2.4: Using Jinja2 and the DPI function template file, construct the test stimulus transport class, namely the trans_process class. This class contains two parts: one is the C part of the trans_process class, in which the DPI function template file generates the set_variable_name_dpi() function to assign values ​​to each parameter in the Transaction class and the get_variable_name_dpi() function to get the parameter values. Another is the `trans_process` class in the System Verilog section. This class declares numerous `set_variable_name_dpi()` and `get_variable_name_dpi()` functions from the C side on the System Verilog side, and then encapsulates them into `set_trans()` and `get_trans()` functions, which are used by the driver in the UVM verification environment to modify and obtain the `Transaction` class instance on the C side. At the same time, the `trans_process` class on the System Verilog side implements a `bool query_trans()` function, which is mainly used by the driver in the UVM verification environment to determine whether the `Translist_fifo` on the C side is empty.

4. The test stimulus generation method based on UVM and C language according to claim 1, characterized in that, Step S3 specifically includes: S3.1: The test environment consists of two domains: the System Verilog domain and the C domain. The two domains use the DPI function defined in the trans_process class to realize the mutual transfer of Transaction class instances between the C domain and the System Verilog domain. S3.2: The C domain consists of user input class instances, constraint condition discrimination class instances, test stimulus storage class instances, and test stimulus transmission class instances automatically generated by the Jinja2 template engine and YAML and TMPL files, and has the function of generating, storing, and transmitting test stimuli; S3.3: A UVM-based verification framework was built in the System Verilog domain, which can receive test stimuli from the C domain and drive the start of tests.

5. The test stimulus generation method based on UVM and C language according to claim 1, characterized in that, Step S4 specifically includes: S4.1: There are two ways to instantiate a Transaction class object: one way is to generate it randomly, by assigning values ​​to the parameters of the Transaction class instance through the rand() method when instantiating a Transaction class object; the other way is to generate it manually, which requires the user to provide the values ​​of the parameters of the Transaction class object. S4.2: After assigning a value to a newly created Transaction class instance, call various methods in the constraint condition judgment class instance to determine whether the newly created Transaction class instance meets the constraints. If it does, store it in the queue of test stimulus storage class instances. If it does not, it will require the creation of a new Transaction class instance.

6. The test stimulus generation method based on UVM and C language according to claim 1, characterized in that, Step S5 specifically includes: The test incentive storage class instance provides other class instances with enqueue pop, dequeue push, and empty check operations on the Translist_fifo queue. After receiving a Transaction class instance, it will store it in its own first-in-first-out queue Translist_fifo and wait for the test incentive transport class instance to access it.

7. The test stimulus generation method based on UVM and C language according to claim 1, characterized in that, Step S6 specifically includes: The test stimulus transport consists of two parts: a test stimulus transport class instance in the C domain and a test stimulus transport class instance in the System Verilog domain. S6.1: In the C domain, the test stimulus transport class instance checks its queue for emptiness by calling the empty operation provided by the test stimulus storage class instance. If it is not empty, it obtains a Transaction class instance through the dequeue push operation and passes it to the test stimulus transport class instance in the System Verilog domain through the encapsulated DPI function. If it is empty, the test ends. S6.2: In the System Verilog domain, the test stimulus transport class instance receives the Transaction class instance from the C domain and hands it over to the driver to drive the device under test to complete the test.

8. The test stimulus generation method based on UVM and C language according to claim 1, characterized in that, Step S7 specifically includes: S7.1: Construct the parameters and their categories in the Transaction class according to the new requirements of the test protocol, and write YAML and TMPL files; S7.2: The above functional code is automatically generated using the Jinja2 template engine and newly written YAML and TMPL files, and the original functional code is overwritten to form a new test environment; S7.3: Provide input that meets the constraints for the new test environment and start the test.

9. A system for implementing the test stimulus generation method based on UVM and C language as described in claim 1, characterized in that: It includes a template file module, a user input module, an input constraint module, a storage module, a transmission module, and a test environment module; The template file module has the function of managing YAML and TMPL files created by users in accordance with the protocol and generating other modules; The user input module has the function of receiving user input parameters and randomly generating input parameters; The input constraint module has the function of detecting whether the parameters transmitted by the user input module meet the requirements; The storage module is used to store data passed through the input constraint module and provides access functions for other modules to access; The transmission module has two different domains, System Verilog domain and C domain, which are used to realize the mutual transmission of data packet class instances Transaction class between System Verilog domain and C domain; The test environment module has two different domains: the System Verilog domain and the C domain. The C domain contains various functional modules that generate, store, and transmit test stimulus data packets using the Transaction class. The System Verilog domain contains a UVM-based verification environment that receives test stimuli from the C domain and drives the test.

Images