Automatic interface signal verification control method, device, equipment and medium

Abstract

The invention provides an automatic interface signal verification management and control method, device and equipment and a medium, and belongs to the technical field of chip verification. Configuring a template file and a configuration file, and creating a to-be-tested design interface and a verification environment interface which interact with each other; creating a verification environment module; the to-be-tested design interface and the verification environment interface are bound to a verification platform, a verification environment module is called, and an interface handle is transmitted to the verification environment module through an inter-module parameter information transmission mechanism; based on the verification platform, tasks of sending an interface signal to the DUT interface, receiving the interface signal from the DUT interface, generating a verification test sequence and the like are realized, and the interface signal of the DUT interface is verified. The verification mode can greatly shorten the test period and reduce manual intervention and errors. And various test scenes and boundary conditions are simulated to ensure that the DUT interface signal can work normally under different conditions, so that the test requirements are met.

Description

Technical Field

[0001] The present invention belongs to the field of chip verification technology, and in particular relates to an automated interface signal verification control method, device, equipment and medium. Background Art

[0002] At present, chip verification is one of the key steps in the chip design process. Potential defects in the design code can be found by verifying the designed chip. In order to meet the chip verification requirements, it is generally necessary to configure the verification platform based on the verification scenario, and implement the verification process based on the verification platform by obtaining and controlling the verification signal.

[0003] The traditional manual verification method relies on the experience and manual operation of the verification engineer, which is inefficient and prone to errors, affecting the accuracy of the verification results. It is easy to mislead the chip design. Although the current script-based automated verification is an improvement over manual verification, the script can only adapt to a single verification environment and cannot simulate multiple test scenarios and boundary conditions, resulting in the inability to execute the verification process under different environments and verification conditions for the DUT interface signal, and it is difficult to adapt to the needs of different environments and verification conditions. Summary of the invention

[0004] The present invention provides an automatic interface signal verification management and control method. The method can automatically integrate a UVM Harness module and an interface in a UVM verification platform according to a DUT design, thereby improving the efficiency of chip verification testing.

[0005] Methods include:

[0006] S101: extracting the interface parameters of the design to be tested;

[0007] S102: configuring a template file and a configuration file, and creating a mutually interactive design interface to be tested and a verification environment interface according to the extracted design interface to be tested parameters, the template file and the configuration file;

[0008] S103: Creating a verification environment module according to the design interface to be tested, the verification environment interface, the template file and the configuration file;

[0009] S104: Bind the design interface to be tested and the verification environment interface to the verification platform, call the verification environment module, and pass the interface handle to the verification environment module through the inter-module parameter information transmission mechanism;

[0010] S105: Based on the verification platform, implementation includes but is not limited to sending interface signals to the design interface to be tested, receiving interface signals from the design interface to be tested, generating a verification test sequence, converting the generated verification test sequence into an interface signal received by the design interface to be tested, and driving it to the design interface to be tested, monitoring the interface signals of the design interface to be tested, and verifying the interface signals of the design interface to be tested.

[0011] It should be further explained that step S101 also includes: traversing the design file, acquiring a first design interface to be tested, and defining the first design interface to be tested as an interface connected to the verification platform.

[0012] It should be further explained that, the design interfaces to be tested other than the first design interface to be tested are traversed to extract interface signal parameters of any design interface to be tested;

[0013] The extracted interface signal parameters are stored in a dictionary container;

[0014] The extracted interface signal parameters include but are not limited to: signal type, signal name, bit width, field, and module level.

[0015] It should be further explained that step S102 also includes:

[0016] Creating an application programming interface according to the template file;

[0017] Wherein, the template file includes: interface signal path, transaction position of re-driving, transaction position and update value of driving end, and whether to check interface signal;

[0018] The template file also defines a counting and control module, a signal conversion module, and a signal checking module;

[0019] The counting and control module controls the time and state in the test process, and generates control signals for interface verification; through the counter and state machine, it controls the sending time and sequence of the test stimulus, as well as the timing of capturing the response of the design interface under test;

[0020] The counting and control module defines the counter and state machine, including state definition, state transition conditions and action output; by configuring parameters, the counting range of the counter and the behavior of the state machine are adjusted;

[0021] The signal conversion module converts the test stimulus signal into a format recognized by the design interface under test, and converts the response signal of the design interface under test into a format processed by the verification platform;

[0022] The signal conversion module realizes the format conversion of input and output signals, and then configures the corresponding conversion logic and parameters according to the test requirements;

[0023] The signal checking module is used to check whether the response signal of the design interface to be tested meets expectations; by comparing the actual response with the expected response, it is determined whether the design interface to be tested is executed according to the preset test process and generates test results;

[0024] The signal check module sets checkpoints and test standards by configuring expected response values ​​and check conditions.

[0025] It should be further explained that the method further includes: defining and calling an interface generation script, importing a preset open source library, and rendering the interface signal parameters and the configuration file into the template file in a preset manner;

[0026] All the extracted design interfaces to be tested are traversed until the first design interface to be tested, and the first design interface to be tested is connected to the verification platform.

[0027] It should be further noted that the method further includes: configuring a test execution module, and instantiating a second design interface to be tested in the test execution module;

[0028] Bind the second design under test interface to the verification platform.

[0029] It is further necessary to explain that the virtual interface module is configured, and based on the virtual interface module, the virtual interface handle for transmitting parameter information between components is configured, the application programming interface is encapsulated and added to the virtual interface function, and the parameter information transmission mechanism between components is configured;

[0030] A reference management interface handle is configured to the verification platform based on the virtual interface module.

[0031] The present application also provides an automation interface signal control device, the device comprising:

[0032] A parameter extraction unit, used to extract the interface parameters of the design to be tested;

