An automatic interface signal verification management method, device, equipment and medium

Abstract

This invention provides an automated interface signal verification and control method, apparatus, equipment, and medium, belonging to the field of chip verification technology. The method involves extracting interface parameters of the design under test (DUT); configuring template and configuration files to create interactive DUT interfaces and verification environment interfaces; creating a verification environment module; binding the DUT interfaces and verification environment interfaces to a verification platform; calling the verification environment module; and passing interface handles to the verification environment module through an inter-module parameter information transfer mechanism. Based on the verification platform, tasks such as sending interface signals to the DUT interface, receiving interface signals from the DUT interface, and generating verification test sequences are implemented, and the interface signals of the DUT interface are verified. This verification method can significantly shorten the testing cycle and reduce manual intervention and errors. Furthermore, by simulating various test scenarios and boundary conditions, it ensures that the DUT interface signals can function normally under different conditions and meet test requirements.

Description

Technical Field

[0001] This invention belongs to the field of chip verification technology, and particularly relates to an automated interface signal verification and control method, device, equipment and medium. Background Technology

[0002] Currently, chip verification is one of the key steps in the chip design process, enabling the discovery of potential defects in the design code after the chip is designed. To meet chip verification requirements, a verification platform is typically configured based on the verification scenario. This platform acquires and controls verification signals to implement the verification process.

[0003] Traditional manual verification methods rely on the experience and manual operation of verification engineers, resulting in low efficiency, high error rates, and compromised accuracy. This can easily mislead chip design. While script-based automated verification is an improvement over manual verification, scripts can only adapt to a single verification environment and cannot simulate various test scenarios and boundary conditions. This leads to verification processes failing to execute under different environments and verification conditions for DUT interface signals, making it difficult to meet the needs of diverse environments and verification requirements. Summary of the Invention

[0004] This invention provides an automated interface signal verification and control method. The method can automatically integrate UVM Harness modules and interfaces in the UVM verification platform according to the DUT design, thereby improving the efficiency of chip verification testing.

[0005] The methods include:

[0006] S101: Extract the interface parameters of the design under test;

[0007] S102: Configure template files and configuration files, and create interactive design-under-test interfaces and verification environment interfaces based on the extracted interface parameters of the design under test, template files and configuration files;

[0008] S103: Create a verification environment module based on the design under test interface, verification environment interface, template file, and configuration file;

[0009] S104: Bind the interface of the design under test and the interface of the verification environment 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 transfer mechanism.

[0010] S105: Based on the verification platform, implements, but is not limited to, sending interface signals to the interface under test, receiving interface signals from the interface under test, generating verification test sequences, converting the generated verification test sequences into interface signals received by the interface under test and driving them to the interface under test, monitoring the interface signals of the interface under test, and verifying the interface signals of the interface under test.

[0011] It should be further noted that step S101 also includes: traversing the design file, obtaining the 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 interface signal parameters of any interface under test are extracted by traversing all interfaces under test except the first interface under test.

[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 noted that step S102 also includes:

[0016] Based on the template file, create an application programming interface;

[0017] The template file includes: interface signal path, the transaction position of the re-drive, the transaction position of the drive end and the update value, and whether to check the 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, as well as generates control signals for interface verification; through counters and state machines, it controls the sending time and order of test stimuli, as well as the timing of capturing the response of the interface under test.

[0020] The counting and control module defines the counter and the state machine, including state definitions, state transition conditions, and action outputs; and adjusts the counting range of the counter and the behavior of the state machine by configuring parameters.

[0021] The signal conversion module converts the test stimulus signal into a format that the design under test (DUT) interface can recognize, and converts the response signal of the DUT interface into a format that the verification platform can process.

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

[0023] The signal inspection module is used to check whether the response signals of the interface under test meet expectations; by comparing the actual response with the expected response, it determines whether the interface under test executes according to the preset test process and generates test results.

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

[0025] It should be further noted that the method also includes: defining and calling the 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] Iterate through all extracted design interfaces to be tested until the first design interface to be tested, and connect the first design interface to the verification platform.

