Equipment verification method and device, computer equipment, storage medium and computer program product

Abstract

The invention relates to an equipment verification method and device, computer equipment, a storage medium and a computer program product. The method comprises the following steps: acquiring an input request associated with to-be-tested equipment and target address information carried in the input request; the target address information at least comprises initial address information and address length information in a first output result corresponding to the input request; the first output result is determined by the to-be-tested device based on the input request; and determining a second output result corresponding to the input request according to the initial address information and the address length information, and determining a target verification result of the to-be-tested device according to the difference between the first output result and the second output result. By adopting the method, the accuracy of equipment verification can be improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a device verification method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Art

[0002] At present, to ensure the normal operation of the device under test (DUT), it is very important to accurately verify the device under test.

[0003] In traditional technology, in the process of verifying the device under test, the method of directly pulling the internal signal is generally adopted; however, this method of directly pulling the internal signal will introduce more unpredictable problems, such as verification errors, which will lead to low accuracy of device verification. Summary of the invention

[0004] Based on this, it is necessary to provide a device verification method, apparatus, computer equipment, computer-readable storage medium and computer program product that can improve the accuracy of device verification in order to address the above technical problems.

[0005] In a first aspect, the present application provides a device verification method, which is applied to a verification terminal, comprising:

[0006] Acquire an input request associated with the device under test, and target address information carried in the input request; the target address information at least includes start address information and address length information in a first output result corresponding to the input request; the first output result is determined by the device under test based on the input request;

[0007] Determining a second output result corresponding to the input request according to the starting address information and the address length information;

[0008] A target verification result of the device to be tested is determined according to a difference between the first output result and the second output result.

[0009] In one embodiment, determining the second output result corresponding to the input request according to the starting address information and the address length information includes:

[0010] In a case where the address length information is equal to the preset address length information, determining a second output result corresponding to the input request;

[0011] or,

[0012] When the address length information is less than the preset address length information, current address boundary information is obtained according to the starting address information and the address length information, and a second output result corresponding to the input request is determined according to the current address boundary information.

[0013] In one embodiment, determining the second output result corresponding to the input request according to the current address boundary information includes:

[0014] When the current address boundary information is equal to the preset address boundary information, determining a second output result corresponding to the input request;

[0015] or,

[0016] In a case where the current address boundary information is smaller than the preset address boundary information, a second output result corresponding to the input request is determined according to the start address information and the address length information.

[0017] In one embodiment, after determining the second output result corresponding to the input request according to the starting address information and the address length information, the method further includes:

[0018] Get the current breakpoint count;

[0019] The method further comprises:

[0020] Determining a target breakpoint number according to the address length information and the processing length information of the device to be tested;

[0021] When the current breakpoint number is greater than the target breakpoint number, a warning message is generated.

[0022] In one of the embodiments, after determining the second output result corresponding to the input request according to the starting address information and the address length information, the method further includes:

[0023] Determining a work queue element corresponding to the input request according to the starting address information and the address length information;

[0024] The method of determining a second output result corresponding to the input request according to the starting address information and the address length information, and sending the input request to the device under test, further includes:

[0025] When the work queue element meets a preset condition, a second output result corresponding to the input request is determined according to the start address information and the address length information, and the input request is sent to the device to be tested.

[0026] In one embodiment, before determining the target verification result of the device to be tested according to the difference between the first output result and the second output result, the method further includes:

[0027] Verifying the first output result to obtain a verification result;

[0028] The step of determining a target verification result of the device to be tested according to a difference between the first output result and the second output result includes:

[0029] When the verification result indicates that the first output result has passed verification, a target verification result of the device to be tested is determined according to a difference between the first output result and the second output result.

[0030] In a second aspect, the present application further provides a device verification apparatus, which is applied to a verification end, comprising:

[0031] An information acquisition module, used to acquire an input request associated with the device under test, and target address information carried in the input request; the target address information at least includes the starting address information and address length information in the first output result corresponding to the input request; the first output result is determined by the device under test based on the input request;

[0032] An information processing module, configured to determine a second output result corresponding to the input request according to the starting address information and the address length information;

[0033] The result determination module is used to determine a target verification result of the device to be tested according to a difference between the first output result and the second output result.

[0034] In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