[0033] An interface communication creation unit, used to configure a template file and a configuration file, and to create an interactive design interface to be tested and a verification environment interface according to the extracted design interface parameters to be tested, the template file and the configuration file;

[0034] A verification environment configuration unit, used to create a verification environment module according to the design interface to be tested, the verification environment interface, the template file and the configuration file;

[0035] The interface binding unit is used to bind the design interface to be tested and the verification environment interface to the verification platform, call the verification environment module, and pass the interface handle to the verification environment module through the inter-module parameter information transmission mechanism;

[0036] The interface verification unit is implemented based on the verification platform, including but not limited to sending interface signals to the design interface to be tested, receiving interface signals from the design interface to be tested, generating a verification test sequence, converting the generated verification test sequence into an interface signal received by the design interface to be tested, and driving it to the design interface to be tested, monitoring the interface signals of the design interface to be tested, and verifying the interface signals of the design interface to be tested.

[0037] According to another embodiment of the present application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the automated interface signal verification and control method when executing the program.

[0038] According to another embodiment of the present application, a storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of the automated interface signal verification and control method are implemented.

[0039] It can be seen from the above technical solutions that the present invention has the following advantages:

[0040] The automated interface signal verification and control method involved in this application, in the design verification of the chip, calls the automated python script, through the interaction of the harness interface and the DUT interface, can realize the integration and reuse of the interface signal management layer, and can also verify whether the function of the DUT interface meets the design requirements. This application creates a verification environment module according to the design interface to be tested, the verification environment interface, the template file and the configuration file; binds the design interface to be tested and the verification environment interface to the verification platform, calls the verification environment module, and passes the interface handle to the verification environment module through the inter-module parameter information transmission mechanism; and implements interface signal verification based on the verification platform. The verification method can greatly shorten the test cycle and reduce manual intervention and errors. It also ensures that the DUT interface signal can work normally in different situations and meet the test requirements by simulating various test scenarios and boundary conditions.

[0041] The method of the present application can reduce the workload of manually writing interface files, avoid duplication of work, and improve development efficiency by using the gen_if.py script to generate interface files. In addition, the automatically generated interface files can reduce human errors, improve the accuracy of verification, and can also adapt to different verification requirements and DUT characteristics. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the technical solution of the present invention, the accompanying drawings required for use in the description will be briefly introduced below. Obviously, the accompanying drawings in the following description are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative work.

[0043] Figure 1 It is a flow chart of the automation interface signal verification control method;

[0044] Figure 2 This is a schematic diagram of the verification platform framework based on UVM Harness;

[0045] Figure 3 Create a process flow diagram for the Harness interface;

[0046] Figure 4 To dynamically generate DUT interface and harness interface flow charts;

[0047] Figure 5 Generate an interface file flow chart using the gen_if.py script under the script file;

[0048] Figure 6 This is a schematic diagram of the generation process of the configuration file and harness module;

[0049] Figure 7 It is a schematic diagram of the automation interface signal control device;

[0050] Figure 8 A schematic diagram of the control and management of the Harness interface;

[0051] Fig. 9 Schematic diagram of the hardware structure of the electronic device. DETAILED DESCRIPTION

[0052] The specific implementation steps of the automated interface signal verification control method will be described in detail below. For the purpose of illustration rather than limitation, specific details such as specific system structures and technologies are proposed to facilitate a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application can also be implemented in other embodiments without these specific details.

[0053] The automated interface signal verification and control method involved in this application can be based on a preset verification platform to perform data communication detection and verification on the timing of the DUT interface. The verification platform involved in this application can adopt the UVM framework, such as Figure 2 shown.

[0054] The automated interface signal verification management and control method defines a series of components and mechanisms required for interface signal verification, and configures interfaces and signals through command lines or configured packages, and then configures interfaces and signals in combination with command lines or configured packages, and uses API control to enhance the applicability and reusability of the UVM framework. The application is also integrated between the verification platform and the DUT interface through template files and scripts, so that the verification personnel only need to provide the designed code to realize the extraction of interfaces and signals, the integration of signal control and management interfaces, thereby reducing the code workload and saving the time of verification platform integration reuse.

[0055] For this application, the components defined may include but are not limited to the following:

[0056] Object components can be used for signal flow interaction, data management, and providing the foundation of the engine.

[0057] The sequence component is a combination of sequence_item. When the driver component obtains the interface signal from the sequencer component, the sequencer component can check whether there is a sequence to send the interface signal. If so, the interface signal can be sent from the sequence_item component to the driver interface signal.

[0058] The driver component can be used to drive the interface signal in the sequence_item component to the DUT interface. The driver component completes the conversion from the transaction level to the interface signal that the DUT interface can accept.

[0059] The monitor component can be used to receive interface signals from the DUT interface, convert the received interface signals into sequence_items at the transaction level, and then send them to the scoreboard component for comparison processing.

[0060] The scoreboard component is used to compare the information sent by the reference model component and the monitor component, and determine whether the behavior of the DUT interface meets the verification requirements based on the comparison results.

[0061] The reference model component can mimic the DUT interface and perform the same functions as the DUT interface, and is used to compare the data sent by the monitor component.

[0062] The agent component is used to encapsulate the driver component and the monitor component together, and judge and analyze the parameter values ​​of the device to instantiate only the monitor component or instantiate both the driver component and the monitor component at the same time.

[0063] The env component is used to encapsulate the fixed components used in the verification platform so that they can be reused in different test cases.

[0064] The test component is used for all test cases derived from uvm_test. In the test case, env needs to be instantiated to build a verification environment.

