Request comparison method applied to UVM verification

Abstract

The invention relates to a request comparison method and device applied to UVM verification, computer equipment, a computer readable storage medium and a computer program product, and can be applied to the technical field of computers. The method comprises the following steps: creating a transaction class corresponding to a storage access operation; generating an instance message for storing the access operation according to the transaction class, and storing the instance message into an expected queue; under the condition that the to-be-compared storage access request message meets the protocol condition and the design specification condition, 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 initial address comparison processing and message length comparison processing; the comparison result is used for determining an access verification result for storing the access request message. By adopting the method, the access verification efficiency can be improved.

Description

Technical Field

[0001] The present application relates to the field of integrated circuit technology, and in particular to a request comparison method, apparatus, computer equipment, computer-readable storage medium, and computer program product for use in UVM verification. Background Art

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

[0003] Traditional technology usually performs access verification by manually writing verification rules and manually checking access requests; however, access verification in this way requires a lot of manual processing time, resulting in low efficiency of access verification. Summary of the invention

[0004] Based on this, it is necessary to provide a request comparison method, device, computer equipment, computer-readable storage medium and computer program product used in UVM verification, which can improve the efficiency of access verification, in order to solve the above technical problems.

[0005] In a first aspect, the present application provides a request comparison method for use in UVM verification. The method comprises:

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

[0007] generating an instance message of the storage access operation according to the transaction class, and storing the instance message in an expected queue;

[0008] When the storage access request message to be compared meets the protocol conditions and the design specification conditions, the storage access request message is compared with the instance message in the expected queue to obtain a comparison result of the storage access request message; the comparison process includes a start address comparison process and a 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 comparing the storage access request message with the instance message in the expected queue to obtain the comparison result of the storage access request message includes:

[0010] Performing a start address comparison process on the storage access request message and the instance message in the expected queue to obtain a start address comparison result of the storage access request message;

[0011] Performing the message length comparison processing on the storage access request message and the instance message in the expected queue to obtain a message length comparison result of the storage access request message;

[0012] The comparison result of the storage access request message is determined according to the comparison result of the start address and the comparison result of the message length.

[0013] In one of the embodiments, determining the comparison result of the storage access request message according to the comparison result of the start address and the comparison result of the message length includes:

[0014] When the starting address comparison result indicates that the starting address of the storage access request message is the same as the starting 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, the comparison result of the storage access request message is confirmed to be a successful comparison.

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

[0016] Performing a deletion process corresponding to the message length of the storage access request message on the instance message in the expected queue;

[0017] In a case where the message information of the instance message does not exist in the expected queue, confirming that the access verification result of the storage access request message is that the access verification is successful;

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

[0019] In one of the embodiments, when the storage access request message to be compared meets the protocol conditions and the design specification conditions, the storage access request message is compared with the instance message in the expected queue, and before obtaining the comparison result of the storage access request message, the method further includes:

[0020] Obtaining the storage access request message;

[0021] Performing detection processing of the protocol condition on the storage access request message to obtain a protocol detection result of the storage access request message;

[0022] When the protocol detection result indicates that the storage access request message does not meet the protocol condition, it is confirmed that there is an error in the storage access request message.

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

[0024] In the case where the protocol detection result indicates that the storage access request message meets the protocol condition, performing detection processing of the design specification condition on the storage access request message to obtain a design specification detection result of the storage access request message;

[0025] When 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.

[0026] In a second aspect, the present application also provides a request comparison device for use in UVM verification. The device comprises:

[0027] A transaction creation module, used to create a transaction class corresponding to a storage access operation;

[0028] A message generation module, used for generating an instance message of the storage access operation according to the transaction class, and storing the instance message in an expected queue;

[0029] A message comparison module is used to compare the storage access request message to be compared with the instance message in the expected queue when the storage access request message meets the protocol conditions and design specification conditions, so as to obtain the comparison result of the storage access request message; the comparison process includes starting 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.

[0030] In a third aspect, the present application further provides a computer device. The computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the following steps when executing the computer program:

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

[0032] generating an instance message of the storage access operation according to the transaction class, and storing the instance message in an expected queue;

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

[0034] In a fourth aspect, the present application further provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the following steps are implemented:

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

[0036] generating an instance message of the storage access operation according to the transaction class, and storing the instance message in an expected queue;

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

[0038] In a fifth aspect, the present application further provides a computer program product. The computer program product includes a computer program, and when the computer program is executed by a processor, the following steps are implemented:

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

[0040] generating an instance message of the storage access operation according to the transaction class, and storing the instance message in an expected queue;

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

[0042] The request comparison method, device, computer equipment, computer readable storage medium and computer program product used in UVM verification create a transaction class corresponding to the storage access operation; according to the transaction class, generate an instance message of the storage access operation, and store the instance message in the expected queue; when the storage access request message to be compared meets the protocol conditions and design specification conditions, compare the storage access request message with the instance message in the expected queue to obtain the comparison result of the storage access request message; the comparison process includes starting 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. The scheme is conducive to establishing a 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 conducive to timely verifying the correctness of the storage access request message, thereby ensuring the accuracy of access verification while improving the efficiency of access verification. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related technologies, the drawings required for use in the embodiments or the related technical descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0044] Figure 1 It is a schematic flow diagram of a request comparison method used in UVM verification in one embodiment;

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

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

