Request comparison method applied to uvm verification

Abstract

The application relates to a request comparison method and device applied to UVM verification, a computer device, a computer readable storage medium and a computer program product, which can be used in the field of computer technology. The method comprises the following steps: creating a transaction class corresponding to a storage access operation; generating an instance message of the storage access operation according to the transaction class, and storing the instance message in an expected queue; in the case that a storage access request message to be compared meets protocol conditions and design specification conditions, comparing the storage access request message with the instance message in the expected queue to obtain a comparison result of the storage access request message; the comparison processing comprises start address comparison processing and message length comparison processing; and the comparison result is used to determine an access verification result of the storage access request message. The method can improve the efficiency of access verification.

Description

Technical Field

[0001] This application relates to the field of integrated circuit technology, and in particular to a request comparison method, apparatus, computer device, computer-readable storage medium, and computer program product used in UVM verification. Background Technology

[0002] With the development of computer technology, access control technology plays an increasingly important role in computer systems. Access verification is necessary to ensure the accuracy of data access.

[0003] Traditional technologies typically involve manually writing verification rules and checking access requests for verification. However, this method requires a significant amount of manual processing time, resulting in low efficiency. Summary of the Invention

[0004] Therefore, it is necessary to provide a request comparison method, apparatus, computer device, computer-readable storage medium, and computer program product for UVM verification that can improve the efficiency of access verification and address the aforementioned technical problems.

[0005] Firstly, this application provides a request comparison method used in UVM verification. The method includes:

[0006] Create a transaction class corresponding to the storage access operation;

[0007] Based on the transaction class, generate an instance message for the storage access operation and store the instance message in the desired queue;

[0008] If the storage access request message to be compared meets the protocol conditions and design specifications, the storage access request message is compared with the instance message in the expected queue to obtain the comparison result of the storage access request message; the comparison process includes start address comparison process and message length comparison process; the comparison result is used to determine the access verification result of the storage access request message.

[0009] In one embodiment, the process of comparing the storage access request message with the instance messages in the expected queue to obtain the comparison result of the storage access request message includes:

[0010] The storage access request message is compared with the instance message in the expected queue using the starting address comparison process to obtain the starting address comparison result of the storage access request message;

[0011] The storage access request message is compared with the instance message in the expected queue to obtain the message length comparison result of the storage access request message.

[0012] Based on the comparison results of the starting address and the comparison results of the message length, the comparison result of the storage access request message is determined.

[0013] In one embodiment, determining the comparison result of the storage access request message based on the starting address comparison result and the message length comparison result includes:

[0014] If the start address comparison result indicates that the start address of the storage access request message is the same as the start address of the instance message in the expected queue, and the message length comparison result indicates that the message length of the storage access request message is less than or equal to the message length of the instance message in the expected queue, then the comparison result of the storage access request message is confirmed as a successful comparison.

[0015] In one embodiment, after confirming that the comparison result of the storage access request message is successful, the method further includes:

[0016] The instance packets in the expected queue are reduced in length to correspond to the packet length of the storage access request packet.

[0017] If the instance message information is not found in the expected queue, the access verification result of the storage access request message is confirmed as successful.

[0018] If the instance message information exists in the expected queue, wait to obtain the next new storage access request message.

[0019] In one embodiment, before comparing the storage access request message to be compared with the instance messages in the expected queue to obtain the comparison result of the storage access request message, provided that the storage access request message meets the protocol conditions and design specifications, the method further includes:

[0020] Obtain the storage access request message;

[0021] The storage access request message is processed to detect the protocol conditions, and the protocol detection result of the storage access request message is obtained.

[0022] If the protocol detection result indicates that the storage access request message does not meet the protocol conditions, it is confirmed that the storage access request message contains an error.

[0023] In one embodiment, after performing the protocol condition detection processing on the storage access request message to obtain the protocol detection result of the storage access request message, the method further includes:

[0024] If the protocol detection result indicates that the storage access request message meets the protocol conditions, the storage access request message is subjected to the design specification condition detection processing to obtain the design specification detection result of the storage access request message;

[0025] If the design specification test result indicates that the storage access request message does not meet the design specification conditions, then it is confirmed that the storage access request message contains an error.

[0026] Secondly, this application also provides a request comparison device used in UVM verification. The device includes:

[0027] The transaction creation module is used to create transaction classes corresponding to storage access operations;

[0028] The message generation module is used to generate an instance message for the storage access operation based on the transaction class, and store the instance message into the desired queue.

[0029] The message comparison module is used to compare the storage access request message with the instance messages in the expected queue when the storage access request message to be compared meets the protocol conditions and design specifications, and to obtain the comparison result of the storage access request message; the comparison process includes start address comparison processing and message length comparison processing; the comparison result is used to determine the access verification result of the storage access request message.

[0030] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to perform the following steps:

[0031] Create a transaction class corresponding to the storage access operation;

[0032] Based on the transaction class, generate an instance message for the storage access operation and store the instance message in the desired queue;

[0033] If the storage access request message to be compared meets the protocol conditions and design specifications, the storage access request message is compared with the instance message in the expected queue to obtain the comparison result of the storage access request message; the comparison process includes start address comparison process and message length comparison process; the comparison result is used to determine the access verification result of the storage access request message.

[0034] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, performs the following steps:

[0035] Create a transaction class corresponding to the storage access operation;

[0036] Based on the transaction class, generate an instance message for the storage access operation and store the instance message in the desired queue;

[0037] If the storage access request message to be compared meets the protocol conditions and design specifications, the storage access request message is compared with the instance message in the expected queue to obtain the comparison result of the storage access request message; the comparison process includes start address comparison process and message length comparison process; the comparison result is used to determine the access verification result of the storage access request message.

[0038] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, performs the following steps:

[0039] Create a transaction class corresponding to the storage access operation;

[0040] Based on the transaction class, generate an instance message for the storage access operation and store the instance message in the desired queue;

[0041] If the storage access request message to be compared meets the protocol conditions and design specifications, the storage access request message is compared with the instance message in the expected queue to obtain the comparison result of the storage access request message; the comparison process includes start address comparison process and message length comparison process; the comparison result is used to determine the access verification result of the storage access request message.