[0065] The verification platform of this application also involves the interface control and management layer: specifically including the DUT interface and the harness interface and a harness module that binds the DUT. The DUT interface and the harness interface implement the control and management of the signal layer. The harness module has an internal module that instantiates and connects the DUT interface, and implements the interface handle transfer method set_vif.

[0066] It should be understood that when used in the present specification, the term "includes" indicates the presence of the described features, integral bodies, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integral bodies, steps, operations, elements, components and / or their collections. The terms "include", "comprise", "have" and their variations all mean "including but not limited to", unless otherwise specifically emphasized.

[0067] It should be understood that the "one or more" mentioned in this application refers to one, two or more than two, and the "multiple" mentioned in this application refers to two or more. In the description of this application, unless otherwise specified, " / " means or, for example, A / B can mean A or B. The "and / or" in this article is just a way to describe the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone.

[0068] The phrases such as "one embodiment" or "some embodiments" described in the present application mean that the specific features, structures or characteristics described in the embodiment are included in one or more embodiments of the present application. Therefore, the phrases such as "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments" etc. that appear in different places in the present application do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways.

[0069] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0070] See also Figure 1 The figure is a flow chart of an automated interface signal verification control method in a specific embodiment, the method comprising:

[0071] S101: Extracting interface parameters of the design to be tested.

[0072] In this embodiment, the design interface to be tested may be a DUT interface. First, the DUT interface signal parameters of the device under test (DUT) to be verified are clarified, and the interface signal parameters are dut_if. The interface signal parameters also include but are not limited to interface type, signal type, signal timing, signal protocol, etc.

[0073] In some embodiments, the present embodiment uses a python script to extract DUT interface parameters.

[0074] Optionally, the file name of the DUT interface parameters can be configured based on the python script. Read the corresponding configured file. Then extract the DUT interface name. Traverse the DUT interface and extract the corresponding parameters. Extract different parameters according to the DUT interface type to meet the verification control requirements.

[0075] This embodiment obtains the DUT interface parameters by consulting the DUT design documents, technical specifications or using a dedicated interface analysis tool. This embodiment can also identify all submodules in the DUT interface that interact with the DUT interface and obtain the interface signal parameters of the submodules.

[0076] Optionally, this embodiment can obtain the first-level DUT interface signal parameter dut_if, and obtain any sub-module of the second-level interface, where the sub-module is expressed as interface signals of m1, m2 . . . and mn.

[0077] S102: configuring a template file and a configuration file, and creating a mutually interactive design interface to be tested and a verification environment interface according to the extracted design interface to be tested parameters, the template file and the configuration file.

[0078] In the process of automatic interface signal verification, this embodiment creates a DUT interface and a harness interface that interact with each other according to the template file, the configuration file and the extracted DUT interface parameters.

[0079] For extracting DUT interface parameters, it can be obtained based on the device's design documents and technical specifications to obtain the interface parameters, functional characteristics, etc. of the verification equipment.

[0080] Alternatively, for open source devices or devices with access rights, interface parameters can be extracted directly from the source code.

[0081] The configuration file of this embodiment may be an INI file, an XML file, or a JSON file, which contains the interface configuration information.

[0082] In this embodiment, an interface analysis tool can be used to automatically scan and extract interface parameters of a device.

[0083] Template files can be predefined by verification personnel based on verification requirements and device characteristics, including the general structure and framework required to create interfaces and verification environments.

[0084] In this embodiment, the configuration files involved can be described as interface parameters of DUT and submodules, verification rules, etc., which will be used to instantiate the common structure in the template file. The configuration file can be in any format that is easy to parse, such as INI, XML, JSON, etc.

[0085] In this embodiment, an automation script is defined to read the template file and the configuration file, and generate the code of the DUT interface and the harness interface according to the extracted DUT parameters. The automation script can be written in Python scripting language and combined with the Handlebars engine to generate the code.

[0086] The present embodiment can utilize UVM framework to create and manage interface. According to actual needs, a test environment generator can be provided to facilitate users to configure interface parameters through a graphical interface and automatically generate corresponding interface code and verification environment.

[0087] In order to simulate the actual working environment of the interface, this embodiment can simulate the actual working environment of the DUT interface based on the harness interface, send a test stimulus signal to the DUT interface, and receive a response signal from the DUT interface. The interactive method of this embodiment can ensure that the DUT interface is fully tested and verified in a controlled environment.

[0088] In some embodiments, the interaction between the harness interface and the DUT interface can verify whether the function of the DUT interface meets the design requirements. Verifying the function of the DUT interface can include verification of the timing, protocol, error handling, etc. of the interface signal.

[0089] It can be seen that the automated interface signal verification process of this embodiment can greatly reduce manual intervention and errors and improve test efficiency. Through the interaction between the harness interface and the DUT interface, a test sequence can be quickly generated and executed, and test results can be automatically collected and analyzed.

[0090] S103: Creating a verification environment module according to the design interface to be tested, the verification environment interface, the template file and the configuration file.

[0091] In some embodiments, the verification environment interface is a harness interface used to simulate or assist in testing an interface of a DUT.

[0092] Create a complete verification environment module based on DUT interface, harness interface, template file and configuration file.

[0093] The verification environment module of this embodiment generally includes a test stimulus generator, a response monitor, a verification control logic and other parts.

[0094] Optionally, UVM can be used to write the functional code of the verification environment module. The verification environment module can simulate the actual working environment of the DUT and provide test stimulus and response monitoring capabilities.

[0095] S104: Bind the design interface to be tested and the verification environment interface to the verification platform, call the verification environment module, and pass the interface handle to the verification environment module through the inter-module parameter information transmission mechanism.

[0096] In some embodiments, the DUT interface and the harness interface may be bound to the verification platform, and the previously created verification environment module may be called.