[0047] Figure 4 It is a structural flowchart of a request comparison device applied in UVM verification in one embodiment;

[0048] Figure 5 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0049] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present 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, stored data, displayed data, 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 relevant data must comply with relevant regulations.

[0051] In an exemplary embodiment, Figure 1 As shown, a request comparison method applied in UVM verification is provided. In the present embodiment, the method comprises the following steps:

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

[0053] Step S102: Generate an instance message of the storage access operation according to the transaction class, and store the instance message into the expected queue.

[0054] Step S103, when the storage access request message to be compared meets the protocol conditions and design specification conditions, 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 the starting address comparison process and the message length comparison process; the comparison result is used to determine the access verification result of the storage access request message.

[0055] Among them, UVM is Universal Verification Methodology, a verification platform development architecture based on the System Verilog (system verification language) library, which is used in the digital front-end design of integrated circuits.

[0056] The storage access operation may be a read or write operation performed on a memory, for example, the storage access operation may be a read or write operation performed on a local storage by RDMA (Remote Direct Data Access).

[0057] The transaction class may be a UVM (Universal Verification Methodology) transaction class for describing information related to storage access operations. For example, the transaction class may be a spec_trans (specification transaction) class including information such as address, length, and data.

[0058] The instance message may be expected operation information generated according to the transaction class. For example, the instance message may be a message containing expected address, length, data and other information generated by the reference model component based on the spec_trans class.

[0059] The expected queue may be a queue structure for storing instance messages, for example, the expected queue may be a queue for storing expected spec_trans messages in a scoreboard component.

[0060] The storage access request message may be a request message for actually performing storage access, for example, the storage access request message may be a PCIe memwr / memrd (memory write / read) message.

[0061] The protocol condition may be a specification requirement specified by a communication protocol, for example, the protocol condition may be a message format requirement of a PCIe (Peripheral Component Interconnect Express) protocol.

[0062] The design specification conditions may be technical requirements specified during device design. For example, the design specification conditions may be the DUT (device under test)'s provisions on parameters such as the requester ID.

[0063] The comparison process may be a comparison operation performed on the storage access request message and the instance message. For example, the comparison process may be a match check performed on the start address and length of the message.

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

[0065] Optionally, the terminal (or verification platform) first creates a transaction class corresponding to the storage access operation, which inherits from the UVM (Universal Verification Methodology) class and contains key information fields such as address, length, and type; the reference model component of the terminal generates a corresponding instance message for each storage access operation based on the transaction class, and the instance message contains the expected starting address and access length information, reference The model component passes the instance message to the scoreboard component through TLM (transaction-level modeling) communication and stores it in the expected queue; when the terminal receives the storage access request message to be compared, the scoreboard component first checks whether the storage access request message complies with the message format requirements specified in the PCIe (Peripheral Component Interconnect) protocol, and whether it meets the design specification requirements of the DUT (device under test), such as whether parameters such as 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 expected queue, specifically checking 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 the terminal needs to verify an RDMA (remote direct data access) operation, the terminal first creates a transaction class of the spec_trans type containing information such as address and length; when the RDMA (remote direct data access) operation starts to execute, the reference model component generates an instance message with an expected access to the local storage address A and a length of B bytes according to the transaction class, and passes the instance message to the expected queue of the scoreboard component through the 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 of the PCIe (Peripheral Component Interconnect) protocol and other specification requirements, and whether it meets the design specification requirements of the DUT (device under test). Then, the request message is compared with the instance message in the expected queue to check 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 is as expected, the instance message is updated or removed accordingly according to the actual length of the request message for subsequent comparison processing.

[0067] In the request comparison method used in UVM verification, a transaction class corresponding to the storage access operation is created; based on the transaction class, an instance message of the storage access operation is generated, and the instance message is stored in the expected queue; when the storage access request message to be compared meets the protocol conditions and the design specification conditions, 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 the start address comparison process and the message length comparison process; the comparison result is used to determine the access verification result of the storage access request message. The scheme is conducive to establishing a 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 start address and message length of the storage access request message to be compared with the instance message in the expected queue, it is conducive to timely verifying the correctness of the storage access request message, thereby ensuring the accuracy of access verification while improving the efficiency of access verification.

[0068] In an exemplary embodiment, a storage access request message is compared with an instance message in an expected queue to obtain a comparison result of the storage access request message, which specifically includes the following contents: a starting address comparison is performed on the storage access request message and the instance message in the expected queue to obtain a starting address comparison result of the storage access request message; a message length comparison is performed on the storage access request message and the instance message in the expected queue to obtain a message length comparison result of the storage access request message; and the comparison result of the storage access request message is determined based on the starting address comparison result and the message length comparison result.

[0069] Among them, the start address comparison processing can be a matching check operation 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 processing can be an operation of checking 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] Among them, the message length comparison processing 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 processing can be an operation of checking 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 start address comparison result may be an address match obtained through the start address comparison process. For example, the start address comparison result may be a result indicating whether the start address of the storage access request message is the same as the start address of the instance message in the expected queue.