[0035] Acquire an input request associated with the device under test, and target address information carried in the input request; the target address information at least includes start address information and address length information in a first output result corresponding to the input request; the first output result is determined by the device under test based on the input request;

[0036] Determining a second output result corresponding to the input request according to the starting address information and the address length information;

[0037] A target verification result of the device to be tested is determined according to a difference between the first output result and the second output result.

[0038] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the following steps are implemented:

[0039] Acquire an input request associated with the device under test, and target address information carried in the input request; the target address information at least includes start address information and address length information in a first output result corresponding to the input request; the first output result is determined by the device under test based on the input request;

[0040] Determining a second output result corresponding to the input request according to the starting address information and the address length information;

[0041] A target verification result of the device to be tested is determined according to a difference between the first output result and the second output result.

[0042] In a fifth aspect, the present application further provides a computer program product, including a computer program, which implements the following steps when executed by a processor:

[0043] Acquire an input request associated with the device under test, and target address information carried in the input request; the target address information at least includes start address information and address length information in a first output result corresponding to the input request; the first output result is determined by the device under test based on the input request;

[0044] Determining a second output result corresponding to the input request according to the starting address information and the address length information;

[0045] A target verification result of the device to be tested is determined according to a difference between the first output result and the second output result.

[0046] The device verification method, apparatus, computer device, storage medium and computer program product first obtain an input request associated with the device to be tested, and the target address information carried in the input request, and then determine the second output result corresponding to the input request according to the starting address information and address length information in the first output result corresponding to the input request in the target address information, and then determine the target verification result of the device to be tested according to the difference between the first output result and the second output result. In this way, in the process of verifying the device to be tested, the second output result corresponding to the input request is accurately determined by the verification end according to the starting address information and address length information in the first output result corresponding to the input request, so that the target verification result of the device to be tested can be more accurately determined according to the comparison result between the first output result and the second output result, which is conducive to improving the accuracy of the verification result of the device to be tested, thereby improving the accuracy of the device verification; moreover, the whole process does not need to directly pull the internal signal, avoiding the use of the direct internal signal pulling method, which will introduce more unpredictable problems, such as easy to cause verification errors, thereby resulting in the defect of low accuracy of device verification, further improving the accuracy of device verification. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0048] Figure 1 A diagram of an application environment of a device verification method in an embodiment;

[0049] Figure 2 A schematic diagram of a flow chart of a device verification method in an embodiment;

[0050] Figure 3 A schematic diagram of a breakpoint scenario request comparison method used in RDMA UVM verification in one embodiment;

[0051] Figure 4 A schematic diagram of an estimated access address range in one embodiment;

[0052] Figure 5 A schematic diagram of a flow chart of a device verification method in another embodiment;

[0053] Figure 6 is a structural block diagram of a device verification apparatus in one embodiment;

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

[0055] 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.

[0056] 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.

[0057] The device verification method provided in the embodiment of the present application can be applied to Figure 1 In the application environment shown in FIG. 1 , the verification terminal 102 communicates with the device to be tested 104 via a network. Specifically, refer to Figure 1 , the verification end 102 obtains the input request associated with the device to be tested 104, and the target address information carried in the input request; the target address information at least includes the starting address information and the address length information in the first output result corresponding to the input request; the first output result is determined by the device to be tested based on the input request; the verification end 102 determines the second output result corresponding to the input request according to the starting address information and the address length information; the verification end 102 determines the target verification result of the device to be tested 104 according to the difference between the first output result and the second output result. Among them, the verification end 102 refers to a device equipped with a UVM (Universal Verification Methodology) verification platform, which can be a terminal or a server. The device to be tested 104 refers to a device that needs to be tested, also known as DUT (Device Under Test), which can be a terminal or a server. Among them, the terminal can be but is not limited to various personal computers, laptops, smart phones and tablets. The server can be implemented as an independent server or a server cluster consisting of multiple servers.

[0058] It should be noted that the UVM verification platform includes env (verification environment) components, reference model (reference model) components, scorboard (comparison module) components, and agent (agent) components. The agent component includes driver (driver) components and monitor (monitor) components.

[0059] In an exemplary embodiment, Figure 2 As shown, a device verification method is provided, which is applied to Figure 1 Taking the verification end in FIG. 1 as an example, in this embodiment, the method includes the following steps:

