UVM-based message transaction data comparison checking method, system, medium and device

Abstract

The application provides a message transaction data comparison checking method, system, medium and equipment based on UVM, the method comprises the following steps: obtaining input message transaction data, the message transaction data comprises predicted message transaction and to-be-evaluated message transaction; performing multi-queue management based on the message transaction data to allocate the belonging queue of the current message transaction data, the allocated belonging queue comprises a predicted message transaction queue and a to-be-evaluated message transaction queue; searching and matching the to-be-evaluated message transaction in the predicted message transaction queue according to the starting configuration, wherein the searching and matching comprises sequential comparison and unordered comparison; outputting the matching result after comparison and checking, and dynamically switching the searching and matching mode based on the matching result and the trigger condition, wherein the starting configuration is switched to the target configuration. The application significantly improves the reusability, adaptability and efficiency of the verification environment, and is especially suitable for high-complexity UVM transaction verification scenarios.

Description

Technical Field

[0001] This invention belongs to the field of data processing technology, and in particular relates to a method, system, medium and device for comparing and checking message transaction data based on UVM. Background Technology

[0002] The scoreboard is a crucial component in a UVM-based validation environment. It is typically used to compare and evaluate the predicted data and the data to be evaluated during the validation process, thus serving as the main component of the validation results.

[0003] in, Figure 1 This is a schematic diagram of a common UVM verification environment structure. In a typical UVM verification environment, the prediction data mentioned above is usually obtained by a series of extrapolations and calculations from the reference model, while the data to be evaluated is usually collected by the monitor from the DUT (Design Under Test). In UVM verification, the above two types of data are usually regarded as transactions. This concept is similar to a structure in a programming language. Here, it is used to hold and manage the values ​​of multiple members in the data that need to be compared.

[0004] In the construction of a conventional UVM verification environment, different scoreboard components are often required to adapt to different verification projects due to different transaction types and different requirements. However, these components may contain many common programs, such as transaction comparison methods and strategies, presentation of transaction comparison results, and some additional functions to facilitate debugging by verification personnel. The traditional scoreboard development model is inefficient and not conducive to iteration and reuse between verification environments.

[0005] In more complex UVM verification environments, transactions may become non-singular, such as multiple transactions of the same type or multiple transactions of different types. In such cases, the traditional scoreboard design approach may involve developing different scoreboard programs for different types of transactions. As the requirements become more complex, the development and maintenance costs become enormous.

[0006] In a more comprehensive UVM verification environment, it is necessary to support anomaly testing and robustness testing. In such tests, it is often necessary to inject errors into the DUT through drivers or directly to observe the DUT's running results. After the error injection is completed, it is often necessary to observe whether the DUT can recover from the abnormal state to the normal working state. This type of test places high demands on the scoreboard component. The scoreboard needs to be able to strictly compare transactions during the normal operation of the DUT, and relax the comparison transaction rules or the reporting of comparison transaction results during the abnormal operation of the DUT. To cope with this scenario, traditional scoreboards often need to develop a program based on the scoreboard architecture, which is costly to maintain and difficult to reuse in different environments. Summary of the Invention

[0007] In view of the shortcomings of the prior art described above, the purpose of this invention is to provide a UVM-based message transaction data comparison and inspection method, system, medium and device to solve the problems of poor reusability, high expansion cost, insufficient scenario adaptability and maintenance difficulties in the comparison and inspection of predicted data and data to be evaluated in the prior art.

[0008] In a first aspect, the present invention provides a method for comparing and checking message transaction data based on UVM, the method comprising:

[0009] Obtain the input message transaction data, which includes predicted message transactions and message transactions to be evaluated;

[0010] Multi-queue management is performed based on the message transaction data to allocate the queue to which the current message transaction data belongs. The allocated queues include the predicted message transaction queue and the message transaction queue to be evaluated.

[0011] Based on the message transaction to be evaluated, a search and matching process is performed in the predicted message transaction queue according to the initial configuration, wherein the search and matching process includes sequential comparison and unordered comparison;

[0012] Output the matching results after comparison and check, and dynamically switch the retrieval matching mode based on the matching results and trigger conditions, including switching the starting configuration to the target configuration.

[0013] This implementation supports custom derived type transactions based on the uvm_object type, allowing the use of the scoreboard queue as a transaction queue for management and maintenance. It supports defining multiple prediction transaction queues and transferring transactions to and from the prediction and evaluation queues via UVM TLM imp and user interface functions. It also supports operations such as clearing, header discarding, and transaction discarding on the transaction queues, thereby calling the scoreboard queue's matching program to compare the evaluation message transactions with the prediction message transaction queues. Furthermore, it supports delayed evaluation / scoring of the evaluation transactions and the transmission of matching results and related transactions via UVM TLM uvm_analysis_port. This provides verifiers with multi-dimensional data to assist in more efficient debugging and more comprehensive verification, saving them significant development costs.

[0014] In one possible implementation of this application, the step of managing multiple queues based on the message transaction data to allocate the queue to which the current message transaction data belongs specifically includes:

[0015] The message transaction data is dynamically type-converted to obtain the pointer type, specifically including a handle of type uvm_object;

[0016] Based on the pointer type, queuing is distinguished according to the transaction queue identifier name, wherein,

[0017] The predicted message transaction is assigned to the predicted message transaction queue; and the message transaction to be evaluated is assigned to the evaluation message transaction queue.

[0018] In this implementation, the multi-queue management can first dynamically convert the message transaction from the transaction input interface to a handle of type uvm_object, and then enqueue the transaction object into the corresponding queue according to the queue identifier name accompanying the input transaction. At the same time, the arrival time of the predicted transaction is recorded for calculating the transaction delay time.

[0019] In one possible implementation of this application, the transaction to be evaluated is sequentially compared and matched in the predicted transaction queue according to the initial configuration mode, specifically including:

[0020] The sequential comparison allows for transaction loss. During the retrieval and matching, the data matching results within the message transaction to be evaluated and the predicted message transaction are specifically compared. The matching results include successful matching and failed matching.

[0021] When a match fails, the matching loop is exited based on the specific settings of the allowed transaction loss mode.

[0022] If the current transaction loss-allowing mode is enabled and the retrieval depth has reached the maximum loss threshold, then exit the loop and compare the next transaction object to be evaluated.

[0023] If the transaction loss allow mode is not currently enabled, the loop will be broken when the retrieval depth reaches the maximum number of forward retrievals, and the next transaction object to be evaluated will be compared.

[0024] Mark the Nth transaction object that matches successfully in the predicted message transaction queue as a successful match, and mark the first N-1 transaction objects as expected loss or unexpected loss depending on whether the allowed transaction loss mode is enabled.