[0072] The message length comparison result may be a length matching condition obtained through message length comparison processing. For example, the message length comparison result may be a 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 the storage access request message to be compared, the scoreboard component of the terminal first performs a starting address comparison process on the storage access request message and the first instance message in the expected queue, checks whether the starting address of the storage access request message is exactly the same as the starting address of the instance message, and obtains a starting address comparison result of the storage access request message; then performs a message length comparison process on the storage access request message and the first instance message in the expected queue, checks whether the length of the storage access request message does not exceed the remaining unmatched length in the instance message, and obtains a message length comparison result of the storage access request message; finally, the comparison result of the storage access request message is determined based on the starting address comparison result and the message length comparison result. If both the starting address comparison result and the message length comparison result are passed, the compared length information of the instance message in the expected queue is updated, and when all lengths of the instance message are compared, the instance message is removed from the expected queue.

[0074] The technical solution provided in this embodiment, by performing a starting address comparison and a message length comparison on the storage access request message with the instance message in the expected queue, is helpful to verify the correctness of the storage access request message from two dimensions: address and length; by combining the starting address comparison result and the message length comparison result to determine the final comparison result, it is helpful 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 starting address comparison result and the message length comparison result, which specifically includes the following contents: when the starting address comparison result indicates that the starting address of the storage access request message is the same as the starting 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, the comparison result of the storage access request message is confirmed to be a successful comparison.

[0076] Among them, the successful comparison can be a verification result indicating that the storage access request message meets the expected access requirements. For example, the successful comparison can be a result indicating that the starting 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 scoreboard component of the terminal 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, and then 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 two conditions are met, the scoreboard component confirms that the comparison result of the storage access request message is successful, 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, and when all lengths of the instance message are compared, the instance message is removed from the expected queue.

[0078] The technical solution provided in this embodiment helps to ensure the accuracy of storage access from two dimensions: address and length. This is beneficial to improving the accuracy of storage access by requiring that both the starting address and the message length not exceed the limit before the comparison is determined to be successful. This is beneficial to accurately verifying 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 contents are also included: performing deletion processing corresponding to the message length of the storage access request message on the instance message in the expected queue; in a case where the message information of the instance message does not exist in the expected queue, confirming that the access verification result of the storage access request message is successful access verification; in a case where the message information of the instance message exists in the expected queue, waiting to obtain the next new storage access request message.

[0080] Among them, the deletion processing can be an operation of updating the length of the instance message in the expected queue. For example, the deletion processing can be an operation of subtracting the length of the PCIe memwr / memrd (memory write / read) message that has been compared from the length of the spec_trans message in the expected queue, or directly deleting the instance message from the expected queue when the length of the instance message is equal to the length of the storage access request message.

[0081] The message information may be content in the instance message in the expected queue that has not yet been compared. For example, the message information may be 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 may be a result indicating an overall verification status of a storage access request message, for example, the access verification result may be a result indicating whether a PCIe memwr / memrd (memory write / read) message fully satisfies an expected access requirement of a spec_trans message in an expected queue.

[0083] Among them, successful access verification can be a verification status indicating that the storage access request message fully meets the expected access requirements. For example, successful access verification can be a status indicating that 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 is no spec_trans message in the expected queue that has not completed the comparison.

[0084] Optionally, after confirming that the comparison result of the storage access request message is successful, the scoreboard component of the terminal first deletes the instance message in the expected queue according to 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 message in the expected queue, the instance message in the expected queue is directly deleted. If the message length of the storage access request message is less than the message length of the instance message in the expected queue, the message length of the storage access request message is subtracted from the message length of the instance message in the expected queue. Then, it is checked whether there is still message information of the instance message in the expected queue. If there is no message information of the instance message in the expected queue, it is confirmed that the access verification result of the storage access request message is successful. If there is message information of the instance message in the expected queue, wait for obtaining the next new storage access request message for comparison processing.

[0085] The technical solution provided in this embodiment facilitates dynamic updating of the status of the expected queue by performing deletion processing on the instance message in the expected queue corresponding to the message length of the storage access request message; facilitates accurate judgment of the verification status of the storage access request by checking whether there is message information of the instance message in the expected queue and performing different processing operations according to the inspection result; thereby facilitates achieving complete verification of the storage access request.

[0086] In an exemplary embodiment, when the storage access request message to be compared meets the protocol conditions and the design specification conditions, the storage access request message is compared with the instance message in the expected queue, and before the comparison result of the storage access request message is obtained, the following contents 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; when 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 condition may be a normative requirement of the PCIe protocol for storage access request messages. For example, the protocol condition may be a requirement of the PCIe protocol that the maximum length of a memwr / memrd (memory write / read) message does not exceed 4KB.

[0088] The design specification condition may be a specification requirement of the DUT design for a storage access request message. For example, the design specification condition may be a requirement of the DUT design for parameters such as a requester ID of a PCIe memwr / memrd (memory write / read) message.

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

[0090] The detection and processing of the protocol conditions may be a process of performing a PCIe protocol compliance check on a storage access request message. For example, the protocol detection and processing may be a process of checking that the length of a PCIe memwr / memrd (memory write / read) message does not exceed 4KB.