[0097] It can be seen that the verification platform is UVM platform to organize and manage the entire verification process. The DUT model, harness model and verification environment module are instantiated in the verification platform. In this way, the interface handle is passed to the verification environment module through the inter-module parameter information transmission mechanism, such as the TLM interface of UVM.

[0098] The Harness interface handle in this embodiment makes the interface connection from the module to the chip level more direct, and the verification engineer does not need to manually create interface instances and perform complex signal connection work. Moreover, through the interface handle, the verification environment can manage and configure the interface instance more flexibly. When the interface changes, only the relevant handle reference and configuration information need to be modified to quickly adapt to the new interface requirements, reducing maintenance costs.

[0099] S105: Based on the verification platform, implementation includes but is not limited to sending interface signals to the design interface to be tested, receiving interface signals from the design interface to be tested, generating a verification test sequence, converting the generated verification test sequence into an interface signal received by the design interface to be tested, and driving it to the design interface to be tested, monitoring the interface signals of the design interface to be tested, and verifying the interface signals of the design interface to be tested.

[0100] In some embodiments, tasks such as sending interface signals to the DUT interface, receiving interface signals from the DUT interface, generating verification test sequences, etc. are implemented based on the verification platform, and the interface signals of the DUT interface are verified.

[0101] Based on this embodiment, a test stimulus signal is sent to the DUT through the harness interface to simulate the signal input in the actual working environment. A response monitor is used to capture the response signal of the DUT interface, and the response signal is processed and analyzed.

[0102] This embodiment can generate normal test sequences and abnormal test sequences according to the verification requirements to cover the working state and boundary conditions of the DUT interface. The verification platform compares the acquired response signal with the expected result to verify whether the function of the DUT interface meets the design requirements. If any inconsistency is found, the error information is recorded and a test report is generated.

[0103] The automated interface signal verification and control method provided in this embodiment creates a verification environment module based on the design interface to be tested, the verification environment interface, the template file and the configuration file; binds the design interface to be tested and the verification environment interface to the verification platform, calls the verification environment module, and passes the interface handle to the verification environment module through the inter-module parameter information transmission mechanism; and implements interface signal verification based on the verification platform. The verification method can greatly shorten the test cycle and reduce manual intervention and errors. It also ensures that the DUT interface signal can work normally in different situations and meet the test requirements by simulating various test scenarios and boundary conditions.

[0104] In one embodiment, Figure 2 This is a flowchart of creating a Harness interface according to an embodiment of the present invention. Based on the above embodiments, this embodiment can verify whether the function of the DUT interface meets the design requirements through the interaction between the harness interface and the DUT interface. The verification process can reduce manual intervention and errors and improve test efficiency. The following implementation process further optimizes and expands the detailed process of creating the Harness interface.

[0105] like Figure 3 As shown, the Harness interface creation process provided in this embodiment may include the following steps:

[0106] S201: Use a python script to extract interface parameters of a design file, traverse the design file, and obtain a first DUT interface.

[0107] In some embodiments, the first DUT interface is an interface directly connected to the verification platform, and the interface signal of any sub-module can be obtained by traversing the sub-modules of the DUT.

[0108] This embodiment stores the extracted parameters in the dictionary if_info_dict. The extracted interface parameters include but are not limited to signal type, signal name, bit width, and module level.

[0109] According to an embodiment of the present application, the interface parameters of the design file include: interface name, interface description, input and output parameters, input parameters, output parameters, data type, input and output direction, interface protocol, port number and error code.

[0110] The interface description is a description of the interface function. The data type can be the data type of the input and output parameters, such as integer, floating point number, string, structure, etc. The interface protocol can adopt HTTP, TCP / IP, UDP and other protocols.

[0111] The traversal of the design file in this embodiment mainly involves using the corresponding Python library to parse the file content according to the format of the design file. After parsing, according to the structure of the file (such as tree, list, etc.), a loop is used to traverse each part of the file. During the traversal process, according to the identification of the interface parameters, information such as the interface name, input and output parameters, and data type are extracted.

[0112] In the process of automated testing or verification, the first DUT, that is, Device Under Test, is obtained. When there are multiple interfaces or DUTs, the first one is selected as the starting point to facilitate the sequencing of the test process and ensure the continuity and consistency of the test.

[0113] Moreover, by testing the first DUT interface first, the correctness of the test environment, test script, and test data can be quickly verified, laying the foundation for subsequent tests.

[0114] In some embodiments, the first DUT interface is the basis or dependency of other interfaces or DUTs, and testing the first DUT interface first can ensure the smooth progress of subsequent tests.

[0115] The first DUT interface of this embodiment can serve as the entry point of the entire test process, providing context or data for subsequent tests. By testing the first DUT interface, a test benchmark can be established to evaluate the performance, stability, and accuracy of subsequent tests. Verifying the first DUT interface and other subsequent interfaces can ensure the integration and compatibility of the entire system.

[0116] S202: Configure the template files dut_if_template.sv and harness_if_template.sv, which are used to dynamically generate the DUT interface and the harness interface respectively.

[0117] Specifically, this embodiment configures a counting and control module, a signal conversion module, and a signal checking module in the DUT interface file;

[0118] This embodiment also creates an API class method of the interface according to the configuration file provided by the verification personnel.

[0119] It should be noted that the configuration file is an Excel file, which contains the signal path of interest, the transaction location begin_loc where the re-drive is located, the transaction location end_loc where the drive ends, the update value update_value, and whether to check the signal trace_on.

[0120] In some embodiments, dut_if_template.sv and harness_if_template.sv are configuration template files that can be used to dynamically generate DUT interfaces and harness interfaces.