[0042] The aforementioned request comparison method, apparatus, computer device, computer-readable storage medium, and computer program product applied in UVM verification create a transaction class corresponding to the storage access operation; based on the transaction class, generate an instance message of the storage access operation and store the instance message in an expectation queue; if the storage access request message to be compared meets the protocol conditions and design specifications, compare the storage access request message with the instance message in the expectation queue to obtain the comparison result of the storage access request message; the comparison process includes start address comparison processing and message length comparison processing; the comparison result is used to determine the access verification result of the storage access request message. This scheme, by creating a transaction class corresponding to the storage access operation and generating an instance message based on the transaction class and storing it in the expectation queue, is conducive to establishing standard expected access behavior; by comparing the start address and message length of the storage access request message to be compared with the instance message in the expectation queue, it is conducive to timely verification of the correctness of the storage access request message, thereby improving the efficiency of access verification while ensuring the accuracy of access verification. Attached Figure Description

[0043] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0044] Figure 1 This is a flowchart illustrating a request comparison method used in UVM verification in one embodiment;

[0045] Figure 2 This is a schematic diagram of the architecture of the verification platform in one embodiment;

[0046] Figure 3 This is a schematic diagram of the address range distribution in one embodiment;

[0047] Figure 4 This is a structural block diagram of a request comparison device used in UVM verification in one embodiment;

[0048] Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0049] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0050] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0051] In one exemplary embodiment, such as Figure 1 As shown, a request comparison method applied in UVM verification is provided. In this embodiment, the method includes the following steps:

[0052] Step S101: Create a transaction class corresponding to the storage access operation.

[0053] Step S102: Based on the transaction class, generate an instance message for the storage access operation and store the instance message in the expected queue.

[0054] Step S103: If the storage access request message to be compared meets the protocol conditions and design specifications, the storage access request message is compared with the instance messages in the expected queue to obtain the comparison result of the storage access request message. The comparison process includes start address comparison process and message length comparison process. The comparison result is used to determine the access verification result of the storage access request message.

[0055] UVM stands for Universal Verification Methodology, a verification platform development architecture based on the System Verilog library, applied in integrated circuit digital front-end design.

[0056] Among them, storage access operations can be read or write operations performed on the memory. For example, storage access operations can be read or write operations performed on local storage by RDMA (Remote Direct Data Access).

[0057] Among them, the transaction class can be a UVM (General Verification Methodology) transaction class used to describe information related to storage access operations. For example, the transaction class can be a spec_trans (specification transaction) class containing information such as address, length, and data.

[0058] Among them, the instance message can be the expected operation information generated based on the transaction class. For example, the instance message can be a message generated by the reference model component based on the spec_trans class, containing information such as the expected address, length, and data.

[0059] The expected queue can be a queue structure used to store instance messages. For example, the expected queue can be a queue in the scoreboard component that stores expected spec_trans messages.

[0060] Among them, the storage access request message can be a request message that actually performs storage access, such as a PCIe memwr / memrd (memory write / read) message.

[0061] Among them, protocol conditions can be the specifications and requirements stipulated by the communication protocol. For example, protocol conditions can be the message format requirements of the PCIe (Peripheral Component Interconnection Standard) protocol.

[0062] Among them, design specifications can be the technical requirements specified during the equipment design. For example, design specifications can be the DUT (Device Under Test) requirements for parameters such as the requester ID.

[0063] The comparison process can be a comparison operation between the storage access request message and the instance message. For example, the comparison process can be a matching check of the start address and length of the message.

[0064] The comparison result can be a verification conclusion obtained through comparison processing. For example, the comparison result can be a verification result used to determine whether the storage access request message meets the expectations.

[0065] Optionally, the terminal (or verification platform) first creates a transaction class corresponding to the storage access operation. This transaction class inherits from a UVM (General Verification Methodology) class and contains key information fields such as address, length, and type. The terminal's reference model component generates a corresponding instance message for each storage access operation based on this transaction class. This instance message contains the expected starting address and access length information. The model (reference model) component transmits the instance message to the scoreboard component via TLM (Transaction Modeling) communication and stores it in the expectation queue. When the terminal receives the storage access request message to be compared, the scoreboard component first checks whether the storage access request message conforms to the message format requirements specified by the PCIe (Peripheral Component Interconnect) protocol and whether it meets the design specifications of the DUT (Device Under Test), such as whether parameters like the requester ID are correct. After passing the above checks, the scoreboard component compares the storage access request message with the instance message in the expectation queue. Specifically, it checks whether the starting address of the storage access request message matches the starting address of the instance message and whether the length of the storage access request message does not exceed the expected length in the instance message, thereby obtaining the comparison result of the storage access request message.

[0066] For example, when a terminal needs to verify an RDMA (Remote Direct Data Access) operation, the terminal first creates a transaction class of type spec_trans containing information such as address and length. When the RDMA operation begins, the reference model component generates an instance message of length B bytes, expecting to access local storage address A, based on the transaction class, and passes this instance message to the expected queue of the scoreboard component via uvm_analysis_port. When the DUT (Device Under Test) generates the actual PCIe... When a memwr / memrd (memory write / read) request message is sent, the scoreboard component first verifies whether the request message complies with the maximum length limit and other specifications of the PCIe (Peripheral Component Interconnect Standard) protocol, and whether it meets the design specifications of the DUT (Device Under Test). Then, the request message is compared with the instance messages in the expected queue. It checks whether the starting address of the request message is equal to address A, and whether the length of the request message does not exceed length B. If the comparison result meets the expectations, the instance message is updated or removed accordingly based on the actual length of the request message, so as to facilitate subsequent comparison processing.

[0067] The request comparison method described above for UVM verification involves creating a transaction class corresponding to the storage access operation; generating an instance message for the storage access operation based on the transaction class and storing the instance message in the expectation queue; and comparing the storage access request message to be compared with the instance message in the expectation queue if the storage access request message meets the protocol and design specifications. The comparison process includes starting address comparison and message length comparison. The comparison result is used to determine the access verification result of the storage access request message. This scheme, by creating a transaction class corresponding to the storage access operation and generating an instance message based on this transaction class and storing it in the expectation queue, facilitates the establishment of standard expected access behavior. By comparing the starting address and message length of the storage access request message to be compared with the instance message in the expectation queue, it facilitates timely verification of the correctness of the storage access request message, thereby improving the efficiency of access verification while ensuring accuracy.

[0068] In an exemplary embodiment, the storage access request message is compared with the instance messages in the expected queue to obtain the comparison result of the storage access request message. Specifically, this includes: comparing the starting address of the storage access request message with the instance messages in the expected queue to obtain the starting address comparison result of the storage access request message; comparing the message length of the storage access request message with the instance messages in the expected queue to obtain the message length comparison result of the storage access request message; and determining the comparison result of the storage access request message based on the starting address comparison result and the message length comparison result.