[0091] Optionally, after obtaining the storage access request message, the scoreboard component of the terminal first performs a PCIe protocol condition detection process on the storage access request message, including checking whether the message length of the storage access request message exceeds the 4KB limit specified by the PCIe protocol, and checking whether the message format of the storage access request message complies with the specification requirements of the PCIe protocol; then, the storage access request message is detected and processed for design specification conditions, including checking whether the requester ID of the storage access request message complies with the requirements of the DUT design specifications, and checking whether other parameters of the storage access request message meet the requirements of the DUT design specifications; if the protocol detection result of the storage access request message indicates that the storage access request message does not comply with the PCIe protocol conditions, the scoreboard component of the terminal confirms that there is an error in the storage access request message, and terminates the subsequent comparison processing flow.

[0092] The technical solution provided in this embodiment helps to early discover errors in storage access request messages that do not meet protocol conditions by performing protocol condition detection on storage access request messages before comparing the storage access request messages with instance messages in the expected queue; helps to avoid incorrect storage access request messages from entering subsequent comparison processing procedures by directly confirming the error when the protocol detection result indicates that the storage access request message does not meet the protocol conditions; thereby 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 content is also included: when 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; when the design specification detection result indicates that the storage access request message does not meet the design specification conditions, confirming that there is an error in the storage access request message.

[0094] Among them, the design specification detection result can be a check result indicating whether the storage access request message meets the DUT design specification requirements. For example, the design specification detection 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] Among them, the detection processing of design specification conditions can be a process of checking the storage access request message for the DUT design specification requirements. For example, the design specification detection processing 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 scoreboard component of the terminal performs PCIe protocol condition detection and processing on the storage access request message and obtains the protocol detection result, if the protocol detection result indicates that the storage access request message meets the PCIe protocol condition, the scoreboard component of the terminal continues to perform DUT design specification condition detection and processing 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 specification, 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 DUT design specification condition, the scoreboard component of the terminal confirms that there is an error in the storage access request message and terminates the subsequent comparison processing flow.

[0097] The technical solution provided in this embodiment helps to avoid invalid design specification detection of storage access request messages that do not meet the protocol conditions by only performing detection and processing of design specification conditions when the protocol detection result indicates that the storage access request message meets the protocol conditions; and helps to promptly discover specification errors in the storage access request message 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, thereby helping to improve the efficiency and accuracy of storage access request message verification.

[0098] The following is an application example to illustrate the request comparison method used in UVM verification provided by this application. This application example uses the method applied to a terminal (which can also be a verification platform) as an example.

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

[0100] Glossary:

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

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

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

[0104] env (environment) / reference model (reference model) / scoreboard (scoreboard) / agent (agent): components defined by UVM (Universal Verification Methodology).

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

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

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

[0108] Common verification platform diagram reference based on UVM (Universal Verification Methodology) architecture Figure 2 . Figure 2 The diagram shows the architecture of a verification platform, 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] In the UVM (Universal Verification Methodology) architecture, agent components are used to control the DUT (device under test) bus and drive / sample the bus data timing. In a DUT (device under test) design, there are often multiple sets of buses, so there will be corresponding multiple agent components; the reference model component is used to simulate the DUT (device under test) behavior, generate the corresponding expected results, and send them to the scoreboard for automatic result comparison; the actual results from the DUT (device under test) are sorted through the scoreboard component and compared with the expected results from the reference model component to check whether the behavior of the DUT (device under test) meets the design requirements.

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

[0111] The path of the actual result is: sequence is generated and sent to the agent_0 component; the agent_0 component converts it into the input bus data stream defined by the DUT (device under test) and drives it to the DUT (device under test); the DUT (device under test) receives the data stream, generates the actual result, and outputs the data stream to the bus; the resulting 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 it and compares it with the expected message.

[0112] The path of the expected result is: sequence is generated and sent to the agent_0 component; the agent_0 component converts it into the input bus data stream defined by the DUT (device under test) and drives it to the DUT (device under test); the agent_0 component samples the 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 passes the expected transaction message to the scoreboard component and waits for comparison.

[0113] RDMA (Remote Direct Data Access) is a remote direct data access operation. Its function is to update the data in the local storage to the remote storage, or to update the data in the remote storage to the local storage. In the RDMA (Remote Direct Data Access) function bus, access to the remote storage needs to be achieved through Ethernet; access to the local storage is usually achieved by the PCIe (Peripheral Component Interconnect) bus due to its excellent transmission efficiency.

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

[0115] Verifying RDMA (remote direct data access) using UVM (Universal Verification Methodology) architecture involves two agent components, one is Ethernet agent, and the other is PCIe (Peripheral Component Interconnect) agent; it involves using reference model component to simulate RDMA (remote direct data access) function; it involves using scoreboard component to compare the results on Ethernet side and PCIe (Peripheral Component Interconnect) side respectively.

[0116] For RDMA (remote direct data access) access operations, there is no requirement for the maximum number of bytes accessed by a single RDMA (remote direct data access) access operation; however, for PCIe (Peripheral Component Interconnect Standard) memwr / memrd (memory write / read) messages, the maximum message length specified by the PCIe (Peripheral Component Interconnect Standard) protocol does not exceed 4KB. Therefore, the RDMA (remote direct data access) DUT (device under test) will involve packet cutting operations for a single RDMA (remote direct data access) access operation, reducing the number of bytes accessed by a single Ethernet message on the Ethernet side and a single memwr / memrd (memory write / read) message on the PCIe (Peripheral Component Interconnect Standard) side.