[0060] Step S201, obtaining an input request associated with the device under test and target address information carried in the input request; the target address information at least includes the starting address information and address length information in the first output result corresponding to the input request; the first output result is determined by the device under test based on the input request.

[0061] The input request is used to represent input information for verifying the device to be tested. It should be noted that the input request is also called a PCIe (Peripheral Component Interconnect Express, a high-speed serial computer expansion bus standard) request.

[0062] The target address information at least includes the start address information and address length information in the first output result corresponding to the input request.

[0063] The first output result is determined by the device to be tested based on the input request.

[0064] The starting address information is used to indicate the starting point of the input request.

[0065] The address length information is used to indicate the address range involved in the input request.

[0066] Exemplarily, the verification end establishes a network path with the device to be tested in response to a device verification instruction for the device to be tested; then, the verification end obtains an input request associated with the device to be tested through the network path, and inputs the input request to the device to be tested to obtain a first output result corresponding to the input request; then, the verification end uses the starting address information and address length information of the first output result as the target address information carried in the input request.

[0067] For example, see Figure 3 The verification end creates a transaction class corresponding to the PCIe request through the UVM verification platform, and generates a PCIe request through the driver component in the UVM verification platform.

[0068] Step S202: Determine a second output result corresponding to the input request according to the start address information and the address length information.

[0069] The second output result is used to represent the output result corresponding to the input request obtained by the verification end.

[0070] Exemplarily, the verification end preprocesses the starting address information and the address length information to obtain preprocessed starting address information and preprocessed address length information; then, the verification end determines the output result corresponding to the input request as the second output result based on the preprocessed starting address information and the preprocessed address length information.

[0071] For example, see Figure 3 The verification end monitors the request of the driver component through the monitor component in the UVM verification platform. When a request is detected, the verification end sends the request to the reference model component based on the verification environment component; the reference model component determines the second output result corresponding to the request according to the starting address information and address length information carried in the request; the driver component also sends the request to the device to be tested, so that the device to be tested processes the request.

[0072] It should be noted that the verification environment component is used to implement TLM (Transaction Level Modeling communication) communication between the reference model component, the comparison module component and the monitor component. TLM communication is a method of inter-component communication defined in UVM.

[0073] Step S203: determining a target verification result of the device to be tested according to the difference between the first output result and the second output result.

[0074] The target verification result is used to indicate the comprehensive verification status of the device to be tested.

[0075] Exemplarily, the verification end compares the first output result and the second output result to obtain the difference between the first output result and the second output result; then, the verification end extracts the first key output result from the first output result, and extracts the second key output result from the second output result; finally, the verification end determines the target verification result of the device to be tested based on the difference between the first key output result and the second key output result.

[0076] For example, see Figure 3 The verification end determines the target verification result of the device to be tested by comparing the module components according to the difference between the first output result and the second output result.

[0077] In the above device verification method, the input request associated with the device to be tested and the target address information carried in the input request are first obtained, and then the second output result corresponding to the input request is determined according to the starting address information and address length information in the first output result corresponding to the input request in the target address information, and then the target verification result of the device to be tested is determined according to the difference between the first output result and the second output result. In this way, in the process of verifying the device to be tested, the second output result corresponding to the input request is accurately determined by the verification end according to the starting address information and address length information in the first output result corresponding to the input request, so that the target verification result of the device to be tested can be more accurately determined according to the comparison result between the first output result and the second output result, which is conducive to improving the accuracy of the verification result of the device to be tested, thereby improving the accuracy of the device verification; moreover, the whole process does not need to directly pull the internal signal, avoiding the use of the method of directly pulling the internal signal, which will introduce more unpredictable problems, such as easy to cause verification errors, thereby resulting in the defect of low accuracy of device verification, and further improving the accuracy of device verification.

[0078] In an exemplary embodiment, the above step S202 determines the second output result corresponding to the input request based on the starting address information and the address length information, and specifically includes the following contents: when the address length information is equal to the preset address length information, the second output result corresponding to the input request is determined; or, when the address length information is less than the preset address length information, the current address boundary information is obtained based on the starting address information and the address length information, and the second output result corresponding to the input request is determined based on the current address boundary information.