[0069] The start address comparison process can be a matching check operation performed on the start address of the storage access request message and the start address of the instance message in the expected queue. For example, the start address comparison process can be an operation to check whether the start address of the PCIememwr / memrd (memory write / read) message is the same as the start address of the spec_trans message in the expected queue.

[0070] The message length comparison process can be a matching check operation between the length of the storage access request message and the length of the instance message in the expected queue. For example, the message length comparison process can be an operation to check whether the length of the PCIe memwr / memrd (memory write / read) message does not exceed the length of the spec_trans message in the expected queue.

[0071] The starting address comparison result can be the address matching status obtained through starting address comparison processing. For example, the starting address comparison result can be the result indicating whether the starting address of the storage access request message is the same as the starting address of the instance message in the expected queue.

[0072] The message length comparison result can be the length matching situation obtained through message length comparison processing. For example, the message length comparison result can be the result indicating whether the length of the storage access request message does not exceed the length of the instance message in the expected queue.

[0073] Optionally, after receiving a storage access request message to be compared, the terminal's scoreboard component first performs a start address comparison process with the first instance message in the expectation queue to check whether the start address of the storage access request message is exactly the same as the start address of the instance message, thus obtaining the start address comparison result of the storage access request message; then, it performs a message length comparison process with the first instance message in the expectation queue to check whether the length of the storage access request message does not exceed the remaining uncompared length in the instance message, thus obtaining the message length comparison result of the storage access request message; finally, it determines the comparison result of the storage access request message based on the start address comparison result and the message length comparison result. If both the start address comparison result and the message length comparison result are successful, the compared length information of the instance messages in the expectation queue is updated. When all lengths of the instance messages have been compared, the instance message is removed from the expectation queue.

[0074] The technical solution provided in this embodiment compares the starting address and message length of the storage access request message with the instance message in the expected queue, which helps to verify the correctness of the storage access request message from both the address and length dimensions. By combining the starting address comparison result and the message length comparison result to determine the final comparison result, it is beneficial to comprehensively judge the correctness of the storage access request message, thereby facilitating accurate verification of whether the storage access request message meets the expected access requirements.

[0075] In an exemplary embodiment, the comparison result of the storage access request message is determined based on the start address comparison result and the message length comparison result. Specifically, this includes the following: if the start address comparison result indicates that the start address of the storage access request message is the same as the start address of the instance message in the expected queue, and the message length comparison result indicates that the message length of the storage access request message is less than or equal to the message length of the instance message in the expected queue, then the comparison result of the storage access request message is confirmed as a successful comparison.

[0076] A successful comparison can be a verification result indicating that the storage access request message meets the expected access requirements. For example, a successful comparison can be a result indicating that the start address and message length of the PCIe memwr / memrd (memory write / read) message both meet the requirements of the spec_trans message in the expected queue.

[0077] Optionally, after obtaining the start address comparison result and message length comparison result of the storage access request message, the terminal's scoreboard component first checks whether the start address comparison result of the storage access request message indicates that the start address of the storage access request message is exactly the same as the start address of the instance message in the expected queue. Then, it checks whether the message length comparison result of the storage access request message indicates that the message length of the storage access request message is less than or equal to the message length of the instance message in the expected queue. When both of the above conditions are met, the scoreboard component confirms that the comparison result of the storage access request message is a successful comparison, and updates the compared length information of the instance message in the expected queue according to the actual length of the storage access request message. When all lengths of the instance message have been compared, the instance message is removed from the expected queue.

[0078] The technical solution provided in this embodiment ensures the accuracy of storage access from both address and length dimensions by performing a complete match between the starting address of the storage access request message and the starting address of the instance message in the expected queue, and by ensuring that the message length of the storage access request message does not exceed the limit. By requiring that both the starting address and the message length not exceed the limit be met for a successful match, the accuracy of storage access is improved, thereby facilitating accurate verification of whether the storage access request message meets the expected access requirements.

[0079] In an exemplary embodiment, after confirming that the comparison result of the storage access request message is successful, the following steps are also included: performing a deletion process on the instance messages in the expectation queue corresponding to the message length of the storage access request message; if there is no instance message information in the expectation queue, confirming that the access verification result of the storage access request message is successful; if there is instance message information in the expectation queue, waiting to obtain the next new storage access request message.

[0080] The deletion process can be an operation that updates the length of instance packets in the expectation queue. For example, the deletion process can be to subtract the length of the PCIe memwr / memrd (memory write / read) packets that have been compared from the length of the spec_trans packets in the expectation queue, or to directly delete the instance packets from the expectation queue when the length of the instance packets is equal to the length of the storage access request packets.

[0081] The message information can be the content in the instance message in the expected queue that has not yet been compared. For example, the message information can be the address and length information remaining in the spec_trans message that has not been compared by the PCIe memwr / memrd (memory write / read) message.

[0082] The access verification result can be a result representing the overall verification status of the storage access request message. For example, the access verification result can be a result representing whether the PCIe memwr / memrd (memory write / read) message fully meets the expected access requirements of the spec_trans message in the expected queue.

[0083] Successful access verification can be a verification status that indicates the storage access request message fully meets the expected access requirements. For example, successful access verification can be a status that indicates the PCIe memwr / memrd (memory write / read) message fully matches the expected access requirements of the spec_trans message in the expected queue, and there are no spec_trans messages in the expected queue that have not been matched.

[0084] Optionally, after confirming that the comparison result of the storage access request message is successful, the terminal's scoreboard component first performs a reduction process on the instance messages in the expectation queue based on the message length of the storage access request message. If the message length of the storage access request message is equal to the message length of the instance messages in the expectation queue, the instance messages in the expectation queue are directly deleted. If the message length of the storage access request message is less than the message length of the instance messages in the expectation queue, the message length of the storage access request message is subtracted from the message length of the instance messages in the expectation queue. Then, it checks whether there is still instance message information in the expectation queue. If there is no instance message information in the expectation queue, the access verification result of the storage access request message is confirmed as successful. If there is instance message information in the expectation queue, it waits to obtain the next new storage access request message for comparison processing.

[0085] The technical solution provided in this embodiment, by reducing the length of instance packets in the expectation queue to correspond to the length of the storage access request packet, facilitates dynamic updating of the expectation queue's state; by checking whether instance packet information exists in the expectation queue and performing different processing operations based on the check results, it facilitates accurate determination of the storage access request's verification status; thus, it facilitates the complete verification of the storage access request.

