Universal verification platform, method and device for functional module, electronic equipment and medium

Abstract

The invention discloses a universal verification platform, method and device for a functional module, electronic equipment and a medium, and the platform comprises an excitation signal input module which is used for generating transaction excitation and transmitting the transaction excitation to a reference model and a tested device; the reference model is used for transmitting transaction excitation to an algorithm model function and sending an expected signal to the scoreboard; the tested device is used for generating an actual output signal and transmitting the actual output signal to the output signal detection module; the output signal detection module is used for detecting an actual output signal and transmitting the actual output signal to the scoreboard; and the scoreboard is used for verifying the function of the tested device. A reference model in the platform connects an algorithm model with a UVM environment through a connection mechanism of a DPI, the algorithm model generates expected data and transmits the data into a verification environment through a DPI interface to detect the correctness of output of a tested device, the process of writing an algorithm according to different test cases is omitted, rapid verification of a complex algorithm is achieved, and the test efficiency is improved. The development difficulty of a general verification platform is reduced, and the verification efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of chip algorithm module functional verification technology, and in particular to a general verification platform, method, apparatus, electronic device, medium and program product for functional modules. Background Technology

[0002] As the complexity of integrated circuit design continues to increase, the importance of verification work is becoming increasingly prominent. Universal Verification Methodology (UVM) is a commonly used verification method in the industry. It provides a standardized framework and components to build an efficient and reusable verification platform.

[0003] In existing technologies, traditional UVM-based verification platforms need to implement the same functions of complex algorithms, such as Digital Front End (DFE) processing algorithms, to obtain the expected output of the Design under Test (DUT). For complex algorithm modules like DFE, verification personnel need to reproduce the complex algorithms in the verification platform, which requires high manpower and time costs and is prone to errors, posing a high risk. Traditional verification schemes and technologies can only achieve black-box verification; if errors occur, locating the errors by design and verification personnel also requires high manpower and time costs. Summary of the Invention

[0004] This invention provides a general verification platform, method, device, electronic device, medium, and program product for functional modules to solve the problems of slow verification efficiency of complex algorithms, high platform development difficulty, and low accuracy and efficiency in locating errors.

[0005] According to one aspect of the present invention, a universal verification platform based on the Universal Verification Methodology (UVM) environment is provided, comprising: a register configuration module, an excitation signal input module, a reference model, a device under test (DUT), an output signal detection module, and a scoring board; the register configuration module, the excitation signal input module, and the output signal detection module are respectively connected to the DUT connected to the universal verification platform; the reference model is connected to the excitation signal input module and the scoring board respectively; the scoring board is also connected to the output signal detection module; the reference model includes a Direct Programming Interface (DPI). The DPI (Direct Programming Interface) imports a target file containing a C-language-based algorithm model function. This algorithm model function implements the internal processing logic of the device under test (DUT). Specifically: a register configuration module configures parameters for at least one register in the DUT based on test cases input to the UVM environment; an excitation signal input module generates transaction stimuli matching the test cases and transmits these stimuli to a reference model and the DUT; a reference model transmits the received transaction stimuli through the DPI to the pre-imported algorithm model function and sends the expected signal generated by the algorithm model function for the transaction stimuli to the scoring board; the DUT, in response to the transaction stimuli, generates an actual output signal matching the transaction stimuli through its internally defined processing logic and transmits the actual output signal to an output signal detection module; the output signal detection module detects the actual output signal sent by the DUT and transmits it to the scoring board; and the scoring board performs functional verification on the DUT based on the received actual output signal and the expected signal.

[0006] According to another aspect of the present invention, a general verification method based on a UVM environment is also provided, which is executed by a reference model in a general verification platform, comprising: acquiring a transaction stimulus generated and sent by a stimulus signal input module; passing the transaction stimulus to a pre-imported algorithm model function via DPI; and sending the expected signal generated by the algorithm model function for the transaction stimulus to a scoring board.

[0007] According to another aspect of the present invention, a general verification method based on a UVM environment is also provided, which is executed by a process real-time detection component in a general verification platform, including: acquiring the actual output sub-value at the target functional sub-module of the device under test; comparing the actual output sub-value with the expected output sub-value matching in the printed file; and ending the continued testing of the device under test when the detected comparison error exceeds a preset number threshold.

[0008] According to another aspect of the present invention, a general verification device based on a UVM environment is also provided. The reference model configured in the general verification platform includes: a transaction incentive acquisition module, used to acquire transaction incentives generated and sent by an incentive signal input module; a transaction incentive transmission module, used to transmit the transaction incentives to a pre-imported algorithm model function via DPI; and a desired signal transmission module, used to send the desired signal generated by the algorithm model function for the transaction incentives to a scoring board.

[0009] According to another aspect of the present invention, a universal verification device based on a UVM environment is also provided, comprising a process real-time detection component configured in a universal verification platform, including: an actual output sub-value acquisition module for acquiring the actual output sub-value at the target functional sub-module of the device under test; and an output sub-value comparison module for comparing the actual output sub-value with the expected output sub-value matched in the printed file, and terminating the continued testing of the device under test when the detected comparison error exceeds a preset number threshold.

[0010] According to another aspect of the present invention, an electronic device is also provided, the electronic device comprising:

[0011] At least one processor; and

[0012] A memory communicatively connected to the at least one processor; wherein,

[0013] The memory stores a computer program that can be executed by the at least one processor, which enables the at least one processor to perform the general verification method based on the UVM environment as described in any embodiment of the present invention.

[0014] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the general verification method based on the UVM environment as described in any embodiment of the present invention.

[0015] According to another aspect of the present invention, a computer program product is also provided, including computer instructions that, when executed by a processor, implement the steps of the method as described in any embodiment of the present invention.

[0016] The technical solution of this invention involves a register configuration module configuring parameters of at least one register in the device under test (DUT) based on test cases input into the UVM environment; an excitation signal input module generating transaction stimuli matching the test cases and transmitting these stimuli to a reference model and the DUT; the DUT responding to the transaction stimuli generating an actual output signal matching the stimuli through internally defined processing logic and transmitting the actual output signal to an output signal detection module; the reference model transmitting the received transaction stimuli to a pre-imported algorithm model function via DPI and sending the expected signal generated by the algorithm model function for the transaction stimuli to a scoring board; the output signal detection module transmitting the detected actual output signal sent by the DUT to the scoring board; and the scoring board performing functional verification on the DUT based on the received actual output signal and the expected signal. The reference model in the platform connects the algorithm model to the UVM environment via the DPI connection mechanism. The algorithm model generates expected data and transmits the data to the verification environment through the DPI interface to detect the correctness of the DUT's output. This eliminates the need to write algorithms based on different test cases, enabling rapid verification of complex algorithms, reducing the development difficulty of a general verification platform, and improving verification efficiency.

[0017] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments 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.

[0019] Figure 1 This is a schematic diagram of the structure of a general verification platform based on a UVM environment according to Embodiment 1 of the present invention;

[0020] Figure 2 This is a flowchart of a general verification method based on a UVM environment according to Embodiment 2 of the present invention;

[0021] Figure 3 This is a flowchart of a general verification method based on a UVM environment provided according to Embodiment 3 of the present invention;

[0022] Figure 4A This is a schematic diagram of the basic structure of a baseband module verification platform applicable to an embodiment of the present invention;

[0023] Figure 4B This is a schematic diagram illustrating the relationship between UVM, DPI, and wrapper functions applicable to an embodiment of the present invention;

[0024] Figure 4C This is a flowchart illustrating real-time monitoring of a DFE module applicable to embodiments of the present invention;

[0025] Figure 4D This is a schematic diagram of a DFE verification environment applicable to an embodiment of the present invention;

[0026] Figure 5 This is a schematic diagram of the structure of a universal verification device based on a UVM environment according to Embodiment 4 of the present invention;

[0027] Figure 6 This is a schematic diagram of the structure of a universal verification device based on a UVM environment according to Embodiment 5 of the present invention;

[0028] Figure 7 This is a schematic diagram of the structure of an electronic device that implements the general verification method based on the UVM environment according to the embodiments of the present invention. Detailed Implementation

[0029] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. 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 should fall within the scope of protection of the present invention.

[0030] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0031] Example 1

