Method and apparatus for mixed testing of multiple data types based on uvm sequence library

Abstract

The application relates to a multi-data-type mixed test method and device based on a UVM sequence library. The method comprises the following steps: instantiating a UVM sequence library in a UVM verification environment, the UVM sequence library being used for unified registration and management of test sequences corresponding to multiple data types; encapsulating multiple test data types into corresponding multiple UVM sequences respectively, and adding the multiple UVM sequences into the UVM sequence library; and through calling a sequence selection mode built in the UVM sequence library, mixing and scheduling the multiple UVM sequences by using the UVM sequence library, so that mixed test of the multiple data types can be carried out without inserting a configuration class instruction set architecture sequence for data type conversion.

Description

Technical Field

[0001] This application generally relates to the field of testing, and more specifically, to a method and apparatus for testing multiple data types based on a Universal Verification Methodology (UVM) sequence library. Background Technology

[0002] In the chip design process, verification is a critical step in ensuring the correctness of chip functionality. As chip complexity continues to increase, the industry widely adopts UVM to build standardized, reusable verification environments. UVM provides a set of systemVerilog-based libraries and frameworks that enable verification engineers to verify whether the behavior of the design under test (DUT) meets expectations by building test platforms, generating stimuli, and comparing results. Summary of the Invention

[0003] This application provides a method and apparatus for testing multiple data types using a UVM sequence library. By encapsulating various test data types into independent UVM sequences and registering them uniformly in the UVM sequence library, and utilizing the library's built-in sequence selection mode to perform mixed scheduling of multiple sequences, this application achieves automatic switching and mixed transmission of multiple data types without inserting any configuration-type ISA sequences for data type conversion.

[0004] According to one aspect of this application, a method for mixed testing of multiple data types based on a UVM sequence library is provided, comprising: instantiating a UVM sequence library in a UVM verification environment, the UVM sequence library being used to uniformly register and manage test sequences corresponding to multiple data types; encapsulating multiple test data types into multiple corresponding UVM sequences, and adding the multiple UVM sequences to the UVM sequence library; and using the UVM sequence library to perform mixed scheduling of multiple UVM sequences by calling the sequence selection mode built into the UVM sequence library, so as to perform mixed testing of multiple data types without inserting configuration class instruction set architecture sequences for data type conversion.

[0005] According to another aspect of this application, a multi-data type mixed testing apparatus based on a UVM sequence library is provided. The apparatus includes: one or more processors; and a memory storing instructions that, when executed by the one or more processors, cause the one or more processors to perform the above-described method. Attached Figure Description

[0006] Figure 1 The illustration shows a flowchart of a multi-data type mixed testing method based on a UVM sequence library according to an embodiment of this application; Figure 2 A schematic diagram of the verification environment interaction architecture utilizing the UVM sequence library according to an embodiment of this application is shown; Figure 3 A schematic diagram of a multi-data type mixed testing apparatus based on a UVM sequence library according to an embodiment of this application is shown. Detailed Implementation

[0007] The features and exemplary embodiments of various aspects of this application will now be described in detail. Numerous specific details are provided in the following detailed description to provide a thorough understanding of this application. However, it will be apparent to those skilled in the art that this application can be implemented without some of these specific details. The following description of embodiments is merely intended to provide a better understanding of this application by illustrating examples. This application is by no means limited to any specific configurations and algorithms described below, but rather covers any modifications, substitutions, and improvements to elements, components, and algorithms without departing from the spirit of this application. Well-known structures and techniques are not shown in the accompanying drawings and the following description in order to avoid unnecessarily obscuring this application.

[0008] In the chip verification process, the traditional approach to testing mixed scenarios of multiple data types is as follows: when conversion between different data types is required, verification engineers insert a configuration instruction set architecture (ISA) sequence into the stimulus sequence to send control information to the design under test (DUT) to drive the data type conversion logic, so that the DUT can correctly parse the data type corresponding to the subsequent instructions.