[0027] It should be further noted that the method also includes: configuring the test execution module and instantiating the second test design interface within the test execution module;

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

[0029] It should be further explained that the virtual interface module is configured, and the virtual interface handle for parameter information transmission between components is configured based on the virtual interface module. The application programming interface is encapsulated and added to the virtual interface function, and the parameter information transmission mechanism between components is configured.

[0030] The virtual interface module is used to configure the reference management interface handle to the verification platform.

[0031] This application also provides an automated interface signal control device, the device comprising:

[0032] The parameter extraction unit is used to extract the interface parameters of the design under test.

[0033] The interface communication creation unit is used to configure template files and configuration files, and to create interactive interfaces for the design under test and the verification environment based on the extracted interface parameters of the design under test, template files and configuration files.

[0034] The verification environment configuration unit is used to create a verification environment module based on 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 interface of the design under test and the interface of the verification environment 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 passing mechanism.

[0036] The interface verification unit, based on the verification platform, includes, but is not limited to, sending interface signals to the interface under test, receiving interface signals from the interface under test, generating verification test sequences, converting the generated verification test sequences into interface signals received by the interface under test and driving them to the interface under test, monitoring the interface signals of the interface under test, and verifying the interface signals of the interface under test.

[0037] According to another embodiment of this 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 executes the program to implement the steps of the automated interface signal verification and control method.

[0038] According to another embodiment of this application, a storage medium is also provided, on which a computer program is stored, wherein the computer program, when executed by a processor, implements the steps of the automated interface signal verification and control method.

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

[0040] This application discloses an automated interface signal verification and control method. In chip design verification, it calls an automated Python script to interact with the DUT interface via a harness interface. This enables the integration and reuse of the interface signal management layer and verifies whether the DUT interface functionality meets design requirements. This application creates a verification environment module based on the DUT interface, verification environment interface, template files, and configuration files. The DUT interface and verification environment interface are bound to the verification platform. The verification environment module is called, and interface handles are passed to it through an inter-module parameter information transfer mechanism. Interface signal verification is then performed based on the verification platform. This verification method significantly shortens the testing cycle and reduces manual intervention and errors. Furthermore, by simulating various test scenarios and boundary conditions, it ensures that the DUT interface signals function correctly under different conditions and meet testing requirements.

[0041] The method described in this application generates interface files using the gen_if.py script, which reduces the workload of manually writing interface files, avoids repetitive work, and improves development efficiency. Furthermore, the automatically generated interface files reduce human error, improve verification accuracy, and can adapt to different verification requirements and DUT characteristics. Attached Figure Description

[0042] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the description will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0043] Figure 1 Flowchart of automated interface signal verification and control method;

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

[0045] Figure 3 Create a flowchart for the Harness interface;

[0046] Figure 4 To dynamically generate flowcharts for the DUT interface and harness interface;

[0047] Figure 5 A flowchart for generating interface files using the gen_if.py script in the script folder;

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

[0049] Figure 7 Schematic diagram of an automated interface signal control device;

[0050] Figure 8 This is a schematic diagram illustrating the control and management of the Harness interface;

[0051] Figure 9 This is a schematic diagram of the hardware structure of an electronic device. Detailed Implementation

[0052] The following details the specific implementation steps of the automated interface signal verification and control method. For illustrative purposes and not for limitation, specific details such as particular system structures and technologies are presented to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this 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 perform data communication detection and verification on the timing of the DUT interface based on a preset verification platform. The verification platform involved in this application can adopt the UVM framework, such as... Figure 2 As shown.

[0054] The automated interface signal verification and control method defines a series of components and mechanisms required for interface signal verification, and configures interfaces and signals via command line or configured packages. Combining command line or configured packages with API control enhances the applicability and reusability of the UVM framework. This application also integrates template files and scripts between the verification platform and the DUT interface, allowing verification personnel to extract interfaces and signals, control signals, and integrate management interfaces simply by providing the designed code. This reduces coding workload and saves time on verification platform integration and reuse.

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

[0056] The object component can be used for signal flow interaction, data management, and to provide the foundation for the engine.