[0032] Figure 1This is a schematic diagram of a general verification platform based on a UVM environment provided in Embodiment 1 of the present invention. This embodiment is applicable to the situation where the algorithm module's function is verified by the expected signal generated by the algorithm module and the actual output signal generated by the design under test, especially for the rapid functional verification of complex algorithm modules. This verification platform can be used to implement a general verification method based on a UVM environment.

[0033] like Figure 1 As shown, the platform includes: a register configuration module 110, an excitation signal input module 120, a reference model 130, a device under test 140, an output signal detection module 150, and a scoring board 160.

[0034] The register configuration module 110, the excitation signal input module 120, and the output signal detection module 150 are respectively connected to the device under test 140 connected to the general verification platform. The reference model 130 is connected to the excitation signal input module 120 and the scoring board 160 respectively. The scoring board 160 is also connected to the output signal detection module 150. The reference model 130 contains a DPI, in which a target file is imported. The target file contains an algorithm model function based on the C language. This algorithm model function is used to implement the internal processing logic of the device under test 140.

[0035] UVM is an industry-standard methodology for building complex chip verification environments. Based on the SystemVerilog language, it provides a rich set of libraries and frameworks for constructing reusable and scalable verification platforms to verify whether integrated circuit designs meet expected specifications. In this embodiment of the invention, the general verification platform based on the UVM environment includes components such as a register configuration module 110, an excitation signal input module 120, a reference model 130, a device under test (DUT) 140, an output signal detection module 150, and a scoring board 160. The reference model 130 includes a Direct Programming Interface (DPI), which is a direct programming interface provided by SystemVerilog. It allows SystemVerilog to directly call interfaces and exchange data with other programming languages ​​(such as C, C++, etc.), enabling the integration of existing C / C++ code into the SystemVerilog test environment, or the calling of C / C++ functions within SystemVerilog. In SystemVerilog, the `import` and `export` keywords are used to import and export functions or tasks from other languages.

[0036] The target file can be understood as a wrapper source file written in C or C++, such as wrapper.c or wrapper.cpp. It provides a simplified interface for the C-based algorithm model functions in the file, ensuring that the verification environment and the algorithm model functions can interact correctly. The C-based algorithm model functions simulate the processing logic of the design under test, thereby simulating and verifying the algorithm's behavior. The number, type, and direction of the interface parameters in the wrapper file are determined by the functionality implemented by the module and the requirements of the verification environment.

[0037] Register configuration module 110 is used to configure parameters of at least one register in device under test 140 according to test cases input into the UVM environment.

[0038] In this embodiment of the invention, a test case can be specifically understood as an incentive generated by an incentive generator, used to describe a set of ordered transactions or data items for a specific test behavior or scenario, including detailed definitions of input data, control signals, and test procedures. The device under test 140 refers to the object that needs to be verified or tested during chip verification, i.e., the DUT.

[0039] During the verification process, due to the numerous and complex registers of the aforementioned components, the Verification Intellectual Property (VIP) of the Advanced High-Performance Bus (AHB) within the Advanced Microcontroller Architecture (AMBA) protocol is used. This involves configuring the registers in the baseband module under test (DUT) through the verification IP. The verification IP is a set of pre-built, reusable verification components that implement specific interfaces or protocols and can interact with the DUT 140 to verify its functionality and performance. VIPs typically include components such as a protocol monitor, stimulus generator, response checker, and coverage model, which help verification engineers quickly build the verification environment, improving verification efficiency and quality.

[0040] The register configuration module 110 uses the VIP to configure the environmental information of registers in components such as the excitation signal input module 120, reference model 130, device under test 140, output signal detection module 150, and scoring board 160. This environmental information includes general environmental configuration information and dynamic environmental configuration information that is dynamically updated based on the test cases input to the UVM environment. Typically, general environmental configuration information may include the interface type, width, and protocol of the device under test 140, as well as the memory address mapping relationship between the register model and the device under test 140; dynamic environmental configuration information may include providing different data packets and transmission rates based on the size of the test case input parameters, and dynamically selecting a series of performance test cases according to the test plan.

[0041] The excitation signal input module 120 is used to generate transaction stimuli that match the test cases and transmit the transaction stimuli to the reference model 130 and the device under test 140.

[0042] In this embodiment of the invention, the excitation signal input module 120 can be specifically understood as a UVM component responsible for generating test transaction stimuli and transmitting them to the reference model 130 and the device under test 140, to simulate all input operations on the device under test 140 in the real world, including user operations, sensor inputs, and interactions with other hardware devices. It ensures that the device under test 140 responds correctly under various expected and unexpected input conditions.

[0043] The stimulus signal input module 120 typically includes the following sub-components: a driver, a stimulus generator, a monitor, and a proxy configuration. The driver drives the input signals of the DUT based on transactions generated by test cases, simulating input conditions in a real hardware environment by converting these transactions into specific signal assignment operations. The stimulus generator controls the execution order of the driver, acquiring transactions from different test cases and passing them to the driver according to a predetermined test plan. The monitor monitors the input ports of the DUT 140, capturing the behavior of the DUT 140 and generating transactions. The proxy configuration includes parameters for configuring the driver and stimulus generator, such as interface protocol, data width, and address space.

[0044] Reference model 130 is used to pass the received transaction incentive to a pre-imported algorithm model function via DPI, and send the expected signal generated by the algorithm model function for the transaction incentive to the scoreboard 160.

[0045] In this embodiment of the invention, the reference model 130 can be specifically understood as an ideal or mathematically precise model used to simulate the behavior of the device under test 140 in order to generate the desired output data signal during the verification process. The reference model 130 typically includes sub-components such as environment configuration, registers, and algorithm models. The reference model 130 is usually implemented in a high-level programming language (such as C / C++), providing a precise description of the behavior of the device under test 140, including detailed implementations of the algorithms and logic. The desired signal refers to the data signal calculated through the algorithm model (such as a C model). During the verification process, the desired data generated by the reference model 130 is used to transmit to the scoring board 160 for comparison with the actual output of the device under test 140 to verify the functional correctness of the device under test 140.

[0046] The device under test 140 is used to generate an actual output signal that matches the transaction stimulus through internally defined processing logic in response to the transaction stimulus, and transmit the actual output signal to the output signal detection module 150.

[0047] In this embodiment of the invention, the device under test 140 is a hardware design whose functionality, performance, and reliability need to be verified. The device under test 140 typically includes numerous registers and ports and analysis interfaces to communicate with other UVM components (such as monitors and scoreboards 160). The device under test 140 can generate an actual output signal that matches the transaction stimulus through internally defined processing logic. The performance of the device under test 140 is verified by comparing it with the expected signal.

[0048] The output signal detection module 150 is used to transmit the detected actual output signal sent by the device under test 140 to the scoring board 160.

[0049] In this embodiment of the invention, the output signal detection module 150 is responsible for managing and monitoring the output signals of the device under test (DUT) 140. It typically includes a monitor that listens to the DUT's output port and captures all output data, control signals, and other related signal activity. These signals may include address bus, data bus, read / write signals, and interrupt signals. The output signal detection module 150 is typically connected to the output interface of the DUT 140 to capture output data, generate transactions, and transmit this data to subsequent verification components, such as the scoring board 160, for further comparison and verification.

[0050] The scoring board 160 is used to perform functional verification on the device under test 140 based on the received actual output signal and the expected signal.

[0051] In this embodiment of the invention, a scoring board 160 verifies and evaluates the behavior of the device under test (DUT) 140. The main purpose of the scoring board is to check whether the actual output signal of the DUT 140 meets expectations, i.e., whether it is consistent with the expected signal generated by the reference model 130. The scoring board 160 typically includes components such as a data comparator, environment configuration, and registers. It receives the actual output signal of the DUT 140 from the monitor of the output signal detection module 150 and the expected data from the reference model 130, and then compares these two sets of data. If the result is inconsistent with expectations, the scoring board marks it as an error or failure, enabling timely detection of problems in the design. The scoring board can monitor test coverage, ensuring that all parts of the design have been verified.