[0025] In one possible implementation of this application, the method further includes reverse retrieval matching, specifically comprising: comparing the current message transaction to be evaluated with transaction objects in past predicted transaction records, wherein,

[0026] If a match is found, an error is reported in the prediction mechanism.

[0027] If a match fails, and the "allow transaction loss" mode is enabled, mark all transaction objects involved in the match as expected to be lost based on the maximum loss threshold, and mark the match result as not found; and / or

[0028] If a match fails and the allowed transaction loss mode is not currently enabled, mark the first transaction object in the predicted message transaction queue as a mismatch, and mark the matching result as a mismatch.

[0029] In this implementation, the reverse retrieval matching of transactions in past predicted transaction records to report error information is very helpful in actual verification and can greatly improve debugging efficiency.

[0030] In one possible implementation of this application, obtaining past predictive transaction records specifically includes:

[0031] If a match is successful in the transaction loss mode, the successfully matched predicted transaction object and the previously attempted matching transaction object will be deleted from the predicted message transaction queue and recorded as a past predicted transaction.

[0032] If a match fails in the transaction loss mode, the transaction object that was attempted to match will be removed from the prediction message transaction queue and recorded as a past prediction transaction. The number of transaction objects deleted is equal to the maximum loss threshold.

[0033] If a match is successful in the transaction loss mode, the successfully matched transaction object and the previously attempted matching transaction objects will be deleted from the prediction message transaction queue and recorded as past prediction transactions.

[0034] If a match fails in the transaction loss mode, the first transaction object that fails to match is removed from the prediction message transaction queue and recorded as a past prediction transaction.

[0035] In one possible implementation of this application, the dynamic switching of the retrieval matching mode based on the matching result and the triggering condition specifically includes:

[0036] Obtain the user-defined initial configuration and target configuration, wherein the initial configuration includes a silent mode and does not allow transaction loss, and the target configuration includes a silent mode and allows transaction loss;

[0037] The triggering conditions include at least one of the following: waiting time condition, number of successes condition, and number of failures condition;

[0038] The search matching mode is dynamically switched based on the matching results and the triggering conditions, wherein,

[0039] For the aforementioned waiting time condition, if the timeout exceeds the waiting time, the current starting configuration will be switched to the target configuration;

[0040] For the success count condition, if the count is greater than or equal to the success count, then the current starting configuration will be switched to the target configuration;

[0041] For the failure count condition, if the count is greater than or equal to the failure count, the current starting configuration will be switched to the target configuration.

[0042] In this implementation, when using the UVM environment for verification, especially during anomaly testing or robustness testing, there is often a need to switch the scoreboard configuration. Dynamic switching between the two scenarios can be achieved by setting up an automated dynamic switching retrieval and matching mechanism, which eliminates the need for manual switching by the user and avoids the problem of difficulty in controlling the switching time caused by manually switching the loss-allowed mode.

[0043] In one possible implementation of this application, the step of obtaining input message transaction data, wherein the message transaction data includes predicted message transactions and message transactions to be evaluated, specifically includes:

[0044] The message transaction data is obtained based on the transaction input interface, which includes a predicted transaction port group and a transaction port group to be evaluated.

[0045] Based on the port group of the transaction to be evaluated, obtain the message transactions to be evaluated that are participating in the matching;

[0046] Based on the predicted transaction port group, the predicted message transactions participating in the matching are obtained, wherein an evaluation delay is also set when obtaining the predicted message transactions.

[0047] Secondly, the present invention provides a message transaction data comparison and inspection system based on UVM, the system comprising:

[0048] The input module is used to acquire input message transaction data, which includes predicted message transactions and message transactions to be evaluated.

[0049] The management module is used to manage multiple queues based on the message transaction data to allocate the queue to which the current message transaction data belongs. The allocated queues include the predicted message transaction queue and the message transaction queue to be evaluated.

[0050] The matching module is used to perform retrieval and matching in the predicted message transaction queue according to the initial configuration based on the message transaction to be evaluated, wherein the retrieval and matching includes sequential comparison and unordered comparison;

[0051] The output module is used to output the matching results after comparison and check, and to dynamically switch the retrieval matching mode based on the matching results and trigger conditions, including switching the starting configuration to the target configuration.

[0052] Thirdly, the present invention provides an electronic device, the electronic device comprising: a processor and a memory;

[0053] The memory is used to store computer programs;

[0054] The processor is used to execute the computer program stored in the memory, so that the electronic device performs the above-described UVM-based message transaction data comparison and inspection method.

[0055] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by an electronic device, implements the above-described UVM-based message transaction data comparison and inspection method.

[0056] As described above, the UVM-based message transaction data comparison and inspection method, system, medium, and device of the present invention have the following beneficial effects:

[0057] (1) Supports multiple input interfaces, innovatively supporting both TLM ports and user interfaces as transaction inputs, adapting to different verification environment structures (such as module-level and system-level verification).

[0058] (2) Multi-queue management and complex topology processing: The transaction matching problem in complex network topology is solved by defining scoreboard queues and multi-queue management programs.

[0059] (3) Supports dynamic configuration switching and scenario adaptation. Through dynamic configuration switching, it supports complex scenarios such as abnormal scenario handling and DUT mode switching, thereby improving the scalability of the verification environment and development efficiency.

[0060] (4) Realize multidimensional statistics and intelligent analysis. Through built-in statistical functions (scoring results, transaction delays, etc.), it provides verification and debugging data support, and combined with control functions such as threshold trigger reporting, it helps verification personnel to quickly locate problems.

[0061] (5) Supports sequential / unordered comparison and reverse retrieval. It supports sequential / unordered comparison mode to adapt to different scenario requirements. Furthermore, the reverse retrieval matching program simplifies the debugging of complex prediction mechanisms and accelerates verification iteration. Attached Figure Description

[0062] Figure 1 This is a schematic diagram of a common UVM validation environment structure;

[0063] Figure 2 The diagram shows a step-by-step illustration of the UVM-based message transaction data comparison and inspection method of the present invention in one embodiment.

[0064] Figure 3 The diagram shows a flowchart of an embodiment of the UVM-based message transaction data comparison and inspection method of the present invention.

[0065] Figure 4 The diagram shows a multi-queue management schematic of an embodiment of the UVM-based message transaction data comparison and inspection method of the present invention;

[0066] Figure 5 The diagram shows a workflow of one embodiment of the UVM-based message transaction data comparison and inspection method of the present invention.

[0067] Figure 6 The diagram shows a sequential comparison flowchart of the UVM-based message transaction data comparison and inspection method of the present invention in one embodiment.