[0117] This application example is mainly proposed for memwr / memrd (memory write / read) messages on the PCIe (Peripheral Component Interconnect) side. Because in the actual DUT (Device Under Test) function implementation, the packet cutting logic of the access byte number of a single memwr / memrd (memory write / read) message on the PCIe (Peripheral Component Interconnect) side is more complicated, such as:

[0118] 1. When supporting a single PCIe (Peripheral Component Interconnect Standard) memwr / memrd (memory write / read) message with a maximum size of 4KB, it was found that in the design of the entire chip, in addition to the RDMA (remote direct data access) service, there are other services that need to use the PCIe (Peripheral Component Interconnect Standard) bus. Tests found that in some scenarios, the maximum size of a single PCIe (Peripheral Component Interconnect Standard) memwr / memrd (memory write / read) message of the RDMA (remote direct data access) service of 4KB will cause an imbalance in bandwidth allocation with other services. Therefore, the maximum size of a single PCIe (Peripheral Component Interconnect Standard) memwr / memrd (memory write / read) message of the RDMA (remote direct data access) service is lowered.

[0119] 2. In the RDMA (remote direct data access) service, there is the concept of QP (queue pair), and each QP (queue pair) can be linked to a separate remote storage. In order to avoid a single QP (queue pair) occupying the entire RDMA (remote direct data access) for a long time, resulting in the blocking of other QPs (queue pairs), the concept of scheduling cycle is proposed. Only one QP (queue pair) is operated in each scheduling cycle, and all QPs (queue pairs) poll using the scheduling cycle. In a scheduling cycle, multiple RDMA (remote direct data access) access operations may be involved, but since each RDMA (remote direct data access) access operation does not have a maximum number of bytes to access, For example: In the first three RDMA (remote direct data access) access operations, each access only accesses storage content within 100 bytes, but the fourth RDMA (remote direct data access) access operation needs to access 100,000 bytes. If only the first three operations are put into one schedule, the data processed by the QP (queue pair) in this scheduling cycle is too small, and it needs to wait for the next scheduling cycle, resulting in a decrease in the performance of this QP (queue pair); if all four operations are put into one schedule, the QP (queue pair) will occupy too long in this scheduling cycle, affecting the performance of other QPs (queue pairs). Therefore, the upper limit of the number of bytes processed in each scheduling cycle is set, and the last RDMA (remote direct data access) access operation will only be partially performed, resulting in a breakpoint.

[0120] According to the UVM (Universal Verification Methodology) architecture, the reference model component needs to generate each memwr / memrd (memory write / read) message in anticipation so that the actual message generated by the DUT (device under test) can be compared. However, due to the complex packet switching logic and the inability of the reference model component to perceive the internal information of the DUT (device under test) in real time, the expected memwr / memrd (memory write / read) message cannot be accurately generated. Taking the above example, when the upper limit of the number of bytes processed in the same single scheduling cycle is set to 100 bytes each for the first three times and 120 bytes each for the first three times, the number of local storage bytes that can be accessed by the fourth RDMA (remote direct data access) access operation in this cycle will be different. Since the reference model component cannot perceive the internal information of the DUT (device under test) in real time, the number of bytes of the last memwr / memrd (memory write / read) message generated in the scheduling cycle must not match the actual behavior of the DUT (device under test).

[0121] Common UVM (Universal Verification Methodology) verification requires the reference model component to generate expected messages that completely correspond to the actual results. When this method is applied 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 mode of the DUT (Device Under Test), since the reference model cannot perceive the internal state of the DUT (Device Under Test) in real time, according to the UVM (Universal Verification Methodology) verification concept, it is not recommended that the UVM (Universal Verification Methodology) component pull the internal state through hard wiring. Therefore, when there is a breakpoint packet cutting behavior that the reference model component cannot expect, at this breakpoint, the reference model component cannot accurately expect the number of bytes of the memwr / memrd (memory write / read) message, and this behavior will inevitably lead to an automatic comparison error of the scoreboard component.

[0122] In summary, a one-to-one correspondence between PCIe (Peripheral Component Interconnect) memwr / memrd (memory write / read) message comparison is an ideal processing operation, but there are unavoidable problems in the RDMA (remote direct data access) DUT (device under test) verification process with unpredictable timing design schemes such as breakpoints.

[0123] Compared with the above detailed comparison scheme, there is another relatively common result verification scheme. Since the essence of PCIe (Peripheral Component Interconnect) memwr / memrd (memory write / read) messages is to read / write data from a certain address in local storage, starting from the results, it is only necessary to check whether the data at the corresponding address is taken away or written and updated through memory checking after the RDMA (remote direct data access) operation is completed (simulation ends).

[0124] For example, the RDMA (remote direct data access) DUT (device under test) needs to take a data of length B bytes from the remote storage address A, and finally write this data to the continuous address starting from the local storage C. The verification method can be that the reference model does not generate the expected message, and the scoreboard no longer automatically compares the actual message; wait for the RDMA (remote direct data access) DUT (device under test) to complete the entire operation, and then check that the data in the local storage address C to C+B interval is consistent with the data in the remote address A to A+B interval by accessing the data.

