A testing method, device, medium and product for PCIe functions

Abstract

The present application discloses a test method, device, medium and product for PCIe functions, relating to the technical field of hardware testing, and is applied to a preset test control component, including: obtaining and parsing a driver test command sent by a standard PCIe device to determine a driver test category; the driver test command is sent by a to-be-tested PCIe device to the standard PCIe device, and the standard PCIe device is constructed based on a transaction-level simulation model of a preset hardware acceleration platform; if it is a message-type driver test, a message stimulus is formed based on a preset transaction layer packet format and test scenario identifiers and test indexes in the driver test command, and the message stimulus is sent to the to-be-tested PCIe device through the standard PCIe device; if it is a configuration-type driver test, a target register is located from the PCIe configuration space of the standard PCIe device based on the test scenario identifiers and test indexes in the driver test command, and the target register is configured based on the test indexes.

Description

Technical Field

[0001] The present invention relates to the technical field of hardware testing, and particularly to a test method, device, medium and product for PCIe functions. Background Art

[0002] Verification is an essential and crucial part in the modern digital IC (Integrated Circuit) design process, and its purpose is to ensure that the design functions are correctly implemented according to the established design specifications. PCIe (Peripheral Component Interconnect Express) is a general serial expansion bus standard used for the connection between internal hardware components of a computer. PCIe interfaces are very common in modern computer hardware and are used to connect various devices, such as graphics processing units, solid-state drives, network cards, etc. With the development of technology, the test requirements for PCIe functions are becoming more and more urgent, especially the pre-silicon functional verification directly affects the success rate of chip silicon tape-out.

[0003] Currently, when performing PCIe functional verification before silicon tape-out, it is usually necessary to build a verification environment, select a standard PCIe device to connect with the PCIe under test, establish a communication link, control the device to execute verification test cases, generate TLP (Transaction Layer Packet) packets and send them to the device under test, and finally judge whether the verification meets the expectations according to the execution results of the test cases. The Zebu (Zero Bug) platform, as a hardware acceleration platform, can be used for the prototype implementation and acceleration verification before chip silicon tape-out. The PCIe Transactor (a transaction-level simulation model) provided by it can be used to build a test environment, and also provides some callback functions and backdoor functions. However, this platform has obvious defects. The implementation effect depends on the technical capabilities and experience of testers, and it cannot provide the test capabilities for standard IP (Intellectual Property) functions. Moreover, testers need to plan and develop test stimuli one by one, resulting in low test efficiency.

[0004] In summary, how to improve the test efficiency of PCIe functions is a problem to be solved currently. Summary of the Invention

[0005] In view of this, the purpose of the present invention is to provide a test method, device, medium and product for PCIe functions, which can improve the test efficiency of PCIe functions. The specific solutions are as follows:

[0006] In a first aspect, the present application discloses a test method for PCIe functions, including:

[0007] Obtain the driver test commands sent by the standard PCIe device, and parse the driver test commands to determine the driver test category; the driver test commands are sent by the PCIe device under test to the standard PCIe device, and the standard PCIe device is built based on the transaction-level simulation model of the preset hardware acceleration platform;

[0008] If the driver test category is a message class driver test, form a message stimulus based on the preset transaction layer packet format, test scenario identifier, and test index in the driver test command, and send the message stimulus to the PCIe device under test through the standard PCIe device;

[0009] If the driver test category is a configuration class driver test, locate the target register from the PCIe configuration space of the standard PCIe device based on the test scenario identifier and test index in the driver test command, and configure the target register based on the test index.

[0010] Optionally, the command format of the driver test command includes a test type identifier, a test scenario identifier, and a test index; among them, the test type identifier includes a first identification information for indicating a message class driver test and a second identification information for indicating a configuration class driver test;

[0011] Correspondingly, parsing the driver test command to determine the driver test category includes:

[0012] Parse the driver test command to obtain the test type identifier;

[0013] If the test type identifier is the first identification information, determine that the driver test category of the driver test command is a message class driver test;

[0014] If the test type identifier is the second identification information, determine that the driver test category of the driver test command is a configuration class driver test.

[0015] Optionally, the test type identifier reuses the format bit field of the header of the transaction layer packet; the test scenario identifier and test index corresponding to the message class driver test reuse the message code bit field of the header of the transaction layer packet, and the high four bits of the message code bit field are mapped to the test scenario identifier, and the low four bits are mapped to the test index; the test scenario identifier and test index corresponding to the configuration class driver test reuse the capability information of the PCIe configuration space, the capability identifier in the capability information is mapped to the test scenario identifier, and the register offset information in the capability information is mapped to the test index.

[0016] Optionally, the message class driver test includes a first message class driver test, a second message class driver test, a third message class driver test and a fourth message class driver test; wherein, the first message class driver test is used to test the functional correctness of the PCIe device under test generating an advanced error report status and transmitting it to the system layer to trigger an interrupt status; the second message class driver test is used to test the functional correctness of the PCIe device under test generating a traditional interrupt status and transmitting it to the system layer to trigger an interrupt status; the third message class driver test is used to test the correctness of the write data of the corresponding address received by the PCIe device under test configured by the message signal interrupt, as well as the correctness of the interrupt status triggered by the write operation and the correctness of the system response process; the fourth message class driver test is used to test the correctness of the write data of the corresponding address received by the PCIe device under test configured by the extended message signal interrupt table, as well as the correctness of the interrupt status triggered by the write operation and the correctness of the system response process.

[0017] Optionally, the configuration class driver test includes a first configuration class driver test, a second configuration class driver test, a third configuration class driver test and a fourth configuration class driver test; wherein, the first configuration class driver test is used to test the correctness of the power state switching and link state switching of the PCIe device under test; the second configuration class driver test is used to test the correctness of all link rate switching supported by the PCIe device under test; the third configuration class driver test is used to test the correctness of all link bandwidth switching supported by the PCIe device under test; the fourth configuration class driver test is used to test the correctness of the link disconnection function, link state switching, system state and interrupt response of the PCIe device under test.