[0068] Figure 7 The diagram shows a flowchart of an unordered comparison in one embodiment of the UVM-based message transaction data comparison and inspection method of the present invention.

[0069] Figure 8 The diagram shows an example of reverse retrieval matching in a transaction loss-allowed mode in one embodiment of the UVM-based message transaction data comparison and inspection method of the present invention.

[0070] Figure 9 The diagram shows an example of reverse retrieval matching in a non-transaction loss mode in one embodiment of the UVM-based message transaction data comparison and inspection method of the present invention.

[0071] Figure 10The diagram shows a structural schematic of the UVM-based message transaction data comparison and inspection system of the present invention in one embodiment.

[0072] Figure 11 The diagram shown is a structural schematic of an embodiment of the electronic device of the present invention.

[0073] Component designation explanation

[0074] Steps S202-S208, Step 10: UVM-based message transaction data comparison and inspection system

[0075] 11 Input Module

[0076] 12 Management Module

[0077] 13 Matching Module

[0078] 14 Output Module Detailed Implementation

[0079] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that, unless otherwise specified, the following embodiments and features described therein can be combined with each other.

[0080] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0081] Furthermore, the use of terms such as "first" and "second" in this application is for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of the various embodiments can be combined with each other, but only on the basis of being achievable by those skilled in the art. If the combination of technical solutions is contradictory or impossible to implement, such a combination of technical solutions should be considered non-existent and not within the scope of protection claimed in this application.

[0082] This application proposes a UVM-based message transaction data comparison and inspection method, system, medium, and device, applicable to different message transaction types. The scoring board is modularized according to common scoring board requirements, facilitating expansion and reuse. It provides multiple functions and supports dynamic switching of scoring board configuration / mode to suit different verification scenarios, achieving the purpose of scoring (i.e., comparison and inspection) of predicted and evaluated message transactions. The technical solutions in the embodiments of this invention will be described in detail below with reference to the accompanying drawings.

[0083] like Figure 2 As shown, in one embodiment of the invention, the UVM-based message transaction data comparison and inspection method of the present invention includes the following steps:

[0084] Step S202: Obtain the input message transaction data, which includes predicted message transactions and message transactions to be evaluated;

[0085] Step S204: Perform multi-queue management based on the message transaction data to allocate the queue to which the current message transaction data belongs. The allocated queues include the predicted message transaction queue and the message transaction queue to be evaluated.

[0086] Step S206: Based on the message transaction to be evaluated, perform a search and matching in the predicted message transaction queue according to the initial configuration, wherein the search and matching includes sequential comparison and unordered comparison;

[0087] Step S208: Output the matching result after comparison check, and synchronously switch the retrieval matching mode dynamically based on the matching result and trigger conditions, including switching the starting configuration to the target configuration.

[0088] It should be noted that, in this embodiment, as Figure 3 The diagram shows a flowchart of the UVM-based message transaction data comparison and inspection method. To support custom transaction types, a parameterized class design is used. Parameterized classes are a feature of the SystemVerilog language, which allows parameters to be provided when declaring an instance of the class for internal use. Two user-defined parameters are provided: a) the type of the predicted transaction object, with the default parameter being the uvm_object type; b) the type of the transaction object to be evaluated, with the default parameter being the type of the predicted transaction object. Both parameters must correspond to types based on the uvm_object type.

[0089] Furthermore, SystemVerilog features are introduced: a) A subclass (derived class) object can be implicitly upcast and directly assigned to the handle of a parent class (base class) object, allowing the parent class handle to point to a subclass object; b) A parent class handle pointing to a subclass can be dynamically cast ($cast system function) to a handle of the subclass object, allowing access to properties / methods in the original subclass object through the subclass handle, and the $cast system function will return an exception if the conversion fails; c) Due to polymorphism, after dynamic conversion, properties / methods with the same name in the subclass object can be accessed through the parent class handle.

[0090] Furthermore, this method is thus endowed with versatility for message transaction objects. Users can perform scoring / comparison checks on any message transaction derived from the uvm_object type. Specifically, in terms of execution steps, the input message transaction data is first obtained, corresponding to predicted message transactions and message transactions to be evaluated. Multi-queue management is then performed to allocate queues, that is, queue allocation is performed in multi-queue management. Accordingly, the allocated queues include the predicted message transaction queue and the message transaction queue to be evaluated. Figure 3 The predicted transaction queues A / B and the transaction queues to be evaluated A / B shown can be used to enable delayed evaluation after the message to be evaluated is obtained, so as to wait for the predicted transaction queues to improve fault tolerance.

[0091] Furthermore, based on the message transaction to be evaluated, a search and matching process is performed in the predicted message transaction queue according to the initial configuration, i.e., the transaction matching phase begins. The search and matching process includes sequential comparison and unordered comparison. The specific matching process will be described in detail in the subsequent specification. The matching results after comparison and checking are compiled and output. Simultaneously, the search and matching mode is dynamically switched based on the matching results and triggering conditions. This includes switching the initial configuration to the target configuration, so that the user does not need to manually switch. Accordingly, the output matching results include, for example, successful matching, failed matching, not found, no match, etc.

[0092] In one embodiment of the invention, the step of obtaining input message transaction data, wherein the message transaction data includes predicted message transactions and message transactions to be evaluated, specifically includes:

[0093] The message transaction data is obtained based on the transaction input interface, which includes a predicted transaction port group and a transaction port group to be evaluated.

[0094] Based on the port group of the transaction to be evaluated, obtain the message transactions to be evaluated that are participating in the matching;

[0095] Based on the predicted transaction port group, the predicted message transactions participating in the matching are obtained, wherein an evaluation delay is also set when obtaining the predicted message transactions.

[0096] It should be noted that, in this embodiment, the user interface provided to the user mainly includes a transaction input interface, a result output interface, and a module control interface. The message transaction data is obtained based on the transaction input interface. Among them, the UVM TLM imp type prediction transaction port group and the transaction to be evaluated port group are declared with the transaction type specified by the corresponding parameter. TLM (Transaction Level Modeling) is a transaction-level transport model defined by UVM, which is usually used for the transfer of transactions between UVM components and is very commonly used in the UVM environment. Correspondingly, the user interface functions predict() and evaluate() are defined with the transaction type specified by the corresponding parameter. The result output interface is a UVM TLM analysis port type port. After each transaction matching is completed, multiple result data are output through the result output port. Different result data are output from different ports for users to use selectively.