[0057] The sequence component is a combination of sequence_items. When the driver component obtains interface signals from the sequencer component, the sequencer component can check if there is a sequence to send interface signals. If so, the sequence_item component can send the interface signals to the driver interface signals.

[0058] The driver component can be used to drive the interface signals in the sequence_item component to the DUT interface. The driver component completes the conversion from the transaction level to the interface signals 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 transaction-level sequence items, 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 to 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, used for comparison with data sent by the monitor component.

[0062] The agent component encapsulates the driver and monitor components together. It analyzes the device's parameter values ​​to determine whether to instantiate only the monitor or both the driver and monitor components simultaneously.

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

[0064] The `test` component is used for all test cases, which are derived from `uvm_test`. Within a test case, `env` needs to be instantiated to build the validation environment.

[0065] The verification platform of this application also involves interface control and management layers: specifically, it includes a DUT interface and a harness interface, as well as a harness module that binds to the DUT. The DUT interface and the harness interface implement signal layer control and management. The harness module has an internal instantiation and connection module for the DUT interface, and implements the interface handle passing method set_vif.

[0066] It should be understood that, when used in this specification, the term "comprising" indicates the presence of the described feature, integral, step, operation, element, and / or component, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0067] It should be understood that "one or more" as mentioned in this application refers to one, two, or more, and "multiple" as mentioned in this application refers to two or more. In the description of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. The "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone.

[0068] The terms "one embodiment" or "some embodiments" used in this application mean that one or more embodiments of this application include the specific features, structures, or characteristics described in that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this application do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized.

[0069] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0070] Please see Figure 1 The diagram shows a flowchart of an automated interface signal verification and control method in a specific embodiment. The method includes:

[0071] S101: Extract the interface parameters of the design under test.

[0072] In this embodiment, the interface to be tested can be the DUT interface. First, the DUT interface signal parameters of the device to be verified (DUT) are defined, and the interface signal parameter is 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, this embodiment uses a Python script to extract DUT interface parameters.

[0074] Optionally, the filenames of the DUT interface parameters can be configured using a Python script. The corresponding configuration file is read, and the DUT interface name is extracted. The DUT interfaces are then traversed, and the corresponding parameters are extracted. Different parameters are extracted based on the DUT interface type to meet verification and control requirements.

[0075] This embodiment obtains DUT interface parameters by consulting the DUT's design documents, technical specifications, or using dedicated interface analysis tools. This embodiment can also identify all sub-modules interacting with the DUT interface and obtain the interface signal parameters of these sub-modules.