[0009] However, this method of conversion relying on inserted configuration class ISAs has significant technical problems. First, the number of ISAs increases unexpectedly. As the complexity of the test scenario increases, the number of combinations of data type conversions grows exponentially, leading to a sharp increase in the number of configuration class ISAs that need to be inserted, far exceeding the number of instructions expected in the design. This makes the test sequence bloated and difficult to maintain, and may even trigger unforeseen boundary conditions in the chip design due to the uncontrolled number of ISAs. Second, there is a risk of deep command buffering. Chip designs typically include command buffers to temporarily store instructions to be executed. Each inserted configuration class ISA occupies one entry in the command buffer. When a large number of data type conversion ISAs are inserted, the entries in the command buffer are quickly filled with such auxiliary instructions. Valid data instructions are blocked because the buffer is full, which may even lead to buffer overflow, causing the verification environment to crash or behave abnormally, making the test results unreliable.

[0010] Traditional mixed data type testing methods suffer from technical drawbacks such as uncontrollable ISA counts and susceptibility to command buffer overflows, making it difficult to meet the stability and scalability requirements of complex chip verification scenarios. Therefore, a more secure and scalable mixed data type testing solution is urgently needed to overcome these problems.

[0011] In view of this, this application provides a multi-data type mixed testing method based on a UVM sequence library to solve the problems of uncontrollable ISA number and buffer depth risk caused by inserting configuration class ISAs in traditional methods. This method encapsulates various test data types into independent UVM sequences and registers them uniformly in the UVM sequence library. It utilizes the sequence selection modes built into the sequence library (such as sequential mode, random mode, or random cyclic mode) to perform mixed scheduling of multiple sequences, thereby completing automatic switching and mixed transmission of multiple data types without inserting any configuration class ISA sequences for data type conversion.

[0012] Compared with existing technologies, this application has the following advantages: It eliminates the risk of ISA number inflation, data type conversion no longer depends on ISA insertion, and the total number of ISAs is fixed by the chip design and will not increase with the complexity of the test scenario; it ensures the safety of the command buffer, since there are no additional configuration ISA entries occupying the buffer, and only valid data transactions are retained in the command buffer, thereby avoiding buffer overflow and the resulting verification platform crash; it improves the scalability of testing, when adding new data types, only the corresponding UVM sequence needs to be written and added to the sequence library, without modifying the existing conversion logic or the top-level test structure; at the same time, the native random scheduling mechanism of UVM can be used to automatically mix multiple data transactions, improving the efficiency of random testing and helping to discover more design boundary defects.

[0013] The present application will now be described in further detail with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the application to these specific forms.

[0014] Figure 1 The illustration shows a flowchart of a multi-data type mixed testing method 100 based on a UVM sequence library according to an embodiment of this application. Figure 1 As shown, method 100 may include steps 110-130. It should be noted that method 100 may also include more or fewer steps, which is not limited in this embodiment.

[0015] In step 110, a UVM sequence library is instantiated in the UVM verification environment. This UVM sequence library can be used to uniformly register and manage test sequences corresponding to various data types.

[0016] In the embodiments of this application, the UVM sequence library can be implemented by deriving a subclass (e.g., my_sequence_lib) from the uvm_sequence_lib class and specifying its parameter type as uvm_sequence_item or its descendant transaction type. During instantiation, the library can be initialized by calling the init_sequence_library method in the sequence library's constructor and registered using the uvm_sequence_library_utils macro, thereby ensuring that the sequence library can correctly run its built-in selection and scheduling logic. This UVM sequence library can be used to uniformly register, manage, and schedule test sequences corresponding to various data types. In other words, as an intelligent container, this sequence library can receive UVM sequences encapsulated from different data types and dynamically determine the next sequence to be executed at runtime based on a preset sequence selection mode (e.g., sequential mode, random mode, or random cyclic mode), thereby achieving mixed transmission of multi-data type stimuli.

[0017] In step 120, multiple test data types are encapsulated into corresponding UVM sequences, and these multiple UVM sequences are added to the UVM sequence library.