[0125] This result verification scheme can ensure that the results within the expected operation address range are correct, but there are risks. For example, the local address D is not in the local storage address range from C to C+B, but the RDMA (remote direct data access) DUT (device under test) may produce an erroneous write. Using this inspection method, it is impossible to accurately check whether there is an erroneous operation at an irrelevant storage address, even though the probability of this phenomenon occurring is extremely low.

[0126] At the same time, because this solution needs to wait for the operation to be completed before starting the check, it is not timely. When there are multiple RDMA (remote direct data access) operations, if different RDMA (remote direct data access) operations have intersecting local storage addresses, it is impossible to verify that the address is correctly accessed in each RDMA (remote direct data access) operation.

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

[0128] Aiming at this special scenario, this application example provides a PCIe (Peripheral Component Interconnect) request comparison method used in RDMA (Remote Direct Data Access) UVM (Universal Verification Methodology) verification to adapt to the unexpected PCIe (Peripheral Component Interconnect) memwr / memrd (memory write / read) message packet cutting rules of the 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 unexpected PCIe (Peripheral Component Interconnect Standard) memwr / memrd (memory write / read) messages due to 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 of the expected storage address range and confirm that there is no error in the operation outside the expected address.

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

[0131] The essence of RDMA (remote direct data access) access to local storage is to read / write data from a certain continuous address in the local storage. This behavior is carried by PCIe (Peripheral Component Interconnect Standard) memwr / memrd (memory write / read) messages. Regardless of the memwr / memrd (memory write / read) message packet cutting rules, these memwr / memrd (memory write / read) messages after packet cutting can eventually achieve RDMA (remote direct data access) access to local storage through the concatenation of address and length information. For example, a certain RDMA (remote direct data access) operation is expected to achieve the writing of local storage address A and length B (operation address A~A+B). No matter how many memwr (memory write) messages on the PCIe (Peripheral Component Interconnect Standard) side are divided into, the result will meet the following requirements, refer to Figure 3 :

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

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

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

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

[0136] Figure 3The following diagram shows the address interval distribution of multiple memory write messages within an RDMA (remote direct data access) expected access address interval. In the entire RDMA expected access address interval, there are the memwr_0 address interval (memory write_0 address interval), memwr_1 address interval (memory write_1 address interval), memwr_2 address interval (memory write_2 address interval), memwr_3 address interval (memory write_3 address interval), memwr_4 address interval (memory write_4 address interval) and memwr_5 address interval (memory write_5 address interval). These address intervals are arranged in order and do not overlap with each other. The end address of the previous address interval is adjacent to the start address of the next address interval. The combination of all these address intervals just completely covers the entire RDMA expected access address interval.

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

[0138] 1. Create a transaction class (spec_trans for short) that contains address / length / data information related to local storage access corresponding to a single RDMA (remote direct data access) operation. It is a UVM (Universal Verification Methodology) transaction type, so it can be used in the UVM (Universal Verification Methodology) architecture and is transmitted between components through UVM (Universal Verification Methodology)-specific TLM (transaction level modeling) communication.

[0139] 2. The Reference model component no longer generates the expected memwr / memrd (memory write / read) messages corresponding to the DUT (device under test). Now, in units of a single RDMA (remote direct data access) operation, spec_trans (specification transaction) is used to generate instances of the address / length / data and other information of the local storage that needs to be accessed by the RDMA (remote direct data access) operation. The operations included in the Reference model component are:

[0140] 1) Create a uvm_analysis_port (analysis port) 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 (reference model) 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 to the corresponding uvm_analysis_port (analysis port) port.

[0143] 3. The Scoreboard component compares the actual PCIe (Peripheral Component Interconnect Standard) memwr / memrd (memory write / read) messages generated by the DUT (device under test) with the spec_trans (specification transaction) instance. Since the actual PCIe (Peripheral Component Interconnect Standard) memwr / memrd (memory write / read) messages generated by the DUT (device under test) and the spec_trans (specification transaction) messages generated by the reference model are different in terms of transaction type and address / length / data information, the comparison process cannot use the built-in comparison function of UVM (Universal Verification Methodology), and the contents of each domain need to be checked. The operations included in the Scoreboard component are:

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

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

[0146] 3) Write a function corresponding to the uvm_analysis_imp (analysis implementation) port of the PCIe (Peripheral Component Interconnect) message type to obtain the actual PCIe (Peripheral Component Interconnect) memwr / memrd (memory write / read) messages generated by the DUT (device under test);

[0147] 4) When the actual PCIe (Peripheral Component Interconnect Express) memwr / memrd (memory write / read) message generated by the DUT (device under test) is detected, the message is compared. The specific process includes:

[0148] ① Check if the memwr / memrd (memory write / read) message complies with the PCIe (Peripheral Component Interconnect Express) protocol. If not, it means that there is an error in the actual message.

[0149] ② Check whether the memwr / memrd (memory write / memory read) message complies with the DUT (device under test) design specifications, such as the requester ID, etc. If it does not comply, it means that there is an error in the actual message;

[0150] ③ Check whether 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 fails;

[0151] ④ Compare the memwr / memrd (memory write / read) message with the first spec_trans (specification transaction) message in the expected message queue. According to the previous requirements, it can be concluded 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, the comparison fails.