[0097] Furthermore, the prediction transaction port group contains multiple defined transaction status ports, which specify the transaction type they transmit as the type specified by the corresponding parameter during declaration. Through this group of ports, the transactions in the prediction transaction queue participating in the matching are output according to their corresponding statuses. The evaluation transaction port group contains multiple defined result type ports, which specify the transaction type they transmit as the type specified by the corresponding parameter during declaration. Through this group of ports, the evaluation transactions participating in the matching are output according to their corresponding statuses. Specifically, the evaluation message transactions participating in the matching are obtained based on the evaluation transaction port group, and the prediction message transactions participating in the matching are obtained based on the prediction transaction port group. An evaluation delay is also set when obtaining the prediction message transactions, specifically as follows: Figure 3 As shown, the waiting delay = arrival time of the transaction to be evaluated + delay time from the module control interface (set delay) - current time. After the delay ends, a request is sent to the prediction transaction multi-queue management to the prediction transaction queue corresponding to the previously identified name, and the transaction to be evaluated enters the transaction matching stage together. This is accomplished through the callback function interface preset in the transaction matching. The callback function refers to the uvm_callback mechanism defined by UVM.

[0098] The module control interface provides users with control commands, including: an enable interface (enabling / disabling the scoreboard function); a mode configuration interface (configuring the scoreboard mode, including silent mode, delayed comparison mode, etc., and configuring scoreboard queue-related parameters); a self-check interface (checking the status of each queue in the scoreboard); a queue configuration interface (configuring the number and identifier names of transaction queues in the scoreboard); a clear interface (clearing all transactions and result data in all scoreboard queues); a specified queue clear interface (clearing transactions in a specified scoreboard queue); a specified number of transaction discards interface (deleting a specified number of head transactions in a specified scoreboard queue); and a manual matching interface (manually providing transactions to be evaluated and performing matching, only returning the matching results without performing any operations on transactions in each queue).

[0099] In one embodiment of the invention, the step of managing multiple queues based on the message transaction data to allocate the queue to which the current message transaction data belongs specifically includes:

[0100] The message transaction data is dynamically type-converted to obtain the pointer type, specifically including a handle of type uvm_object;

[0101] Based on the pointer type, queuing is distinguished according to the transaction queue identifier name, wherein,

[0102] The predicted message transaction is assigned to the predicted message transaction queue; and the message transaction to be evaluated is assigned to the evaluation message transaction queue.

[0103] It should be noted that, in this embodiment, since the transaction queue adopts the uvm_queue type defined by UVM, various attributes / methods defined by the uvm_queue type itself can be used in queue management. For example, the queue depth method size(), the queue transaction object get() at a specified index, the transaction object push_back() at the tail of the queue, the transaction object insert() at a specified index position, the transaction object pop_front() at the head of the queue, and the queue transaction object delete() at a specified index position are all performed. The multi-queue management is specifically divided into prediction transaction multi-queue management and evaluation transaction multi-queue management, but their execution logic and functions are basically the same. Specifically, dynamic type conversion is performed to obtain the pointer type, and the transaction queue is distinguished by the transaction queue identifier name based on the pointer type. The prediction message transaction is assigned to the prediction message transaction queue, and the evaluation message transaction is assigned to the evaluation message transaction queue.

[0104] Specifically, the example of predictive message transaction multi-queue management is used. The management between users and queues (where a user inputs a transaction, and queues are distinguished based on the transaction's keywords / attributes) requires assigning a queue to the user. Multi-queue management creates a specified number of transaction queues with specified identifier names based on data from the configuration interface, or simply creates default transaction queues. During declaration, the transaction type stored is specified as the type specified by the corresponding parameter. In application, the uvm_queue type defined by UVM or the message transaction type defined in this application can be used as the transaction queue type. The transaction queue type is universal, and the queue identifier names created by the two multi-queue management systems are consistent.

[0105] Multi-queue management first dynamically converts the transactions from the transaction input interface, assigning them handles of type uvm_object. Then, based on the queue identifier name accompanying the input transaction, it enqueues the transaction object into the corresponding queue, simultaneously recording the arrival time of the predicted transaction for calculating transaction latency. Specifically, the multi-queue management system provides a predicted transaction queue with the queue identifier name corresponding to the transaction to be evaluated, for retrieval and matching. Furthermore, if... Figure 4 As shown, multi-queue management can also dynamically accept control commands from the module control interface, including configuring queue modes, initiating queue self-checks, and clearing or discarding queue transactions. These correspond to different program execution logics. Specifically, upon receiving an enqueue command from the queue management interface, the `uvm_queue`'s `push_back()` method is used to enqueue the transaction and predict the transaction count. Upon receiving a discard / clear transaction command, the `pop_front()` or `delete()` method is used to discard a specified number of queue transactions at a specified position. When the check interface is called, the check program starts, which checks the current status of the transaction queue and reports the number of transactions in the queue. It also checks and reports statistical information.

[0106] Furthermore, such as Figure 5 The diagram shows the statistical workflow. First, the transactions to be evaluated are counted. Then, the queues of transactions to be evaluated and predicted transactions are searched and compared. After the comparison is completed, the corresponding matching results are given. If the comparison is successful, the dequeue time of the successfully matched transactions in the predicted transaction queue is recorded. The obtained matching results are classified and counted according to different statistical items defined by the statistical function. When a certain count exceeds the set warning threshold and the current scoreboard queue is in non-silent mode, an error report will be made. In addition, the delay time of the successfully matched transactions is calculated as follows: transaction delay = dequeue time of successfully matched transactions - enqueue time, and the result is recorded and printed.

[0107] In one embodiment of the invention, the process of sequentially comparing and matching the message transaction to be evaluated in the predicted message transaction queue according to the initial configuration mode specifically includes:

[0108] The sequential comparison allows for transaction loss. During the retrieval and matching, the data matching results within the message transaction to be evaluated and the predicted message transaction are specifically compared. The matching results include successful matching and failed matching.

[0109] When a match fails, the matching loop is exited based on the specific settings of the allowed transaction loss mode.

[0110] If the current transaction loss-allowing mode is enabled and the retrieval depth has reached the maximum loss threshold, then exit the loop and compare the next transaction object to be evaluated.

[0111] If the transaction loss allow mode is not currently enabled, the loop will be broken when the retrieval depth reaches the maximum number of forward retrievals, and the next transaction object to be evaluated will be compared.

[0112] Mark the Nth transaction object that matches successfully in the predicted message transaction queue as a successful match, and mark the first N-1 transaction objects as expected loss or unexpected loss depending on whether the allowed transaction loss mode is enabled.

[0113] It should be noted that, in this embodiment, the comparison based on transactions (inherited from the uvm_object base class) typically employs the following comparison methods:

[0114] (1) Extract the transaction attributes that need to be focused on and compare them separately. For example, compare the "load data" of the predicted transaction with the "load data" of the transaction to be evaluated. To achieve this comparison, the "load data" attribute needs to be obtained. Therefore, in the comparator that processes objects of type uvm_object, the base class uvm_object object must be dynamically converted into the specified subclass transaction type through the $cast system function. However, this comparator considers generality and maintainability and decouples the transaction type from the comparator task, so this approach is not adopted.

[0115] (2) The `compare()` method built into the `uvm_object` type is used for comparison. This method automatically compares the attributes registered using the UVM factory mechanism in the transaction. User-defined transaction type objects derived from the `uvm_object` class are statically converted to a base class handle when the comparator's transaction comparison interface is called. Based on SystemVerilog's polymorphism, when using the `compare()` method of this base class handle, the `compare()` method of the derived class object it points to is actually used, thus allowing comparison of attributes registered in the factory mechanism in the derived class. This scheme utilizes the built-in features and methods of SV / UVM, has high reliability, and is easy to maintain and extend. Therefore, this embodiment will also use the `compare()` method built into the `uvm_object` type for comparison. Specifically, based on the description of the comparator's underlying comparison principle, constraints are imposed on user-defined transaction types: user-defined transactions are required to be derived from the `uvm_object` type, and the attributes to be compared must be registered using the UVM factory mechanism without being marked with `UVM_NOCOMPARE`.

[0116] To improve efficiency in transaction comparison scenarios with high transaction complexity, large amount of data to be compared attributes, and many transactions to be evaluated, a multi-layered comparison logic was designed, from simple to complex. This allows for rapid pre-comparison of transactions with minimal overhead, enabling more efficient filtering of obviously mismatched transactions.

[0117] (1) The first level of comparison is the transaction type comparison. When the subclass is registered by the UVM factory mechanism, the handle pointing to its parent class can use the get_object_type() method defined by UVM to get the name of the subclass's real type. By comparing the real types of the two transactions participating in the comparison through this method, transactions with different real types can be excluded.

[0118] (2) The second-level comparison is a fast comparison of transaction characteristics. It starts only if the first-level transaction type comparison is not enabled or is successful. Since transactions have different characteristics, fast comparison requires users to implement the fast comparison method `quick_compare()` in their custom transaction types, defining the fast comparison standard themselves. This embodiment proposes an interface class for transaction fast comparison, `trans_quick_comparable`. This interface class is a special type defined by SystemVerilog, which can be applied by regular types and used as a constraint / template. Therefore, the virtual functions defined in the interface class must be implemented in the regular type. Furthermore, regular type objects using a certain interface class can be dynamically converted to handles of the corresponding interface class using the `$cast` system function. This interface class defines the virtual function `quick_compare()`. Users need to apply this interface class and implement the `quick_compare` function when defining a transaction. Thus, when the comparator reaches the fast comparison transaction stage, it can attempt to dynamically convert the transaction into a handle of the transaction fast comparison interface class using the `$cast` system function to determine if the transaction supports fast comparison. Fast comparison is only implemented if the conversion is successful.

[0119] 3) The third-level comparison is a complete comparison of transaction content. It is executed only if the first and second-level transaction type comparisons are not enabled or are successful. The complete comparison uses the compare() method built into the uvm_object type. This method can compare the attributes registered by the UVM factory mechanism in the subclass and not marked with UVM_NOCOMPARE. At the end of the transaction comparison, the results such as transaction matching and non-matching will be output according to the comparison process.