[0121] The template file dut_if_template.sv of this embodiment can be used to define the structure and characteristics of the DUT interface. Specifically, it involves the signal definition, interface protocol and module configuration required for interacting with the DUT interface. Through the setting of the template file, a preset DUT interface file can be automatically generated, so that the verification platform can accurately communicate and exchange data with the DUT interface.

[0122] The template file harness_if_template.sv defines the structure of the harness interface, which is used to simulate the external environment and generate test stimuli, while capturing and analyzing the response of the DUT interface.

[0123] In this embodiment, a harness interface matching the DUT interface can be dynamically generated through harness_if_template.sv, ensuring that the verification platform can correctly control the DUT interface and collect test data.

[0124] In some embodiments, the counting and control module can be used to control the time and state in the test process and generate control signals for interface verification. The counting and control module can control the sending time and sequence of the test stimulus and the timing of the DUT response capture through the counter and state machine.

[0125] In this embodiment, the counting and control module defines a counter and a state machine, including state definition, state transition conditions, action output, etc. By configuring parameters, the counting range of the counter and the behavior of the state machine can be adjusted.

[0126] The signal conversion module of this embodiment is used to convert the test stimulus signal into a format that can be recognized by the DUT interface, and convert the response signal of the DUT interface into a format that can be processed by the verification platform, so as to ensure the signal compatibility and data consistency between the verification platform and the DUT interface.

[0127] In this embodiment, the signal conversion module defines a signal conversion function or module, which can input and output signal formats, conversion rules, etc. Different conversion logics and parameters can be configured according to test requirements.

[0128] The signal checking module of this embodiment is used to check whether the response signal of the DUT meets expectations. By comparing the actual response with the expected response, it is determined whether the DUT interface works as expected, and a corresponding test result is generated.

[0129] In this embodiment, the signal check module can define signal check logic, including comparators, assertions, etc. By configuring expected response values ​​and check conditions, check points and test standards are set.

[0130] S203: Call the DUT interface and generate a gen_if.py script based on the script file. Import the gen_if.py script into the mako open source library, and render the dynamic fields into the template files dut_if_tempate.sv and harness_templete.sv through the render method according to the configuration file.

[0131] Then traverse all the extracted DUT interface nodes until the first DUT interface, and connect the first DUT interface to the verification platform.

[0132] In some embodiments, calling the DUT interface to generate the gen_if.py script can realize the verification process of automatically processing the interface signal. Through the gen_if.py script, the required interface file can be dynamically generated according to the configuration file and the template file, thereby reducing the dependence on repeated work and improving the verification efficiency.

[0133] The gen_if.py script of this embodiment is written in Python script, which reads the signal name, type, and direction information in the configuration file, and generates it in combination with the structure of the template files dut_if_template.sv and harness_template.sv.

[0134] The contents of the gen_if.py script include logic such as reading configuration files, parsing template files, rendering dynamic fields into templates, and outputting generated files.

[0135] In this way, the implementation of the gen_if.py script automatically generates the DUT interface and harness interface files. By using the gen_if.py script to generate interface files, the workload of manually writing interface files can be reduced, duplication of work can be avoided, and development efficiency can be improved. Moreover, the automatically generated interface files can reduce human errors, improve the accuracy of verification, and can also adapt to different verification requirements and DUT characteristics.

[0136] In some specific embodiments, the dynamic fields are rendered into the template files dut_if_tempate.sv and harness_templete.sv through the render method, where the Render method is used to render the dynamic data into the template file.

[0137] In the gen_if.py script, you can call the Render method to render the dynamic fields in the configuration file into the dut_if_template.sv and harness_template.sv template files to generate the final interface file.

[0138] It can be seen that the present embodiment uses the Render method to enable the template file to flexibly adapt to different input data and generate an interface file that meets the requirements. Moreover, by automatically rendering the template file, the degree of automation of the verification process can be further improved. Since the Render method automatically generates an interface file based on the template and dynamic data, it can reduce errors caused by manually writing the interface file.

[0139] S204: Create a module named b_harness_x, instantiate a DUT interface in the b_harness_x module, and connect the DUT interface to the rtl signal through a port reference.

[0140] This embodiment also adds a bind dutb_harness_xharness_x(x=1,2...n) statement for the DUT interface to bind the DUT interface and the instantiated b_harness module.

[0141] In this embodiment, the b_harness_x module (where x may represent different instance numbers or types) is one of the modules of the verification platform, which is used to automatically verify the DUT interface. Each b_harness_x module can be designed for different test scenarios or test cases to generate test stimuli, control the test process, capture the response of the DUT, and verify whether these responses meet expectations.

[0142] In this embodiment, the DUT interface is instantiated inside the b_harness_x module in order to establish a communication channel between the verification platform and the DUT. By instantiating the DUT interface, the b_harness_x module can access and control the port of the DUT, so that it can send test stimuli to the DUT and receive response signals from the DUT. This enables the verification platform to perform various test operations and verify whether the behavior of the DUT meets the design requirements.

[0143] This embodiment also connects the DUT interface with the RTL signal. Considering that the RTL code is the underlying code that describes the behavior of the hardware design, and the DUT interface is the interface between the verification platform and the hardware design. By connecting the DUT interface with the RTL signal, the verification platform can directly interact with the internal signals of the hardware design, thereby being able to more accurately simulate the actual working environment of the hardware and verify whether its behavior meets expectations.

[0144] This embodiment also adds a bind dutb_harness_xharness_x(x=1,2...n) statement for the interface of interest. The bind statement here is used in SystemVerilog to bind a DUT interface to another interface in a hierarchy. It is possible to add test or monitoring functions to the DUT interface without modifying the original RTL code. The harness_x module can be bound to the b_harness_x module bound to the DUT interface, thereby performing verification without interfering with the original design.