[0018] In the embodiments of this application, for each data type to be tested (e.g., integer type, floating-point type, fixed-point type, vector type, etc.), an independent UVM sequence class can be created, such as integer sequence (int_seq), floating-point sequence (float_seq), fixed-point sequence (fixed_seq), vector sequence (vector_seq), etc. In the embodiments of this application, each sequence class can define one or more instruction forms for the corresponding data type. Taking signed integer type as an example, its sequence can include scalar operation instructions (s_type), matrix operation instructions (m_type), register operation instructions (r_type), and immediate number operation instructions (i_type), etc.

[0019] In the embodiments of this application, within each sequence, a constraint mechanism can be used to limit the maximum number of valid command packets generated in a single runtime. For example, UVM constraint statements can be used to set the range of random variables, or the internal control logic of the sequence can be used to ensure that the number of instructions generated by each sequence during execution does not exceed a preset threshold. Setting this maximum number of instructions can control the number of command buffer entries occupied by each data type in a single runtime, avoiding excessive buffer pressure due to too many instructions generated by a single sequence. After the sequence implementation is completed, each sequence instance or sequence type can be registered to the UVM sequence library by calling the UVM sequence library's add function (e.g., the add_sequence method). After the above operations, the UVM sequence library can internally maintain a list containing sequences of multiple data types for subsequent mixed scheduling.

[0020] In step 130, multiple UVM sequences can be mixed and scheduled by calling the sequence selection mode built into the UVM sequence library, so as to perform mixed testing of multiple data types without inserting configuration class instruction set architecture sequences for data type conversion.

[0021] In embodiments of this application, the UVM sequence library can be started directly in the top-level test of the verification environment (e.g., in a base test class (base_test)) (e.g., by calling the start method of the sequence library instance, such as my_sequence_lib.start(sequencer)). In embodiments of this application, the UVM sequence library can dynamically select the next sequence to be executed according to a pre-configured sequence selection mode (e.g., sequential mode, random mode, or random loop mode). When set to random loop mode (e.g., the SEQ_LIB_RANDC mode provided in the UVM standard library), the sequence library will randomly sort all registered sequences and then execute each sequence in that order; after one round of execution is completed, it will re-randomize and start the next round. During sequence execution, each sequence generates a valid transaction of the corresponding data type (e.g., a transaction object in UVM) and sends it to the driver (e.g., the driver in UVM) through the sequencer (e.g., the sequencer in UVM), ultimately driving the design under test. When all transactions of a sequence have been sent, the sequence library automatically calls its built-in sequence selection function (e.g., the select_sequence method) to select the next sequence and continue execution.

[0022] The entire switching process requires no insertion of any configuration class ISA sequences to indicate data type conversion, as the data type information is implicitly included in the sequence selection and startup process. Since there are no additional configuration class ISAs, the command buffer only retains valid data transaction entries, avoiding the risk of buffer depth exceeding limits due to ISA occupancy. Simultaneously, the sequence library's random scheduling mechanism can automatically and efficiently mix test transactions of multiple data types, improving verification coverage and random testing efficiency.

[0023] In the embodiments of this application, when a new data type needs to be added, it is only necessary to encapsulate the new data type into a new UVM sequence and add it to the sequence library, without modifying any existing sequences or scheduling logic. This direct method of adding new data types greatly improves the scalability of the verification environment.

[0024] Figure 2 A schematic diagram of the verification environment interaction architecture utilizing the UVM sequence library according to an embodiment of this application is shown below. Figure 2 The technical solution of this application is described in detail.

[0025] like Figure 2 As shown, the interactive architecture of the verification environment may include a sequence library 210, a sequence addition module 220, a notification module 230, a simulation time control module 240, a design under test execution module 250, a reference model execution module 260, and a result comparison module 270.

[0026] The sequence library 210 (e.g., an instance of uvm_sequence_lib) registers multiple data type sequences, such as data type 0 (data_type 0) sequence, data type 1 (data_type 1) sequence, ..., data type n (data_type n) sequence. Each data type corresponds to an independent UVM sequence. Each sequence can contain multiple instruction forms under that data type, such as scalar operation instructions (s_type isa), matrix operation instructions (m_type isa), register operation instructions (r_type isa), immediate operation instructions (i_type isa), and optional synchronization instructions (sync_isa). These instruction forms are all different operation variants under the same data type, used to comprehensively verify the chip's ability to process that data type. The instructions within each sequence can be randomly generated, meaning the instruction order and specific operands within the sequence can be randomized under constraints to increase the randomness and coverage of the test.