[0120] Specifically, such as Figure 6 The diagram shows a flowchart of the sequential comparison process. The sequential retrieval mode is typically used in scenarios where the order of transactions to be evaluated matches the order of transactions in the prediction transaction queue. To adapt to more complex verification scenarios, a transaction loss mode is supported. This means that during the sequential retrieval process, a specified number of transactions are allowed to fail to match the transaction to be evaluated. This implies that the "transaction to be evaluated" corresponding to these failed prediction transactions has not appeared, often indicating a defect in the design under test or inconsistency with the prediction mechanism. Preprocessing is performed first to initialize the retrieval results and check if the prediction transaction queue is empty. After the preprocessing is successful, a retrieval loop is entered. The uvm_queue queue's get() method is used to sequentially retrieve prediction transaction objects from the beginning and call the transaction comparison task to compare them with the transaction to be evaluated.

[0121] If the returned result is a match, the process starts directly to organize and retrieve the matching results. Otherwise, it checks whether the current comparator has enabled the transaction loss allow mode. If it is enabled and the current retrieval depth has not reached the maximum loss threshold, it jumps to the beginning of the loop to compare the next predicted transaction object in the prediction queue.

[0122] If the current comparator does not have the allowed transaction loss mode enabled, it then checks whether the current search depth has reached the maximum search depth. Only if it has not reached the maximum search depth does it jump to the beginning of the loop. In the above loop, once the comparator result is a match, it immediately exits the loop and begins to organize the search matching results. At this time, the results are organized according to the search depth when the loop exits after a successful match. First, the predicted transaction object that has successfully matched (assuming it is the Nth transaction object in the predicted transaction queue) is marked as a match. Then, depending on whether the current comparator has the allowed transaction loss mode enabled, the first N-1 transaction objects are marked as expected loss or unexpected loss. Among them, predicted transactions that have already participated in the matching are deleted to avoid affecting subsequent matching. If there is still no successful match when the above loop ends, that is, when the allowed transaction loss mode is enabled, the search depth has reached the maximum loss threshold and there is still no successful match; and / or when the allowed transaction loss mode is not enabled, the search depth has reached the maximum search depth (maximum number of forward searches) and there is still no successful match, then a reverse search matching task will be executed depending on whether reverse search matching is enabled. The details will be explained in detail in the subsequent instructions.

[0123] Furthermore, such as Figure 7The diagram shows a flowchart of unordered comparison. Unordered retrieval mode is typically used in scenarios where the order of the transactions to be evaluated and the order of transactions in the prediction transaction queue are not strictly required. In this mode, the transaction retrieval and matching process is simplified. Preprocessing is performed to initialize the retrieval results, and the prediction transaction queue is checked for emptiness. After preprocessing, a retrieval loop is entered. The `get()` method of the `uvm_queue` queue retrieves prediction message transaction objects sequentially from the beginning. The transaction comparison task is called to compare with the transaction to be evaluated. If the returned result is a match, the retrieval and matching process begins directly. Otherwise, it checks whether the current retrieval depth has reached the maximum retrieval depth. Only if it has not reached the maximum depth does it jump back to the beginning of the loop. In the above loop, once the comparator result is a match, the loop immediately exits. After the loop ends, the results are processed based on whether a match was successful. Specifically, if a match is successful, the match result is marked as a match, and the successfully matched predicted message transaction object (assuming it is the Nth transaction object in the predicted transaction queue) is also marked as a match and deleted from the predicted transaction queue. If a match fails, the match result is marked as [not found], and no transaction object is deleted from the predicted message transaction queue. These results are returned to the calling interface at the same time as the report is submitted, for further use by the user.