[0079] The preset address length information refers to the preset address length information. It should be noted that the preset address length information depends on the situation. In actual scenarios, the preset address length information is also called the requested fixed length.

[0080] The current address boundary information refers to the address information currently reached by the input request. It should be noted that the current address boundary information is determined by the input request and the historical input request corresponding to the input request. For example, Figure 4 As shown, when the input request is request 3, the current address boundary information is determined by the start address information of request 1, request 2 and request 3, and the address length information of request 1, request 2 and request 3.

[0081] Exemplarily, the verification end compares the address length information with the preset address length information through the reference model component in the UVM verification platform; when the address length information is equal to the preset address length information, the verification end determines the second output result corresponding to the input request according to the input request through the reference model component in the UVM verification platform; when the address length information is less than the preset address length information, the verification end obtains the current address boundary information according to the starting address information and the address length information through the reference model component in the UVM verification platform, and compares the current address boundary information with the preset address boundary information, and determines the second output result corresponding to the input request according to the comparison result.

[0082] In this embodiment, the second output result is determined by distinguishing between the two situations where the address length information is equal to the preset address length information and the situation where the address length information is less than the preset address length information. This allows for targeted processing of input requests in different boundary scenarios, and is beneficial for improving the accuracy of determining the second output result corresponding to the input request.

[0083] In an exemplary embodiment, a second output result corresponding to the input request is determined based on current address boundary information, specifically including the following contents: when the current address boundary information is equal to the preset address boundary information, the second output result corresponding to the input request is determined; or, when the current address boundary information is less than the preset address boundary information, the second output result corresponding to the input request is determined based on the starting address information and the address length information.

[0084] The preset address boundary information refers to the preset address boundary information. It should be noted that the preset address boundary information depends on the situation. In actual scenarios, the preset address boundary information is also called the expected access address interval, such as Figure 4 shown.

[0085] Exemplarily, when the current address boundary information is equal to the preset address boundary information, the verification end determines the second output result corresponding to the input request through the reference model component in the UVM verification platform according to the input request; when the current address boundary information is less than the preset address boundary information, the verification end determines the second output result corresponding to the input request through the reference model component in the UVM verification platform according to the starting address information and the address length information.

[0086] For example, see Figure 4 When the input request is request 5, it is determined that the current address boundary information is equal to the expected access address interval; when the input request is request 4, it is determined that the current address boundary information is smaller than the expected access address interval.

[0087] In this embodiment, different address boundary conditions are considered to determine the second output result, so that the test cases can cover more real and diverse boundary scenarios, thereby more comprehensively examining the processing capabilities of the device to be tested under different boundary conditions, thereby avoiding test omissions and helping to improve the comprehensiveness of the overall functional verification of the device.

[0088] In an exemplary embodiment, after determining the second output result corresponding to the input request according to the start address information and the address length information, the method specifically includes the following contents: obtaining the current breakpoint count.

[0089] Then, the method further includes: determining a target breakpoint number according to the address length information and the processing length information of the device to be tested; and generating warning information when the current breakpoint number is greater than the target breakpoint number.

[0090] The current breakpoint count refers to the breakpoint count recorded at the current time.

[0091] The processing length information is used to indicate the maximum length inside the device to be tested.

[0092] The target breakpoint number is also called the theoretical breakpoint number.

[0093] The warning information is used to indicate the alarm information associated with the device to be tested.

[0094] Exemplarily, the verification end obtains the number of breakpoints recorded at the current time through the reference model component in the UVM verification platform as the current number of breakpoints; then, the verification end obtains the maximum length inside the device to be tested through the reference model component in the UVM verification platform as the processing length information of the device to be tested, and determines the target number of breakpoints according to the address length information and the processing length information of the device to be tested; then, the verification end compares the current number of breakpoints and the target number of breakpoints through the reference model component in the UVM verification platform; when the current number of breakpoints is greater than the target number of breakpoints, the verification end determines that an error occurs in the device to be tested at this time, generates early warning information of the device to be tested, and sends the early warning information to a terminal associated with the device to be tested.

[0095] In this embodiment, the target breakpoint number is determined by address length information and processing length information of the device under test, thereby setting a breakpoint number threshold that matches the characteristics of the device under test, thereby ensuring the stability and reliability of device operation.