[0027] The sequence addition module 220 can be used to register a "complete sequence" in the sequence library 210 or set a completion event. This module triggers a completion signal after all data type sequences in the sequence library 210 have been executed. The notification module 230 can be used to send a notification to the test base class via an event when a sequence has finished executing, informing it that all instructions for the current sequence have been sent. The simulation time control module 240 can be used by the test base class to manage the simulation time of the entire verification environment based on the received notifications, such as advancing the simulation time, starting the next sequence, or ending the simulation at appropriate times.

[0028] The design under test (e.g., RTL) execution module 250 can be used to: receive ISA instructions scheduled by the sequence library 210 (e.g., via a sequencer and driver), execute these instructions, and obtain actual execution results (e.g., RTL results). The reference model execution module 260 can be used to: obtain the same ISA instructions as the RTL, execute these instructions, and obtain the expected results. The result comparison module 270 is used to compare the actual results output by the design under test execution module 250 with the expected results output by the reference model execution module 260. If they match, the test passes; otherwise, an error is reported.

[0029] This application, based on the UVM sequence library, achieves automatic switching and mixed transmission of multiple data types without inserting configuration-type ISA sequences, avoiding the risks of ISA number expansion and command buffer overflow, and preventing verification platform crashes. Simultaneously, randomized scheduling improves testing efficiency and coverage; adding new data types only requires adding the corresponding sequence, enhancing scalability, maintainability, and randomization. This application is particularly suitable for multi-data type mixed verification scenarios in complex chip designs.

[0030] Figure 3 A schematic diagram of a multi-data type mixed testing apparatus based on a UVM sequence library according to an embodiment of this application is shown. The apparatus is shown as a computing device 300, which can be used to execute the aforementioned multi-data type mixed testing method 100 based on a UVM sequence library. Figure 3 As shown, computing device 300 may include bus 302 or other communication mechanism for transmitting information, and one or more hardware processors 304 coupled to bus 302 for processing information. The one or more hardware processors 304 may include, for example, one or more general-purpose microprocessors.

[0031] like Figure 3As shown, in some embodiments, computing device 300 may further include main memory 306 coupled to bus 302. Main memory 306 is used to store information and instructions executed by one or more processors 304, such as random access memory (RAM), cache, and / or other dynamic storage devices. Main memory 306 may also be used to store temporary variables or other intermediate information during the execution of instructions executed by one or more processors 304. When these instructions are stored in storage media accessible to one or more processors 304, they can cause computing device 300 to become a dedicated machine customized to perform the operations specified in the instructions. Storage device 308 may include non-volatile and / or volatile storage media. Non-volatile storage media may include, for example, optical discs or magnetic disks. Volatile storage media may include dynamic memory. Common forms of storage media may include, for example, floppy disks, hard disks, solid-state drives, magnetic tape, or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a perforated pattern, RAM, DRAM, PROM, and EPROM, FLASH-EPROM, NVRAM, any other memory chip or cartridge, or their networking versions.

[0032] like Figure 3 As shown, in some embodiments, computing device 300 may further include one or more communication interfaces or network interfaces 310 coupled to bus 302. Network interface 310 may provide bidirectional data communication coupling to one or more network links connected to one or more networks. As another example, network interface 310 may be a local area network (LAN) card to provide data communication connectivity to a LAN-compatible (or WAN component communicating with a WAN) network. Wireless links may also be implemented.

[0033] The execution of certain operations can be distributed across processors rather than residing within a single machine, but rather deployed across multiple machines. In some example embodiments, the processor or processor-implemented engine may reside in a single geographic location (e.g., in a home environment, office environment, or server farm). In other example embodiments, the processor or processor-implemented engine may be distributed across multiple geographic locations.