[0145] In this embodiment, binding the DUT interface and the instantiated b_harness module can ensure that the verification platform can correctly interact with the DUT interface. Through binding, the verification platform can access and control the internal signals of the DUT interface, thereby performing various test operations.

[0146] The binding method can be implemented in SystemVerilog through the bind statement to meet the accuracy and effectiveness of the test.

[0147] S205: Declare the set_vif method in the added module, which implements the config_db transmission virtual interface handle, encapsulates the interface API classes driver_h and check_h, and adds the set_vif function to pass it to config_db. The top level of the testbench calls the set_vif method to pass the UVM_Harness interface handle to other components of the verification platform, including the driver component and the monitor component.

[0148] In some specific embodiments, the encapsulation interface API class may define an interface API class that encapsulates operations related to the DUT interface, such as reading and writing signals, checking signal status, etc., in order to utilize the characteristics and mechanisms of UVM.

[0149] In the UVM framework, the set_vif method can use the UVM config_db mechanism to set and pass virtual interface handles. The UVM framework allows components to pass configuration interface handles, parameters, etc.

[0150] Inside the set_vif method, store the virtual interface handle in config_db using the set method of uvm_config_db and specify the driver component and the monitor component as the receivers.

[0151] At the top level of the testbench, call the set_vif method to pass the UVM_Harness interface handle to other components in the testbench.

[0152] In the driver component and monitor component, the virtual interface handle is obtained through the get method of uvm_config_db, and the handle is used to send stimulus, capture response, etc.

[0153] In this way, the decoupling between test platform components is achieved by passing the virtual interface handle through config_db. In the UVM framework, components do not need to directly know the specific implementation of other components, but only need to obtain the required configuration information through config_db. Moreover, config_db allows the flexible transmission of configuration information between different levels of the test platform, making the design of the test platform more flexible, easy to expand and maintain. The encapsulated interface API class can be reused in different test environments, improving the reusability and development efficiency of the code.

[0154] like Figure 4 As shown, based on the above embodiment, the method of dynamically generating the DUT interface and the harness interface includes the following steps:

[0155] S301: Customize the dut_if_template.sv and harness_if_template.sv template files according to the test requirements and DUT characteristics.

[0156] S302: Configure the parameters in the template file according to the specific requirements of the test project through a script or an automation tool. The parameters include but are not limited to interface type, signal name, bit width, direction, etc.

[0157] S303: Instantiate the template file using the configured parameters to generate specific DUT interface files and harness interface files.

[0158] S304: The generated interface files need to be verified and debugged to ensure that they can correctly interact with the DUT and harness.

[0159] As for calling the DUT interface and generating the script file in this embodiment, the interface file is generated by using the gen_if.py script under the script file, which reduces the workload of manually writing the interface file, avoids duplication of work, and improves development efficiency. The specific implementation steps are described in detail below, such as Figure 5 As shown:

[0160] The steps of calling the DUT interface and generating the script file gen_if.py usually involve a series of automation and programming operations. Since the direct, implementation-specific details may vary from project to project, the following is a general process based on general automated testing and script generation principles:

[0161] S401: Obtain the DUT interface parameters to be verified; determine the target and function of the generated script.

[0162] The goals and functions of the script include: support for dynamic field rendering, whether to support multiple interface configurations, etc. The DUT interface parameters include the interface's signal, protocol, data format, etc.

[0163] S402: Obtain the dut_if_template.sv and harness_template.sv template files and define variables and logic in the template files according to the characteristics of the DUT interface.

[0164] S403: Use Python script to write the gen_if.py script.

[0165] In the script, implement the functions of reading the configuration file, parsing the template file, rendering the dynamic fields into the template, and outputting the generated file.

[0166] The configuration file should contain all necessary dynamic information, such as interface name, signal list, signal type, etc.

[0167] S404: Use the template engine to implement rendering of dynamic fields.

[0168] The gen_if.py script of this embodiment can traverse the dynamic fields in the configuration file and insert them into the corresponding positions of the template file.

[0169] S405: Perform sufficient testing on the gen_if.py script to ensure that the gen_if.py script correctly reads the configuration file, renders the template, and generates the expected output.

[0170] Verify that the generated interface file meets the requirements of the DUT interface and can work correctly in the verification environment.

[0171] S406: Integrate the gen_if.py script into the verification process to automatically generate the required interface files at the beginning of each verification.

[0172] It can be seen that by using the gen_if.py script to generate interface files, the workload of manually writing interface files can be reduced, duplication of work can be avoided, and development efficiency can be improved. In addition, the automatically generated interface files can reduce human errors, improve the accuracy of verification, and can also adapt to different verification requirements and DUT characteristics.

[0173] In this embodiment, in order to automatically integrate the Harness module and interface in the verification platform according to the DUT interface design, as shown in FIG. Figure 6 As shown, the generation process of the configuration file and Harness module of this embodiment is as follows:

[0174] The configuration file is defined in Excel format to facilitate the processing of batch signals. The interface signals and module names are stored in the form of associative arrays and rendered as fields in the template file.

[0175] This embodiment controls whether the harness module is decoupled from the verification platform through the force_en bit of the harness interface and maintains a passive / active state, so that the setting information can be applied to all interface signals.

[0176] The begin_tr and end_tr of this embodiment can be used to control the start and end positions of the signal, and activemode supports four signal driving and control modes. This parameter is called in signal_collection as an API parameter.

[0177] After the control signal is read from the configuration file, harness_module obtains the control signal name through macro definition.