[0096] In an exemplary embodiment, the above step S202, in determining the second output result corresponding to the input request according to the starting address information and the address length information, specifically includes the following content: determining the work queue element corresponding to the input request according to the starting address information and the address length information.

[0097] Then, based on the starting address information and the address length information, the first output result corresponding to the input request is determined, and the input request is sent to the device to be tested, which specifically includes the following contents: when the working queue element meets the preset conditions, based on the starting address information and the address length information, the second output result corresponding to the input request is determined, and the input request is sent to the device to be tested.

[0098] The work queue element refers to a specific operation task to which the input request belongs. It should be noted that the work queue element is also called WQE (Work Queue Element).

[0099] The preset condition refers to a pre-set judgment condition used to judge the work queue element corresponding to the input request. For example, a WQE is found and the WQE has not been processed. It should be noted that the preset condition depends on the situation.

[0100] Exemplarily, the verification end determines, through the reference model component in the UVM verification platform, a work queue element corresponding to the starting address information and the address length information according to the starting address information and the address length information, as the work queue element corresponding to the input request; then, the verification end judges the work queue element corresponding to the input request; when the work queue element meets the preset conditions, the first output result corresponding to the input request is determined according to the starting address information and the address length information, and the input request is sent to the device to be tested; when the work queue element does not meet the preset conditions, the verification end generates warning information for the device to be tested, and sends the warning information to a terminal associated with the device to be tested.

[0101] In this embodiment, based on the starting address information and address length information, the work queue element corresponding to the input request can be accurately determined to facilitate subsequent judgment and processing; by using preset conditions to judge the work queue elements, it is possible to avoid processing too many or unreasonable tasks at the same time, which is conducive to the reasonable allocation and optimal utilization of resources.

[0102] In an exemplary embodiment, the above step S203, before determining the target verification result of the device to be tested according to the difference between the first output result and the second output result, specifically includes the following contents: verifying the first output result to obtain a verification result.

[0103] Then, according to the difference between the first output result and the second output result, the target verification result of the device to be tested is determined, which specifically includes the following contents: when the verification result indicates that the first output result is verified to be passed, according to the difference between the first output result and the second output result, the target verification result of the device to be tested is determined.

[0104] The verification result is used to indicate the verification status of the first output result.

[0105] Exemplarily, the verification end checks whether the first output result complies with the protocol based on the PCIe protocol through the comparison module component in the UVM verification platform, and checks whether the first output result complies with the specification based on the DUT design specification to obtain a verification result; when the verification result indicates that the first output result is verified to be passed, the verification end determines the target verification result of the device to be tested through the comparison module component in the UVM verification platform according to the difference between the first output result and the second output result; when the verification result indicates that the first output result is not verified to be passed, the verification end generates early warning information for the device to be tested, and sends the early warning information to a terminal associated with the device to be tested.

[0106] In this embodiment, by verifying the first output result, the first output result that obviously does not meet the requirements can be preliminarily screened out, thereby avoiding interference of some simple errors or outputs that obviously do not meet expectations on subsequent detailed comparative analysis, which is beneficial to improving the reliability of the verification results of the device to be tested, and thus improving the verification accuracy of the device to be tested.

[0107] In an exemplary embodiment, Figure 5 As shown, the present application also provides another device verification method, which is applied to Figure 1 The verification end in the example is used to illustrate the specific steps as follows:

[0108] Step S501, obtaining an input request associated with the device under test and target address information carried in the input request; the target address information at least includes the starting address information and address length information in the first output result corresponding to the input request; the first output result is determined by the device under test based on the input request.

[0109] Step S502: when the address length information is equal to the preset address length information, determine a second output result corresponding to the input request.

[0110] Step S503, when the address length information is less than the preset address length information, current address boundary information is obtained according to the start address information and the address length information.

[0111] Step S504: when the current address boundary information is equal to the preset address boundary information, determine the second output result corresponding to the input request.

[0112] Step S505 : when the current address boundary information is smaller than the preset address boundary information, a second output result corresponding to the input request is determined according to the start address information and the address length information.

[0113] Step S506: verify the first output result to obtain a verification result.

[0114] Step S507 : when the verification result indicates that the first output result has passed the verification, determine a target verification result of the device to be tested according to the difference between the first output result and the second output result.