[0124] In one embodiment of the invention, the method further includes reverse retrieval matching, specifically comprising: comparing the current message transaction to be evaluated with transaction objects in past predicted transaction records, wherein,

[0125] If a match is found, an error is reported in the prediction mechanism.

[0126] If a match fails, and the "allow transaction loss" mode is enabled, mark all transaction objects involved in the match as expected to be lost based on the maximum loss threshold, and mark the match result as not found; and / or

[0127] If a match fails and the allowed transaction loss mode is not currently enabled, mark the first transaction object in the predicted message transaction queue as a mismatch, and mark the matching result as a mismatch.

[0128] In one embodiment of the invention, if a match is successful in the transaction loss mode, the successfully matched predicted transaction object and the previously attempted matching transaction object are deleted from the predicted message transaction queue and recorded as past predicted transactions.

[0129] If a match fails in the transaction loss mode, the transaction object that was attempted to match will be removed from the prediction message transaction queue and recorded as a past prediction transaction. The number of transaction objects deleted is equal to the maximum loss threshold.

[0130] If a match is successful in the transaction loss mode, the successfully matched transaction object and the previously attempted matching transaction objects will be deleted from the prediction message transaction queue and recorded as past prediction transactions.

[0131] If a match fails in the transaction loss mode, the first transaction object that fails to match is removed from the prediction message transaction queue and recorded as a past prediction transaction.

[0132] It should be noted that, in this embodiment, the reverse retrieval matching task can discover potential defects in the prediction mechanism in the verification environment that provides the prediction queue by reverse retrieval of previously matched prediction transactions (those that were matched last time), thus helping verification personnel to calibrate. This task relies on the records of previously matched prediction transactions, which are generated at the final stage of each transaction retrieval matching task, i.e., the post-processing stage of the prediction transaction queue. Under different modes, for different matching results, there are the following post-processing schemes:

[0133] (1) In the mode that allows transaction loss, if a match is successful, the successfully matched predicted transaction object and the previously attempted matching transaction object will be deleted from the predicted transaction queue and treated as members in the past predicted transaction record.

[0134] (2) In the mode that allows transaction loss, if the match fails, the transaction objects that were tried to match will be deleted from the predicted transaction queue (the number is equal to the maximum loss threshold) and they will be used as members of the past predicted transaction records. When the number of past predicted transaction records exceeds the reverse retrieval depth, the excess part will be removed.

[0135] (3) In the no-transaction-loss mode, if a match is successful, the successfully matched transaction object and the previously attempted matching transaction object will be deleted from the predicted transaction queue and added as members in the past predicted transaction record.

[0136] (4) In the no-transaction-loss mode, if the match fails, the first failed transaction object will be deleted from the prediction transaction queue and added as a member of the past prediction transaction record.

[0137] Furthermore, by performing a reverse retrieval matching task, the current transaction to be evaluated is compared sequentially with the transactions in the past prediction transaction records. Once a comparison is successful, an error is reported. This error can be used to indicate that there may be a defect in the prediction mechanism in the verification environment. This is because the current transaction to be evaluated has not matched a transaction object in the current prediction transaction queue, but has matched a prediction transaction that participated in the matching in the past. This often indicates that there was an anomaly in the previous matching process. For example, the previous transaction to be evaluated failed to match because it was not predicted by the prediction mechanism. Therefore, the prediction transactions that originally corresponded to the current transaction to be evaluated are removed in advance as objects that failed to match. The information reported by this reverse retrieval matching is very helpful in the actual verification process and can greatly improve the efficiency of debugging.

[0138] like Figure 8 The diagram shown illustrates an example of reverse search matching in a transaction loss-allowed mode. Figure 9 The diagram illustrates an example of reverse retrieval matching in a no-transaction-loss-allowed mode. After the reverse retrieval matching task is completed or a successful match has already been made, the transaction retrieval matching task enters the matching result processing and prediction transaction queue post-processing stage. If a match is successful, the successfully matched prediction transaction object (assuming it is the Nth transaction object in the prediction transaction queue) is marked as a match. Then, depending on whether the current comparator enables the no-transaction-loss-allowed mode, the first N-1 transaction objects are marked as expected or unexpected loss: if no loss-allowed mode is set, the overall matching result is marked as a match. If a match fails, and the current comparator enables the no-transaction-loss-allowed mode, all transactions participating in the matching are marked as expected loss according to the maximum loss threshold, and the overall matching result is marked as not found. If a match fails, and the no-transaction-loss-allowed mode is not currently enabled, the first transaction object in the prediction transaction queue is marked as a mismatch, and the overall matching result is marked as a mismatch. The post-processing of the prediction transaction queue is as described above. These results are reported and returned to the calling interface for further user use.

[0139] In one embodiment of the invention, the step of dynamically switching the retrieval matching mode based on the matching result and the triggering condition specifically includes:

[0140] Obtain the user-defined initial configuration and target configuration, wherein the initial configuration includes a silent mode and does not allow transaction loss, and the target configuration includes a silent mode and allows transaction loss;

[0141] The triggering conditions include at least one of the following: waiting time condition, number of successes condition, and number of failures condition;

[0142] The search matching mode is dynamically switched based on the matching results and the triggering conditions, wherein,

[0143] For the aforementioned waiting time condition, if the timeout exceeds the waiting time, the current starting configuration will be switched to the target configuration;

[0144] For the success count condition, if the count is greater than or equal to the success count, then the current starting configuration will be switched to the target configuration;

[0145] For the failure count condition, if the count is greater than or equal to the failure count, the current starting configuration will be switched to the target configuration.

[0146] It should be noted that, in this embodiment, when using the UVM environment for verification, especially during anomaly testing or robustness testing, the following scenarios often arise, leading to the need for dynamic configuration switching.

[0147] (1) Perform abnormal tests during a certain period of time. During this period, the matching results are not checked, that is, the matching failure results are allowed to occur during the operation.

[0148] (2) After the abnormal test is completed, normal operation needs to be restored, that is, there are no failures during the operation.

[0149] Retrieves the user-defined initial configuration and target configuration. Initial configuration includes options such as silent mode and no data loss allowed. If not provided, the current scoreboard queue configuration will be used as the initial configuration; multiple configurations can be provided. Target configuration (the target after switching) includes options such as silent mode and no data loss allowed; this is mandatory and multiple configurations can be provided. Switching conditions include options such as "wait for a specified time," "a specified number of successful comparisons," and "a specified number of failed comparisons"; these are also mandatory, and if multiple conditions are provided, switching will occur when any condition is met.