[0052] This invention provides a general verification platform based on a UVM environment, comprising: a register configuration module, an excitation signal input module, a reference model, a device under test (DUT), an output signal detection module, and a scoring board. The register configuration module configures parameters of at least one register in the DUT according to test cases input into the UVM environment. The excitation signal input module generates transaction stimuli matching the test cases and transmits these stimuli to the reference model and the DUT. In response to the transaction stimuli, the DUT generates an actual output signal matching the transaction stimuli through internally defined processing logic and transmits the actual output signal to the output signal detection module. The reference model transmits the received transaction stimuli to a pre-imported algorithm model function via DPI and sends the expected signal generated by the algorithm model function for the transaction stimuli to the scoring board. The output signal detection module detects the actual output signal sent by the DUT and transmits it to the scoring board. The scoring board performs functional verification on the DUT based on the received actual output signal and the expected signal. The DPI connection mechanism connects the algorithm model to the UVM environment, enabling the algorithm model to generate expected data and transmit this data to the verification environment via the DPI interface for accuracy testing of the DUT's output. This approach avoids the tedious process of rewriting algorithms for each different test case, thus enabling rapid verification of complex algorithms. It not only reduces the development difficulty of general-purpose verification platforms but also significantly improves the efficiency of verification work.

[0053] Optionally, in this embodiment of the invention, the device under test 140 may include multiple functional sub-modules connected end to end, with each pair of adjacent functional sub-modules forming a sub-module pair; the general verification platform may further include a real-time process detection component, which is connected to the output end of the preceding functional sub-module in at least one sub-module pair and a reference model; the reference model 130 may further be used to transmit the expected output sub-value of each functional sub-module of the device under test 140 to the real-time process detection component for printing and generate a matching print file during the process of generating an actual output signal that matches the transaction stimulus through internally defined processing logic; the real-time process detection component is specifically used to compare the actual output sub-value with the expected output sub-value matched in the print file when obtaining the actual output sub-value from the target functional sub-module of the device under test 140, print the error position when a comparison error is detected, and terminate the continued testing of the device under test 140 when the detected comparison error exceeds a preset number threshold.

[0054] In this embodiment of the invention, in a general verification platform based on a UVM environment, the device under test 140 may include multiple functional sub-modules connected end to end. These sub-modules can be verified individually or in combination. Each functional sub-module refers to a logic unit with a specific function inside the device under test 140. A sub-module pair refers to the relationship between two adjacent functional sub-modules, which can work together to generate intermediate output values.

[0055] The general verification platform may also include a real-time process monitoring component, which is connected to the output of the preceding functional sub-module of at least one sub-module in the device under test 140 and the reference model 130. The reference model 130, during the process of generating an actual output signal matching the transaction stimulus through its internally defined processing logic, transmits the intermediate output values ​​of each functional sub-module of the device under test 140 in the C-language-based algorithm model function as expected output sub-values ​​to the real-time process monitoring component for printing, and generates a matching print file recording each intermediate output value.

[0056] The real-time process monitoring component can be understood as a component used to compare expected output sub-values ​​with actual output sub-values ​​to verify the internal logic function of the device under test (DUT) 140. When the real-time process monitoring component obtains the actual output sub-value from the target functional sub-module of the DUT 140, it compares the actual output sub-value with the matching expected output sub-value in the printed file. When a comparison error is detected, the error location is printed. If the number of detected comparison errors exceeds a preset threshold, the test on the DUT 140 is terminated. Each functional sub-module can use intermediate output values ​​between sub-module pairs, simplifying the verification process and improving the flexibility and maintainability of verification. Through intermediate output values ​​between sub-module pairs, the functionality of the sub-modules can be verified more meticulously without completely relying on the final output. By recording each intermediate output value and the location of the error in the printed file, the exact location of the error can be quickly located when the test fails, facilitating debugging and repair. The file provides rich debugging information, making the intermediate execution state visible and facilitating understanding of the behavior and state changes of the DUT 140. In some testing scenarios, a certain number of errors may be expected. For example, when testing error handling mechanisms, setting an error threshold can prevent the processing flow from being triggered every time an error occurs, thereby reducing interference with the testing process. This batch error processing method allows for centralized processing after a certain number of errors have been reached, reducing repetitive processing logic and improving overall verification efficiency. Centralized error processing allows for better utilization of computing resources, avoiding frequent context switching or repeated execution of the same error handling procedures.

[0057] Optionally, in this embodiment of the invention, the device under test 140 is specifically a general digital front-end processing algorithm module; the general digital front-end processing algorithm module includes a time-domain frequency offset calibration submodule and a low-pass filter submodule, and the real-time process detection component is connected to the output terminals of the time-domain frequency offset calibration submodule and the low-pass filter submodule respectively.

[0058] In this embodiment of the invention, general digital front-end processing algorithms typically refer to a series of algorithms and techniques for digital signal processing of analog signals in digital communication systems. These algorithms are crucial for improving the performance of communication systems, reducing power consumption, and enhancing signal quality. In baseband chip accelerators, their functions include frequency offset adjustment and low-pass filtering downsampling. Baseband chip accelerators typically refer to hardware units integrated into baseband chips used to accelerate specific computational tasks, such as signal encoding / decoding, encryption / decryption, signal modulation, and demodulation. These accelerators can significantly improve processing speed and efficiency, thereby enhancing overall communication performance. Frequency offset refers to the deviation between the actual frequency of a signal and its nominal frequency. In wireless communication, frequency offset adjustment refers to adjusting the frequency of the transmitted or received signal to compensate for frequency deviations caused by hardware imperfections or environmental factors, thereby improving signal quality and communication accuracy. Downsampling is the process of reducing the signal sampling rate, usually performed after low-pass filtering to avoid aliasing. Therefore, the general digital front-end processing algorithm module includes a time-domain frequency offset calibration submodule and a low-pass filter submodule. The real-time process detection component is connected to the output terminals of the time-domain frequency offset calibration submodule and the low-pass filter submodule, respectively, to receive and compare important intermediate values ​​in the general digital front-end processing algorithm module to verify the correctness of the internal logic function.

[0059] Optionally, in this embodiment of the invention, the register configuration module 110 specifically includes: a register model, an adapter, and a VIP for acting as a bus, connected in sequence; the register model is used to model each register contained in the device under test according to test cases, obtain register configuration parameters, and transmit the register configuration parameters to the adapter; the adapter is used to convert the received register configuration parameters to a data format compatible with the VIP, and then transmit them to the device under test through the VIP, so as to configure parameters for at least one register in the device under test.

[0060] In this embodiment of the invention, the register configuration module 110 specifically includes: a register model, an adapter, and a VIP (Virtual Identity Provider) acting as a bus, connected sequentially. The VIP connects an advanced high-performance bus based on an on-chip bus protocol to the device under test (DUT) via an interface. The register model models the registers in the DUT 140 according to test cases generated by the stimulus generator, obtaining dynamic register configuration parameters, and transmits these parameters to the adapter connected to the register model. The adapter converts the received register configuration parameters to a data format compatible with the VIP, and then generates transaction stimuli through the stimulus generator within the register configuration module 110. The transaction defines the specific form of the stimulus and defines multiple variables corresponding to the input signals. The driver sends these transaction stimuli according to timing requirements, transmitting the transaction stimulus signal from the stimulus generator to the DUT 140 via the interface between the register configuration module 110 and the DUT 140, through the VIP, to configure parameters for at least one register in the DUT 140. In addition, for a UVM-based general verification platform, besides parameter configuration, test case data can also be transmitted to the stimulus signal input module 120 via VIP in this way as test cases for the reference model 130. The adapter can convert the transactions transmitted by the VIP into data that the register model can accept, thereby updating the register value, so that the verifier can check whether the register has stored data and whether the stored data is correct.

[0061] Optionally, in this embodiment of the invention, the VIP is used to act as an advanced high-performance bus based on an on-chip bus protocol.

[0062] In this embodiment of the invention, in the field of chip design and verification, VIP refers to a core of intellectual property used for verification. It is an advanced high-performance bus based on various on-chip bus protocols, providing a pre-built, reusable, and simulation-ready bus interface model capable of simulating bus behavior, such as AHB (Advanced Peripheral Bus) of AMBA, APB (Advanced Peripheral Bus), and AXI (Advanced Extensible Interface). AHB is a bus designed for high performance, supporting high bandwidth and low latency data transmission. AHB is typically used to connect processors, high-speed memory, and other modules requiring high data transfer rates. APB is a bus designed for low power consumption, typically used to connect peripherals that do not require high bandwidth. AXI is a high-performance and scalable bus protocol that supports high bandwidth and low latency data transmission, suitable for complex system-on-chip designs. Because the AXI protocol is much more complex than the AHB protocol, it supports read / write channel separation, out-of-order processing, and more transmission types. This complexity may make the implementation and maintenance of AXI VIPs more difficult, requiring more simulation resources and time. Therefore, AHB or APB VIPs can be used in a UVM-based general verification platform. AHB's VIP can be used in UVM-based verification platforms used for DFE verification.