[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 represented by interface signals m1, m2, ... and mn.

[0077] S102: Configure template files and configuration files, and create interactive design-under-test interfaces and verification environment interfaces based on the extracted interface parameters of the design under test, template files and configuration files.

[0078] In this embodiment, during the automated interface signal verification process, interactive DUT interfaces and harness interfaces are created based on template files, configuration files, and extracted DUT interface parameters.

[0079] To extract DUT interface parameters, one can obtain them based on the device's design documents and technical specifications, thus obtaining the interface parameters and functional characteristics of the verification device.

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

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

[0082] This embodiment can use an interface analysis tool to automatically scan and extract the device's interface parameters.

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

[0084] In this embodiment, the configuration file involved can be described as the interface parameters, validation rules, etc. of the DUT and submodules. These parameters will be used to instantiate the general structure in the template file. The configuration file can be any easily parsed format, such as INI, XML, JSON, etc.

[0085] In this embodiment, an automated script is defined to read template files and configuration files, and generate DUT interface and harness interface code based on the extracted DUT parameters. The automated script can be written in Python and used in conjunction with the Handlebars engine to generate the code.

[0086] This embodiment utilizes the UVM framework to create and manage interfaces. A test environment generator can be provided as needed, allowing users to configure interface parameters through a graphical interface and automatically generate the corresponding interface code and verification environment.

[0087] In this embodiment, to simulate the actual working environment of the interface, the actual working environment of the DUT interface can be simulated based on the harness interface. Test stimulus signals are sent to the DUT interface, and response signals are received from the DUT interface. The interaction method of this embodiment can ensure comprehensive testing and verification of the DUT interface in a controlled environment.

[0088] In some embodiments, the interaction between the harness interface and the DUT interface can be used to verify whether the functionality of the DUT interface meets the design requirements. Verifying the functionality of the DUT interface can include verifying aspects such as the timing, protocol, and error handling of interface signals.

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

[0090] S103: Create a verification environment module based on the 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 the DUT.

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

[0093] The verification environment module in this embodiment typically includes a test stimulus generator, a response monitor, verification control logic, and other components.

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

[0095] S104: Bind the 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 transfer mechanism.

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

[0097] It can be seen that the UVM platform is used to organize and manage the entire verification process. The DUT model, harness model, and verification environment module are instantiated within the verification platform. Then, through inter-module parameter information transfer mechanisms, such as UVM's TLM interface, the interface handle is passed to the verification environment module.

[0098] This embodiment, based on Harness interface handles, makes interface connections from the module to the chip level more direct, eliminating the need for verification engineers to manually create interface instances and perform complex signal connection work. Furthermore, the interface handles allow for more flexible management and configuration of interface instances within the verification environment. When an interface changes, only the relevant handle references and configuration information need to be modified to quickly adapt to new interface requirements, reducing maintenance costs.

[0099] S105: Based on the verification platform, implements, but is not limited to, sending interface signals to the interface under test, receiving interface signals from the interface under test, generating verification test sequences, converting the generated verification test sequences into interface signals received by the interface under test and driving them to the interface under test, monitoring the interface signals of the interface under test, and verifying the interface signals of the interface under test.

[0100] In some embodiments, the verification platform is used to perform tasks such as sending interface signals to the DUT interface, receiving interface signals from the DUT interface, generating verification test sequences, and verifying the interface signals of the DUT interface.

[0101] In this embodiment, test stimulus signals are sent to the DUT via the harness interface to simulate signal input in a real working environment. A response monitor is used to capture, process, and analyze the response signals from the DUT interface.

[0102] This embodiment can generate normal and abnormal test sequences according to verification requirements to cover the working states and boundary conditions of the DUT interface. The verification platform compares the acquired response signals with the expected results to verify whether the functionality of the DUT interface meets the design requirements. If any inconsistencies are found, 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 DUT interface, verification environment interface, template file, and configuration file; binds the DUT interface and verification environment interface to the verification platform, calls the verification environment module, and passes the interface handle to the verification environment module through an inter-module parameter information transfer mechanism; and verifies the interface signals based on the verification platform. This verification method can significantly shorten the testing cycle and reduce manual intervention and errors. Furthermore, by simulating various test scenarios and boundary conditions, it ensures that the DUT interface signals can function normally under different conditions and meet test requirements.

[0104] In one embodiment, Figure 2 This embodiment provides a flowchart for creating the Harness interface according to an embodiment of the present invention. Building upon the previous embodiments, this embodiment verifies whether the functionality of the DUT interface meets design requirements through interaction between the Harness interface and the DUT interface. This verification process reduces manual intervention and errors, improving testing 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 the interface parameters from the design file, traverse the design file, and obtain the first DUT interface.

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

[0108] In this embodiment, the extracted parameters are stored 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 embodiments of this application, the interface parameters in the design file include: interface name, interface description, input / output parameters, input parameters, output parameters, data type, input / output direction, interface protocol, port number, and error code.

[0110] The interface description specifies the functionality of the interface. Data types can be the data types of input and output parameters, such as integers, floating-point numbers, strings, and structures. The interface protocol can use protocols such as HTTP, TCP / IP, and UDP.

[0111] This embodiment of traversing the design file mainly involves using the appropriate Python library to parse the file content according to the design file's format. After parsing, based on the file's structure (such as a tree or list), loops are used to traverse different parts of the file. During the traversal, information such as the interface name, input / output parameters, and data type is extracted based on the identifiers of the interface parameters.

[0112] In automated testing or verification, the first DUT (Device Under Test) is selected as the starting point when multiple interfaces or DUTs exist. This facilitates the sequencing of the testing process and ensures the continuity and consistency of the tests.

[0113] Furthermore, by testing the first DUT interface, the correctness of the test environment, test scripts, 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] In this embodiment, the first DUT interface can serve as the entry point for the entire testing process, providing context or data for subsequent tests. By testing the first DUT interface, a testing benchmark can be established to evaluate the performance, stability, and accuracy of subsequent tests. Verifying the first DUT interface with other subsequent interfaces ensures the integration and compatibility of the entire system.