[0115] In the above-mentioned device verification method, in the process of verifying the device under test, the second output result corresponding to the input request is accurately determined by the verification end based on the starting address information and address length information in the first output result corresponding to the input request, so that the target verification result of the device under test can be more accurately determined according to the comparison result between the first output result and the second output result, which is beneficial to improve the accuracy of determining the verification result of the device under test, thereby improving the accuracy of device verification; moreover, the entire process does not require the direct pulling of internal signals, avoiding the use of direct pulling of internal signals, which will introduce more unpredictable problems, such as easy errors, resulting in the defect of low accuracy of device verification, further improving the accuracy of device verification.

[0116] In an exemplary embodiment, in order to more clearly illustrate the device verification method provided in the embodiment of the present application, the device verification method is specifically described below with a specific embodiment. Figure 3 As shown, the present application also provides a breakpoint scenario request comparison method used in RDMA (Remote Direct Memory Access) UVM verification. In the process of verifying the device under test, the input request associated with the device under test and the target address information carried in the input request are first obtained, and then the second output result corresponding to the input request is determined based on the starting address information and address length information in the first output result corresponding to the input request in the target address information. Then, based on the difference between the first output result and the second output result, the target verification result of the device under test is determined. Specifically, it includes the following contents:

[0117] The essence of RDMA request is to read / write a certain memory segment. The request is transmitted through PCIe message. No matter how the internal scheduling is performed or when the breakpoint occurs, the request initiated by the same WQE is consistent with the address information in the WQE and can be uniquely confirmed by the address and length. Figure 4 In WQES, the address and length are used to uniquely identify an address range. For example, RDMA needs to read the length of B from the local address A and the length of D from the local address C in WQES. Regardless of the RDMA internal scheduling and breakpoint logic, the final request will meet the following requirements:

[0118] 1. The address carried in the request must be sent to RDMA before the request is initiated, that is, WQE S will read data of length B and D from addresses A and C respectively. This is sent along with WQE, which is predictable.

[0119] 2. The address accessed in the request is unique, that is, the address + length will not overlap between different requests.

[0120] 3. The requested addresses within the determined address and length range are continuous, that is, for requests to access address [A, A+B], the next address after the previous requested address range is the starting address of the next request, see Figure 4 .

[0121] 4. A PCIe message only involves a segment of addresses, that is, a request will only operate the local address A or D.

[0122] 5. When an address range has not been fully requested or there is no breakpoint, the address length of a request access is fixed, that is, the address range in multiple requests is in [A, A+B], and the length of these requests is fixed length L.

[0123] On the basis of the above, this application proposes a RDMA breakpoint scenario request comparison method based on the UVM framework with timely comparison capability, which mainly includes:

[0124] 1. Create a transaction class corresponding to the RDMA PCIe request (hereinafter referred to as PCIe_trans) to generate the expected PCIe request. PCIe_trans belongs to the transaction type in the UVM framework and can be transferred between components through TLM communication;

[0125] 2. The monitor component monitors the requests issued by RDMA and sends them to the referencemodel component after being carried by PCIe_trans.

[0126] 3. The reference model component uses the request sent by the actual RDMA to generate the expected request and sends it to the scoreboard component for comparison with the DUT request. The specific operations are:

[0127] (1) Receive the actual request from the DUT and confirm which WQE the request is for through the address and length of the request. If the WQE cannot be found or has been processed, it is an irrelevant or erroneous request.

[0128] (2) If the request length is a fixed length, an expected request is generated based on the WQE content and sent to the scoreboard component.

[0129] (3) If the request length is less than the fixed length, different processing is performed based on the WQE content and the previously received request to confirm whether it reaches the upper limit of the address range: if it reaches the upper limit of the address, the WQE content is generated to generate the expected request and send it to the scoreboard component; if it does not reach the upper limit of the address, it is considered that a breakpoint has occurred at this time, the number of breakpoints is recorded, and the actual request length is used to generate the expected request and send it to the scoreboard component.

[0130] (4) If the requested length and the maximum length inside the DUT are known, the theoretical number of breakpoints can be calculated. If the number of breakpoints recorded in the above steps is greater than the theoretical number of breakpoints, an error is reported.

[0131] (5) Each time an expected request is generated, it is calculated whether there are any remaining address intervals that have not been accessed. If there are any remaining address intervals, the simulation is terminated after the set waiting time has expired.