[0150] Specifically, the parameter configuration is first preprocessed, which involves an admission check on the three elements provided by the user interface, such as checking whether the target configuration and switching conditions are provided. If the check passes, an attempt is made to acquire the right to switch the configuration. This step is for multi-process conflict protection and is implemented using the semaphore defined in SystemVerilog. `semaphore.try_get()` attempts to acquire the right. If it is unavailable, `semaphore.get()` is used to wait for the right to acquire it based on the configuration option "whether to wait for the right to acquire". At the end, `semaphore.put()` is used to release the right to acquire. Currently, only one dynamic switching procedure can run.

[0151] Once the right to use the slot is acquired, the scoreboard and its application comparators are configured according to the initial configuration. Then, the process enters the stage of waiting for the switching conditions to take effect. Here, the waiting processes for multiple switching conditions are controlled using the `fork…join_any` block defined in SystemVerilog. Once any waiting process for a switching condition terminates, the block is exited, and the other waiting processes are terminated. The scoreboard queue has a built-in timer and statistics monitor.

[0152] Furthermore, for the "wait for a specified time" switching condition, a timer will be activated to count according to the set time. After the timeout, the switch to the target configuration will be triggered. For switching conditions related to statistics, such as "compare a specified number of successful comparisons" or "compare a specified number of failed comparisons," a statistics monitor will be applied to wait for the switching condition to be met. For example, for the success count condition, if the count is greater than or equal to the number of successful comparisons, the current starting configuration will be switched to the target configuration; for the failure count condition, if the count is greater than or equal to the number of failed comparisons, the current starting configuration will be switched to the target configuration. After the waiting period for the switching condition is completed, the target configuration will be applied for configuration, and the occupancy right will be released. Dynamic switching is required between the two scenarios. If this is not done, the user will need to manually switch, which allows for loss of mode and makes it difficult to control the switching timing.

[0153] The scope of protection of the UVM-based message transaction data comparison and inspection method described in this application is not limited to the execution order of the steps listed in this embodiment. Any solution implemented by adding, subtracting, or replacing steps in the prior art based on the principles of this application is included within the scope of protection of this application.

[0154] This application also provides a UVM-based message transaction data comparison and inspection system. The UVM-based message transaction data comparison and inspection system can implement the UVM-based message transaction data comparison and inspection method described in this application. However, the implementation device of the UVM-based message transaction data comparison and inspection method described in this application includes, but is not limited to, the structure of the UVM-based message transaction data comparison and inspection system listed in this embodiment. All structural modifications and substitutions of the prior art made in accordance with the principles of this application are included within the protection scope of this application.

[0155] Please see Figure 10 In one embodiment, this embodiment provides a UVM-based message transaction data comparison and inspection system 10, the system comprising:

[0156] Input module 11 is used to acquire input message transaction data, which includes predicted message transactions and message transactions to be evaluated;

[0157] Management module 12 is used to perform multi-queue management based on the message transaction data to allocate the queue to which the current message transaction data belongs. The allocated queues include the predicted message transaction queue and the message transaction queue to be evaluated.

[0158] Matching module 13 is used to perform retrieval and matching in the predicted message transaction queue according to the initial configuration based on the message transaction to be evaluated, wherein the retrieval and matching includes sequential comparison and unordered comparison;

[0159] Output module 14 is used to output the matching results after comparison check, and synchronously switch the retrieval matching mode dynamically based on the matching results and trigger conditions, including switching the starting configuration to the target configuration.

[0160] Since the specific implementation of this embodiment corresponds to the aforementioned method embodiment, the same details will not be repeated here, and those skilled in the art should also understand this. Figure 10 The division of the modules in the embodiments is only a logical functional division. In actual implementation, they can be fully or partially integrated into one or more physical entities. These modules can be fully implemented in software through processing element calls, fully implemented in hardware, or some modules can be implemented in software through processing element calls and some modules can be implemented in hardware.

[0161] In the embodiments provided by this invention, it should be understood that the disclosed apparatus or method can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules / units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or units may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of the apparatus or module or unit may be electrical, mechanical, or other forms.

[0162] The modules / units described as separate components may or may not be physically separate. The components shown as modules / units may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules / units can be selected to achieve the objectives of the embodiments of the present invention, depending on actual needs. For example, the functional modules / units in the various embodiments of the present invention may be integrated into one processing module, or each module / unit may exist physically separately, or two or more modules / units may be integrated into one module / unit.

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

[0164] This invention also provides an electronic device, such as... Figure 11 As shown, the electronic device includes a processor and a memory.

[0165] The memory is used to store computer programs.

[0166] The processor is configured to execute a computer program stored in the memory to cause the electronic device to perform any of the methods described above.

[0167] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, or methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules / units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or units may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of apparatuses or modules or units may be electrical, mechanical, or other forms.

[0168] The modules / units described as separate components may or may not be physically separate. The components shown as modules / units may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules / units can be selected to achieve the objectives of the embodiments of this application, depending on actual needs. For example, the functional modules / units in the various embodiments of this application may be integrated into one processing module, or each module / unit may exist physically separately, or two or more modules / units may be integrated into one module / unit.

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

[0170] This application also provides a computer-readable storage medium. Those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing a processor. The program can be stored in a computer-readable storage medium, which is a non-transitory medium, such as random access memory, read-only memory, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof. The storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid-state drive (SSD)).

[0171] This application embodiment may also provide a computer program product comprising one or more computer instructions. When the computer instructions are loaded and executed on a computing device, all or part of the processes or functions described in this application embodiment are generated. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means.

[0172] When the computer program product is executed by a computer, the computer performs the method described in the foregoing method embodiments. The computer program product can be a software installation package; when the foregoing method is required, the computer program product can be downloaded and executed on the computer.

[0173] The descriptions of the processes or structures corresponding to the above-mentioned figures each have their own emphasis. For parts of a process or structure that are not described in detail, please refer to the relevant descriptions of other processes or structures.