[0116] S202: Configure template files dut_if_template.sv and harness_if_template.sv, which are used to dynamically generate DUT interfaces and harness interfaces, 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 API class methods for the interface based on the configuration file provided by the verification personnel.

[0119] It should be noted that the configuration file is in Excel format and contains the signal path to be monitored, the transaction position where the re-driving occurs (begin_loc), the transaction position where the driving ends (end_loc), 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 serve as configuration template files that can be used to dynamically generate DUT interfaces and harness interfaces.

[0121] The template file dut_if_template.sv in this embodiment can be used to define the structure and characteristics of the DUT interface. Specifically, it involves the signal definitions, interface protocols, and module configurations required for interaction with the DUT interface. By setting the template file, interface files for the preset DUT can be automatically generated, enabling the verification platform to accurately communicate and exchange data with the DUT interface.

[0122] The template file harvest_if_template.sv defines the structure of the harvest interface. It is used to simulate the external environment and generate test stimuli, while capturing and analyzing the responses of the DUT interface.

[0123] In this embodiment, the harness_if_template.sv can be used to dynamically generate a harness interface that matches the DUT interface, 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, as well as to generate control signals for interface verification. The counting and control module can control the timing and order of test stimulus transmission, as well as the timing of DUT response capture, through counters and state machines.

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

[0126] The signal conversion module in this embodiment converts test stimulus signals into a format recognizable by the DUT interface, and converts the DUT interface response signals into a format processable by the verification platform. This ensures signal compatibility and data consistency between the verification platform and the DUT interface.

[0127] In this embodiment, the signal conversion module defines signal conversion functions or modules that can input and output signal formats, conversion rules, etc. Different conversion logics and parameters can be configured according to testing requirements.

[0128] The signal inspection module in 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 determines whether the DUT interface works as expected and generates corresponding test results.

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

[0130] S203: Call the DUT interface and generate the 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 according to the configuration file using the render method.

[0131] Then iterate through 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 automate the verification process of interface signals. The gen_if.py script can dynamically generate the required interface files based on configuration files and template files, thereby reducing reliance on repetitive work and improving verification efficiency.

[0133] The gen_if.py script in this embodiment is written in Python. It reads the signal name, type, and direction information from the configuration file and generates the signal by combining the structures of the template files dut_if_template.sv and harness_template.sv.

[0134] The gen_if.py script includes logic for reading configuration files, parsing template files, rendering dynamic fields into templates, and outputting the generated files.

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

[0136] In some specific embodiments, the render method is used to render dynamic fields into the template files dut_if_tempate.sv and harness_templete.sv. The render method is used to render dynamic data into the template files.

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

[0138] As can be seen, this embodiment utilizes the Render method to allow the template file to flexibly adapt to different input data and generate a qualified interface file. Furthermore, by automating the rendering of the template file, the automation level of the verification process can be further improved. Since the Render method automatically generates the interface file based on the template and dynamic data, errors caused by manually writing interface files can be reduced.

[0139] S204: Create a module named b_harness_x, instantiate the DUT interface within the b_harness_x module, and connect the DUT interface to the RTL signal via port references.

[0140] This embodiment also adds a bind dutb_haress_xharness_x (x = 1, 2, ..., n) declaration to the DUT interface, binding 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 in the verification platform used to automate the verification of 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 DUT's response, and verify whether these responses meet expectations.

[0142] In this embodiment, the DUT interface is instantiated within the b_harness_x module 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 DUT's ports, thereby enabling it to send test stimuli to the DUT and receive response signals from the DUT. This allows the verification platform to perform various test operations and verify whether the DUT's behavior meets the design requirements.