[0063] Optionally, in this embodiment of the invention, the excitation signal input module 120 specifically includes: an excitation generator, a driver, and a monitor; the excitation generator is used to generate transaction excitations that match the test cases; the driver is used to sequentially send the transaction excitations to the device under test 140 according to preset timing requirements; and the monitor is used to transmit the detected transaction excitations to the reference model 130 when the transaction excitations are detected.

[0064] Specifically, the stimulus signal input module 120 includes a stimulus generator, a driver, and a monitor. The stimulus generator generates corresponding transactions according to the requirements of the test cases. These transactions are data structures in UVM used to represent test actions, containing all the information required to execute the test, such as data, control signals, and timestamps. The driver sends these transaction stimuli according to timing requirements, transmitting the transaction signals from the stimulus generator to the corresponding registers in the device under test (DUT) 140 via an interface, thus enabling content-driven delivery to the DUT 140. The monitor monitors these transaction stimuli and can transmit the detected transaction stimuli to the reference model 130 in the form of Transaction Level Modeling (TLM). By separating computational and communication functions during system modeling, communication between modules is achieved using function calls. Modules do not need to concern themselves with port definitions and port timing, resulting in faster modeling and improved efficiency and reliability of the verification process.

[0065] Furthermore, in this embodiment of the invention, the general verification platform also includes a top-level configuration module; the top-level configuration module is used to configure the basic parameters of the reference model, register configuration module, excitation signal input module and scoring board before performing tests on the device under test.

[0066] In this embodiment of the invention, the general verification platform further includes a top-level configuration module. This layer includes a test environment, a device under test (DUT) 140, interfaces, and clock and reset mechanisms. At this level, the DUT 140 needs to be instantiated, the test environment connected to the DUT 140 via the interface, and basic parameters of various components in the test environment configured, such as register addresses, fields, and default values ​​in the DUT 140. The interface configuration connects the DUT 140's interface to components in the UVM environment, and the clock frequency, period, rise / fall time, and reset signal behavior are also configured. The test environment is like a container holding all necessary components, such as a reference model, register configuration module, stimulus signal input module, and scoring board. A hierarchical verification platform is built upon this foundation.

[0067] Optionally, in this embodiment of the invention, the excitation signal input module 120 and the reference model 130 transmit data through a first-in-first-out queue, and the output signal detection module 150 and the scoring board 160 transmit data through a first-in-first-out queue.

[0068] Specifically, the First-In-First-Out (FIFO) queue follows a specific order rule to process data items, meaning the data item that enters the queue first will be removed first. By constructing FIFO-style data buffers between the excitation signal input module 120 and the reference model 130, and between the output signal detection module 150 and the scoring board 160, a buffering mechanism is used to temporarily store data, preventing data loss under high load. This ensures that execution proceeds in the triggered order, effectively managing and processing the data flow, and ensuring the reliability of the UVM-based general verification platform.

[0069] Optionally, in this embodiment of the invention, the target file is implemented by adding a shell function outside the algorithm model function. The number, type, input or output direction of the interface parameters defined in the shell function are determined by the functions implemented by the device under test 140 and the configuration parameters required by the UVM environment.

[0070] Specifically, a shell function can be understood as an encapsulation or adaptation function. It acts as an intermediate layer, adapting external calls to the underlying implementation functions (such as the top-level function). The top-level function refers to the highest-level function or method in a module, library, or system that can be directly called externally. In an algorithm model, the top-level function is the interface that provides the model to the outside world. It encapsulates the model's internal logic and implementation details, allowing other modules or testing environments to interact with the algorithm model through this function. In hardware verification, the shell function is used to adapt the verification environment's calls to the algorithm model's top-level function. The shell function can handle tasks such as data format conversion, parameter mapping, and call synchronization to ensure that the verification environment and the algorithm model functions can interact correctly.

[0071] The number, type, and input or output direction of the interface parameters defined in the shell function are determined by the functionality implemented by the device under test (DUT) 140 and the configuration parameters required by the UVM environment. Typically, the number of signals or buses defined by the DUT 140's interface corresponds to the number of parameters defined in the shell function. For example, if the DUT 140 has a bus interface containing address, data, and read / write signals, then the shell function needs to define three parameters to represent these signals. Typically, the parameter type should match the type of the signal in the DUT 140. If a signal in the DUT 140 is a 32-bit wide data bus, then the corresponding parameter in the shell function should also be a 32-bit wide data type. Typically, the direction of the parameter (input, output, or bidirectional) depends on the signal's role in the DUT 140. For example, a control signal might be an output (from the test environment to the DUT 140), while a data signal might be an input (from the DUT 140 to the test environment). Typically, the specific functionality of the DUT 140 determines which types of signals are needed for interaction. For example, an adder requires two input signals (operands) and one output signal (result). Typically, a UVM environment may require additional parameters to control test execution, such as clock frequency, reset signal, or test mode, which determine the interface definition in the shell function.

[0072] Optionally, in this embodiment of the invention, test cases are input using at least one seed number, with each seed number pointing to a set test file; based on various seed numbers, each test file is automatically executed in batches using automated scripts.

[0073] Specifically, in automated testing and verification, a seed number is an identifier used to associate a specific test case or test dataset. Each seed number can point to a defined test file, allowing the triggering and tracking of test case execution. To achieve completeness in verifying the functionality of algorithm modules, numerous fixed-phasor tests are required. Fixed-vector test cases typically use fixed test vectors from data files. By passing externally input seed numbers to the stimuli, the path is directed to the file to be read, and read / write operations are performed on that file. This allows all fixed-phasor tests to be completed simply by inputting the seed number of the file to be run in the script, significantly improving the efficiency of the testing process. Automated scripts ensure that each test is executed under the same conditions, improving the consistency and repeatability of test results. Automated scripts are easy to maintain and update; when test requirements change, the script can be quickly adjusted without redesigning the test process.

[0074] Example 2

[0075] Figure 2This is a flowchart of a general verification method based on a UVM environment provided in Embodiment 2 of the present invention. The method is executed by a reference model in a general verification platform. This embodiment is applicable to situations where the processing logic of the design under test is simulated based on transaction stimuli to generate corresponding expected signals. This method can be executed by a general verification device based on a UVM environment. This general verification device based on a UVM environment can be implemented in hardware and / or software, and is generally configured in the reference model of a general verification platform based on a UVM environment. Figure 2 As shown, the method includes:

[0076] S210. Obtain the transaction stimulus generated and sent by the stimulus signal input module.

[0077] S220, Pass the transaction incentive to the pre-imported algorithm model function via DPI.

[0078] S230. Send the expected signal generated by the algorithm model function for the transaction incentive to the scoreboard.

[0079] Specifically, the reference model integrates the DPI feature, enabling SystemVerilog to interface with and exchange data with other programming languages ​​such as C and C++. This feature greatly facilitates the integration of existing C / C++ code into the SystemVerilog testing environment, and also allows direct calling of C / C++ functions from within SystemVerilog code. In the SystemVerilog context, interoperability with functions or tasks from other programming languages ​​can be achieved using the `import` and `export` keywords. Specifically, the `import` keyword is used to import functions or tasks from other languages, while the `export` keyword is used to export functions or tasks from SystemVerilog so that other languages ​​can call them. This flexible interface mechanism not only enhances code reusability but also improves the efficiency of cross-language collaboration.

[0080] Furthermore, in this embodiment of the invention, the method may further include:

[0081] The actual output signal is generated by the internally defined processing logic and matches the transaction incentive.

[0082] The expected output sub-values ​​of each functional sub-module of the device under test are printed, and a matching print file is generated and transmitted to the process real-time detection component.

[0083] Specifically, the reference model generates actual output signals that match the transaction incentives through internal processing logic. It uses the intermediate output values ​​of the C language algorithm model function as expected output sub-values ​​to transmit to the real-time detection component for printing, and generates matching print files that record each intermediate output value, thereby achieving accurate verification, facilitating debugging, improving efficiency, and supporting documentation.