[0152] ⑤ If all the above processes are passed, it means that the actual PCIe (Peripheral Component Interconnect Standard) memwr / memrd (memory write / read) message meets expectations, and then the expected spec_trans (specification transaction) message needs to be corrected for the next comparison operation. If the length of the memwr / memrd (memory write / read) message is consistent with the expected spec_trans (specification transaction) message, the first spec_trans (specification transaction) message in the expected message queue is deleted, indicating that the expectation has completely detected the corresponding actual message; if not, the expected spec_trans (specification transaction) message only needs to subtract a segment of address / length / data information that has passed the comparison, and then wait for the next actual message.

[0153] 4. According to the requirements in the previous article, when the entire simulation is finished, no matter how many RDMA (remote direct data access) operations are involved in the middle, the final comparison result in the scoreboard must be: all actual memwr / memrd (memory write / read) messages can find the corresponding expected spec_trans (specification transaction) messages; all expected spec_trans (specification transaction) messages will be consumed. If not met, it means that the overall comparison fails.

[0154] 5. Implement the connection between the uvm_analysis_port port of the spec_trans type of the reference model component and the uvm_analysis_imp port of the spec_trans type of the scoreboard component in the env component.

[0155] There are two related technologies:

[0156] One is that the reference model component generates the expected PCIe (Peripheral Component Interconnect Standard) memwr / memrd (memory write / read) message, and the scoreboard component compares the actual message generated by the DUT (device under test) with the expected message generated by the reference model component. Both are messages of the same transaction type. This comparison method is very sophisticated, but for special DUT (device under test) design solutions, the reference model component cannot anticipate the special state of the DUT (device under test) in real time, resulting in the expected message not meeting the actual situation. Therefore, the application scenarios of this technology are limited.

[0157] The other is to not use the reference model component to generate the expected message, and the scoreboard component does not compare the actual message generated by the DUT (device under test), but only checks the data information in the memory after the simulation to determine the correctness of the result. This comparison scheme is very rough and cannot accurately identify the DUT (device under test)'s misaccess to irrelevant addresses, which can easily lead to problems being missed.

[0158] This application example aims at the design features of RDMA (remote direct data access) DUT (device under test), and proposes a new PCIe (Peripheral Component Interconnect) request comparison method in UVM (Universal Verification Methodology) verification. Compared with the first related technology, it does not require the reference model component to pay attention to the special status in the DUT (device under test), and can also generate relatively detailed expected messages; compared with the second related technology, it can accurately determine the DUT's (device under test) erroneous access to irrelevant addresses and valid access to relevant addresses. At the same time, it is also timely. The actual message of each DUT (device under test) can be compared immediately after it is generated, without waiting for the end of the simulation.

[0159] The advantages of this application example over related technologies are:

[0160] 1. Propose a new transaction class to simulate RDMA (Remote Direct Data Access) DUT (Device Under Test) side requests.

[0161] 2. The reference model component is no longer required to generate PCIe memwr / memrd (memory write / read) messages that fully correspond to the actual DUT (device under test). Now the reference model component only needs to generate instance messages of the new transaction class on its PCIe (Peripheral Component Interconnect Standard) side per RDMA (remote direct data access) operation.

[0162] 3. The Scoreboard component no longer compares the actual and expected two PCIe (Peripheral Component Interconnect Standard) memwr / memrd (memory write / read) messages of the same type. Now the scoreboard component needs to compare the actual PCIe (Peripheral Component Interconnect Standard) memwr / memrd (memory write / read) message with the expected newly defined transaction class instance message.

[0163] This application example is between the two related technologies in terms of the level of sophistication of the comparison method, but 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 unexpected state of the DUT (device under test) design; at the same time, it solves the problems of immediacy and completeness of the comparison of the extensive comparison scheme.

[0164] The comparison method described in this application example is not limited to the RDMA (remote direct data access) function scenario, nor is it limited to PCIe (Peripheral Component Interconnect Express) protocol messages. Any operation for accessing consecutive addresses can be compared using a similar idea.

[0165] The technical solution provided by this application example is conducive to establishing 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 conducive to timely verifying the correctness of the storage access request message, thereby ensuring the accuracy of access verification while improving the efficiency of access verification.

[0166] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0167] Based on the same inventive concept, the embodiment of the present application also provides a request comparison device for realizing the above-mentioned request comparison method for UVM verification. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitation in the one or more request comparison device embodiments for UVM verification provided below can be found in the above for the limitation of the request comparison method for UVM verification, and will not be repeated here.

[0168] In an exemplary embodiment, Figure 4 As shown, a request comparison device used in UVM verification is provided, and the request comparison device 400 used in UVM verification may include:

[0169] A transaction creation module 401, used to create a transaction class corresponding to a storage access operation;

[0170] The message generation module 402 is used to generate an instance message of the storage access operation according to the transaction class, and store the instance message into the expected queue;