[0018] Optionally, a message stimulus is formed based on a preset transaction layer data packet format and a test scenario identifier and a test index in a drive test command, including:

[0019] The test scenario identifier and the test index in the drive test command are concatenated according to the bit field to obtain the concatenated target message code;

[0020] The message stimulus is constructed based on the header structure of the preset transaction layer data packet format and the target message encoding.

[0021] Optionally, the message stimulus is sent to the PCIe device to be tested through a standard PCIe device, including:

[0022] The callback function of the standard PCIe device is called to send the message stimulus to the PCIe device under test through the standard PCIe device.

[0023] Optionally, locating a target register from a PCIe configuration space of a standard PCIe device based on a test scenario identifier and a test index in the driver test command includes:

[0024] Scan the capability pointer of the PCIe configuration space of the standard PCIe device based on the test scenario identifier in the driver test command to locate the corresponding target offset address;

[0025] Locate the target register from the PCIe configuration space of the standard PCIe device based on the target offset address and the test index in the driver test command.

[0026] Optionally, scanning the capability pointer of the PCIe configuration space of the standard PCIe device based on the test scenario identifier in the driver test command to locate the corresponding target offset address includes:

[0027] Determine the capability pointer in the PCIe configuration space of the standard PCIe device;

[0028] Starting from the offset address pointed to by the capability pointer, traverse each capability structure in the PCIe configuration space based on the test scenario identifier in the driver test command until the target capability structure is read; the capability identifier of the target capability structure is the test scenario identifier in the driver test command;

[0029] Determine the target offset address pointed to by the target capability structure.

[0030] Optionally, the test index in the driver test command includes a byte index and a value index;

[0031] Correspondingly, locating the target register from the PCIe configuration space of the standard PCIe device based on the target offset address and the test index in the driver test command includes:

[0032] Merge the target offset address and the byte index in the driver test command to obtain the register address;

[0033] Locate the target register from the PCIe configuration space of the standard PCIe device based on the register address.

[0034] Optionally, configuring the target register based on the test index includes:

[0035] Read the current data of the target register, and perform an OR operation on the value index in the test index and the current data to obtain the operation result;

[0036] Configure the target register based on the operation result and call the backdoor function of the standard PCIe device.

[0037] Optionally, the process of the PCIe device under test sending a driver test command to the standard PCIe device includes:

[0038] The PCIe device under test sends a memory read request to the standard PCIe device; the memory read request carries the driver test command;

[0039] The standard PCIe device responds to the memory read request and returns the read memory data to the PCIe device under test to complete the communication handshake with the PCIe device under test.

[0040] In a second aspect, the present application discloses an electronic device, including:

[0041] A memory for storing a computer program;

[0042] A processor for executing the computer program to implement the steps of the foregoing disclosed test method for PCIe functions.

[0043] In a third aspect, the present application discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, the steps of the foregoing disclosed test method for PCIe functions are implemented.

[0044] In a fourth aspect, the present invention discloses a computer program product, including computer program / instructions, and when the computer program / instructions are executed by a processor, the steps of the foregoing disclosed test method for PCIe functions are implemented.

[0045] Beneficial effects: The present application discloses a test control component, and a standard PCIe device is constructed based on a transaction-level simulation model of a preset hardware acceleration platform. After the standard PCIe device obtains the drive test command sent by the PCIe device under test, it will send the drive test command to the test control component, which will first parse the drive test command to determine the current drive test category. If the drive test category is a message-type drive test, a message stimulus will be formed based on the preset transaction layer packet format and the test scenario identifier and test index in the drive test command, and the message stimulus will be sent to the PCIe device under test through the standard PCIe device. After receiving the message stimulus, the PCIe device under test can continue to complete the subsequent drive test process. If the drive test category is a configuration-type drive test, the target register will be located from the PCIe configuration space of the standard PCIe device based on the test scenario identifier and test index in the drive test command, and the target register will be configured based on the test index. After the configuration is completed, the PCIe device under test can continue to complete the subsequent drive test process. In this way, through the test control component of the present application, the automatic configuration of the standard PCIe device and the automatic feedback of messages can be realized, and the full-automatic test process between the standard PCIe device and the PCIe device under test can be realized, greatly improving the test efficiency of PCIe functions. Description of the Drawings

[0046] To more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the accompanying drawings required for the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are only the embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other accompanying drawings can be obtained based on the provided drawings.

[0047] Figure 1 Flowchart of a test method for PCIe function disclosed in the present application;

[0048] Figure 2 Schematic diagram of the command format of a drive test command disclosed in the present application;

[0049] Figure 3 Flowchart of a specific test method for PCIe function disclosed in the present application;

[0050] Figure 4 Self-driving test control flowchart disclosed in the present application;

[0051] Figure 5 Schematic diagram of the structure of a test device for PCIe function disclosed in the present application;

[0052] Figure 6 Structural diagram of an electronic device disclosed in the present application. Detailed implementation manners

[0053] The following will clearly and completely describe the technical solutions in the embodiments of the present application in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of the present invention.

[0054] Currently, as a hardware acceleration platform, the Zebu platform can be used for prototype implementation and acceleration verification before chip tape-out. The PCIe Transactor (a transaction-level simulation model) provided by it can be used to build a test environment, and some callback functions and backdoor functions are also provided. However, this platform has obvious defects. The implementation effect depends on the technical ability and experience of testers, and it cannot provide the test ability of standard IP functions. Moreover, testers need to plan and develop test stimuli one by one, resulting in low test efficiency. Therefore, the embodiments of the present application disclose a test method, device, medium and product for PCIe function, which can improve the test efficiency of PCIe function.