[0084] The technical solution of this invention acquires transaction stimuli generated and sent by the excitation signal input module, transmits these stimuli to a pre-imported algorithm model function via DPI, and sends the expected signal generated by the algorithm model function in response to the transaction stimuli to the scoring board. Through the DPI connection mechanism, the algorithm model is connected to the UVM environment, enabling the algorithm model to generate the expected data. This data is then transmitted to the verification environment via the DPI interface for accuracy testing of the device under test's output. This method avoids the tedious process of rewriting algorithms for each different test case, thus achieving rapid verification of complex algorithms. It not only reduces the development difficulty of a general verification platform but also significantly improves the efficiency of verification work.

[0085] Example 3

[0086] Figure 3 This is a flowchart of a general verification method based on a UVM environment provided in Embodiment 3 of the present invention. It is executed by the real-time process monitoring component in the general verification platform. This embodiment is applicable to situations where the internal algorithm logic of the device under test is functionally verified by comparing the expected output sub-values ​​with the actual output sub-values. This method can be executed by a general verification device based on a UVM environment. This general verification device based on a UVM environment can be implemented in hardware and / or software, and is generally configured in the real-time process monitoring component of the general verification platform. Figure 3 As shown, the method includes:

[0087] S310. Obtain the actual output sub-value at the target functional sub-module of the device under test.

[0088] S320. Compare the actual output sub-value with the expected output sub-value that matches in the printed file, and terminate the continued testing of the device under test when the detected comparison error exceeds a preset number threshold.

[0089] In this embodiment of the invention, the real-time process detection component is used to compare the output of each target functional sub-module in the middle of the register transfer stage, according to the execution order of each link of the target functional module, such as the target functional sub-modules of the general digital front-end processing algorithm module, thereby realizing real-time monitoring of the execution process of the target functional sub-module.

[0090] In the UVM validation methodology, a dedicated scoreboard derived from `uvm_scoreboard` is typically defined in the validation environment based on requirements, and data comparison is performed using this scoreboard. This data comparison method requires that the actual output of each target functional submodule be passed to the scoreboard in a first-in, first-out (FIFO) manner. The expected output data of the algorithm model (such as the C model) also needs to be stored in an array and passed from the reference model to the scoreboard in a FIFO manner, and then compared between the two in a FIFO manner. For a target functional module containing numerous target functional submodules, and requiring real-time monitoring of the output of each submodule according to configuration, such as a general digital front-end processing algorithm module, this comparison method is very complex and prone to errors due to differences in the format and quantity of output data. Furthermore, excessive FIFO data transfer significantly increases the overall validation process time, leading to low validation efficiency.

[0091] Therefore, the real-time process monitoring component proposed in this embodiment compares the calculation output results of each target functional sub-module within its monitor. Expected data is transmitted to the real-time monitoring component for printing via intermediate output values ​​from the C language algorithm model function in the reference model, generating a matching print file recording each intermediate output value. The monitor monitors the values ​​of the corresponding target functional sub-module interface signals to obtain the actual output results of the target functional sub-module of the device under test. This allows for direct comparison of the actual data of the corresponding target functional sub-module with the expected data in the corresponding file using conditional statements within the monitor of the real-time process monitoring component. The valid information of the comparison results is then printed using uvm_info. If a certain number of comparison errors occur, the process stops. This not only eliminates the need to run the entire chain to know the comparison results as in traditional methods, reducing the verification time of each target functional sub-module within the target functional module, but also allows for direct identification of the target functional sub-module with the output comparison problem, reducing error localization time.

[0092] Specifically, the actual output sub-values ​​at the target functional sub-module of the device under test (DUT) are obtained. For example, these sub-values ​​are connected to the outputs of the time-domain frequency offset calibration sub-module and the low-pass filter sub-module of the digital front-end processing algorithm module within the DUT. This allows for the reception and comparison of important intermediate values ​​from the general digital front-end processing algorithm module, verifying the correctness of the internal logic function. Then, the actual output sub-values ​​are compared with the expected output sub-values ​​matching in the printed file. If the detected comparison errors exceed a preset threshold, the testing of the DUT is terminated.

[0093] The technical solution of this invention obtains the actual output sub-values ​​at the target functional sub-module of the device under test (DUT), compares these actual output sub-values ​​with the expected output sub-values ​​matching the printed file, and terminates further testing of the DUT when the detected comparison errors exceed a preset threshold. Setting an error threshold helps prevent each error from triggering a complete processing flow, reducing unnecessary interference with the testing process. This batch error handling strategy allows for unified processing after errors accumulate to a certain threshold, effectively reducing repetitive work and improving the efficiency of the verification process. Centralized error handling also optimizes the use of computing resources, avoiding frequent switching of processing contexts or repeated execution of the same error handling steps.

[0094] Specific application scenarios

[0095] Figure 4A This is a schematic diagram of the basic structure of a baseband module verification platform applicable to an embodiment of the present invention. In this specific application scenario, in order to achieve rapid verification of complex algorithms, reduce the development difficulty of a general verification platform, and improve verification efficiency, each embodiment of the present invention designs a general verification platform based on a UVM environment. By designing a reference model and connecting it to the UVM environment through the DPI connection mechanism, the process of writing algorithms according to different test cases is eliminated.

[0096] Accordingly, as shown in Figure 4, the baseband module verification platform includes: UVM test case, Test Bench TOP, Test Environment, Reference Model (RM), FIFO (First-In-First-Out) queue, Scoreboard, Compare Function, C Model, Sequence, Sequencer, Driver, Monitor, Virtual Sequencer, and Register Model. The components include: model, adapter, design under test (DUT, equivalent to the device under test mentioned above), input signal module (input_agent), output signal detection module (output_agent), agent module environment configuration information (agent_cfg), clock signal (clk), reset signal (reset), environment configuration information (env_cfg), AHB / APB system environment (svt_ahb / apb_system_env), AHB / APB environment configuration information (ahb / apb_env_cfg), AHB / APB interface (Ahb / apb_if), input interface (input_if), and output interface (output_if).

[0097] This platform uses the Advanced High-Performance Bus (AHB) or the VIP of the APB in the AMBA on-chip bus protocol to configure the registers in the baseband module under test.

[0098] Virtual_sequencer is used to uniformly pass stimuli to each agent through this module, serving as a connection between various agent components.

[0099] The Adapter is used for data format conversion, converting data received from the Reg Model into a format suitable for transmission via AHB or APB VIP.

[0100] A sequence is an ordered set of transactions or data items used to describe specific test behaviors or scenarios in a test case. The sequencer generates these transaction stimuli. The driver sends these transaction stimuli according to timing requirements, passing the transaction signals from the sequencer to the input agent via Ahb / apb_if and input_if. Similarly, after processing by the sequencer and driver, data is pushed into a queue for sorting, and data is popped from the queue to the Reg Model of the Resource Manager (RM), thus implementing content-driven delivery to the RM. The monitor monitors these transaction stimuli and transmits the detected transactions to the DUT via TLM. The RM transmits the generated expected values ​​to the scoreboard via a FIFO queue, and the DUT sends the actual output values ​​to the output agent via output_if, and then to the scoreboard via a FIFO queue.

[0101] The scoreboard is used to compare the expected value (equivalent to the expected signal mentioned earlier) generated by c_model with the actual value (equivalent to the actual output signal mentioned earlier) to verify the correctness of the module's output. In this design, the computational model in the RM does not consume platform simulation time. The expected data can be stored in a queue first, and then passed to the scoreboard for data comparison using a first-in, first-out (FIFO) method, improving verification efficiency.

[0102] The configuration information in Env_cfg is encrypted using data randomization to ensure security. The env_cfg contained in Ahb / apb_env_cfg, agent_cfg, and c_model, as well as the env_cfg contained in scoreboard, all include the env_cfg in the environment, i.e., general environment configuration information.

[0103] In addition, the aforementioned environmental information also includes dynamic environment configuration information related to the input stimulus passed from the previous level component. Ahb / apb_env_cfg includes the env_cfg in the environment and dynamic configuration information related to the received stimulus information. agent_cfg includes the env_cfg in the environment and dynamic configuration information passed from the Ahb / apb protocol module.

[0104] The env_cfg in cmodel includes the env_cfg in the environment and the dynamic configuration information from input_agent. The env_cfg in Scoreboard includes the independent env_cfg in the environment and the dynamic configuration information from output_agent.

[0105] Figure 4B This is a schematic diagram illustrating the relationship between UVM, dpi, and wrapper functions applicable to an embodiment of the present invention. Based on the DPI-based connection mechanism, the verification platform directly calls the algorithm model (c model) to calculate the expected data of the algorithm input data, and the data output is transmitted to the Scoreboard and compared with the actual output information in the monitor of the output_agent.