[0143] This embodiment also connects the DUT interface to RTL signals. Considering that RTL code is the low-level code describing the behavior of the hardware design, while the DUT interface is the interface between the verification platform and the hardware design, by connecting the DUT interface to the RTL signals, the verification platform can directly interact with the internal signals of the hardware design, thereby more accurately simulating the actual working environment of the hardware and verifying whether its behavior meets expectations.

[0144] This embodiment also adds a `bind dutb_harness_xharness_x` (x = 1, 2, ..., n) declaration to the interface of interest. The `bind` statement here is used in SystemVerilog to bind a DUT interface to another interface in a hierarchy. This allows adding test or monitoring functionality to the DUT interface without modifying the original RTL code. The `harness_x` module can be bound to the `b_harness_x` module, which in turn is bound to the DUT interface, thus enabling verification without interfering with the original design.

[0145] In this embodiment, binding the DUT interface and the instantiated b_harness module ensures 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] Binding can be implemented in SystemVerilog using the bind statement, which satisfies the accuracy and validity of the test.

[0147] S205: Declare the `set_vif` method within the added module. This method implements the transfer of the virtual interface handle to `config_db`, encapsulates the interface API classes `driver_h` and `check_h`, and adds the `set_vif` function to be passed to `config_db`. The top-level testbench calls the `set_vif` method to pass the UVM_Harness interface handle to other components of the verification platform, including the driver and monitor components.

[0148] In some specific embodiments, an interface API class can be defined to encapsulate operations related to the DUT interface, such as reading and writing signals, and checking signal status, in order to utilize the features and mechanisms of UVM.

[0149] In the UVM framework, the `set_vif` method can use UVM's `config_db` mechanism to set and pass virtual interface handles. The UVM framework allows components to pass configuration interface handles, parameters, and other information between them.

[0150] Inside the set_vif method, the set method of uvm_config_db is used to store the virtual interface handle in config_db, and the driver component and monitor component are specified as receivers.

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

[0152] In the driver and monitor components, the virtual interface handle is obtained through the get method of uvm_config_db, and the handle is used to perform tasks such as sending stimuli and capturing responses.

[0153] In this way, by passing virtual interface handles through `config_db`, decoupling between test platform components is achieved. In the UVM framework, components do not need to directly know the specific implementations of other components; they only need to obtain the required configuration information through `config_db`. Furthermore, `config_db` allows for flexible passing of configuration information between different layers of the test platform, making the test platform design more flexible, easier to extend, and easier to maintain. The encapsulated API classes can be reused in different test environments, improving code reusability and development efficiency.

[0154] like Figure 4 As shown, based on the above embodiments, the method for dynamically generating DUT interfaces and harness interfaces includes the following steps:

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

[0156] S302: Configure the parameters in the template file according to the specific requirements of the test project using scripts or automation tools. Parameters include, but are not limited to, interface type, signal name, bit width, and direction.

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

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

[0159] In this embodiment, calling the DUT interface and generating the script file involves using the `gen_if.py` script within the script file to generate the interface file. This reduces the workload of manually writing the interface file, avoids repetitive work, and improves development efficiency. The specific implementation steps will be explained 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 typically involve a series of automated and programmatic operations. Since direct, implementation-specific details can vary from project to project, the following is a generalized process based on common principles of automated testing and script generation:

[0161] S401: Obtain the DUT interface parameters for verification; determine the target and function of the generated script.

[0162] The script's goals and functions include: supporting dynamic field rendering, and whether it needs to support multiple interface configurations. DUT interface parameters include the interface's signals, protocol, and data format.

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

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

[0165] The script reads the configuration file, parses the template file, renders dynamic fields into the template, and outputs 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 a template engine to render dynamic fields.

[0168] The gen_if.py script in this example can iterate through the dynamic fields in the configuration file and insert them into the corresponding positions in the template file.

[0169] S405: Perform thorough testing on the gen_if.py script to ensure that it 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 start of each verification.