[0086] In an exemplary embodiment, before comparing the storage access request message with the instance messages in the expected queue to obtain the comparison result of the storage access request message, if the storage access request message to be compared meets the protocol conditions and design specifications, the following steps are also included: obtaining the storage access request message; performing protocol condition detection processing on the storage access request message to obtain the protocol detection result of the storage access request message; if the protocol detection result indicates that the storage access request message does not meet the protocol conditions, confirming that there is an error in the storage access request message.

[0087] The protocol conditions can be the PCIe protocol's specification requirements for storage access request messages. For example, the protocol conditions can be the PCIe protocol's requirement that the maximum length of memwr / memrd (memory write / read) messages not exceed 4KB.

[0088] Among them, the design specifications can be the specification requirements of the DUT design for storage access request messages. For example, the design specifications can be the requirements of the DUT design for parameters such as the requester ID of PCIe memwr / memrd (memory write / read) messages.

[0089] The protocol detection result can be a check result indicating whether the storage access request message conforms to the PCIe protocol requirements. For example, the protocol detection result can be a check result indicating whether the length of the PCIe memwr / memrd (memory write / read) message exceeds 4KB.

[0090] The protocol condition detection process can be a process of checking the PCIe protocol compliance of the storage access request message. For example, the protocol detection process can be a process of checking the length of the PCIe memwr / memrd (memory write / read) message to no more than 4KB.

[0091] Optionally, after receiving a storage access request message, the terminal's scoreboard component first performs PCIe protocol condition checks on the storage access request message, including checking whether the message length exceeds the 4KB limit specified by the PCIe protocol and whether the message format conforms to the PCIe protocol specification requirements. Then, it performs design specification condition checks on the storage access request message, including checking whether the requester ID of the storage access request message conforms to the DUT design specification requirements and whether other parameters of the storage access request message meet the DUT design specification requirements. If the protocol check result of the storage access request message indicates that the storage access request message does not conform to the PCIe protocol conditions, the terminal's scoreboard component confirms that there is an error in the storage access request message and terminates the subsequent comparison processing.

[0092] The technical solution provided in this embodiment detects protocol conditions in the storage access request message before comparing it with the instance message in the expected queue. This helps to detect errors in the storage access request message that do not meet the protocol conditions as early as possible. By directly confirming the error when the protocol detection result indicates that the storage access request message does not meet the protocol conditions, it helps to prevent incorrect storage access request messages from entering the subsequent comparison process. This helps to improve the accuracy and efficiency of storage access request message verification.

[0093] In an exemplary embodiment, after performing protocol condition detection processing on the storage access request message to obtain the protocol detection result of the storage access request message, the following steps are also included: if the protocol detection result indicates that the storage access request message meets the protocol conditions, performing design specification condition detection processing on the storage access request message to obtain the design specification detection result of the storage access request message; if the design specification detection result indicates that the storage access request message does not meet the design specification conditions, it is confirmed that there is an error in the storage access request message.

[0094] The design specification test result can be a check result indicating whether the storage access request message conforms to the DUT design specification requirements. For example, the design specification test result can be a check result indicating whether the requester ID of the PCIe memwr / memrd (memory write / read) message is within the range allowed by the DUT design.

[0095] The design specification detection process can be a process of checking the DUT design specification requirements of the storage access request message. For example, the design specification detection process can be a process of checking whether the requester ID of the PCIe memwr / memrd (memory write / read) message is within the range allowed by the DUT design.

[0096] Optionally, after the terminal's scoreboard component performs PCIe protocol condition detection on the storage access request message and obtains the protocol detection result, if the protocol detection result indicates that the storage access request message conforms to the PCIe protocol conditions, the terminal's scoreboard component continues to perform DUT design specification condition detection on the storage access request message, including checking whether the requester ID of the storage access request message is within the range allowed by the DUT design, and checking whether other parameters of the storage access request message meet the requirements of the DUT design specifications, to obtain the design specification detection result of the storage access request message; if the design specification detection result indicates that the storage access request message does not conform to the DUT design specifications, the terminal's scoreboard component confirms that there is an error in the storage access request message and terminates the subsequent comparison processing process.

[0097] The technical solution provided in this embodiment performs design specification condition detection only when the protocol detection result indicates that the storage access request message meets the protocol conditions. This helps to avoid invalid design specification detection for storage access request messages that do not meet the protocol conditions. Furthermore, by directly confirming the error when the design specification detection result indicates that the storage access request message does not meet the design specification conditions, it helps to promptly detect specification errors in the storage access request message, thereby improving the efficiency and accuracy of storage access request message verification.

[0098] The following application example illustrates the request comparison method provided in this application for UVM verification. This application example uses the method applied to a terminal (or verification platform) as an example.

[0099] This application example can be a PCIe (Peripheral Component Interconnect Standard) request comparison method used in RDMA (Remote Direct Data Access) UVM (General Verification Methodology) verification.

[0100] Definitions:

[0101] PCIe (Peripheral Component Interconnect Standard): A high-speed serial computer expansion bus standard.

[0102] memory write / memory read: A transaction layer operation type defined in the PCIe (Peripheral Component Interconnect) protocol.

[0103] UVM (Universal Verification Methodology) is a verification platform development architecture based on the System Verilog library, widely used in integrated circuit digital front-end design.

[0104] env (environment) / reference model / scoreboard / agent: Components defined by UVM (Generalized Validation Methodology).

[0105] TLM (Transaction Level Modeling) is a component communication method defined in UVM (Generalized Verification Methodology).

[0106] uvm_analysis_port / uvm_analysis_imp (analysis port / analysis implementation): A port type used in TLM (Transaction Modeling) communication, corresponding to output / input ports respectively.

[0107] This application example relates to the field of integrated circuit verification, and in particular to the functional verification of PCIe (Peripheral Component Interconnect Standard) requests for data transfer purposes.

[0108] A schematic diagram of a common verification platform based on the UVM (Universal Verification Methodology) architecture is provided. Figure 2 . Figure 2 A schematic diagram of the architecture of a verification platform is shown, which includes the following components: Env (environment) component, DUT (device under test) component, Agent_0 (agent 0) component, Agent_1 (agent 1) component, Reference Model (reference model) component, and Scoreboard (scoreboard) component.