[0034] Each of the processes, methods, and algorithms described above may be embodied in code modules executed by one or more computer systems or computer processors including computer hardware, and may be fully or partially automated by these code modules. The processes and algorithms may be implemented partially or fully in dedicated circuit systems.

[0035] When the functions disclosed herein are implemented as software functional units and sold or used as stand-alone products, they may be stored in a processor-executable, non-volatile, computer-readable storage medium. Specific technical solutions (all or part) disclosed herein, or aspects contributing to the prior art, may be embodied in the form of a software product. The software product may be stored in a storage medium and includes several instructions that cause a computing device (which may be a personal computer, server, network device, etc.) to perform all or some steps of the methods of the embodiments of this application. The storage medium may include a flash drive, portable hard disk drive, ROM, RAM, magnetic disk, optical disk, other media operable to store program code, or any combination thereof.

[0036] Specific embodiments further provide an apparatus including a processor and a non-transitory computer-readable storage medium storing instructions executable by the processor to cause the apparatus to perform operations corresponding to steps in any method of the embodiments disclosed above. Specific embodiments further provide a non-transitory computer-readable storage medium storing instructions executable by one or more processors to cause the one or more processors to perform operations corresponding to steps in any method of the embodiments disclosed above.

[0037] The embodiments disclosed herein can be implemented via a cloud platform, server, or server cluster (collectively referred to below as the "Service System") that interacts with a client. The client can be a terminal device or a client registered by a user at the platform, wherein the terminal device can be a mobile terminal, a personal computer (PC), or any device that can have the platform application installed.

[0038] The various features and processes described above can be used independently of each other or combined in various ways. All possible combinations and sub-combinations are intended to fall within the scope of this application. Additionally, certain method or process blocks may be omitted in some embodiments. The methods and processes described herein are not limited to any particular order, and their associated blocks or states may be executed in other suitable orders. For example, described blocks or states may be executed in an order other than that specifically disclosed, or multiple blocks or states may be combined into a single block or state. Example blocks or states may be executed sequentially, in parallel, or in some other manner. Blocks or states may be added to or removed from the disclosed example embodiments. The exemplary systems and components described herein may be configured differently than described. For example, components may be added to, removed from, or rearranged compared to the disclosed example embodiments.

[0039] The various operations of the exemplary methods described herein can be performed at least in part by an algorithm. The algorithm may be included in program code or instructions stored in memory (e.g., the aforementioned non-transitory computer-readable storage medium). This algorithm may include a machine learning algorithm. In some embodiments, the machine learning algorithm may not explicitly refer to the computer as performing the function but may learn from training data to generate a predictive model of the function.

[0040] The various operations of the exemplary methods described herein can be performed, at least in part, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, these processors can constitute an engine of processor implementation that operates to perform one or more of the operations or functions described herein.

[0041] Similarly, the methods described herein may be implemented at least in part by a processor, wherein one or more specific processors are instances of hardware. For example, at least some operations of the methods may be performed by one or more processors or an engine implemented by a processor. Furthermore, one or more processors may also be operable to support the execution of relevant operations in a “cloud computing” environment or as the execution of relevant operations in a “Software as a Service” (SaaS) context. For example, at least some operations may be performed by a group of computers (as an example of a machine containing processors), wherein these operations are accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., application programming interfaces (APIs)).

[0042] The execution of certain operations can be distributed across processors rather than residing within a single machine, and can be deployed across multiple machines. In some example embodiments, the processor or processor-implemented engine may reside in a single geographic location (e.g., in a home environment, office environment, or server farm). In other example embodiments, the processor or processor-implemented engine may be distributed across multiple geographic locations.

[0043] Throughout this specification, multiple instances may be implemented as components, operations, or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of these individual operations may be performed simultaneously, and not necessarily in the order illustrated. Structures and functions presented as separate components in the example configuration may be implemented as composite structures or components. Similarly, structures and functions presented as single components may be implemented as single components. These and other variations, modifications, additions, and improvements fall within the scope of this document.