[0172] As can be seen, using the gen_if.py script to generate interface files can reduce the workload of manually writing interface files, avoid repetitive work, and improve development efficiency. Furthermore, automatically generated interface files can reduce human error, improve validation accuracy, and adapt to different validation requirements and DUT characteristics.

[0173] In this embodiment, in order to enable the automated integration of the Harness module and interface into the verification platform according to the DUT interface design, such as... Figure 6 As shown, the configuration file and Harness module generation process in this embodiment are as follows:

[0174] Define the configuration file as an Excel file to facilitate the processing of batch signals. The interface signals and module names are stored in an associative array and rendered as fields in the template file.

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

[0176] In this embodiment, `begin_tr` and `end_tr` 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 as an API parameter in `signal_collection`.

[0177] After the control signals can be read from the configuration file, the harness_module obtains the control signal name through macro definitions.

[0178] The following are embodiments of the automated interface signal control device provided in this disclosure. This device and the automated interface signal verification and control method of the above embodiments belong to the same inventive concept. For details not described in detail in the embodiments of the automated interface signal control device, please refer to the embodiments of the automated interface signal verification and control method described above.

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

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

[0181] The interface communication creation unit is used to configure template files and configuration files, and to create interactive interfaces for the design under test and the verification environment based on the extracted interface parameters of the design under test, template files and configuration files.

[0182] The verification environment configuration unit is used to create a verification environment module based on 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 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 transfer mechanism.

[0184] The interface verification unit, based on the verification platform, includes, but is not limited to, sending interface signals to the interface under test, receiving interface signals from the interface under test, generating verification test sequences, converting the generated verification test sequences into interface signals received by the interface under test and driving them to the interface under test, monitoring the interface signals of the interface under test, and verifying the interface signals of the interface under test.

[0185] In some specific embodiments, such as 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 signals and convert them to obtain the ID number for transaction-level transmission. At the same time, it maintains or delays the driving interface signals according to the parameters begin_loc and end_loc in the configuration file, expands the bit width of the DUT interface signals, and re-drives the interface signals to the verification environment by performing an OR operation between the extended bits and the original signals.

[0187] The control module is used to count the transactions after signal flipping and conversion.

[0188] The control module in this embodiment can output a release_on signal and a signal indication 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] Force mode can be used to maintain updated values ​​for user-specified interface signals until the start of the next transaction-level transfer.

[0192] Delay mode is based on a delay of N beats from the start of the control position of the interface signal.

[0193] The append mode is a re-driving signal for the interface signals of the first DUT, simulating the influence of external modules on the transmission of bus interface signals.

[0194] The signal checking module is used for assertions on interface signals.

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

[0196] This embodiment also provides Figure 9 The diagram shows a hardware structure for implementing an electronic device.

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

[0198] Those skilled in the art will understand that the electronic device structures involved in the embodiments of the present invention do not constitute a limitation on the electronic device. An electronic device may include more or fewer components than illustrated, or combine certain components, or have different component arrangements. In the embodiments of the present invention, the electronic device includes, but is not limited to, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, 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 claimed herein.

[0199] In this embodiment, processor 501 can be implemented 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, or an electronic unit designed to perform the functions described herein. In some cases, such implementations can be implemented within a controller. For software implementations, implementations such as processes or functions can be implemented with separate software modules that allow the performance of at least one function or operation. The software code can be implemented by a software application (or program) written in any suitable programming language, and the software code can be stored in memory and executed by the controller.

[0200] The processor 501 provides wireless internet access to the user through the network module 502, enabling 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 GPU processes image data of still images or videos acquired by an image capture device (such as a camera) in video capture mode or image capture mode.

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

[0202] User input unit 507 may include, but is not limited to, physical keyboards, function keys (such as volume control buttons, power buttons, etc.), trackballs, mice, joysticks, etc., which will not be described in detail here.

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

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

[0205] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0206] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

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

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