[0178] The following is an embodiment of the automated interface signal control device provided in the embodiments of the present disclosure. The device and the automated interface signal verification and control methods of the above-mentioned embodiments belong to the same inventive concept. For details not described in detail in the embodiment of the automated interface signal control device, reference can be made to the embodiment of the above-mentioned automated interface signal verification and control method.

[0179] like Figure 7 As shown, the device comprises:

[0180] The parameter extraction unit is used to extract the interface parameters of the design to be tested.

[0181] The interface communication creation unit is used to configure the template file and the configuration file, and to create the interactive design interface to be tested and the verification environment interface according to the extracted design interface parameters to be tested, the template file and the configuration file.

[0182] The verification environment configuration unit is used to create a verification environment module according to the design interface to be tested, the verification environment interface, the template file and the configuration file.

[0183] The interface binding unit is used to bind the design interface to be tested and the verification environment interface to the verification platform, call the verification environment module, and pass the interface handle to the verification environment module through the inter-module parameter information transmission mechanism.

[0184] The interface verification unit is implemented based on the verification platform, including but not limited to sending interface signals to the design interface to be tested, receiving interface signals from the design interface to be tested, generating a verification test sequence, converting the generated verification test sequence into an interface signal received by the design interface to be tested, and driving it to the design interface to be tested, monitoring the interface signals of the design interface to be tested, and verifying the interface signals of the design interface to be tested.

[0185] In some specific embodiments, Figure 8 As shown, the device also involves the control and management of the Harness interface, specifically including:

[0186] The signal conversion module is used to process the interface signal and convert it to obtain the transaction-level transmission ID number. At the same time, according to the parameters begin_loc and end_loc in the configuration file, the interface signal is maintained or delayed to expand the bit width of the DUT interface signal, and the interface signal that is re-driven to the verification environment is obtained by ORing the extended bit and the original signal.

[0187] A control module for counting transactions after signal toggling and conversion.

[0188] The control module of this embodiment can output a release_on signal and signal indicating bus drive start information, and can also indicate the end of this signal control transmission.

[0189] Optionally, the control module supports four modes: Raw mode, force mode, delay mode and append mode.

[0190] It should be noted that in Raw mode, the signal is not controlled or processed directly.

[0191] The force mode can be used to keep the updated value of the user-specified interface signal until the next transaction-level transfer starts.

[0192] The delay mode is based on the interface signal delaying N beats from the start control position.

[0193] The append mode is to re-drive the interface signal of the first DUT, simulating the influence of the external module on the bus interface signal transmission.

[0194] The signal checking module is used for assertion of interface signals.

[0195] In the template file of this embodiment, the API methods of signal processing are encapsulated for easy calling, and the provided methods include but are not limited to: waiting signal wait_signal, forcing signal force_signal, releasing signal release_signal, and delaying signal delay_signal.

[0196] This embodiment also provides Fig. 9 The figure shows a schematic diagram of the hardware structure of an electronic device.

[0197] The electronic device 500 includes, but is not limited to, a processor 501 , a network module 502 , an audio output unit 503 , an input unit 504 , a display unit 506 , a user input unit 507 , an interface unit 508 , a memory 509 and other components.

[0198] Those skilled in the art will appreciate that the electronic device structure involved in the embodiments of the present invention does not constitute a limitation on the electronic device, and the electronic device may include more or fewer components than shown, or combine certain components, or arrange different components. In the embodiments of the present invention, the electronic device includes but is not limited to a laptop computer, a desktop computer, a workbench, a personal digital assistant, a server, a blade server, a mainframe computer, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments of the present application described and / or required herein.

[0199] In the embodiment of the present application, the processor 501 can be implemented by using at least one of an application-specific integrated circuit (ASIC), a digital signal processor (DSP), a field programmable gate array (FPGA), a processor, a controller, a microcontroller, a microprocessor, and an electronic unit designed to perform the functions described herein. In some cases, such an implementation can be implemented in a controller. For software implementation, implementations such as processes or functions can be implemented with separate software modules that allow execution of at least one function or operation. The software code can be implemented by a software application (or program) written in any appropriate programming language, and the software code can be stored in a memory and executed by a controller.

[0200] The processor 501 provides the user with wireless Internet access through the network module 502, realizing the transmission and communication of data information in this application. The audio output unit 503 includes a speaker, a buzzer, and a receiver. The input unit 504 may include a graphics processing unit (GPU) and a microphone. The graphics processor processes the image data of the static picture or video obtained by the image capture device (such as a camera) in the video capture mode or the image capture mode.

[0201] The display unit 506 includes a display panel, which may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), or the like.

[0202] The user input unit 507 may include, but is not limited to, a physical keyboard, function keys (such as a volume control key, a switch key, etc.), a trackball, a mouse, and a joystick, which will not be described in detail here.

[0203] The memory 509 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0204] In addition, the electronic device 500 includes some functional modules not shown, which will not be described in detail here.

[0205] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0206] The flowchart and block diagram in the accompanying drawings illustrate the possible architecture, functions and operations of the equipment, methods and computer program products according to various embodiments of the present disclosure. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. Exemplarily, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or the flowchart, and the combination of the boxes in the block diagram and / or the flowchart can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0207] The storage medium provided in this embodiment stores a program product that can implement the automated interface signal verification and control method of this specification.

[0208] The stored automated interface signal verification and control methods include:

[0209] Extract the parameters of the design interface to be tested; configure the template file and the configuration file, and create the interactive design interface to be tested and the verification environment interface according to the extracted parameters of the design interface to be tested, the template file and the configuration file; create the verification environment module according to the design interface to be tested, the verification environment interface, the template file and the configuration file; bind the design interface to be tested and the verification environment interface to the verification platform, call the verification environment module, and pass the interface handle to the verification environment module through the inter-module parameter information transmission mechanism; based on the verification platform, implement including but not limited to sending interface signals to the design interface to be tested, receiving interface signals from the design interface to be tested, generating a verification test sequence, converting the generated verification test sequence into an interface signal received by the design interface to be tested, and driving it to the design interface to be tested, monitoring the interface signals of the design interface to be tested, and verifying the interface signals of the design interface to be tested.