[0106] The algorithm model in this module is written in C language, while the verification environment is written in System Verilog language. To connect the two, DPI is needed, which can help the verification environment pass parameters to the algorithm model (referred to as the C model).

[0107] DPI needs to be declared using `import`, specifying whether the parameter direction is input or output. `input` refers to the data fed into the C model, and `output` refers to the parameters output by the C model to the validation environment. Secondly, the top-level function of the C model needs to be determined. If the top-level function of the C model is to be used directly in the validation environment, a wrapper function needs to be added. The number, type, and direction (input or output) of the interface parameters of the wrapper function are determined by the functionality implemented by the module and the requirements of the validation environment.

[0108] In this module, configuration parameters and input data serve as the input to the wrapper function, while output data (expected values) and some configuration data that needs to be configured for the DUT serve as the output of the wrapper function. Besides the interface, to implement the functionality of the algorithm module, the wrapper function also needs to call the algorithm's function calls (C model), all of which need to be written separately in wrapper.c. Finally, the wrapper function is imported into the UVM platform via the aforementioned DPI and its import function.

[0109] To address the challenge of error localization caused by the numerous submodules in the DFE module, a real-time process monitoring and comparison component was added to the verification platform to enable timely error detection and rapid localization during verification. This component's function is to compare the output of each submodule sequentially according to the execution order of each link during RTL (Register Transfer Level) operation. In the UVM verification methodology, data comparison is typically performed on a dedicated scoreboard. Verification personnel will customize a scoreboard derived from uvm_scoreboard within the verification environment based on their needs.

[0110] This verification platform does not use the scoreboard component for routine data comparison during intermediate monitoring data comparison. Instead, the comparison of the computational output results of each submodule is designed within the monitor of the process monitoring component. Using the traditional scoreboard comparison method, the actual output of each submodule needs to be passed to the scoreboard via FIFO, and the expected output data of the C model also needs to be stored in an array and passed from the reference model to the scoreboard via FIFO, with the two then compared using a first-in-first-out (FIFO) approach. For this module, which contains numerous submodules and requires real-time monitoring of each submodule's output based on configuration, this comparison method is extremely complex and prone to errors due to differences in output data format and quantity. Furthermore, excessive FIFO transmission significantly increases the overall verification process time, leading to low verification efficiency. Therefore, the process monitoring component directly monitors the values ​​of the corresponding submodule interface signals to obtain the actual output results of the corresponding DUT submodule. Expected data is added to the wrapper.c file mentioned earlier for process data printing, printing the output value of the c_model corresponding to each submodule and generating the corresponding output file. This allows you to directly compare the actual data of the corresponding submodule with the expected data in the corresponding file using conditional statements in the monitor, and then print the valid information of the comparison result using uvm_info. If a certain number of comparison errors occur, the process stops.

[0111] This approach eliminates the need to run the entire process chain to determine the comparison results, unlike traditional methods, significantly reducing verification time. Furthermore, it allows for direct identification of the bug in a specific submodule based on its output. This also drastically reduces error localization time.

[0112] Figure 4CThis is a flowchart illustrating real-time monitoring of a DFE module applicable to embodiments of the present invention. SCB, or scoreboard, compares the expected signal with the actual output signal. FOC (Time-domain Frequency Offset Calibration) refers to the process in signal processing and communication systems of estimating and correcting frequency offsets by analyzing the time-domain characteristics of the received signal, and performing calibration to improve signal quality and communication accuracy. LPF (Low-Pass Filter) refers to low-pass filtering, followed by downsampling to reduce the signal sampling rate while retaining important signal characteristics for processing and transmission. In baseband chip accelerators, the DFE algorithm primarily functions as frequency offset adjustment and low-pass filtering downsampling, which are crucial components of the DFE algorithm. Correspondingly, such as... Figure 4C As shown, a process real-time detection component conforming to the real-time monitoring process is designed to verify important sub-modules in the DFE algorithm. Specifically, the process real-time detection component is connected to the output terminals of the time-domain frequency offset calibration sub-module and the low-pass filter sub-module to receive and compare important intermediate values ​​in the general digital front-end processing algorithm module, verifying the correctness of the internal logic function. If the verification is correct, the output data is printed in the form of a file; if the verification is incorrect, an error is reported and the program exits.

[0113] Figure 4D This is a schematic diagram of a DFE verification environment applicable to an embodiment of the present invention, that is, applying the designed real-time process detection component to the baseband module verification platform. Correspondingly, as... Figure 4D As shown, it includes the following components: stimuli (sequences), register model (Registermodel), adapter, driver (drv), stimulus generator (sqr), monitor (mon), AHB environment configuration information (ahb_cfg), AHB-based system environment (svt_ahb_systerm_env), first-in-first-out queue (fifo), design under test (DUT), stimulus signal input module (data_i_agt), output signal detection module (data_o_agt), process real-time detection module (internal_agt), reference model (rm), algorithm model (c_model), environment configuration information (cfg), data configuration information (data_cfg), basic configuration information (base_cfg), virtual stimulus generator (virtual sqr), scoreboard (scb), and comparison function (comparefunction).

[0114] This verification platform adopts the AHB VIP protocol. The platform framework is mainly divided into two layers: the top connection layer (tb_top) and the environment (env) component layer.

[0115] tb_top layer: This layer includes the environment (env), the DUT (Device Under Test), various interfaces, and clock and reset mechanisms. At this layer, the DUT needs to be instantiated, and the environment (env) needs to be connected to the DUT via interfaces. env layer: Contains the subsystem environment svt_ahb_system_env and various environment components.

[0116] The various environmental components are as follows:

[0117] 1. `env`: Belongs to the `uvm_env` component class, and is similar to a container. It is the top layer of the verification platform, containing all the necessary components upon which a hierarchical verification platform is built. An AHB VIP is added to it. The AHB VIP's interface `svt_ahb_if` connects to the DUT's AHBslave interface. This verification platform uses AHB to configure all registers.

[0118] The env also contains components such as C_model, config configuration file, virtualsequencer, data_i_agent, data_o_agt, internl_agent, and scoreboard.

[0119] VirtualSequencer internally connects to ahb_if, regmodel, DUT output interrupts, and other auxiliary signals.

[0120] 2. `data_i_agent`: `data_i_agent` is derived from `uvm_agent` and is contained within `env`. `data_i_agent` encapsulates three components: `data_i_driver`, `data_i_monitor`, and `data_i_sequencer`, which drive and emit the same protocol-based stimuli. The `transaction` component defines the specific form of the stimuli and defines multiple variables to correspond to the input signals of the interface. The sequencer generates these transaction stimuli. The driver sends these transaction stimuli according to timing requirements, pushes the transaction signals passed from the sequencer into a queue for sorting, and pops data from the queue to the corresponding interface of the DUT, thus implementing content-driven delivery to the DUT. The monitor monitors these transaction stimuli and transmits the detected transactions to the reference model via TLM.

[0121] 3. data_o_agent: data_o_agent is derived from uvm_agent and is included in env. data_o_agent contains the data_o_monitor component, which detects the output signals of the DUT and transmits the detected signals to the scoreboard via TLM.

[0122] 4. `internal_agent`: `internal_agent` is derived from `uvm_agent` and is included in `env`. Its main function is to read the input and output data of the submodules FOC and LPF. It encapsulates two components: `internal_monitor` and `internal_sequencer`. `internal_monitor` is used to monitor and compare the correctness of the submodule's input and output data to help quickly locate bugs. `internal_sequencer` is used to generate transactions based on the comparison between the intermediate expected values ​​sent by `c_model` and the actual intermediate values ​​sent by the DUT by `internal_monitor`, and writes the results to a file for printing.

[0123] 5. c_model: This acts as a reference model, connecting to the verification environment via DPI. Input parameters are obtained from the configuration file (specifically, from the data_cfg section of cfg) using the get function of the config_db mechanism. The calculated output data is then compared with the output data of the DUT.

[0124] 6. `cfg`: Belongs to the `uvm_object` type and is the top-level configuration file, containing two sub-configuration files: `base_cfg` and `data_cfg`. `base_cfg` contains transfer-related register configuration parameters, input configuration parameters for `C_model`, and random constraints for all parameters. Configuration information for each module is obtained from `base_cfg`. `data_cfg` contains the input data. This hierarchical structure leverages the key concept of UVM hierarchy, facilitating overall instantiation and reducing the likelihood of errors when using the `config_db` mechanism for data transfer according to the hierarchical relationship.