[0055] See Figure 1As shown, an embodiment of the present application discloses a test method for PCIe functions, which is applied to a preset test control component. The method includes:

[0056] Step S11: Obtain a driver test command sent by a standard PCIe device, and parse the driver test command to determine the driver test category; the driver test command is sent by the PCIe device under test to the standard PCIe device, and the standard PCIe device is constructed based on the transaction-level simulation model of a preset hardware acceleration platform.

[0057] This embodiment discloses a test control component, and a standard PCIe device is constructed based on the transaction-level simulation model of a preset hardware acceleration platform; wherein, the preset hardware acceleration platform specifically refers to the Zebu platform, that is, the present application uses the Zebu PCIe Transactor as the standard test device, that is, the standard PCIe device. After the standard PCIe device obtains the driver test command sent by the PCIe device under test, it will send the driver test command to the test control component, and this component will first parse the driver test command to determine the current driver test category.

[0058] It should be noted that the process of the PCIe device under test sending a driver test command to the standard PCIe device includes: the PCIe device under test sends a memory read request to the standard PCIe device; the memory read request carries the driver test command; the standard PCIe device responds to the memory read request and returns the read memory data to the PCIe device under test to complete the communication handshake with the PCIe device under test.

[0059] That is, an embodiment of the present application discloses a handshaking mechanism for ensuring normal communication between the standard PCIe device and the PCIe device under test, and enabling the smooth sending and response of test stimuli. Among them, the PCIe device under test is used as the PCIe master device, and the standard PCIe device is used as the PCIe slave device. First, the PCIe master device initiates a Memory Read Request (memory read request) and adds a driver test command to the Memory TLP packet; after receiving the memory read request, the PCIe slave device directly returns a read completion packet with memory data to complete the handshake feedback with the PCIe master device to ensure that the master and slave devices are in a normal measurable state; then, the PCIe slave device transfers the received driver test command to the test control component for subsequent self-driving test control processes.

[0060] Specifically, the command format of the drive test command includes a test type identifier, a test scenario identifier, and a test index. Among them, the test type identifier includes first identification information for indicating message class drive tests and second identification information for indicating configuration class drive tests. Correspondingly, parsing the drive test command to determine the drive test category includes: parsing the drive test command to obtain the test type identifier; if the test type identifier is the first identification information, determining that the drive test category of the drive test command is a message class drive test; if the test type identifier is the second identification information, determining that the drive test category of the drive test command is a configuration class drive test.

[0061] It can be understood that to achieve the automatic execution of drive tests (subsequently abbreviated as self-driven tests, i.e., Self-driven Testing), a convenient control information interaction path needs to be constructed between the PCIe device under test and the standard PCIe device. Therefore, this application discloses a custom drive test command, and its command format can specifically include 3 bit fields, namely a test type identifier, a test scenario identifier, and a test index. Among them, as Figure 2 shown, the test type identifier includes first identification information (011b) for indicating message class drive tests and second identification information (010b) for indicating configuration class drive tests. Therefore, when determining the drive test category of the drive test command, the test type identifier can be obtained by parsing the drive test command, and then the specific drive test category can be determined through the test type identifier. If the test type identifier is the first identification information, it indicates that the drive test category of the drive test command is a message class drive test. If the test type identifier is the second identification information, it indicates that the drive test category of the drive test command is a configuration class drive test. In addition, in addition to the above 3 bit fields, the command format of the drive test command can also include a priority field and a timestamp field. The priority field can be used to control the sending order of test stimuli, and the timestamp field is used to record the sending and receiving times of test stimuli, facilitating performance analysis, thereby improving the flexibility and scalability of test commands and supporting more complex test requirements.

[0062] It should be noted that the test type identifier reuses the format bit field of the header of the transaction layer packet; the test scenario identifier and test index corresponding to the message class drive test reuse the message code bit field of the header of the transaction layer packet. The high four bits of the message code bit field are mapped to the test scenario identifier, and the low four bits are mapped to the test index; the test scenario identifier and test index corresponding to the configuration class drive test reuse the capability information of the PCIe configuration space. The capability identifier in the capability information is mapped to the test scenario identifier, and the register offset information in the capability information is mapped to the test index.

[0063] That is, considering the generality and comprehensibility of information interaction, by reusing the parameter information of the PCIe IP itself, this application can be compatible with the PCIe Transactor, which can greatly reduce the implementation complexity of the driver test control process. Specifically, as Figure 2 shown, by reusing the format bit field (i.e., the Fmt bit field) of the header (HEADER) of the Transaction Layer Packet (TLP), it is mapped to the test type identifier; for message-based driver tests, the message code bit field of the header of the transaction layer packet, that is, the TLP Message Code bit field, is reused, and the high four bits of the message code bit field are mapped to the test scenario identifier, and the low four bits of the code are mapped to the test index; for configuration-based driver tests, the capability information (PCIe Capability, i.e., CAP information) of the PCIe protocol configuration space is reused, the capability identifier (i.e., CAP ID) in the capability information is mapped to the test scenario identifier, and the register offset information in the capability information is mapped to the test index; among them, the byte index in the test index is mapped to the high 8 bits, and the value index is mapped to the low 8 bits.

[0064] Furthermore, the message-based driver tests include the first message-based driver test, the second message-based driver test, the third message-based driver test, and the fourth message-based driver test; among them, the first message-based driver test is used to test the functional correctness of the PCIe device under test to generate an advanced error report status and transmit it to the system layer to trigger the interrupt status; the second message-based driver test is used to test the functional correctness of the PCIe device under test to generate a traditional interrupt status and transmit it to the system layer to trigger the interrupt status; the third message-based driver test is used to test the correctness of the write data at the corresponding address of the message signal interrupt configuration received by the PCIe device under test, as well as the correctness of the interrupt status and system response process triggered by the write operation; the fourth message-based driver test is used to test the correctness of the write data at the corresponding address of the extended message signal interrupt table configuration received by the PCIe device under test, as well as the correctness of the interrupt status and system response process triggered by the write operation.