[0132] 4. The scoreboard component compares the actual request of the DUT with the expected request generated by the reference model component. The specific comparison logic is:

[0133] (1) Check whether the actual request complies with the PCIe protocol. If not, an error is reported.

[0134] (2) Check whether the actual request complies with the DUT design specifications. If not, an error is reported.

[0135] (3) After the above checks are passed, the actual request is placed in the queue, and the expected request is also placed in the queue. If it is a read request, the address and length are compared. If it is a write request, the data is also compared. If only one of the address range and data passes the comparison, an error is reported and the request is deleted from the queue.

[0136] (4) Requests that have passed the complete comparison are deleted from the queue, and an error is reported based on the remaining requests in the queue after the simulation is completed.

[0137] 5. Implement TLM communication between reference model component, scoreboard component and monitor component through env component.

[0138] In the above-mentioned embodiment, during the process of verifying the device under test, the verification end accurately determines the second output result corresponding to the input request based on the starting address information and address length information in the first output result corresponding to the input request, so that the target verification result of the device under test can be more accurately determined based on the comparison result between the first output result and the second output result, which is beneficial to improving the accuracy of determining the verification result of the device under test, thereby improving the accuracy of device verification; moreover, the entire process does not require the direct pulling of internal signals, thus avoiding the use of the direct pulling of internal signals, which will introduce more unpredictable problems, such as prone to verification errors, resulting in the defect of low accuracy of device verification, further improving the accuracy of device verification. At the same time, this solution proposes a new breakpoint scenario request comparison method in UVM verification for the internal scheduling characteristics of RDMA DUT. This solution does not require the reference model component to predict the breakpoint position of the DUT request in advance, and can also generate detailed expected messages; this solution does not need to occupy a large amount of verification resources, and can also accurately determine the DUT error or irrelevant request; this solution proposes to use a new expected request generation method to generate expected requests after receiving the actual request of the DUT; this solution uses the characteristics that the breakpoint position is unpredictable but the number of breakpoints is predictable to solve the problem that the scheduling breakpoint cannot generate the expected request; this solution uses the request length information that needs to be compared to generate expectations to achieve a more detailed comparison; this solution uses the expected address range and the expected number of breakpoints to verify the request length, expanding the verification coverage and rationality; this solution solves the problem that the reference model component cannot predict when the request will break due to the unpredictable internal scheduling of the DUT, and has the timeliness of comparison and guarantees the verification coverage; the comparison method described in this solution is not limited to the RDMA function scenario, nor is it limited to the PCIe protocol request. Any scenario with breakpoints for continuous address access operations can be compared using a similar idea.

[0139] 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 is not strictly limited in order, 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 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.

[0140] Based on the same inventive concept, the embodiment of the present application also provides a device verification device for implementing the device verification method involved above. The implementation solution provided by the device to solve the problem is similar to the implementation solution recorded in the above method, so the specific limitations in one or more device verification device embodiments provided below can refer to the limitations on the device verification method above, and will not be repeated here.

[0141] In an exemplary embodiment, Figure 6 As shown, a device verification apparatus is provided, including: an information acquisition module 601, an information processing module 602 and a result determination module 603, wherein:

[0142] The information acquisition module 601 is used to obtain the input request associated with the device under test and the target address information carried in the input request; the target address information at least includes the starting address information and address length information in the first output result corresponding to the input request; the first output result is determined by the device under test based on the input request.

[0143] The information processing module 602 is used to determine a second output result corresponding to the input request according to the start address information and the address length information.

[0144] The result determination module 603 is used to determine a target verification result of the device to be tested according to the difference between the first output result and the second output result.

[0145] In an exemplary embodiment, the information processing module 602 is also used to determine the second output result corresponding to the input request when the address length information is equal to the preset address length information; or, when the address length information is less than the preset address length information, obtain the current address boundary information based on the starting address information and the address length information, and determine the second output result corresponding to the input request based on the current address boundary information.

[0146] In an exemplary embodiment, the information processing module 602 is also used to determine the second output result corresponding to the input request when the current address boundary information is equal to the preset address boundary information; or, when the current address boundary information is less than the preset address boundary information, determine the second output result corresponding to the input request based on the starting address information and the address length information.