[0171] The message comparison module 403 is used to compare the storage access request message with the instance message in the expected queue when the storage access request message to be compared meets the protocol conditions and design specification conditions, so as to obtain the comparison result of the storage access request message; the comparison processing includes the starting address comparison processing and the 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 also used to perform a start address comparison process on the storage access request message and the instance message in the expected queue to obtain a start address comparison result of the storage access request message; perform a message length comparison process on the storage access request message and the instance message in the expected queue to obtain a 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 also used to confirm that the comparison result of the storage access request message is a successful comparison when the starting address comparison result indicates that the starting address of the storage access request message is the same as the starting 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 also includes: a result confirmation module, which 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; when there is no message information of the instance message in the expected queue, confirm that the access verification result of the storage access request message is successful access verification; when there is message information of the instance message in the expected queue, wait for obtaining the next new storage access request message.

[0175] In an exemplary embodiment, the device 400 also includes: a message acquisition module, used to obtain 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; when the protocol detection result indicates that the storage access request message does not meet the protocol condition, confirm that there is an error in the storage access request message.

[0176] In an exemplary embodiment, the device 400 also includes: a message detection module, which is used to perform design specification condition detection processing on the storage access request message when the protocol detection result indicates that the storage access request message meets the protocol conditions, so as to obtain a design specification detection result of the storage access request message; when the design specification detection result indicates that the storage access request message does not meet the design specification conditions, confirming that there is an error in the storage access request message.

[0177] Each module in the request comparison device used in the UVM verification can be realized in whole or in part by software, hardware and a combination thereof. Each module can be embedded in or independent of the processor in the computer device in hardware form, or can be stored in the memory in the computer device in software form, so that the processor calls and executes the corresponding operation of each module above.

[0178] In an exemplary embodiment, a computer device is provided. The computer device may be a terminal, and its internal structure diagram may be as shown in FIG. Figure 5 As shown. The computer device includes a processor, a memory, an input / output interface, a communication interface, a display unit and an input device. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface, the display unit and the input device are connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and the external device. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless manner can be realized through WIFI, a mobile cellular network, NFC (near field communication) or other technologies. When the computer program is executed by the processor, a request comparison method used in UVM verification is realized. The display unit of the computer device is used to form a visually visible picture, which can be a display screen, a projection device or a virtual reality imaging device. The display screen can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device can be a touch layer covering the display screen, or a button, trackball or touchpad set on the computer device shell, or an external keyboard, touchpad or mouse.

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

[0180] In an exemplary embodiment, a computer device is further provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above-mentioned method embodiments when executing the computer program.

[0181] In an exemplary embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0182] In an exemplary embodiment, a computer program product is provided, including a computer program, and when the computer program is executed by a processor, the steps in the above method embodiments are implemented.

[0183] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium 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), magnetoresistive 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. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but are not limited to this.

[0184] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, 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 above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A request comparison method used in UVM verification, characterized in that, The method comprises: Create a transaction class corresponding to the 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; When the storage access request message to be compared meets the protocol conditions and the design specification conditions, the storage access request message is compared with the instance message in the expected queue to obtain a comparison result of the storage access request message; the comparison process includes a start address comparison process and a message length comparison process; the comparison result is used to determine the access verification result of the storage access request message.

2. The method according to claim 1, characterized in that: The 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 includes: Performing a start address comparison process on the storage access request message and the instance message in the expected queue to obtain a start address comparison result of the storage access request message; Performing the message length comparison processing on the storage access request message and the instance message in the expected queue to obtain a message length comparison result of the storage access request message; The comparison result of the storage access request message is determined according to the comparison result of the start address and the comparison result of the message length.

3. The method according to claim 2, characterized in that The determining the comparison result of the storage access request message according to the comparison result of the start address and the comparison result of the message length includes: When the starting address comparison result indicates that the starting address of the storage access request message is the same as the starting 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, the comparison result of the storage access request message is confirmed to be a successful comparison.

4. The method according to claim 3, characterized in that After confirming that the comparison result of the storage access request message is successful, the method further includes: Performing a deletion process corresponding to the message length of the storage access request message on the instance message in the expected queue; In a case where the message information of the instance message does not exist in the expected queue, confirming that the access verification result of the storage access request message is that the access verification is successful; When the message information of the instance message exists in the expected queue, wait to obtain the next new storage access request message.

5. The method according to claim 1, characterized in that When the storage access request message to be compared meets the protocol condition and the design specification condition, 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, and the method further includes: Obtaining the storage access request message; Performing detection processing of the protocol condition on the storage access request message to obtain a protocol detection result of the storage access request message; When the protocol detection result indicates that the storage access request message does not meet the protocol condition, it is confirmed that there is an error in the storage access request message.

6. The method according to claim 5, characterized in that After performing the detection process of the protocol condition on the storage access request message to obtain the protocol detection result of the storage access request message, the method further includes: In the case where the protocol detection result indicates that the storage access request message meets the protocol condition, performing detection processing of the design specification condition on the storage access request message to obtain a design specification detection result of the storage access request message; When 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.

7. A request comparison device used in UVM verification, characterized in that, The device comprises: A transaction creation module, used to create a transaction class corresponding to a storage access operation; A message generation module, used for generating an instance message of the storage access operation according to the transaction class, and storing the instance message into an expected queue; A message comparison module is used to compare the storage access request message to be compared with the instance message in the expected queue when the storage access request message meets the protocol conditions and design specification conditions, so as to obtain the comparison result of the storage access request message; the comparison process includes starting 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.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

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

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

Images