[0109] The UVM (Universal Verification Methodology) architecture uses agent components to control the DUT (Device Under Test) bus, driving / sampling data timing on the bus. In a DUT design, there are often multiple buses, thus requiring multiple agent components. The reference model component simulates the DUT behavior, generating expected results, which are then sent to the scoreboard for automatic result comparison. The scoreboard component organizes the actual results from the DUT and compares them with the expected results from the reference model component to check whether the DUT behavior meets the design requirements.

[0110] During the simulation, the actual and the expected results belong to two different paths.

[0111] The actual result path is as follows: the sequence is generated and sent to the agent_0 component; the agent_0 component converts it into an input bus data stream defined by the DUT (Device Under Test) and drives it to the DUT; the DUT receives the data stream, generates the actual result, and outputs the data stream onto the bus; the result output data stream on the bus is sampled by the agent_1 component and converted into a transaction message; the agent_1 component passes the transaction message to the scoreboard component; the scoreboard component receives the actual transaction message, searches for and compares it with the expected message.

[0112] The expected path is as follows: a sequence is generated and sent to the agent_0 component; the agent_0 component converts it into an input bus data stream defined by the DUT (Device Under Test) and drives it to the DUT; the agent_0 component samples this input bus data stream and converts it into a transaction message; the agent_0 component passes the transaction message to the reference model component; the reference model component generates the expected output transaction message based on the input transaction message; the reference model component delivers the expected transaction message to the scoreboard component and waits to be compared.

[0113] RDMA (Remote Direct Data Access) is a type of remote direct data access operation. Simply put, its function is to update data in local storage to remote storage, or vice versa. In the RDMA bus, access to remote storage is achieved via Ethernet; access to local storage is typically achieved via the PCIe (Peripheral Component Interconnect) bus due to its superior transmission efficiency.

[0114] The PCIe (Peripheral Component Interconnect) protocol defines a variety of transaction message types. The transaction message types used in RDMA (Remote Direct Data Access) for local storage access operations are mainly memory write / read operations (which can be simply referred to as memwr / memrd).

[0115] Verifying RDMA (Remote Direct Data Access) using the UVM (Universal Verification Methodology) architecture involves two agent components: an Ethernet agent and a PCIe (Peripheral Component Interconnect Standard) agent. It also involves simulating RDMA functionality using a reference model component and comparing results on both the Ethernet and PCIe sides using a scoreboard component.

[0116] For RDMA (Remote Direct Data Access) operations, there is no requirement for the maximum number of bytes accessed in a single RDMA operation. However, for PCIe (Peripheral Component Interconnect) memwr / memrd (memory write / read) packets, the maximum packet length specified by the PCIe protocol is no more than 4KB. Therefore, RDMA DUTs (Device Under Test) involve packet segmentation for single RDMA operations to reduce the number of bytes accessed in a single Ethernet packet on the Ethernet side and a single memwr / memrd (memory write / read) packet on the PCIe side.

[0117] This application example primarily addresses PCIe (Peripheral Component Interconnect Standard) side memwr / memrd (memory write / read) packets. This is because, in the actual implementation of the DUT (Device Under Test), the packet segmentation logic for the number of bytes accessed in a single memwr / memrd (memory write / read) packet on the PCIe side is more complex, such as:

[0118] 1. When supporting a maximum of 4KB for a single PCIe (Peripheral Component Interconnect) memwr / memrd (memory write / read) message, it was found that, because the entire chip design includes other services besides RDMA (Remote Direct Data Access) that require the use of the PCIe bus, testing revealed that in certain scenarios, the maximum 4KB maximum PCIe memwr / memrd (memory write / read) message size for RDMA services could cause an imbalance in bandwidth allocation with other services. Therefore, the maximum message size for a single PCIe memwr / memrd (memory write / read) message size for RDMA services was reduced.

[0119] 2. In RDMA (Remote Direct Data Access) services, there is a concept of QPs (Queue Pairs), each of which can be linked to a separate remote storage. To prevent a single QP from occupying the entire RDMA for an extended period, causing other QPs to become blocked, a scheduling cycle is introduced. Only one QP operates within each scheduling cycle, and all QPs use the scheduling cycle in a round-robin fashion. Within a single scheduling cycle, multiple RDMA operations may be involved. However, since there is no maximum number of bytes accessed per RDMA operation, for example, the first three RDMA operations might each access less than 100 bytes of storage, while the fourth RDMA operation might require accessing 100,000 bytes. If only the first three operations are placed in one scheduler, the QP (queue pair) will process too little data within that scheduling cycle, requiring waiting for the next scheduling cycle, thus degrading the performance of that QP (queue pair). If all four operations are placed in one scheduler, the QP (queue pair) will be occupied for too long within that scheduling cycle, impacting the performance of other QPs (queue pairs). Therefore, an upper limit is set on the number of bytes processed within each scheduling cycle, ensuring that the last RDMA (Remote Direct Data Access) operation is only partially executed, resulting in a breakpoint.

[0120] According to the UVM (Universal Verification Methodology) architecture, the reference model component needs to anticipate and generate each memwr / memrd (memory write / read) message so that it can be compared with the actual messages generated by the DUT (Device Under Test). However, due to the complex packet splitting logic and the fact that the reference model component cannot perceive the internal information of the DUT in real time, the expected memwr / memrd messages cannot be accurately generated. In the example above, with the same upper limit on the number of bytes processed within a single scheduling cycle, setting 100 bytes for the first three cycles and 120 bytes for the first three cycles will result in different numbers of local storage bytes accessible by the fourth RDMA (Remote Direct Data Access) operation within that cycle. Since the reference model component cannot perceive the internal information of the DUT in real time, the number of bytes in the last memwr / memrd message generated within that scheduling cycle will inevitably not match the actual behavior of the DUT.

[0121] Common UVM (Universal Verification Methodology) verification requires the reference model component to generate expected messages that perfectly correspond to the actual results. When applying this method to RDMA (Remote Direct Data Access) verification, on the PCIe (Peripheral Component Interconnect Standard) side, the reference model component is required to generate memwr / memrd (memory write / read) messages corresponding to the DUT (Device Under Test). In the above example, in the actual behavior of the DUT, since the reference model cannot perceive the internal state of the DUT in real time, and according to the UVM verification philosophy, it is not recommended that UVM components retrieve the internal state via hardwired connections. Therefore, when there is an unexpected breakpoint packet-splitting behavior at the breakpoint, the reference model component cannot accurately predict the number of bytes in the memwr / memrd (memory write / read) message. This behavior inevitably leads to automatic comparison errors by the scoreboard component.