[0065] And the configuration-based driver tests include the first configuration-based driver test, the second configuration-based driver test, the third configuration-based driver test, and the fourth configuration-based driver test; among them, the first configuration-based driver test is used to test the correctness of the power state switching and link state switching of the PCIe device under test; the second configuration-based driver test is used to test the correctness of all link rate switching supported by the PCIe device under test; the third configuration-based driver test is used to test the correctness of all link bandwidth switching supported by the PCIe device under test; the fourth configuration-based driver test is used to test the correctness of the link cut-off function, link state switching, system state, and interrupt response of the PCIe device under test.

[0066] That is, by analyzing the source types of PCIe test stimuli, the present application discloses a self-driven test set, which is divided into message-driven tests and configuration-driven tests. It can be understood that self-driven tests mainly focus on the integration test scenarios related to protocol-related external interactions that cannot be automatically responded to by the PCIe Transactor. Specifically, 8 test scenarios are designed. Among them, both message-driven tests and configuration-driven tests include 4 test scenarios. These self-driven test scenarios are all related to the PCIE protocol. To implement these different functions, PCIe provides corresponding message passing paths and configuration space configuration interfaces at the protocol layer. It should be noted that the 8 test scenarios mentioned in this embodiment are only specific examples given in this embodiment, and more test scenarios can be added in different application scenarios to cover a wider range of PCIe functions, such as hot plug test: testing the behavior of the device in the hot plug scenario; multi-device communication test: testing the communication and collaborative work between multiple PCIe devices; performance test: testing the performance of the device under different loads (such as throughput, latency, etc.).

[0067] The four test scenarios corresponding to message class-driven tests respectively include the first message class-driven test, the second message class-driven test, the third message class-driven test, and the fourth message class-driven test. Among them, the first message class-driven test specifically refers to the AER (Advanced Error Reporting) self-driven test, which is mainly used to test the functional correctness of the PCIe device under test (i.e., DUT, Device Under Test) to generate the AER status and transmit it to the system layer to trigger the interrupt status, as well as the correctness of the interaction response process between the interrupt status and the system. That is, the test content is to verify whether the DUT can correctly generate the AER status when an error occurs, and to verify whether the AER status can be correctly transmitted to the system layer and trigger the corresponding interrupt. The AER status can specifically include Correctable Errors, Fatal Errors, and Non-Fatal Errors. The second message class-driven test specifically refers to the INTx (Legacy Interrupt) self-driven test, which is specifically used to test the functional correctness of the PCIe device under test to generate the INTx interrupt status and transmit it to the system layer to trigger the interrupt status, as well as the correctness of the interaction response process between the interrupt status and the system. That is, the test content is to verify whether the DUT can correctly generate the INTx interrupt (such as Assert_INTA, Deassert_INTA, etc.), and to verify whether the INTx interrupt can be correctly transmitted to the system layer and trigger the corresponding interrupt handling. The third message class-driven test specifically refers to the MSI (Message Signaled Interrupts) self-driven test, which is specifically used to test whether the data written to the corresponding address is correct after the PCIe device under test receives the MSI configuration, as well as the correctness of the interrupt status and system response process triggered by the write operation. That is, the test content is to verify whether the DUT can correctly receive the MSI configuration, and to verify whether the write operation can correctly trigger the interrupt and check whether the system response meets the expectations. The fourth message class-driven test specifically refers to the MSI-X (Message Signaled Interrupts – Extended) self-driven test, which is mainly used to test whether the data written to the corresponding address is correct after the PCIe device under test receives the MSI-X table configuration, as well as the correctness of the interrupt status and system response process triggered by the write operation. That is, the test content is to verify whether the DUT can correctly receive the MSI-X configuration, and to verify whether the write operation can correctly trigger the interrupt and check whether the system response meets the expectations.

[0068] The four test scenarios corresponding to the configuration class driver test respectively include the first configuration class driver test, the second configuration class driver test, the third configuration class driver test, and the fourth configuration class driver test. Among them, the first configuration class driver test specifically refers to the POWER (power) self-driving test, which is mainly used to test the power management function of the DUT, including the correctness of power state switching and link state switching, that is, the test content is to verify whether the DUT can correctly switch the power state, and verify whether the link state is correctly switched when the power state is switched. The second configuration class driver test specifically refers to the LINK SPEED (link rate) self-driving switching test, which is mainly used to test the correctness of all link rate switches supported by the DUT, that is, the test content is to verify whether the DUT can correctly switch the link rate, and verify whether the link state is normal after the link rate is switched. The third configuration class driver test specifically refers to the LINK WIDTH (link bandwidth) self-driving switching test, which is mainly used to test the correctness of all link bandwidth switches supported by the DUT, that is, the test content is to verify whether the DUT can correctly switch the link width, and verify whether the link state is normal after the link width is switched. The fourth configuration class driver test specifically refers to the LINK DOWN (link cut-off) self-driving test, which is mainly used to test the correctness of the link cut-off function, link state switching, system state, and interrupt response of the PCIe device under test, that is, the test content is to verify whether the DUT can correctly cut off the link, verify whether the link state and related system states are correctly switched after the link is cut off, and verify whether the link cut-off triggers the corresponding interrupt response.

[0069] In summary, the test scenarios covered by the self-driving test set are summarized as shown in Table 1:

[0070] Table 1 Self-driving test set

[0071]

[0072] Step S12: If the driver test category is a message class driver test, a message stimulus is constructed based on the preset transaction layer packet format and the test scenario identifier and test index in the driver test command, and the message stimulus is sent to the PCIe device under test through a standard PCIe device.