[0125] 7. The referencemodel:rm needs to implement all the functions of the DUT using the SystemVerilog language. It should simulate the relevant functions of the DUT to produce the expected results, and then pass the expected data to the scoreboard.

[0126] 8. Scoreboard: This function compares the expected data with the actual values. The expected data comes from the reference model, while the actual data comes from the transactions transmitted by the monitor of data_o_agent.

[0127] 9. Sequence and test: These are the test cases created to achieve test point coverage. The sequences designed in this verification platform can be divided into two categories according to their function:

[0128] `config_reg_seq` and `cfg_c_seq` complete all register configurations and assign all necessary parameters to `C_model`; `data_seq` implements the DFE function and performs data comparison. In `test`, each verification component is instantiated, randomization is implemented, platform connection is executed, and the sequence is started, running the entire main verification process.

[0129] 10. During the verification process, the most important step in controlling the DUT to generate different test scenarios is configuring the DUT's registers. To enable the DFE module to implement different operating modes, the corresponding configuration parameters need to be input into the corresponding registers. If the register configuration does not match the expected content, the DUT may not be able to operate in the correct mode, and the correct state of the DUT may not be reflected.

[0130] 11. To correctly configure a large number of complex registers, UVM provides register model classes. A register model is essentially a model of the registers of the module under test (DUT) built on the verification environment side. Its smallest unit is `uvm_reg_field`, one or more `uvm_reg_field`s can constitute a register `uvm_reg`, and multiple `uvm_reg`s can constitute a `uvm_reg_block`. A register can contain multiple `uvm_reg_blocks`, but for the baseband module, all registers in this module belong to the data front-end processing registers, only differing in address. Therefore, only the register offset addresses in the DUT need to be configured. This verification environment's register model only designs one set of `uvm_reg_block`, which includes all registers of the baseband module. Since this platform is only for verifying a sub-module of a specific module in the algorithm—that is, one functional module corresponds to one DUT—rather than a system-level verification platform, this platform only involves one set of `uvm_reg_block`. The specific number of `uvm_reg_block`s involved is not limited in this embodiment.

[0131] 12. When configuring register parameters, interaction with the DUT is required according to the bus protocol. To improve verification efficiency and platform reusability, this verification uses the AHB VIP to simulate bus functionality and interact with the DUT according to the bus protocol. The AHB VIP contains a complete system verification environment (svt_ahb_system_env) and an external interface (ahb_if). In the verification environment, the AHB bus acts as the master device, and the DUT acts as the slave device. Therefore, the AHBslave interface is specifically designed in the baseband module design code to connect to the AHB bus. This operation is performed at the top layer of the verification environment. That is, the top layer contains the AHBslave interface to implement the connection between the AHBVIP verification environment and the DUT, as well as to implement the data_i_if, internal_if, and data_o_if interfaces.

[0132] 13. Whether performing a write or read operation, the register model generates a variable `uvm_reg_bus_op` via a sequence. This variable stores the operation type, operation address, and, if it's a write operation, the data to be written. However, this variable cannot be passed to the AHB VIP's sequencer due to data format mismatch. This requires using the `reg2bus` function defined in the adapter to convert the variable `uvm_reg_bus_op` into a data format acceptable to the AHB sequencer. In addition, the adapter provides the `bus2reg` function, which helps convert the transaction from the AHB VIP into data acceptable to the register model, thereby updating the register value and allowing the verifier to check whether the register outputs the expected result.

[0133] To ensure the completeness of DFE module functional verification, extensive fixed-phasor testing is required. Fixed-vector test cases typically use fixed test vectors in data files. Traditional fixed-vector testing necessitates reading different files depending on the function being tested, and repeatedly modifying code within the corresponding sequence based on file paths, leading to extremely low efficiency and a high risk of errors. This platform utilizes the system function `$value$plusargs` to pass an externally input seed number to the sequence. This seed number allows the path to the desired file to be read, and `$fopen`, `$fscanf`, and `$fwrite` (corresponding to opening, reading, and writing files) are used for file reading and writing. A dedicated Python script for running fixed-phasor tests is also provided; simply inputting the seed number of the file to be run in the script allows for the simultaneous execution of all fixed-phasor tests.

[0134] This technical solution presents a general-purpose verification platform designed for complex algorithm modules such as DFE (Device Execution Environment), enabling rapid internal verification of complex algorithms. Traditional verification platforms require writing corresponding algorithms to output expected data based on different test cases, then passing this expected data to a scoring board for comparison with actual data. For complex modules like baseband modules with numerous algorithms, this method is error-prone, inefficient, and difficult to develop. However, this platform's reference model has been redesigned. The verification platform directly calls the algorithm model to calculate the expected data from the algorithm input data. Through the DPI (Device Implementation) connection mechanism, c_model is connected to the UVM environment. The data output is then transmitted to the scoring board for comparison with the actual output information of the DFE from the monitor of the output signal detection module. Furthermore, addressing the challenges of inaccurate error localization and low efficiency due to the numerous DFE submodules, a real-time process monitoring component is designed to compare the input and output of each submodule in real time, achieving error localization. For the large number of fixed phasor tests required, a dedicated script is designed to automate the testing of all fixed phasors, improving verification efficiency.

[0135] Example 4

[0136] Figure 5 This is a schematic diagram of a general verification device based on a UVM environment provided in Embodiment 4 of the present invention. Figure 5 As shown, the device is configured in the reference model of a general verification platform based on a UVM environment, and includes: a transaction stimulus acquisition module 510, a transaction stimulus transmission module 520, and a desired signal transmission module 530.

[0137] The transaction incentive acquisition module 510 is used to acquire the transaction incentive generated and sent by the incentive signal input module.

[0138] The transaction incentive delivery module 520 is used to deliver the transaction incentive to the pre-imported algorithm model function via DPI.

[0139] The expected signal sending module 530 is used to send the expected signal generated by the algorithm model function for the transaction incentive to the scoring board.

[0140] The technical solution of this invention acquires transaction stimuli generated and sent by the excitation signal input module, transmits these stimuli to a pre-imported algorithm model function via DPI, and sends the expected signal generated by the algorithm model function in response to the transaction stimuli to the scoring board. Through the DPI connection mechanism, the algorithm model is connected to the UVM environment, enabling the algorithm model to generate the expected data. This data is then transmitted to the verification environment via the DPI interface for accuracy testing of the device under test's output. This method avoids the tedious process of rewriting algorithms for each different test case, thus achieving rapid verification of complex algorithms. It not only reduces the development difficulty of a general verification platform but also significantly improves the efficiency of verification work.

[0141] Furthermore, a general verification device based on a UVM environment also includes: an actual output signal generation module and an expected output sub-value printing module.

[0142] The actual output signal generation module is used to generate actual output signals that match the transaction incentives through internally defined processing logic.

[0143] The expected output sub-value printing module is used to print the expected output sub-values ​​of each functional sub-module of the device under test and generate a matching print file to be transmitted to the process real-time detection component.

[0144] The universal verification device based on the UVM environment provided in the embodiments of the present invention can execute the universal verification method based on the UVM environment provided in any embodiment of the present invention, which is executed by the reference model of the universal verification platform based on the UVM environment, and has the corresponding functional modules and beneficial effects of the execution method.

[0145] Example 5

[0146] Figure 6 This is a schematic diagram of a general verification device based on a UVM environment provided in Embodiment 5 of the present invention. Figure 6 As shown, the device is configured in the process real-time detection component of a general verification platform based on a UVM environment, including: an actual output sub-value acquisition module 610 and an output sub-value comparison module 620.

[0147] The actual output sub-value acquisition module is used to acquire the actual output sub-value at the target functional sub-module of the device under test.

[0148] The output sub-value comparison module is used to compare the actual output sub-value with the expected output sub-value that matches in the printed file, and to end the continued testing of the device under test when the detected comparison error exceeds a preset number threshold.