[0122] In summary, a one-to-one matching of PCIe (Peripheral Component Interconnect Standard) memwr / memrd (Memory Write / Read) packets is an ideal processing operation, but it has unavoidable problems in the verification process of RDMA (Remote Direct Data Access) DUT (Device Under Test) with unpredictable timing design schemes such as breakpoints.

[0123] Compared to the detailed comparison schemes mentioned above, there is another relatively common result verification scheme. Since the essence of PCIe (Peripheral Component Interconnect Standard) memwr / memrd (memory write / read) messages is to read / write data from a certain address in local storage, based on the results, it is only necessary to check whether the data at the corresponding address has been taken away or written and updated after the RDMA (Remote Direct Data Access) operation is completed (the simulation ends) by checking the memory.

[0124] For example, an RDMA (Remote Direct Data Access) DUT (Device Under Test) needs to retrieve B bytes of data from a remote storage address A and then write this data into a contiguous block of addresses starting at local storage address C. Verification can be achieved by having the reference model not generate the expected message and the scoreboard no longer automatically compare the actual message; waiting for the RDMA DUT to complete the entire operation, and then accessing the data in the local storage address range C to C+B to check if this data matches the data in the remote address range A to A+B.

[0125] This result verification scheme can guarantee the correctness of results within the expected operation address range, but it carries risks. For example, if local address D is not within the local storage address range of C to C+B, the RDMA (Remote Direct Data Access) DUT (Device Under Test) may still produce erroneous writes. Using this checking method, it is impossible to accurately detect whether there are erroneous operations on irrelevant storage addresses, even if the probability of such an occurrence is extremely low.

[0126] Furthermore, because this approach requires waiting for the operation to complete before starting the check, it lacks timeliness. When multiple RDMA (Remote Direct Data Access) operations exist, if different RDMA operations have overlapping local storage addresses, it is impossible to verify that the address is correctly accessed in each RDMA operation.

[0127] In summary, the second result checking scheme is relatively crude and cannot guarantee that anomalies in extreme scenarios will be detected.

[0128] This application example addresses this specific scenario by providing a PCIe (Peripheral Component Interconnect Standard) request comparison method for RDMA (Remote Direct Data Access) UVM (General Verification Methodology) verification, to adapt to the unpredictable PCIe (Peripheral Component Interconnect Standard) memwr / memrd (Memory Write / Read) packet segmentation rules of RDMA (Remote Direct Data Access) DUT (Device Under Test).

[0129] This application example is based on the UVM (Universal Verification Methodology) architecture. Compared with the first comparison scheme, it can solve the problem of unpredictable PCIe (Peripheral Component Interconnect Standard) memwr / memrd (memory write / read) messages caused by the inability of the reference model component to synchronize the real-time information of the DUT (Device Under Test). Compared with the second comparison scheme, it can ensure the correctness of the operation sequence within the expected memory address range and confirm that there are no erroneous operations outside the expected addresses.

[0130] The following is a detailed description of this application example.

[0131] RDMA (Remote Direct Data Access) access to local storage essentially involves reading / writing data from a contiguous range of addresses within the local storage. This action is carried out via PCIe (Peripheral Component Interconnect) memwr / memrd (memory write / read) packets. Regardless of the packet segmentation rules for these memwr / memrd packets, the resulting packets can be concatenated using address and length information to achieve RDMA access to local storage. For example, if an RDMA operation aims to write data from local storage address A to length B (operation address A~A+B), regardless of how many memwr packets are segmented on the PCIe side, the result will satisfy the following requirements (see reference). Figure 3 :

[0132] 1. The address range corresponding to the address and length information of each message must be within the operation address range A to A+B;

[0133] 2. The address ranges corresponding to the address and length information of each message will not overlap;

[0134] 3. The concatenation result of the address ranges corresponding to the address and length information of all messages matches the operation address A~A+B exactly;

[0135] 4. The address following the end address of the address range of the previous message must be the start address of the address range of the next message.

[0136] Figure 3This diagram illustrates the address range distribution of multiple memory write packets within the expected RDMA (Remote Direct Data Access) address range. Within the entire expected RDMA address range, the address ranges memwr_0 (memory write_0), memwr_1 (memory write_1), memwr_2 (memory write_2), memwr_3 (memory write_3), memwr_4 (memory write_4), and memwr_5 (memory write_5) are distributed sequentially. These address ranges are arranged in order, do not overlap, and the end address of one address range is adjacent to the start address of the next. All these address ranges, in combination, completely cover the entire expected RDMA address range.

[0137] Therefore, this application example proposes a PCIe (Peripheral Component Interconnect Standard) request comparison method for RDMA (Remote Direct Data Access) UVM (General Verification Methodology) verification, which includes:

[0138] 1. Create a transaction class (short for spec_trans) that contains information such as address, length, and data related to local storage access for a single RDMA (Remote Direct Data Access) operation. It is a UVM (General Verification Methodology) transaction type, and therefore can be used in the UVM architecture, and can be transmitted between components through the TLM (Transaction Level Modeling) communication specific to UVM.

[0139] 2. The Reference Model component no longer generates expected memwr / memrd (memory write / read) messages corresponding to the DUT (Device Under Test). Instead, it generates instances of the local storage address, length, and data to be accessed by each individual RDMA (Remote Direct Data Access) operation using spec_trans. The Reference Model component includes the following operations:

[0140] 1) Create a uvm_analysis_port of type spec_trans (specification transaction) and instantiate it;

[0141] 2) When the DUT (Device Under Test) is expected to generate memwr / memrd (memory write / read) messages, the referencemodel instantiates a new spec_trans (specification transaction) and generates the expected spec_trans (specification transaction) message;

[0142] 3) Write the generated spec_trans (specification transaction) message into the corresponding uvm_analysis_port (analysis port).

[0143] 3. The Scoreboard component compares the actual PCIe (Peripheral Component Interconnect Standard) memwr / memrd (memory write / read) packets generated by the DUT (Device Under Test) with the spec_trans (specification transaction) instances. Because the actual PCIe memwr / memrd packets generated by the DUT and the spec_trans packets generated by the reference model differ in transaction type, address / length / data, etc., this comparison process cannot use the built-in comparison functions of UVM (Generalized Verification Methodology) and requires checking the contents of each field. The Scoreboard component includes the following operations:

[0144] 1) Create a uvm_analysis_imp port of type spec_trans (specification transaction) and instantiate it;

[0145] 2) Write the function corresponding to the uvm_analysis_imp port of type spec_trans (specification transaction) in order to obtain the expected spec_trans (specification transaction) message generated by the reference model and store it in the expected message queue;