[0209] Extract the parameters of the interface to be tested; configure the template file and configuration file, and create an interactive interface between the interface to be tested and the verification environment based on the extracted parameters, template file, and configuration file; create a verification environment module based on the interface to be tested, the verification environment interface, the template file, and the configuration file; bind the 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 transfer mechanism; implement, but not limited to, sending interface signals to the interface to be tested, receiving interface signals from the interface to be tested, generating verification test sequences, converting the generated verification test sequences into interface signals received by the interface to be tested and driving them to the interface to be tested, monitoring the interface signals of the interface to be tested, and verifying the interface signals of the interface to be tested based on the verification platform.

[0210] In some possible implementations, various aspects of this disclosure may also be implemented as a program product comprising program code that, when run on a terminal device, causes the terminal device to perform the steps described in the “Exemplary Methods” section of this specification according to various exemplary embodiments of this disclosure.

[0211] The storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example,, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0212] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those 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 invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded 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, The methods include: S101: Extract the interface parameters of the design under test; Define and call the interface generation script, import the preset open source library, and render the interface signal parameters and configuration files into the template file in a preset way; Iterate through all extracted design interfaces to be tested until the first design interface to be tested, and connect the first design interface to the verification platform; S102: Configure template files and configuration files, and create interactive design-under-test interfaces and verification environment interfaces based on the extracted interface parameters of the design under test, template files and configuration files; Based on the template file, create an application programming interface; The template file includes: interface signal path, the transaction position of the re-drive, the transaction position of the drive end and the update value, and whether to check the 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, as well as generates control signals for interface verification; through counters and state machines, it controls the sending time and order of test stimuli, as well as the timing of capturing the response of the interface under test. The counting and control module defines the counter and the state machine, including state definitions, state transition conditions, and action outputs; and adjusts the counting range of the counter and the behavior of the state machine by configuring parameters. The signal conversion module converts the test stimulus signal into a format that the design under test (DUT) interface can recognize, and converts the response signal of the DUT interface into a format that the verification platform can process. The signal conversion module performs format conversion between input and output signals, and then configures the corresponding conversion logic and parameters according to the test requirements; The signal inspection module is used to check whether the response signals of the interface under test meet expectations; by comparing the actual response with the expected response, it determines whether the interface under test executes according to the preset test process and generates test results. The signal inspection module sets checkpoints and test standards by configuring expected response values ​​and inspection conditions; S103: Create a verification environment module based on the design under test interface, verification environment interface, template file, and configuration file; S104: Bind the interface of the design under test and the interface of the verification environment 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 transfer mechanism. S105: Based on the verification platform, implements, but is not limited to, sending interface signals to the interface under test, receiving interface signals from the interface under test, generating verification test sequences, converting the generated verification test sequences into interface signals received by the interface under test and driving them to the interface under test, monitoring the interface signals of the interface under test, and verifying the interface signals of the interface under test.

2. The automated interface signal verification and control method according to claim 1, characterized in that, Step S101 further includes: traversing the design file, obtaining the 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, Traverse all test interfaces except the first test interface and extract the interface signal parameters of any test interface. 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, The method also includes: configuring the test execution module and instantiating a second design interface to be tested within the test execution module; Bind the second design interface to the verification platform.

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

6. An automated interface signal control device, characterized in that, The apparatus is used to implement the automated interface signal verification and control method as described in any one of claims 1 to 5; the apparatus includes: The parameter extraction unit is used to extract the interface parameters of the design under test. The interface communication creation unit is used to configure template files and configuration files, and to create interactive interfaces for the design under test and the verification environment based on the extracted interface parameters of the design under test, template files and configuration files. The verification environment configuration unit is used to create a verification environment module based on 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 interface of the design under test and the interface of the verification environment 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 passing mechanism. The interface verification unit, based on the verification platform, includes, but is not limited to, sending interface signals to the interface under test, receiving interface signals from the interface under test, generating verification test sequences, converting the generated verification test sequences into interface signals received by the interface under test and driving them to the interface under test, monitoring the interface signals of the interface under test, and verifying the interface signals of the interface under test.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the automated interface signal verification and control method as described in any one of claims 1 to 5.

8. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the automated interface signal verification and control method as described in any one of claims 1 to 5.

Images