[0073] In this embodiment, if the driver test category is a message class driver test, a message stimulus will be constructed based on the preset transaction layer packet format and the test scenario identifier and test index in the driver test command, and the message stimulus will be sent to the PCIe device under test through a standard PCIe device. After receiving the message stimulus, the PCIe device under test can continue to complete the subsequent driver test process. It can be seen that through the test control component of the present application, automatic feedback of messages can be realized, and a fully automatic test process between the standard PCIe device and the PCIe device under test can be realized.

[0074] Step S13: If the driver test category is a configuration - type driver test, locate the target register from the PCIe configuration space of the standard PCIe device based on the test scenario identifier and test index in the driver test command, and configure the target register based on the test index.

[0075] In this embodiment, if the driver test category is a configuration - type driver test, locate the target register from the PCIe configuration space of the standard PCIe device based on the test scenario identifier and test index in the driver test command, and configure the target register based on the test index. After the configuration is completed, the PCIe device under test can continue to complete the subsequent driver test process. It can be seen that through the test control component of the present application, the automatic configuration of the standard PCIe device can be realized, and the full - automatic test process between the standard PCIe device and the PCIe device under test can be achieved.

[0076] It can be seen that the present application discloses a test control component, and a standard PCIe device is constructed based on the transaction - level simulation model of a preset hardware acceleration platform. After the standard PCIe device obtains the driver test command sent by the PCIe device under test, it will send the driver test command to the test control component. This component will first parse the driver test command to determine the current driver test category. If the driver test category is a message - type driver test, a message stimulus will be formed based on the preset transaction - layer packet format and the test scenario identifier and test index in the driver test command, and the message stimulus will be sent to the PCIe device under test through the standard PCIe device. After the PCIe device under test receives the message stimulus, it can continue to complete the subsequent driver test process. If the driver test category is a configuration - type driver test, locate the target register from the PCIe configuration space of the standard PCIe device based on the test scenario identifier and test index in the driver test command, and configure the target register based on the test index. After the configuration is completed, the PCIe device under test can continue to complete the subsequent driver test process. In this way, through the test control component of the present application, the automatic configuration of the standard PCIe device and the automatic feedback of messages can be realized, and the full - automatic test process between the standard PCIe device and the PCIe device under test can be achieved, greatly improving the test efficiency of the PCIe function.

[0077] See Figure 3 As shown, the embodiment of the present application discloses a specific test method for PCIe functions. Compared with the previous embodiment, this embodiment further explains and optimizes the technical solution. Specifically, it includes:

[0078] Step S21: Obtain the driver test command sent by the standard PCIe device, and parse the driver test command to determine the driver test category; the driver test command is sent from the PCIe device under test to the standard PCIe device, and the standard PCIe device is built based on the transaction-level simulation model of the preset hardware acceleration platform.

[0079] In this embodiment, as Figure 4 shown, the test control component specifically includes a self-driving control module, a message excitation module, and a configuration management module. First, the self-driving control module parses the Fmt bit field to determine the driver test category of the driver test command.

[0080] Step S22: If the driver test category is a message-type driver test, splice the test scenario identifier and test index in the driver test command according to the bit field to obtain the spliced target message code.

[0081] In this embodiment, if the driver test category is a message-type driver test, the self-driving control module splices the test scenario identifier and test index in the driver test command according to the bit field to obtain the spliced target message code, and then sends the target message code to the message excitation module for subsequent processing.

[0082] Step S23: Build a message excitation based on the header structure of the preset transaction layer packet format and the target message code, and call the callback function of the standard PCIe device to send the message excitation to the PCIe device under test through the standard PCIe device.

[0083] In this embodiment, after receiving the target message code sent by the self-driving control module, the message excitation module builds a message excitation based on the header structure of the preset transaction layer packet format and the target message code, and calls the callback function (Callback) of the standard PCIe device to send the message excitation to the PCIe device under test through the standard PCIe device. That is, this application reuses the callback function provided by the Transactor to reply the message excitation to the DUT, without the need to develop an additional Transactor function interface. After receiving the message, the DUT can continue to complete the subsequent self-driving test process.

[0084] Step S24: If the driver test category is a configuration-type driver test, scan the capability pointer of the PCIe configuration space of the standard PCIe device based on the test scenario identifier in the driver test command to locate the corresponding target offset address.

[0085] In this embodiment, if the drive test category is a configuration - type drive test, the self - drive control module scans the capability pointer of the PCIe configuration space of the standard PCIe device based on the test scenario identifier in the drive test command to locate the corresponding target offset address, and then sends the target offset address to the configuration management module for subsequent processing.

[0086] In the specific implementation, scanning the capability pointer of the PCIe configuration space of the standard PCIe device based on the test scenario identifier in the drive test command to locate the corresponding target offset address includes: determining the capability pointer in the PCIe configuration space of the standard PCIe device; starting from the offset address pointed to by the capability pointer, traversing each capability structure in the PCIe configuration space based on the test scenario identifier in the drive test command until the target capability structure is read; the capability identifier of the target capability structure is the test scenario identifier in the drive test command; determining the target offset address pointed to by the target capability structure.

[0087] First, it should be pointed out that the configuration space of a PCIe device is a standardized data structure used to describe the characteristics and functions of the device. The Capability (CAP) structure in the configuration space is used to describe the extended functions of the device, such as power management, advanced error reporting, etc. Each CAP structure has a CAP ID (capability identifier) and a Next CAP Pointer (indicating the offset address pointing to the next CAP structure), which are used to traverse all CAP structures in the configuration space.