[0210] In some possible implementations, various aspects of the present disclosure may also be implemented in the form of a program product, which includes program code. When the program product is run on a terminal device, the program code is used to enable the terminal device to execute the steps of various exemplary implementations of the present disclosure described in the above “Exemplary Method” section of this specification.

[0211] The storage medium can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, but not limited to, a system, device or device of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination of the above. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0212] The above description of the disclosed embodiments enables one skilled in the art to implement or use the present invention. Various modifications to these embodiments will be apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An automated interface signal verification and control method, characterized in that: Methods include: S101: extracting the interface parameters of the design to be tested; S102: configuring a template file and a configuration file, and creating a mutually interactive design interface to be tested and a verification environment interface according to the extracted design interface to be tested parameters, the template file and the configuration file; S103: Creating a verification environment module according to the design interface to be tested, the verification environment interface, the template file and the configuration file; S104: Bind the design interface to be tested and the verification environment interface to the verification platform, call the verification environment module, and pass the interface handle to the verification environment module through the inter-module parameter information transmission mechanism; S105: Based on the verification platform, implementation includes but is not limited to sending interface signals to the design interface to be tested, receiving interface signals from the design interface to be tested, generating a verification test sequence, converting the generated verification test sequence into an interface signal received by the design interface to be tested, and driving it to the design interface to be tested, monitoring the interface signals of the design interface to be tested, and verifying the interface signals of the design interface to be tested.

2. The automated interface signal verification and control method according to claim 1, characterized in that: Step S101 also includes: traversing the design file, acquiring a first design interface to be tested, and defining the first design interface to be tested as an interface connected to the verification platform.

3. The automated interface signal verification and control method according to claim 2, characterized in that: Traversing the design interfaces to be tested other than the first design interface to be tested, and extracting interface signal parameters of any design interface to be tested; The extracted interface signal parameters are stored in a dictionary container; The extracted interface signal parameters include but are not limited to: signal type, signal name, bit width, field, and module level.

4. The automated interface signal verification and control method according to claim 1, characterized in that: Step S102 also includes: Creating an application programming interface according to the template file; Wherein, the template file includes: interface signal path, transaction position of re-driving, driving end transaction position and update value, and whether to check interface signal; The template file also defines a counting and control module, a signal conversion module, and a signal checking module; The counting and control module controls the time and state in the test process, and generates control signals for interface verification; through the counter and state machine, it controls the sending time and sequence of the test stimulus, as well as the timing of capturing the response of the design interface under test; The counting and control module defines the counter and state machine; including state definition, state transition conditions and action output; by configuring parameters, the counting range of the counter and the behavior of the state machine are adjusted; The signal conversion module converts the test stimulus signal into a format recognized by the design interface to be tested, and converts the response signal of the design interface to be tested into a format processed by the verification platform; The signal conversion module realizes the format conversion of input and output signals, and then configures the corresponding conversion logic and parameters according to the test requirements; The signal checking module is used to check whether the response signal of the design interface to be tested meets expectations; by comparing the actual response with the expected response, it is determined whether the design interface to be tested is executed according to the preset test process and generates test results; The signal check module sets checkpoints and test standards by configuring expected response values ​​and check conditions.

5. The automated interface signal verification and control method according to claim 3, characterized in that: The method further includes: defining and calling an interface generation script, importing a preset open source library, and rendering the interface signal parameters and the configuration file into the template file in a preset manner; All the extracted design interfaces to be tested are traversed until the first design interface to be tested, and the first design interface to be tested is connected to the verification platform.

6. The automated interface signal verification and control method according to claim 1, characterized in that: The method further includes: configuring a test execution module, and instantiating a second design interface to be tested in the test execution module; Bind the second design under test interface to the verification platform.

7. The automated interface signal verification and control method according to claim 1, characterized in that: Configure a virtual interface module, and based on the virtual interface module, configure a virtual interface handle for transmitting parameter information between components, encapsulate an application programming interface and add a function to the virtual interface, and configure a parameter information transmission mechanism between components; A reference management interface handle is configured to the verification platform based on the virtual interface module.

8. An automated interface signal control device, characterized in that: The device is used to implement the automated interface signal verification control method according to any one of claims 1 to 7; the device comprises: A parameter extraction unit, used to extract the interface parameters of the design to be tested; An interface communication creation unit, used to configure a template file and a configuration file, and to create an interactive design interface to be tested and a verification environment interface according to the extracted design interface parameters to be tested, the template file and the configuration file; A verification environment configuration unit, used to create a verification environment module according to the design interface to be tested, the verification environment interface, the template file and the configuration file; The interface binding unit is used to bind the design interface to be tested and the verification environment interface to the verification platform, call the verification environment module, and pass the interface handle to the verification environment module through the inter-module parameter information transmission mechanism; The interface verification unit is implemented based on the verification platform, including but not limited to sending interface signals to the design interface to be tested, receiving interface signals from the design interface to be tested, generating a verification test sequence, converting the generated verification test sequence into an interface signal received by the design interface to be tested, and driving it to the design interface to be tested, monitoring the interface signals of the design interface to be tested, and verifying the interface signals of the design interface to be tested.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the steps of the automated interface signal verification and control method according to any one of claims 1 to 7 are implemented.

10. A storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the automated interface signal verification and control method according to any one of claims 1 to 7 are implemented.

Images