[0146] 3) Write the function corresponding to the uvm_analysis_imp port of the PCIe (Peripheral Component Interconnect Standard) message type in order to obtain the actual PCIe (Peripheral Component Interconnect Standard) memwr / memrd (memory write / read) messages generated by the DUT (Device Under Test);

[0147] 4) When an actual PCIe (Peripheral Component Interconnect Standard) memwr / memrd (memory write / read) packet generated by the DUT (Device Under Test) is detected, the packets are compared. The specific process includes:

[0148] ① Check whether the memwr / memrd (memory write / read) message conforms to the PCIe (Peripheral Component Interconnect Standard) protocol. If it does not conform, it means that there is an error in the actual message.

[0149] ② Check whether the memwr / memrd (memory write / memory read) messages conform to the DUT (Device Under Test) design specifications, such as the requester ID. If they do not conform, it means that there is an error in the actual message.

[0150] ③ Check if there is a spec_trans (specification transaction) message in the expected message queue at this time. If there is no expected message, it means that the comparison has failed.

[0151] ④ Compare the memwr / memrd (memory write / read) message with the first spec_trans (specification transaction) message in the expected message queue. Based on the previous requirements, it can be determined that the starting address of the memwr / memrd (memory write / read) message must be the same as the starting address of the current spec_trans (specification transaction) message, and the length of the message must not be greater than the length of the current spec_trans (specification transaction) message. If they do not match, it means that the comparison has failed.

[0152] ⑤ If the aforementioned processes all pass, it means that the actual PCIe (Peripheral Component Interconnect Standard) memwr / memrd (memory write / read) message meets expectations. Afterwards, the expected spec_trans (specification transaction) message needs to be corrected for the next comparison operation. If the memwr / memrd (memory write / read) message and the expected spec_trans (specification transaction) message have the same length, the first spec_trans (specification transaction) message in the expected message queue is deleted, indicating that the expected message has completely detected the corresponding actual message. If they do not match, the expected spec_trans (specification transaction) message only needs to have a section of address / length / data information that passed the comparison subtracted, and then wait for the next actual message.

[0153] 4. Based on the preceding requirements, it can be concluded that when the entire simulation ends, regardless of the number of RDMA (Remote Direct Data Access) operations involved, the final comparison result in the scoreboard will be: all actual memwr / memrd (memory write / read) messages will find corresponding expected spec_trans (specification transaction) messages; all expected spec_trans (specification transaction) messages will be exhausted. If this condition is not met, it indicates that the overall comparison has failed.

[0154] 5. In the env component, implement the connection between the uvm_analysis_port of type spec_trans of the reference model component and the uvm_analysis_imp of type spec_trans of the scoreboard component.

[0155] There are two related technologies:

[0156] One approach involves the reference model component generating the expected PCIe (Peripheral Component Interconnect Standard) memwr / memrd (memory write / read) packets. The scoreboard component then compares the actual packets generated by the DUT (Device Under Test) with the expected packets generated by the reference model component; both are packets of the same transaction type. This comparison method is highly sophisticated. However, for specific DUT designs, the reference model component cannot anticipate special states within the DUT in real time, leading to expected packets that do not match reality. Therefore, the applicability of this technique is limited.

[0157] Another approach is to completely omit the reference model component from generating the expected message, and the scoreboard component does not compare the actual message generated by the DUT (Device Under Test). Instead, it judges the correctness of the result solely by checking the memory data after the simulation. This comparison scheme is very crude and cannot accurately identify erroneous accesses to irrelevant addresses by the DUT, easily leading to missed problems.

[0158] This application example proposes a novel PCIe (Peripheral Component Interconnect Standard) request comparison method in UVM (Universal Verification Methodology) verification, targeting the design characteristics of RDMA (Remote Direct Data Access) DUT (Device Under Test). Compared to the first related technique, it does not require the reference model component to pay attention to the special state of the DUT and can still generate relatively refined expected messages. Compared to the second related technique, it can accurately determine the DUT's erroneous access to irrelevant addresses and the valid access to relevant addresses. At the same time, it is also timely, and the actual messages of each DUT can be compared immediately after they are generated, without waiting for the simulation to end.

[0159] The relevant technologies in this application example are as follows:

[0160] 1. A new transaction class is proposed to simulate PCIe (Peripheral Component Interconnect Standard) side requests of RDMA (Remote Direct Data Access) DUT (Device Under Test).

[0161] 2. The reference model component no longer needs to generate PCIe (Peripheral Component Interconnect Standard) memwr / memrd (memory write / read) messages that completely correspond to the actual DUT (Device Under Test). Now, the reference model component only needs to generate a new transaction class instance message on its PCIe side for each RDMA (Remote Direct Data Access) operation.

[0162] 3. The Scoreboard component no longer compares two identical PCIe (Peripheral Component Interconnect Standard) memwr / memrd (memory write / read) messages, but now compares the actual PCIe memwr / memrd (memory write / read) message with the newly defined expected transaction class instance message.

[0163] In terms of the level of precision of the comparison method, this application example falls between the two related technologies. However, it effectively avoids the problem that the reference model component cannot monitor the internal state of the DUT (Device Under Test) in real time due to the unpredictable state of the DUT design. At the same time, it solves the problems of immediacy and completeness of the comparison in the coarse comparison scheme.

[0164] The comparison method described in this application example is not limited to RDMA (Remote Direct Data Access) scenarios, nor is it limited to PCIe (Peripheral Component Interconnect) protocol messages. A similar approach can be used to compare any operation involving consecutive address accesses.

[0165] The technical solution provided in this application example helps establish standard expected access behavior by creating a transaction class corresponding to the storage access operation and generating an instance message based on the transaction class and storing it in the expected queue. By comparing the starting address and message length of the storage access request message to be compared with the instance message in the expected queue, it is beneficial to verify the correctness of the storage access request message in a timely manner, thereby improving the efficiency of access verification while ensuring the accuracy of access verification.

[0166] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0167] Based on the same inventive concept, this application also provides a request comparison device for implementing the request comparison method for UVM verification described above. The solution provided by this device is similar to the implementation described in the above method. Therefore, the specific limitations of one or more request comparison device embodiments for UVM verification provided below can be found in the limitations of the request comparison method for UVM verification above, and will not be repeated here.

[0168] In one exemplary embodiment, such as Figure 4 As shown, a request comparison device for UVM verification is provided. The request comparison device 400 for UVM verification may include:

[0169] Transaction creation module 401 is used to create transaction classes corresponding to storage access operations;

[0170] The message generation module 402 is used to generate instance messages for storage access operations based on the transaction class and store the instance messages in the desired queue.

[0171] The message comparison module 403 is used to compare the storage access request message with the instance messages in the expected queue when the storage access request message to be compared meets the protocol conditions and design specifications, and to obtain the comparison result of the storage access request message. The comparison process includes start address comparison processing and message length comparison processing. The comparison result is used to determine the access verification result of the storage access request message.

[0172] In an exemplary embodiment, the message comparison module 403 is further configured to perform start address comparison processing on the storage access request message and the instance message in the expected queue to obtain the start address comparison result of the storage access request message; perform message length comparison processing on the storage access request message and the instance message in the expected queue to obtain the message length comparison result of the storage access request message; and determine the comparison result of the storage access request message based on the start address comparison result and the message length comparison result.

[0173] In an exemplary embodiment, the message comparison module 403 is further configured to confirm that the comparison result of the storage access request message is a successful comparison if the start address comparison result indicates that the start address of the storage access request message is the same as the start address of the instance message in the expected queue, and the message length comparison result indicates that the message length of the storage access request message is less than or equal to the message length of the instance message in the expected queue.

[0174] In an exemplary embodiment, the device 400 further includes: a result confirmation module, configured to perform deletion processing on instance messages in the expectation queue corresponding to the message length of the storage access request message; if there is no instance message information in the expectation queue, confirm that the access verification result of the storage access request message is successful; if there is instance message information in the expectation queue, wait to obtain the next new storage access request message.

[0175] In an exemplary embodiment, the device 400 further includes: a message acquisition module, configured to acquire a storage access request message; perform protocol condition detection processing on the storage access request message to obtain a protocol detection result of the storage access request message; and confirm that the storage access request message has an error if the protocol detection result indicates that the storage access request message does not meet the protocol conditions.

[0176] In an exemplary embodiment, the device 400 further includes: a message detection module, configured to perform design specification detection processing on the storage access request message to obtain a design specification detection result for the storage access request message if the protocol detection result indicates that the storage access request message meets the protocol conditions; and to confirm that there is an error in the storage access request message if the design specification detection result indicates that the storage access request message does not meet the design specification conditions.

[0177] The modules in the request comparison device used in UVM verification described above can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0178] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When executed by the processor, the computer program implements a request comparison method used in UVM verification. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0179] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0180] In one exemplary embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0181] In one exemplary embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above-described method embodiments.

[0182] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0183] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0184] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0185] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A request comparison method used in UVM verification, characterized in that, The method includes: Create a transaction class corresponding to the storage access operation; Based on the transaction class, generate an instance message for the storage access operation and store the instance message in the desired queue; If the storage access request message to be compared meets the protocol conditions and design specifications, the storage access request message is compared with the instance message in the expected queue by the starting address comparison process to obtain the starting address comparison result of the storage access request message. The message length of the storage access request message is compared with that of the instance message in the expected queue to obtain the message length comparison result of the storage access request message. If the start address comparison result indicates that the start address of the storage access request message is the same as the start address of the instance message in the expected queue, and the message length comparison result indicates that the message length of the storage access request message is less than or equal to the message length of the instance message in the expected queue, then the comparison result of the storage access request message is confirmed as a successful comparison. The instance packets in the expected queue are reduced in length to correspond to the packet length of the storage access request packet. If the instance message information is not found in the expected queue, the access verification result of the storage access request message is confirmed as successful. If the instance message information exists in the expected queue, wait to obtain the next new storage access request message.

2. The method according to claim 1, characterized in that, The storage access operations include read or write operations performed on the memory.

3. The method according to claim 1, characterized in that, If the storage access request message to be compared meets the protocol conditions and design specifications, before performing a start address comparison process between the storage access request message and the instance message in the expected queue to obtain the start address comparison result of the storage access request message, the process further includes: Obtain the storage access request message; The storage access request message is processed to detect the protocol conditions, and the protocol detection result of the storage access request message is obtained. If the protocol detection result indicates that the storage access request message does not meet the protocol conditions, it is confirmed that the storage access request message contains an error.

4. The method according to claim 3, characterized in that, After performing the protocol condition detection processing on the storage access request message and obtaining the protocol detection result of the storage access request message, the method further includes: If the protocol detection result indicates that the storage access request message meets the protocol conditions, the storage access request message is subjected to the design specification condition detection processing to obtain the design specification detection result of the storage access request message; If the design specification test result indicates that the storage access request message does not meet the design specification conditions, then it is confirmed that the storage access request message contains an error.

5. A request comparison device used in UVM verification, characterized in that, The device includes: The transaction creation module is used to create transaction classes corresponding to storage access operations; The message generation module is used to generate an instance message for the storage access operation based on the transaction class, and store the instance message into the desired queue. The message comparison module is used to, when the storage access request message to be compared meets the protocol conditions and design specifications, perform start address comparison processing on the storage access request message and the instance message in the expected queue to obtain the start address comparison result of the storage access request message; perform message length comparison processing on the storage access request message and the instance message in the expected queue to obtain the message length comparison result of the storage access request message; if the start address comparison result indicates that the start address of the storage access request message is the same as the start address of the instance message in the expected queue, and the message length comparison result indicates that the message length of the storage access request message is less than or equal to the message length of the instance message in the expected queue, then confirm that the comparison result of the storage access request message is successful. The result confirmation module is used to perform deletion processing on the instance message in the expected queue corresponding to the message length of the storage access request message; if the message information of the instance message does not exist in the expected queue, it confirms that the access verification result of the storage access request message is successful; if the message information of the instance message exists in the expected queue, it waits to obtain the next new storage access request message.

6. The apparatus according to claim 5, characterized in that, The apparatus further includes: a message acquisition module, configured to acquire the storage access request message; perform protocol condition detection processing on the storage access request message to obtain a protocol detection result of the storage access request message; and confirm that the storage access request message has an error if the protocol detection result indicates that the storage access request message does not conform to the protocol conditions.

7. The apparatus according to claim 6, characterized in that, The device further includes: a message detection module, configured to, when the protocol detection result indicates that the storage access request message conforms to the protocol conditions, perform the design specification condition detection processing on the storage access request message to obtain the design specification detection result of the storage access request message; and when the design specification detection result indicates that the storage access request message does not conform to the design specification conditions, confirm that the storage access request message has an error.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 4.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 4.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 4.

Images