[0088] In this embodiment, first determine the CAP pointer in the PCIe configuration space of the standard PCIe device. The CAP pointer is usually located at the 0x34 offset of the configuration space (i.e., the Capabilities Pointer register), and this register stores the offset address of the first CAP structure. In this embodiment, starting from the offset address pointed to by the capability pointer, traverse all the capability structures in the PCIe configuration space based on the test scenario identifier in the drive test command until the target capability structure is found. The CAP ID of the target capability structure is the test scenario identifier in the drive test command, and determine the target offset address pointed to by the target capability structure. The specific traversal process is as follows: Read the CAP pointer from the 0x34 offset of the configuration space to obtain the offset address of the first CAP structure. Starting from the offset address pointed to by the CAP pointer, read the CAP ID of the current CAP structure. If the CAP ID is the test scenario identifier, it means the target CAP structure has been found, and record its current offset address as the target offset address. If the CAP ID is not the test scenario identifier, read the Next CAP Pointer, jump to the next CAP structure and continue scanning, repeating the above process until the target CAP structure is found or all CAP structures have been traversed.

[0089] Step S25: Locate the target register from the PCIe configuration space of the standard PCIe device based on the target offset address and the test index in the drive test command.

[0090] In this embodiment, after the configuration management module receives the target offset address sent by the self-driving control module, it then locates the target register from the PCIe configuration space of the standard PCIe device based on the target offset address and the test index in the drive test command.

[0091] Specifically, the test index in the drive test command includes a byte index and a value index; correspondingly, locating the target register from the PCIe configuration space of the standard PCIe device based on the target offset address and the test index in the drive test command includes: combining the target offset address and the byte index in the drive test command to obtain a register address; locating the target register from the PCIe configuration space of the standard PCIe device based on the register address.

[0092] That is, the test index includes a byte index (Byte index) and a value index (Value index). First, the target offset address and the byte index are combined to obtain a register address, so as to locate the target register from the PCIe configuration space of the standard PCIe device based on the register address. Among them, the value index is used to configure the target register subsequently.

[0093] Step S26: Read the current data of the target register, perform an OR operation on the value index in the test index and the current data to obtain an operation result, and configure the target register by calling the backdoor function of the standard PCIe device based on the operation result.

[0094] In this embodiment, call the read configuration space function of the Transactor to read the current data of the target register, then perform an OR operation on the value index (Value index) in the test index and the current data to obtain an operation result, so as to configure the target register by calling the backdoor function (Backdoor) of the standard PCIe device based on the operation result. After the configuration is completed, the PCIe device to be tested can continue to complete the subsequent self-driving test process.

[0095] Among them, for the more specific processing process of the above step S21, reference can be made to the corresponding content disclosed in the foregoing embodiments, and details will not be elaborated here.

[0096] It can be seen that in view of the problems that the PCIe Transactor cannot provide standard IP function verification capabilities and has low verification efficiency, this application discloses a self-driven test method. By initiating self-driven test requirements from the side of the PCIe device under test and implementing self-driven control responses on the side of the standard PCIe device, autonomous responses to test stimuli are achieved, and standard configurations are made for the test stimuli. That is, it can achieve automatic configuration of the ZEBU PCIe Transactor and automatic feedback of messages, realizing a fully automated test process with the DUT and improving the verification efficiency of PCIe standard functions.

[0097] Next, taking the self-driven test of message class INTx and the self-driven test of configuration class LINK SPEED as examples respectively, the technical solutions of this application will be described in detail.

[0098] First, according to the definition rules of the drive test commands, the self-driven test commands for message class INTx are defined as shown in Table 2:

[0099] Table 2 Definition of INTx Self-driven Test Commands

[0100]

[0101] The self-driven test commands for configuration class LINK SPEED are shown in Table 3:

[0102] Table 3 Definition of LINK SPEED Self-driven Test Commands

[0103]

[0104] Furthermore, for the INTx self-driven test commands, the operation process of the self-driven control module is as follows:

[0105] Directly splice Code[3:0] and Index[3:0] in Table 2 to form a complete target message encoding, and then send the target message encoding to the message stimulus module for subsequent processing. The target message encoding is specifically shown in Table 4:

[0106] Table 4 INTx Self-driven Test Message Encoding

[0107]

[0108] For the LINK SPEED self-driven test commands, the operation process of the self-driven control module is as follows:

[0109] Scan the CAP pointer of the PCIe configuration space of the PCIe Transactor through the test scenario identifier 10h. Assume that the target offset address is located at 70h, and then send the target offset address to the configuration management module for subsequent processing.

[0110] After receiving the target message encoding sent by the self-driving control module, the message incentive module constructs the message incentive for the INTx self-driving test according to the message class standard TLP header structure and the target message encoding, as shown in Table 5 specifically:

[0111] Table 5 Message Incentive

[0112]

[0113] Then, it calls the callback function of the PCIe Transactor to perform TLP packet assembly and sends it to the PCIe device under test through the CPLD feedback channel to meet the INTx test requirements of the PCIe device under test. Among them, 34000000h in Byte0-Byte3 can be understood as a combination of multiple fields of the header, such as Fmt (indicating the type and length of the TLP), Type (indicating the type of the TLP), TC (traffic class), Attr (attributes of the TLP), Length (data length of the TLP), etc.

[0114] After receiving the target offset address sent by the self-driving control module, the configuration management module first performs offset merging with the Byte index in the test index to locate the target register address to be configured as: 70h + 30h = A0h. Then it calls the read configuration space function of the Transactor to read the current data of A0h, performs an OR operation with the Value index value, and uses the obtained new data as the target register configuration data. Finally, it calls the backdoor function of the Transactor to implement the configuration of the target register.

[0115] See Figure 5 As shown, the embodiment of the present application discloses a test device for PCIe functions, which is applied to a preset test control component. The device includes:

[0116] Parsing module 11, configured to obtain a driver test command sent by a standard PCIe device and parse the driver test command to determine the driver test category; the driver test command is sent by the PCIe device under test to the standard PCIe device, and the standard PCIe device is constructed based on a transaction-level simulation model of a preset hardware acceleration platform;