[0174] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A method for checking packet transaction data comparison based on UVM, characterized in that, include: Obtain the input message transaction data, which includes predicted message transactions and message transactions to be evaluated; Multi-queue management is performed based on the message transaction data to allocate the queue to which the current message transaction data belongs. The allocated queues include the predicted message transaction queue and the message transaction queue to be evaluated. Based on the transaction to be evaluated, a search and matching process is performed in the predicted transaction queue according to the initial configuration. This search and matching includes both sequential and unordered comparisons. Specifically, the sequential comparison search and matching process in the predicted transaction queue, based on the transaction to be evaluated, allows for transaction loss. During the search and matching process, the data matching results within the transaction to be evaluated and the predicted transaction are compared. The matching results include successful and unordered matches. When a match fails, the matching loop is exited based on the specific settings of the allowed transaction loss mode. If the allowed transaction loss mode is currently enabled and the search depth reaches the maximum loss threshold, the loop is exited to compare the next transaction object to be evaluated. If the allowed transaction loss mode is not currently enabled, the loop is exited to compare the next transaction object to be evaluated when the search depth reaches the maximum loss threshold. When the maximum number of forward searches is reached, the loop is exited to compare the next transaction object to be evaluated; the Nth transaction object that matches successfully in the predicted message transaction queue is marked as a successful match, and the first N-1 transaction objects are marked as expected loss or unexpected loss depending on whether the allowed transaction loss mode is enabled; and reverse search matching, specifically including: comparing the current message transaction to be evaluated with the transaction objects in the past predicted transaction records, wherein, if the match is successful, an error in the prediction mechanism is reported; if the match fails, and the allowed transaction loss mode is enabled, all transaction objects participating in the matching are marked as expected loss according to the maximum loss threshold, and the matching result is marked as not found; and / or if the match fails, and the allowed transaction loss mode is not currently enabled, the first transaction object in the predicted message transaction queue is marked as a mismatch, and the matching result is marked as a mismatch; Output the matching results after comparison and check, and dynamically switch the retrieval matching mode based on the matching results and trigger conditions, including switching the starting configuration to the target configuration.

2. The UVM-based message transaction data comparison and inspection method according to claim 1, characterized in that, The step of managing multiple queues based on the message transaction data to allocate the queue to which the current message transaction data belongs specifically includes: The message transaction data is dynamically type-converted to obtain the pointer type, specifically including a handle of type uvm_object; Based on the pointer type, queuing is distinguished according to the transaction queue identifier name, wherein, The predicted message transaction is assigned to the predicted message transaction queue; and the message transaction to be evaluated is assigned to the evaluation message transaction queue.

3. The UVM-based message transaction data comparison and inspection method according to claim 1, characterized in that, Retrieve past prediction transaction records, specifically including: If a match is successful in the transaction loss mode, the successfully matched predicted transaction object and the previously attempted matching transaction object will be deleted from the predicted message transaction queue and recorded as a past predicted transaction. If a match fails in the transaction loss mode, the transaction object that was attempted to match will be removed from the prediction message transaction queue and recorded as a past prediction transaction. The number of transaction objects deleted is equal to the maximum loss threshold. If a match is successful in the transaction loss mode, the successfully matched transaction object and the previously attempted matching transaction objects will be deleted from the prediction message transaction queue and recorded as past prediction transactions. If a match fails in the transaction loss mode, the first transaction object that fails to match is removed from the prediction message transaction queue and recorded as a past prediction transaction.

4. The UVM-based message transaction data comparison and inspection method according to claim 1, characterized in that, The dynamic switching of the search matching mode based on the matching results and triggering conditions specifically includes: Obtain the user-defined initial configuration and target configuration, wherein the initial configuration includes a silent mode and does not allow transaction loss, and the target configuration includes a silent mode and allows transaction loss; The triggering conditions include at least one of the following: waiting time condition, number of successes condition, and number of failures condition; The search matching mode is dynamically switched based on the matching results and the triggering conditions, wherein, For the aforementioned waiting time condition, if the timeout exceeds the waiting time, the current starting configuration will be switched to the target configuration; For the success count condition, if the count is greater than or equal to the success count, then the current starting configuration will be switched to the target configuration; For the failure count condition, if the count is greater than or equal to the failure count, the current starting configuration will be switched to the target configuration.

5. The UVM-based message transaction data comparison and inspection method according to claim 1, characterized in that, The step of acquiring input message transaction data, which includes predicted message transactions and message transactions to be evaluated, specifically includes: The message transaction data is obtained based on the transaction input interface, which includes a predicted transaction port group and a transaction port group to be evaluated. Based on the port group of the transaction to be evaluated, obtain the message transactions to be evaluated that are participating in the matching; Based on the predicted transaction port group, the predicted message transactions participating in the matching are obtained, wherein an evaluation delay is also set when obtaining the predicted message transactions.

6. A message transaction data comparison and inspection system based on UVM, characterized in that, include: The input module is used to acquire input message transaction data, which includes predicted message transactions and message transactions to be evaluated. The management module is used to manage multiple queues based on the message transaction data to allocate the queue to which the current message transaction data belongs. The allocated queues include the predicted message transaction queue and the message transaction queue to be evaluated. The matching module is used to perform retrieval and matching in the predicted message transaction queue based on the message transaction to be evaluated, according to the initial configuration. The retrieval and matching includes sequential comparison and unordered comparison. Specifically, the sequential comparison retrieval and matching in the predicted message transaction queue based on the message transaction to be evaluated, according to the initial configuration mode, includes: allowing transaction loss during sequential comparison; specifically comparing the data matching results between the message transaction to be evaluated and the predicted message transaction during retrieval and matching, with matching results including successful matching and failed matching; when a match fails, the matching loop is exited based on the specific setting of the allowed transaction loss mode. Specifically, if the allowed transaction loss mode is currently enabled and the retrieval depth reaches the maximum loss threshold, the loop is exited and the next message transaction to be evaluated is compared; if the allowed transaction loss mode is not currently enabled, the retrieval depth is increased. When the maximum number of forward searches is reached, the loop exits and the next transaction object to be evaluated is compared; the Nth transaction object that matches successfully in the predicted message transaction queue is marked as a successful match, and the first N-1 transaction objects are marked as expected loss or unexpected loss depending on whether the allowed transaction loss mode is enabled; and reverse search matching, specifically including: comparing the current message transaction to be evaluated with the transaction objects in the past predicted transaction records, wherein, if the match is successful, an error in the prediction mechanism is reported; if the match fails, and the allowed transaction loss mode is enabled, all transaction objects participating in the matching are marked as expected loss according to the maximum loss threshold, and the matching result is marked as not found; and / or if the match fails, and the allowed transaction loss mode is not currently enabled, the first transaction object in the predicted message transaction queue is marked as a mismatch, and the matching result is marked as a mismatch; The output module is used to output the matching results after comparison and check, and to dynamically switch the retrieval matching mode based on the matching results and trigger conditions, including switching the starting configuration to the target configuration.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by the processor, the program implements the UVM-based message transaction data comparison and inspection method as described in any one of claims 1 to 5.

8. An electronic device, characterized in that, The electronic device includes a processor and a memory; wherein the memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory to enable the electronic device to perform the UVM-based message transaction data comparison and inspection method as described in any one of claims 1 to 5.

Images