PCIe function test method and device, medium and product
By analyzing the driver test commands and assigning or configuring test incentives according to categories, the fully automatic testing process of PCIe function is realized, solving the problem of inefficient testing in the existing technology and improving testing efficiency.
Patent Information
- Application Number
- CN202510353843.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-25
- Publication Date
- 2025-04-22
- Estimated Expiration
- 2045-03-25
AI Technical Summary
When the prior art performs PCIe function verification before the chip, the test efficiency is inefficient and depends on the technical ability and experience of the tester, and cannot provide standard IP function testing capabilities.
By obtaining the driver test commands sent by the standard PCIe device, parsing the commands to determine the driver test category. If it is a message-class driver test, a message incentive is formed and sent; if it is a configuration-class driver test, a target register is located and configured from the PCIe configuration space.
The fully automatic testing process for PCIe functions is realized, which improves testing efficiency and reduces the dependence on the technical capabilities of testers.
Smart Images

Figure CN119862077A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of hardware testing, and in particular to a PCIe function testing method, device, medium and product. Background Art
[0002] Verification is an indispensable and crucial part of the modern digital IC (Integrated Circuit) design process. Its purpose is to ensure that the design function is correctly implemented according to the established design specifications. PCIe (Peripheral Component Interconnect Express) is a universal serial expansion bus standard used for connecting hardware components inside 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 demand for testing PCIe functions has become more and more urgent, especially its pre-tapeline functional verification directly affects the success rate of chip tape-out.
[0003] At present, when performing PCIe functional verification before tape-out, it is usually necessary to build a verification environment, select a standard PCIe device to connect to the PCIe to be tested, establish a communication link, control the device to execute the verification test case, generate a TLP (Transaction Layer Packet) packet and send it to the device to be tested, and finally judge whether the verification meets expectations based on the test case execution results. Zebu (Zero Bug) platform is a hardware acceleration platform that can be used for prototype implementation and accelerated verification before chip tape-out. The PCIe Transactor (a transaction-level simulation model) it provides can be used to build a test environment, and some callback functions and backdoor functions are also provided. However, the platform has obvious defects. The implementation effect depends on the technical ability and experience of the tester. It cannot provide the test capability of the standard IP (Intellectual Property) function, and the tester needs to plan and develop test incentives one by one, resulting in low test efficiency.
[0004] In summary, how to improve the testing efficiency of PCIe functions is a problem that needs to be solved. Summary of the invention
[0005] In view of this, the purpose of the present invention is to provide a PCIe function testing method, device, medium and product, which can improve the testing efficiency of PCIe function. The specific scheme is as follows:
[0006] In a first aspect, the present application discloses a method for testing a PCIe function, comprising: Obtaining a drive test command sent by a standard PCIe device, and parsing 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 driver test category is a message driver test, a message stimulus is constructed based on the preset transaction layer data 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 to be tested through a standard PCIe device; If the driver test category is a configuration driver test, the 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.
[0007] Optionally, 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, the drive test command is parsed to determine the drive test category, including: Parse the driver 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-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.
[0008] Optionally, the test type identifier reuses 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 reuse 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 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.
[0009] 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.
[0010] 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.
[0011] 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: 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; The message stimulus is constructed based on the header structure of the preset transaction layer data packet format and the target message encoding.
[0012] Optionally, the message stimulus is sent to the PCIe device to be tested through a standard PCIe device, including: 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.
[0013] 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: 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; The target register is located 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.
[0014] Optionally, based on the test scenario identifier in the driver test command, a capability pointer of a PCIe configuration space of a standard PCIe device is scanned to locate a corresponding target offset address, including: Determine the capability pointer in the PCIe configuration space of a 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 the 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 capabilities structure.
[0015] Optionally, the test index in the drive test command includes a byte index and a value index; Accordingly, the target register is located 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, including: Combine the target offset address and the byte index in the drive test command to obtain the register address; A target register is located from a PCIe configuration space of a standard PCIe device based on the register address.
[0016] Optionally, configure the target register based on the test index, including: 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; Based on the operation results, the backdoor function of the standard PCIe device is called to configure the target register.
[0017] Optionally, the process of the PCIe device to be tested sending a driver 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 a drive test command; The standard PCIe device responds to the memory read request and replies the read memory data to the PCIe device under test to complete the communication handshake with the PCIe device under test.
[0018] In a second aspect, the present application discloses an electronic device, comprising: Memory, used to store computer programs; The processor is used to execute a computer program to implement the steps of the aforementioned disclosed PCIe function testing method.
[0019] 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 aforementioned method for testing the PCIe function are implemented.
[0020] In a fourth aspect, the present invention discloses a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the aforementioned PCIe function testing method.
[0021] Beneficial effects: The present application discloses a test control component, and constructs a standard PCIe device based on a transaction-level simulation model of a preset hardware acceleration platform. After obtaining the drive test command sent by the PCIe device to be tested, the standard PCIe device 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 data 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 to be tested through the standard PCIe device. After the PCIe device to be tested receives the message stimulus, it can continue to complete the subsequent drive test process. If the drive test category is a configuration-type drive test, the target register is 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 is configured based on the test index. After the configuration is completed, the PCIe device to be tested can continue to complete the subsequent drive test process. In this way, the test control component of the present application can realize automatic configuration of standard PCIe devices and automatic feedback of messages, realize a fully automatic test process between standard PCIe devices and PCIe devices to be tested, and greatly improve the test efficiency of PCIe functions. BRIEF DESCRIPTION OF THE DRAWINGS
[0022] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.
[0023] Figure 1 A flow chart of a PCIe function testing method disclosed in this application; Figure 2 A schematic diagram of a command format of a drive test command disclosed in this application; Figure 3A flowchart of a specific PCIe function testing method disclosed in this application; Figure 4 A self-driving test control flow chart disclosed in this application; Figure 5 A schematic diagram of the structure of a PCIe function test device disclosed in this application; Figure 6 This is a structural diagram of an electronic device disclosed in this application. DETAILED DESCRIPTION
[0024] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.
[0025] Currently, Zebu platform, as a hardware acceleration platform, can be used for prototype implementation and accelerated verification before chip tape-out. The PCIe Transactor (a transaction-level simulation model) it provides can be used to build a test environment, and some callback functions and backdoor functions are also provided. However, the platform has obvious defects. The implementation effect depends on the technical ability and experience of the tester. It cannot provide standard IP function testing capabilities, and the tester needs to plan and develop test incentives one by one, resulting in low test efficiency. To this end, the embodiment of the present application discloses a PCIe function testing method, equipment, medium and product, which can improve the test efficiency of PCIe functions.
[0026] See also Figure 1 As shown, the embodiment of the present application discloses a method for testing a PCIe function, which is applied to a preset test control component, and the method includes:
[0027] Step S11: obtaining a drive test command sent by a standard PCIe device, and parsing the drive test command to determine the 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.
[0028] This embodiment discloses a test control component, and builds a standard PCIe device based on a transaction-level simulation model of a preset hardware acceleration platform; wherein the preset hardware acceleration platform specifically refers to the Zebu platform, that is, this application uses the ZebuPCIe Transactor as a standard test device, that is, a standard PCIe device. After obtaining the drive test command sent by the PCIe device to be tested, the standard PCIe device 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.
[0029] It should be pointed out 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 replies the read memory data to the PCIe device under test to complete the communication handshake with the PCIe device under test.
[0030] That is, the embodiment of the present application discloses a handshake mechanism for ensuring that the communication between the standard PCIe device and the PCIe device to be tested is normal, and that the sending and response of the test stimulus can be completed smoothly. Among them, the PCIe device to be tested is used as the PCIe master device, and the standard PCIe device is used as the PCIe slave device. First, a Memory ReadRequest is initiated through the PCIe master device, and a drive test command is added to the Memory TLP packet; after the PCIe slave device receives the memory read request, it directly replies with a read completion packet with memory data, completes the handshake feedback with the PCIe master device, and ensures that the master and slave devices are in a normal testable state; then, the PCIe slave device transfers the received drive test command to the test control component for subsequent self-driving test control processes.
[0031] Specifically, 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 a first identifier information for representing a message-type drive test and a second identifier information for representing 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 the test type identifier; if the test type identifier is the first identifier 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 identifier information, determining that the drive test category of the drive test command is a configuration-type drive test.
[0032] It is understandable that in order to realize the automatic execution of the drive test (hereinafter referred to as self-driven testing), a convenient control information interaction path needs to be established between the PCIe device to be tested and the standard PCIe device. Therefore, the present application discloses a custom drive test command, and its command format may specifically include 3 bit fields, namely, test type identifier, test scenario identifier and test index. Among them, Figure 2 As shown, the test type identifier includes first identification information (011b) for indicating a message-type drive test and second identification information (010b) for indicating a configuration-type drive test. Therefore, when determining the drive test category of the drive test command, the drive test command can be parsed to obtain the test type identifier, and then the specific drive test category can be determined by the test type identifier. If the test type identifier is the first identification information, it means 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 means that the drive test category of the drive test command is a configuration-type drive test. In addition, in addition to the above three bit fields, the command format of the drive test command can also add a priority field and a timestamp field. The priority field can be used to control the order in which the test stimulus is sent, and the timestamp field is used to record the sending and receiving time of the test stimulus, which is convenient for performance analysis, thereby improving the flexibility and scalability of the test command and supporting more complex test requirements.
[0033] It should be pointed out that the test type identifier reuses the format bit field of the header of the transaction layer data packet; the test scenario identifier and test index corresponding to the message type driver test reuse 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 type 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.
[0034] That is, considering the universality and understandability of information interaction, this application can be compatible with PCIe Transactor by reusing the parameter information of PCIe IP itself, which can greatly reduce the implementation complexity of the drive test control process. Figure 2As shown, by reusing the format bit field (i.e., Fmt bit field) of the header (HEADER) of the transaction layer packet (Transaction Layer Packet, TLP), it is mapped to the test type identifier; for the message type driver test, the message code bit field of the header of the transaction layer packet, i.e., TLP Message Code bit field, is reused, and the upper four bits of the message code bit field are mapped to the test scenario identifier, and the lower four bits are mapped to the test index; for the configuration type driver test, 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; wherein, the byte index in the test index is mapped to the upper 8 bits, and the value index is mapped to the lower 8 bits.
[0035] Furthermore, 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.
[0036] In addition, 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; and 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.
[0037] That is, the present application discloses a self-driven test set by analyzing the source type of PCIe test stimulus, and divides the set into two categories: message-driven test and configuration-driven test. It can be understood that the self-driven test mainly focuses on the integrated test scenarios of protocol-related external interactions to which the PCIe Transactor cannot respond automatically, and specifically designs 8 test scenarios, of which message-driven test and configuration-driven test each include 4 test scenarios. These self-driven test scenarios are all related to the PCIE protocol. In order to achieve these different functions, PCIe provides corresponding message delivery 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-swap test: test the behavior of the device in the hot-swap scenario; multi-device communication test: test the communication and collaborative work between multiple PCIe devices; performance test: test the performance of the device under different loads (such as throughput, latency, etc.).
[0038] The four test scenarios corresponding to the message-type driven test include the first message-type driven test, the second message-type driven test, the third message-type driven test, and the fourth message-type driven test. Among them, the first message-type 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 (DUT) generating the AER state and transmitting it to the system layer to trigger the interrupt state, as well as the correctness of the interrupt state and the system interaction response process. That is, the test content is to verify whether the DUT can correctly generate the AER state when an error occurs, and whether the AER state can be correctly transmitted to the system layer and trigger the corresponding interrupt; the AER state can specifically include correctable errors (Correctable Errors), fatal errors (Fatal Errors) and non-fatal errors (Non-Fatal Errors). The second message-type driver 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 generating the INTx interrupt status and transmitting it to the system layer to trigger the interrupt status, as well as the correctness of the interrupt status and the system interaction response process. 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 verify whether the INTx interrupt can be correctly transmitted to the system layer and trigger the corresponding interrupt processing. The third message-type driver test specifically refers to the MSI (MessageSignaled Interrupts) self-driven test, which is specifically used to test whether the data written to the corresponding address after the PCIe device under test receives the MSI configuration is correct, as well as the correctness of the interrupt status triggered by the write operation and the system response process. That is, the test content is to verify whether the DUT can correctly receive the MSI configuration, and verify whether the write operation can correctly trigger the interrupt, and check whether the system response meets expectations. The fourth message-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 triggered by the write operation and the system response process. That is, the test content is to verify whether the DUT can correctly receive the MSI-X configuration, verify whether the write operation can correctly trigger the interrupt, and check whether the system response meets expectations.
[0039] The four test scenarios corresponding to the configuration-type drive test include the first configuration-type drive test, the second configuration-type drive test, the third configuration-type drive test, and the fourth configuration-type drive test. Among them, the first configuration-type drive test specifically refers to the POWER (power supply) self-driven test, which is mainly used to test the power management function of the DUT, including the correctness of the power state switching and the 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-type drive test specifically refers to the LINK SPEED (link rate) self-driven switching test, which is mainly used to test the correctness of all link rate switching 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-type drive test specifically refers to the LINK WIDTH (link bandwidth) self-driven switching test, which is mainly used to test the correctness of all link bandwidth switching 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 type drive test specifically refers to the LINK DOWN (link cut) self-driven test, which is mainly used to test the link cut function, link state switching, system state and interrupt response correctness 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 triggers the corresponding interrupt response.
[0040] In summary, the test scenarios covered by the self-driving test set are summarized as shown in Table 1:
[0041] Table 1 Self-driving test set
[0042]
[0043] Step S12: If the driver test category is a message driver test, a message stimulus is constructed based on a preset transaction layer data packet format and a test scenario identifier and a test index in the driver test command, and the message stimulus is sent to the PCIe device to be tested through a standard PCIe device.
[0044] In this embodiment, if the driver test category is a message driver test, a message stimulus is formed based on the preset transaction layer data 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 to be tested through the standard PCIe device. After the PCIe device to be tested receives the message stimulus, it can continue to complete the subsequent driver test process. It can be seen that the test control component of the present application can realize automatic feedback of the message and realize the fully automatic test process between the standard PCIe device and the PCIe device to be tested.
[0045] Step S13: If the drive test category is a configuration drive test, the 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 drive test command, and the target register is configured based on the test index.
[0046] In this embodiment, if the driver test category is a configuration driver test, the 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 to be tested can continue to complete the subsequent driver test process. It can be seen that the test control component of the present application can realize automatic configuration of the standard PCIe device and realize the fully automatic test process between the standard PCIe device and the PCIe device to be tested.
[0047] 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 obtains the drive test command sent by the PCIe device to be tested, the drive test command will be sent to the test control component, and the component will first parse the drive test command to determine the current drive test category. If the drive test category is a message-based drive test, a message stimulus will be formed based on the preset transaction layer data 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 to be tested through the standard PCIe device. After the PCIe device to be tested receives the message stimulus, it can continue to complete the subsequent drive test process. If the drive test category is a configuration-based drive test, the target register is 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 is configured based on the test index. After the configuration is completed, the PCIe device to be tested can continue to complete the subsequent drive test process. In this way, the test control component of the present application can realize automatic configuration of standard PCIe devices and automatic feedback of messages, realize a fully automatic test process between standard PCIe devices and PCIe devices to be tested, and greatly improve the test efficiency of PCIe functions.
[0048] See also Figure 3 As shown, the embodiment of the present application discloses a specific PCIe function testing method. Compared with the previous embodiment, this embodiment further illustrates and optimizes the technical solution. Specifically, it includes:
[0049] Step S21: Obtain the drive test command sent by the standard PCIe device, and parse the drive test command to determine the 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.
[0050] In this embodiment, Figure 4 As shown, the test control component specifically includes an autonomous driving control module, a message excitation module and a configuration management module. First, the autonomous driving control module parses the Fmt bit field to determine the driving test category of the driving test command.
[0051] Step S22: If the drive test category is a message drive test, 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.
[0052] In this embodiment, if the driving test category is a message-type driving test, the self-driving control module splices the test scenario identifier and test index in the driving 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.
[0053] Step S23: construct a message stimulus based on the header structure of the preset transaction layer data packet format and the target message code, and call the callback function of the standard PCIe device to send the message stimulus to the PCIe device to be tested through the standard PCIe device.
[0054] In this embodiment, after receiving the target message code sent by the self-driving control module, the message stimulus module builds a message stimulus based on the header structure of the preset transaction layer data packet format and the target message code, and calls the callback function (Callback) of the standard PCIe device to send the message stimulus to the PCIe device under test through the standard PCIe device. That is, this application reuses the callback function provided by Transactor to reply the message stimulus 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.
[0055] Step S24: If the driver test category is a configuration driver test, the capability pointer of the PCIe configuration space of the standard PCIe device is scanned based on the test scenario identifier in the driver test command to locate the corresponding target offset address.
[0056] In this embodiment, if the drive test category is a configuration 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.
[0057] In a specific implementation, the capability pointer of the PCIe configuration space of the standard PCIe device is scanned based on the test scenario identifier in the drive test command to locate the corresponding target offset address, including: 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; and determining the target offset address pointed to by the target capability structure.
[0058] First of all, 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 a 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 Next CAP Pointer (indicating the offset address pointing to the next CAP structure), which is used to traverse all CAP structures in the configuration space.
[0059] In this embodiment, the CAP pointer in the PCIe configuration space of the standard PCIe device is first determined. The CAP pointer is usually located at the 0x34 offset of the configuration space (i.e., the Capabilities Pointer register), which stores the offset address of the first CAP structure. Starting from the offset address pointed to by the capability pointer, this embodiment traverses all 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 the target offset address pointed to by the target capability structure is determined. The specific traversal process is: read the CAP pointer from the 0x34 offset of the configuration space, obtain the offset address of the first CAP structure, start 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 that the target CAP structure is found, and its current offset address is recorded 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 to continue scanning, and repeat the above process until the target CAP structure is found or all CAP structures are traversed.
[0060] 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.
[0061] In this embodiment, after receiving the target offset address sent by the self-driving control module, the configuration management module 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.
[0062] Specifically, the test index in the driver test command includes a byte index and a value index; accordingly, the target register is located 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, including: merging the target offset address and the byte index in the driver test command to obtain the register address; and locating the target register from the PCIe configuration space of the standard PCIe device based on the register address.
[0063] That is, the test index includes a byte index and a value index. First, the target offset address and the byte index are combined to obtain the register address, and then the target register is located 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 later.
[0064] Step S26: 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, and configure the target register based on the operation result and calling the backdoor function of the standard PCIe device.
[0065] In this embodiment, the read configuration space function of the Transactor is called to read the current data of the target register, and then the value index (Value index) in the test index and the current data are ORed to obtain the operation result, so as to configure the target register based on the operation result and call the backdoor function (Backdoor) of the standard PCIe device. After the configuration is completed, the PCIe device to be tested can continue to complete the subsequent self-driving test process.
[0066] For a more specific processing procedure of the above step S21, reference may be made to the corresponding contents disclosed in the above embodiments, which will not be described in detail here.
[0067] It can be seen that in response to the problem that PCIe Transactor cannot provide standard IP function verification capability and has low verification efficiency, the present application discloses a self-driven test method, which initiates a self-driven test demand through the PCIe device side to be tested, and realizes self-driven control response on the standard PCIe device side, realizes autonomous response to test stimulus, and performs standard configuration on the test stimulus, that is, it can realize automatic configuration of ZEBU PCIe Transactor and automatic feedback of messages, realize a fully automatic test process with DUT, and improve the verification efficiency of PCIe standard functions.
[0068] The technical solution of the present application is described in detail below by taking the message type INTx self-driving test and the configuration type LINK SPEED self-driving test as examples.
[0069] First, according to the definition rules of the drive test command, the message class INTx self-drive test command is defined as shown in Table 2:
[0070] Table 2 INTx self-drive test command definition
[0071]
[0072] The configuration class LINK SPEED self-driving test commands are shown in Table 3:
[0073] Table 3 LINK SPEED self-drive test command definition
[0074]
[0075] Furthermore, for the INTx self-driving test command, the self-driving control module operation process is as follows:
[0076] Directly concatenate Code[3:0] and Index[3:0] in Table 2 to form a complete target message code, and then send the target message code to the message excitation module for subsequent processing. The target message code is shown in Table 4:
[0077] Table 4 INTx self-drive test message encoding
[0078]
[0079] For the LINK SPEED self-drive test command, the self-drive control module operation process is as follows:
[0080] Through the test scenario identifier 10h, the CAP pointer of the PCIe configuration space of the PCIe Transactor is scanned, assuming that the target offset address is located at 70h, and then the target offset address is sent to the configuration management module for subsequent processing.
[0081] After receiving the target message code sent by the self-driving control module, the message stimulus module constructs the message stimulus of the INTx self-driving test according to the message class standard TLP header structure and the target message code, as shown in Table 5:
[0082] Table 5 Message incentives
[0083]
[0084] Then the callback function of PCIe Transactor is called to perform TLP packetization and send 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 in the packet header, such as Fmt (indicating the type and length of TLP), Type (indicating the type of TLP), TC (traffic category), Attr (attribute of TLP), Length (data length of TLP) and other fields.
[0085] After receiving the target offset address sent by the self-driving control module, the configuration management module first merges the offset with the Byte index in the test index and locates the target register address to be configured: 70h+30h=A0h. Then the Transactor's read configuration space function is called to read the current data of A0h and perform an OR operation with the Value index value, and the obtained new data is used as the target register configuration data. Finally, the Transactor's backdoor function is called to configure the target register.
[0086] See also Figure 5 As shown, the embodiment of the present application discloses a PCIe function test device, which is applied to a preset test control component, and the device includes: The parsing module 11 is used to obtain 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; A message stimulus reply module 12 is used for, if the drive test category is a message-type drive test, to form a message stimulus based on a preset transaction layer data packet format and a test scenario identifier and a test index in the drive test command, and to send the message stimulus to the PCIe device to be tested through the standard PCIe device; The configuration module 13 is used to locate the 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 if the drive test category is a configuration type drive test, and configure the target register based on the test index.
[0087] 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 obtains the drive test command sent by the PCIe device to be tested, the drive test command will be sent to the test control component, and the component will first parse the drive test command to determine the current drive test category. If the drive test category is a message-based drive test, a message stimulus will be formed based on the preset transaction layer data 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 to be tested through the standard PCIe device. After the PCIe device to be tested receives the message stimulus, it can continue to complete the subsequent drive test process. If the drive test category is a configuration-based drive test, the target register is 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 is configured based on the test index. After the configuration is completed, the PCIe device to be tested can continue to complete the subsequent drive test process. In this way, the test control component of the present application can realize automatic configuration of standard PCIe devices and automatic feedback of messages, realize a fully automatic test process between standard PCIe devices and PCIe devices to be tested, and greatly improve the test efficiency of PCIe functions.
[0088] Since the embodiments of the device part correspond to the above embodiments, please refer to the description of the embodiments of the method part for the embodiments of the device part, and will not be repeated here.
[0089] Figure 6 A schematic diagram of the structure of an electronic device provided in 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 performed by the electronic device disclosed in any of the aforementioned embodiments.
[0090] In this embodiment, the power supply 23 is used to provide working voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and the external device, and the communication protocol it follows is any communication protocol that can be applied to the technical solution of the present application, and is not specifically limited here; the input and output interface 25 is used to obtain external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs and is not specifically limited here.
[0091] Among them, the processor 21 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 21 can be implemented in at least one hardware form of 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 awake state, also known as a 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), which 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, which is used to process computing operations related to machine learning.
[0092] In addition, the memory 22, as a carrier for storing resources, can be a read-only memory, a random access memory, a disk or an optical disk, etc. The resources stored thereon include an operating system 221, a computer program 222 and data 223, etc. The storage method can be temporary storage or permanent storage.
[0093] Among them, the operating system 221 is used to manage and control the hardware devices and computer programs 222 on the electronic device 20, so as to realize the operation and processing of the massive data 223 in the memory 22 by the processor 21, which can be Windows, Unix, Linux, etc. In addition to including a computer program that can be used to complete the test method of the PCIe function performed by the electronic device 20 disclosed in any of the aforementioned embodiments, the computer program 222 can further include a computer program that can be used to complete other specific tasks. In addition to data transmitted from an external device received by the electronic device, the data 223 can also include data collected by its own input and output interface 25, etc.
[0094] Furthermore, an 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 test method steps of the PCIe function disclosed in any of the aforementioned embodiments are implemented.
[0095] An embodiment of the present invention further discloses a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the PCIe function testing method disclosed in any of the aforementioned embodiments.
[0096] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between 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, and the relevant parts can be referred to the method part.
[0097] Those skilled in the art may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented with 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 in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.
[0098] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a compact disc read-only memory (CD-ROM), or any other form of storage medium known in the art.
[0099] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.
[0100] The above is a detailed introduction to a PCIe function testing method, device, medium and product provided by the present invention. Specific examples are used in this article to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea. At the same time, for those skilled in the art, according to the idea of the present invention, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on 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, the 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 drive test command, and the target register is configured based on the test index.
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 message stimulus is formed based on the preset transaction layer data packet format and the test scenario identifier and the 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.
7. 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.
8. 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.
9. The PCIe function testing method according to claim 8, 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.
10. The PCIe function testing method according to claim 8, 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.
11. The PCIe function testing method according to claim 10, 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.
12. The PCIe function testing method according to any one of claims 1 to 11, 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.
13. 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 12.
14. A computer-readable storage medium, characterized in that: Used to store a computer program; 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 12 are implemented.
15. 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 12 are implemented.
Citation Information
Patent Citations
Keyword-based automated test engine
CN107807878A
Comprehensive monitoring system software test platform
CN112181850A
Vector index registers
CN113853582A
Driving package testing method and related device
CN115658493A
SMBus module level verification system based on UVM and VIP
CN117057286A