[0117] Message incentive reply module 12, configured to, if the driver test category is a message class driver test, construct a message incentive based on a preset transaction layer packet format and a test scenario identifier and a test index in the driver test command, and send the message incentive to the PCIe device under test through the standard PCIe device;

[0118] The configuration module 13 is configured to, if the driver test category is a configuration - type driver test, locate a target register from the PCIe configuration space of the standard PCIe device based on the test scenario identifier and the test index in the driver test command, and configure the target register based on the test index.

[0119] It can be seen that the present application discloses a test control component, and a standard PCIe device is constructed based on a transaction - level simulation model of a preset hardware acceleration platform. After the standard PCIe device receives a driver test command sent by a PCIe device under test, it will send the driver test command to the test control component. This component will first parse the driver test command to determine the current driver test category. If the driver test category is a message - type driver test, a message stimulus will be formed based on a preset transaction - layer packet format and the test scenario identifier and the test index in the driver test command, and the message stimulus will be sent to the PCIe device under test through the standard PCIe device. After receiving the message stimulus, the PCIe device under test can continue to complete the subsequent driver test process. If the driver test category is a configuration - type driver test, a target register is located from the PCIe configuration space of the standard PCIe device based on the test scenario identifier and the test index in the driver test command, and the target register is configured based on the test index. After the configuration is completed, the PCIe device under test can continue to complete the subsequent driver test process. In this way, through the test control component of the present application, automatic configuration of the standard PCIe device and automatic feedback of messages can be achieved, realizing a fully automatic test process between the standard PCIe device and the PCIe device under test, and greatly improving the test efficiency of PCIe functions.

[0120] Since the embodiments of the device part correspond to the above - mentioned embodiments, the embodiments of the device part are described with reference to the embodiments of the above - mentioned method part and will not be elaborated here.

[0121] Figure 6 It is a schematic structural diagram of an electronic device provided by an embodiment of the present application. Specifically, it may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input - output interface 25, and a communication bus 26. Among them, the memory 22 is used to store a computer program, and the computer program is loaded and executed by the processor 21 to implement the relevant steps in the PCIe function test method executed by the electronic device disclosed in any of the foregoing embodiments.

[0122] In this embodiment, the power supply 23 is used to provide operating voltages for the various hardware devices on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and specific limitations thereof are not provided herein; the input / output interface 25 is used to obtain external input data or output data to the outside, and the specific interface type thereof can be selected according to specific application requirements, and specific limitations thereof are not provided herein.

[0123] Among them, the processor 21 may include one or more processing cores, such as a quad-core processor, an octa-core processor, etc. The processor 21 may be implemented in at least one of the following hardware forms: DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 21 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the wake state, also known as the CPU (Central Processing Unit); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 21 may be integrated with a GPU (Graphics Processing Unit), and the GPU is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 21 may also include an AI (Artificial Intelligence) processor, and the AI processor is used to process computational operations related to machine learning.

[0124] In addition, the memory 22, as a carrier for resource storage, may be a read-only memory, a random access memory, a magnetic disk, an optical disk, etc. The resources stored thereon include an operating system 221, a computer program 222, data 223, etc., and the storage method may be short-term storage or permanent storage.

[0125] Among them, the operating system 221 is used to manage and control each hardware device on the electronic device 20 and the computer program 222, so as to implement the operation and processing of the massive data 223 in the memory 22 by the processor 21. It can be Windows, Unix, Linux, etc. In addition to the computer program that can be used to complete the test method of the PCIe function executed by the electronic device 20 disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs that can be used to complete other specific tasks. In addition to the data that can include the data transmitted by the external device received by the electronic device, the data 223 may also include the data collected by its own input / output interface 25, etc.

[0126] Furthermore, the embodiment of the present application also discloses a computer-readable storage medium, in which a computer program is stored. When the computer program is loaded and executed by a processor, the steps of the test method of the PCIe function disclosed in any of the foregoing embodiments are implemented.

[0127] The embodiment of the present invention also discloses a computer program product, including a computer program / instructions. When the computer program / instructions are executed by a processor, the steps of the test method of the PCIe function disclosed in any of the foregoing embodiments are implemented.

[0128] In this specification, each embodiment is described in a progressive manner. The key point of each embodiment is to illustrate the differences from other embodiments. The same or similar parts among the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple. For the relevant parts, refer to the description of the method part.

[0129] Those skilled in the art can further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed in this article can be implemented by electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application.

[0130] The steps of the methods or algorithms described in connection with the embodiments disclosed herein may be implemented directly in hardware, in software modules executed by a processor, or in a combination thereof. The software modules may be located in a random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, compact disc read-only memory (CD-ROM), or any other form of storage medium known in the art.

[0131] Finally, it should also be noted that in this document, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprising", "including" or any other variation thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, article or device comprising the element.

[0132] The above has introduced in detail a method, device, medium and product for testing PCIe functions provided by the present invention. Specific examples are used in this document to elaborate on the principles and implementation manners of the present invention. The description of the above embodiments is only used to help understand the method and its core idea of the present invention; at the same time, for those of ordinary skill in the art, according to the idea of the present invention, there will be changes in the specific implementation manners and application scopes. In summary, the content of this specification should not be construed as a limitation to the present invention.

Claims

1. A method for testing PCIe functions, characterized in that: Applied to a preset test control component, the method comprises: Acquire a drive test command sent by a standard PCIe device, and parse the drive test command to determine a drive test category; the drive test command is sent by the PCIe device to be tested to the standard PCIe device, and the standard PCIe device is constructed based on a transaction-level simulation model of a preset hardware acceleration platform; If the drive test category is a message drive test, a message stimulus is formed based on a preset transaction layer data packet format and a test scenario identifier and a test index in the drive test command, and the message stimulus is sent to the PCIe device to be tested through the standard PCIe device; If the drive test category is a configuration drive test, locating a target register from a PCIe configuration space of the standard PCIe device based on a test scenario identifier and a test index in the drive test command, and configuring the target register based on the test index; The message stimulus is formed based on the preset transaction layer data packet format and the test scenario identifier and test index in the drive test command, including: The test scenario identifier and the test index in the drive test command are concatenated according to the bit field to obtain a concatenated target message code; A message stimulus is formed based on a header structure of a preset transaction layer data packet format and the target message encoding.