[0147] In an exemplary embodiment, the device verification device also includes a breakpoint acquisition module for obtaining the current breakpoint number; the device verification device also includes an information generation module for determining the target breakpoint number based on the address length information and the processing length information of the device to be tested; when the current breakpoint number is greater than the target breakpoint number, a warning message is generated.

[0148] In an exemplary embodiment, the device verification apparatus further includes an element determination module, which is used to determine a work queue element corresponding to an input request based on starting address information and address length information; the information processing module 602 is also used to determine a second output result corresponding to the input request based on starting address information and address length information when the work queue element meets preset conditions, and send the input request to the device to be tested.

[0149] In an exemplary embodiment, the device verification apparatus further includes a result verification module for verifying the first output result to obtain a verification result; the result determination module 603 is further used to determine the target verification result of the device to be tested based on the difference between the first output result and the second output result when the verification result indicates that the first output result has passed the verification.

[0150] Each module in the above-mentioned device verification apparatus can be implemented in whole or in part by software, hardware, or a combination thereof. Each of the above-mentioned modules can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute the operations corresponding to each of the above modules.

[0151] In an exemplary embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. Figure 7As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. The processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. 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, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store data such as starting address information and address length information. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a device verification method is implemented.

[0152] Those skilled in the art will understand that Figure 7 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.

[0153] 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.

[0154] 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.

[0155] 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.

[0156] 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.

[0157] 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.

[0158] 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 device verification method, characterized in that: Applied to the verification end, the method includes: Acquire an input request associated with the device under test, and target address information carried in the input request; the target address information at least includes start address information and address length information in a first output result corresponding to the input request; the first output result is determined by the device under test based on the input request; Determining a second output result corresponding to the input request according to the starting address information and the address length information; A target verification result of the device to be tested is determined according to a difference between the first output result and the second output result.

2. The method according to claim 1, characterized in that The determining, according to the starting address information and the address length information, a second output result corresponding to the input request includes: In a case where the address length information is equal to the preset address length information, determining a second output result corresponding to the input request; or, When the address length information is less than the preset address length information, current address boundary information is obtained according to the starting address information and the address length information, and a second output result corresponding to the input request is determined according to the current address boundary information.

3. The method according to claim 2, characterized in that The determining, according to the current address boundary information, a second output result corresponding to the input request includes: When the current address boundary information is equal to the preset address boundary information, determining a second output result corresponding to the input request; or, In a case where the current address boundary information is smaller than the preset address boundary information, a second output result corresponding to the input request is determined according to the start address information and the address length information.

4. The method according to claim 3, characterized in that After determining the second output result corresponding to the input request according to the starting address information and the address length information, the method further includes: Get the current breakpoint count; The method further comprises: Determining a target breakpoint number according to the address length information and the processing length information of the device to be tested; When the current breakpoint number is greater than the target breakpoint number, a warning message is generated.

5. The method according to claim 1, characterized in that: After determining a second output result corresponding to the input request according to the starting address information and the address length information, the method further includes: Determining a work queue element corresponding to the input request according to the starting address information and the address length information; The method of determining a second output result corresponding to the input request according to the starting address information and the address length information, and sending the input request to the device under test, further includes: When the work queue element meets a preset condition, a second output result corresponding to the input request is determined according to the start address information and the address length information, and the input request is sent to the device to be tested.

6. The method according to any one of claims 1 to 5, characterized in that Before determining the target verification result of the device to be tested according to the difference between the first output result and the second output result, the method further includes: Verifying the first output result to obtain a verification result; The step of determining a target verification result of the device to be tested according to a difference between the first output result and the second output result includes: When the verification result indicates that the first output result has passed verification, a target verification result of the device to be tested is determined according to a difference between the first output result and the second output result.

7. A device verification device, characterized in that: Applied to the verification end, the device comprises: An information acquisition module, used to acquire an input request associated with the device under test, and target address information carried in the input request; the target address information at least includes the starting address information and address length information in the first output result corresponding to the input request; the first output result is determined by the device under test based on the input request; An information processing module, configured to determine a second output result corresponding to the input request according to the starting address information and the address length information; The result determination module is used to determine a target verification result of the device to be tested according to a difference between the first output result and the second output result.

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