[0149] The technical solution of this invention obtains the actual output sub-values ​​at the target functional sub-module of the device under test (DUT), compares these actual output sub-values ​​with the expected output sub-values ​​matching the printed file, and terminates further testing of the DUT when the detected comparison errors exceed a preset threshold. Setting an error threshold helps prevent each error from triggering a complete processing flow, reducing unnecessary interference with the testing process. This batch error handling strategy allows for unified processing after errors accumulate to a certain threshold, effectively reducing repetitive work and improving the efficiency of the verification process. Centralized error handling also optimizes the use of computing resources, avoiding frequent switching of processing contexts or repeated execution of the same error handling steps.

[0150] The universal verification device based on the UVM environment provided in the embodiments of the present invention can execute the universal verification method based on the UVM environment provided in any embodiment of the present invention, which is executed by the process real-time detection component of the universal verification platform based on the UVM environment, and has the corresponding functional modules and beneficial effects of the execution method.

[0151] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0152] Example 6

[0153] Figure 7 A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0154] like Figure 7As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0155] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0156] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as a general-purpose verification method based on a UVM environment executed by a reference model in a general-purpose verification platform.

[0157] That is:

[0158] Obtain the transaction incentive generated and sent by the incentive signal input module;

[0159] The transaction incentive is passed to the pre-imported algorithm model function via DPI;

[0160] The expected signal generated by the algorithm model function for the transaction incentive is sent to the scoreboard.

[0161] Alternatively, a generic verification method based on a UVM environment, such as one performed by a process real-time detection component in a generic verification platform.

[0162] That is:

[0163] Obtain the actual output sub-value at the target functional sub-module of the device under test;

[0164] The actual output sub-value is compared with the expected output sub-value that matches in the printed file, and the test on the device under test ends when the number of detected comparison errors exceeds a preset threshold.

[0165] In some embodiments, the UVM-based universal verification method can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the UVM-based universal verification method described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to perform the UVM-based universal verification method by any other suitable means (e.g., by means of firmware).

[0166] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0167] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0168] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0169] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0170] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0171] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0172] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0173] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A universal verification platform based on the Universal Verification Methodology (UVM) environment, characterized in that, include: Register configuration module, excitation signal input module, reference model, device under test, output signal detection module, and scoring board; The register configuration module, excitation signal input module, and output signal detection module are respectively connected to the device under test (DUT) connected to the general verification platform. The reference model is connected to the excitation signal input module and the scoring board, respectively. The scoring board is also connected to the output signal detection module. The reference model contains a DPI (Device Performance Detector), which imports an object file. The object file contains an algorithm model function based on the C language. This algorithm model function is used to implement the internal processing logic of the DUT, wherein: The register configuration module is used to configure parameters of at least one register in the device under test according to the test cases input into the UVM environment. The excitation signal input module is used to generate transaction stimuli that match the test cases and transmit the transaction stimuli to the reference model and the device under test; A reference model is used to pass the received transaction incentives to a pre-imported algorithm model function via DPI, and send the expected signal generated by the algorithm model function for the transaction incentives to the scoreboard; The device under test (DUT) is used to generate an actual output signal that matches the transaction stimulus through its internally defined processing logic in response to the transaction stimulus, and then transmits the actual output signal to the output signal detection module. The output signal detection module is used to transmit the detected actual output signal sent by the device under test to the scoring board; A scoring board is used to verify the functionality of the device under test based on the received actual output signal and the expected signal.

2. The universal verification platform according to claim 1, characterized in that, The device under test includes multiple functional sub-modules connected end to end. Two adjacent functional sub-modules form a sub-module pair. The general verification platform also includes a real-time process detection component, which is connected to the output of the preceding functional sub-module in at least one sub-module pair and the reference model. The reference model is further used to transmit the expected output sub-values ​​of each functional sub-module of the device under test to the real-time process detection component for printing during the process of generating an actual output signal that matches the transaction stimulus through internally defined processing logic, and to generate a matching print file. The real-time process detection component is specifically used to compare the actual output sub-value with the expected output sub-value matched in the printed file when obtaining the actual output sub-value from the target functional sub-module of the device under test. When a comparison error is detected, the error position is printed, and when the number of detected comparison errors exceeds a preset threshold, the continued testing of the device under test is terminated.

3. The universal verification platform according to claim 2, characterized in that, The device under test is specifically a general digital front-end processing algorithm module; The general digital front-end processing algorithm module includes a time-domain frequency offset calibration submodule and a low-pass filter submodule, and the real-time process detection component is connected to the output terminals of the time-domain frequency offset calibration submodule and the low-pass filter submodule, respectively.

4. The universal verification platform according to any one of claims 1-3, characterized in that, The register configuration module specifically includes: a register model, an adapter, and a verification intellectual property core (VIP) that acts as a bus, connected in sequence. The register model is used to model the various registers contained in the device under test according to the test cases, obtain the register configuration parameters, and transmit the register configuration parameters to the adapter; An adapter is used to convert the received register configuration parameters into a data format compatible with the VIP, and then transmit them to the device under test through the VIP to configure parameters of at least one register in the device under test.

5. The universal verification platform according to claim 4, characterized in that, The VIP is used to act as an advanced high-performance bus based on the on-chip bus protocol.

6. The universal verification platform according to any one of claims 1-3, characterized in that, The excitation signal input module specifically includes: an excitation generator, a driver, and a monitor; The stimulus generator is used to generate transaction stimuli that match the test cases; The driver is used to sequentially send the transaction stimuli to the device under test according to preset timing requirements; A monitor is configured to transmit the detected transaction stimulus to the reference model when the transaction stimulus is detected.

7. The universal verification platform according to any one of claims 1-3, characterized in that, It also includes a top-level configuration module; The top-level configuration module is used to configure the basic parameters of the reference model, register configuration module, excitation signal input module, and scoring board before performing tests on the device under test.

8. The universal verification platform according to any one of claims 1-3, characterized in that, The excitation signal input module and the reference model transmit data through a first-in-first-out queue, and the output signal detection module and the scoring board transmit data through a first-in-first-out queue.

9. The universal verification platform according to any one of claims 1-3, characterized in that, The target file is implemented by adding a shell function outside the algorithm model function. The number, type, input or output direction of the interface parameters defined in the shell function are determined by the functions implemented by the device under test and the configuration parameters required by the UVM environment.

10. The universal verification platform according to any one of claims 1-3, characterized in that, The test cases are entered using at least one seed number, with each seed number pointing to a designated test file; based on the various seed numbers, each test file is automatically executed in batches using automated scripts.

11. A general verification method based on a UVM environment, characterized in that, Performed by a reference model in a universal verification platform as described in any one of claims 1-3, the method comprises: Obtain the transaction incentive generated and sent by the incentive signal input module; pass the transaction incentive to the pre-imported algorithm model function through DPI; The expected signal generated by the algorithm model function for the transaction incentive is sent to the scoreboard.

12. The general verification method according to claim 11, characterized in that, The method further includes: The actual output signal is generated by the internally defined processing logic and matches the transaction incentive. The expected output sub-values ​​of each functional sub-module of the device under test are printed, and a matching print file is generated and transmitted to the process real-time detection component.

13. A general verification method based on a UVM environment, characterized in that, Performed by the real-time process detection component in the universal verification platform as described in any one of claims 2-3, the method includes: Obtain the actual output sub-value at the target functional sub-module of the device under test; The actual output sub-value is compared with the expected output sub-value that matches in the printed file, and the test on the device under test ends when the number of detected comparison errors exceeds a preset threshold.

14. A universal verification device based on a UVM environment, characterized in that, The reference model configured in the universal verification platform as described in any one of claims 1-3, the apparatus comprising: The transaction incentive acquisition module is used to acquire the transaction incentives generated and sent by the incentive signal input module; The transaction incentive delivery module is used to deliver the transaction incentive to the pre-imported algorithm model function via DPI; The expected signal sending module is used to send the expected signal generated by the algorithm model function for the transaction incentive to the scoring board.

15. A universal verification device based on a UVM environment, characterized in that, The process real-time detection component configured in the universal verification platform as described in any one of claims 2-3, the device comprising: The actual output sub-value acquisition module is used to acquire the actual output sub-value at the target functional sub-module of the device under test. The output sub-value comparison module is used to compare the actual output sub-value with the expected output sub-value that matches in the printed file, and to end the continued testing of the device under test when the detected comparison error exceeds a preset number threshold.

16. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the general verification method based on the UVM environment according to any one of claims 11-13.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the general verification method based on the UVM environment as described in any one of claims 11-13.

18. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the general verification method based on a UVM environment according to any one of claims 11-13.

Images