2. The PCIe function testing method according to claim 1, characterized in that: The command format of the drive test command includes a test type identifier, a test scenario identifier and a test index; wherein the test type identifier includes first identification information for indicating a message-type drive test and second identification information for indicating a configuration-type drive test; Accordingly, parsing the drive test command to determine the drive test category includes: Parsing the drive test command to obtain a test type identifier; If the test type identifier is the first identification information, determining that the drive test category of the drive test command is a message-type drive test; If the test type identifier is the second identification information, it is determined that the drive test category of the drive test command is a configuration type drive test.

3. The PCIe function testing method according to claim 2, characterized in that: The test type identifier multiplexes the format bit field of the header of the transaction layer data packet; the test scenario identifier and test index corresponding to the message class driver test multiplex the message code bit field of the header of the transaction layer data packet, the high four bits of the message code bit field are mapped to the test scenario identifier, and the low four bits are mapped to the test index; the test scenario identifier and test index corresponding to the configuration class driver test multiplex the capability information of the PCIe configuration space, the capability identifier in the capability information is mapped to the test scenario identifier, and the register offset information in the capability information is mapped to the test index.

4. The PCIe function testing method according to claim 1, characterized in that: The message class driver test includes a first message class driver test, a second message class driver test, a third message class driver test and a fourth message class driver test; wherein, the first message class driver test is used to test the functional correctness of the PCIe device under test generating an advanced error report status and transmitting it to the system layer to trigger an interrupt status; the second message class driver test is used to test the functional correctness of the PCIe device under test generating a traditional interrupt status and transmitting it to the system layer to trigger an interrupt status; the third message class driver test is used to test the correctness of the write data of the corresponding address received by the PCIe device under test configured by the message signal interrupt, as well as the correctness of the interrupt status triggered by the write operation and the correctness of the system response process; the fourth message class driver test is used to test the correctness of the write data of the corresponding address received by the PCIe device under test configured by the extended message signal interrupt table, as well as the correctness of the interrupt status triggered by the write operation and the correctness of the system response process.

5. The PCIe function testing method according to claim 1, characterized in that: The configuration class drive test includes a first configuration class drive test, a second configuration class drive test, a third configuration class drive test and a fourth configuration class drive test; wherein the first configuration class drive test is used to test the correctness of the power state switching and link state switching of the PCIe device under test; the second configuration class drive test is used to test the correctness of all link rate switching supported by the PCIe device under test; the third configuration class drive test is used to test the correctness of all link bandwidth switching supported by the PCIe device under test; the fourth configuration class drive test is used to test the correctness of the link disconnection function, link state switching, system state and interrupt response of the PCIe device under test.

6. The PCIe function testing method according to claim 1, characterized in that: The step of sending the message stimulus to the PCIe device to be tested through the standard PCIe device includes: The callback function of the standard PCIe device is called, and the message stimulus is sent to the PCIe device to be tested through the standard PCIe device.

7. The PCIe function testing method according to claim 1, characterized in that: The locating a target register from the PCIe configuration space of the standard PCIe device based on the test scenario identifier and the test index in the drive test command includes: Scanning the capability pointer of the PCIe configuration space of the standard PCIe device based on the test scenario identifier in the drive test command to locate the corresponding target offset address; A target register is located from a PCIe configuration space of the standard PCIe device based on the target offset address and a test index in the drive test command.

8. The PCIe function testing method according to claim 7, characterized in that: The scanning of the capability pointer of the PCIe configuration space of the standard PCIe device based on the test scenario identifier in the drive test command to locate the corresponding target offset address includes: Determining a capability pointer in a PCIe configuration space of the standard PCIe device; Starting from the offset address pointed to by the capability pointer, traverse each capability structure in the PCIe configuration space based on the test scenario identifier in the drive test command until a target capability structure is read; the capability identifier of the target capability structure is the test scenario identifier in the drive test command; Determine the target offset address pointed to by the target capability structure.

9. The PCIe function testing method according to claim 7, characterized in that: The test index in the drive test command includes a byte index and a value index; Accordingly, locating a target register from a PCIe configuration space of the standard PCIe device based on the target offset address and a test index in the drive test command includes: Merging the target offset address and the byte index in the drive test command to obtain a register address; A target register is located from a PCIe configuration space of the standard PCIe device based on the register address.

10. The PCIe function testing method according to claim 9, characterized in that: The configuring the target register based on the test index includes: Read the current data of the target register, and perform an OR operation on the value index in the test index and the current data to obtain an operation result; The target register is configured based on the operation result and by calling a backdoor function of the standard PCIe device.

11. The PCIe function testing method according to any one of claims 1 to 10, characterized in that: The process of the PCIe device to be tested sending the drive test command to the standard PCIe device includes: The PCIe device to be tested sends a memory read request to the standard PCIe device; the memory read request carries the drive test command; The standard PCIe device responds to the memory read request and replies the read memory data to the PCIe device to be tested, so as to complete the communication handshake with the PCIe device to be tested.

12. An electronic device, characterized in that: include: Memory, used to store computer programs; A processor, configured to execute the computer program to implement the steps of the PCIe function testing method according to any one of claims 1 to 11.

13. A computer-readable storage medium, characterized in that: Used to store computer programs; wherein, when the computer program is executed by a processor, the steps of the PCIe function testing method as described in any one of claims 1 to 11 are implemented.

14. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instruction is executed by a processor, the steps of the PCIe function testing method according to any one of claims 1 to 11 are implemented.

Images