[0044] As used herein, "or" is inclusive rather than exclusive unless explicitly indicated by the context. Therefore, in this document, "A, B, or C" means "A, B, A and B, A and C, B and C, or A, B, and C" unless explicitly indicated by the context. Furthermore, "and" is combined and separate unless explicitly indicated by the context. Therefore, in this document, "A and B" means "A and B, combined or separate" unless explicitly indicated by the context. Additionally, multiple instances of resources, operations, or structures described herein may be provided as a single instance. Furthermore, the boundaries between various resources, operations, engines, and data storage devices are somewhat arbitrary and specific operations are illustrated within the context of a particular illustrative configuration. Other functional assignments are foreseeable and fall within the scope of various embodiments of this application. Generally, structures and functions presented as individual resources in example configurations may be implemented as combined structures or resources. Similarly, structures and functions presented as single resources may be implemented as single resources. These and other changes, modifications, additions, and improvements fall within the scope of the embodiments of this application as defined by the appended claims. Therefore, this specification and drawings should be considered illustrative rather than restrictive.

[0045] The terms “comprising” or “including” are used to indicate the presence of a subsequently claimed feature, but do not preclude the addition of other features. Unless otherwise specifically stated or otherwise understood in the context in which they are used, conditional language such as “may,” “can,” “may,” and “can” is generally intended to convey that certain embodiments include certain features, components, and / or steps that are not included in other embodiments. Therefore, this conditional language is generally not intended to imply that one or more embodiments require features, components, and / or steps in any way, or that one or more embodiments must include logic for determining whether such features, components, and / or steps are included in or performed in any particular embodiment, with or without user input or prompts.

[0046] Although the general outline of the subject matter has been described with reference to specific exemplary embodiments, various modifications and changes can be made to these embodiments without departing from the broad scope of embodiments of this application. Where more than one embodiment is disclosed, these embodiments of the subject matter may be referred to individually or collectively herein as the term "invention," this is for convenience only and is not intended to automatically limit the scope of this application to any single disclosure or concept.

[0047] The embodiments illustrated herein are described in detail to enable those skilled in the art to practice the disclosed teachings. Other embodiments may be used and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this application. Therefore, "implementation" is not intended to be limiting, and the scope of the various embodiments is defined only by the appended claims and their equivalents in their full scope.

Claims

1. A multi-data type mixed testing method based on the UVM sequence library, characterized in that, include: Instantiate the UVM sequence library in the UVM verification environment. This UVM sequence library is used to uniformly register and manage test sequences corresponding to various data types. Multiple test data types are encapsulated into corresponding UVM sequences, and the multiple UVM sequences are added to the UVM sequence library. The multiple test data types include at least two of integer type, floating-point type, fixed-point type, and vector type. as well as By invoking the built-in sequence selection mode of the UVM sequence library, multiple UVM sequences can be mixed and scheduled using the UVM sequence library to perform mixed testing of multiple data types without inserting configuration class instruction set architecture sequences for data type conversion.

2. The method according to claim 1, characterized in that, Also includes: For each UVM sequence among multiple UVM sequences, set the maximum number of instructions for that UVM sequence to control the number of command buffer entries occupied by the data type corresponding to that UVM sequence during a single runtime.

3. The method according to claim 1, characterized in that, Also includes: The new test data type is encapsulated into a new UVM sequence and the new UVM sequence is added to the UVM sequence library.

4. The method according to claim 1, characterized in that, Sequence selection modes include sequential modes.

5. The method according to claim 1, characterized in that, Sequence selection modes include random mode.

6. The method according to claim 5, characterized in that, Random patterns include random cyclic patterns.

7. The method according to claim 1, characterized in that, Each of the multiple UVM sequences includes one or more instruction forms under the corresponding data type.

8. The method according to claim 7, characterized in that, The instruction can take many forms, including at least one of scalar, matrix, register, and immediate forms.

9. A multi-data type mixed testing device based on a UVM sequence library, characterized in that, The device includes: One or more processors; and A memory storing instructions that, when executed by the one or more processors, cause the one or more processors to perform the method according to any one of claims 1-8.

Images