Interface testing system for computers

Abstract

This application discloses a computer interface testing system, relating to the field of computer technology. By employing a link parameter monitoring module, a multi-dimensional indicator monitoring module, a traffic indicator testing module, and a version switching control module working together, this system tests the multi-dimensional indicator parameters of the root complex under test when switching between current test software, and dynamically tests the traffic indicators of the root complex under test under various test modes. This solves the problems that using a preset fixed version of test software simulation cannot handle switching tests between different versions of test software, and that using a preset fixed version simulation method cannot efficiently test the performance parameters of the root complex. Therefore, this invention not only enables testing the performance parameters of the root complex under various different versions of test software, but also improves the efficiency of root complex performance testing without the need for simulation software.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a computer interface testing system. Background Technology

[0002] The Root Complex (RC) is an interface component in the Peripheral Component Interconnect Express (PCIe) system that connects the processor, memory subsystem, and PCIe devices. Performance testing of the PCIe RC during the chip front-end verification phase is crucial for ensuring system reliability and efficiency. As the core hub between the processor and external devices, the PCIe RC undertakes key functions such as protocol conversion, data transmission scheduling, terminal device management, and error handling. Its performance directly determines the overall system throughput, transmission latency, quality of service (QoS), and long-term operational stability. With the evolution of the PCIe protocol to the standard test versions Gen5 / Gen6, single-channel data transmission rates have exceeded 32GT / s. Simultaneously, application scenarios have expanded from traditional storage to numerous critical areas, posing unprecedented challenges to the RC: in modern scenarios, it is necessary to support the synchronous transmission of massive amounts of data, requiring the RC to maintain data integrity under a maximum bandwidth of 128GT / s; this places stringent deterministic requirements on the RC's transaction scheduling algorithm; and facing mixed traffic and high-density virtualized device access, the RC is a mechanism for achieving intelligent QoS assurance.

[0003] Currently, the Universal Verification Methodology (UVM) is commonly used to construct layered and configurable test environments for RC (Responsive Controller). Formal verification ensures the completeness of the protocol state machine, and prototype simulation using a Field Programmable Gate Array (FPGA) is combined to conduct real-world load stress testing. For example, at the transaction layer injection end, a conflict scenario is simulated where multiple device endpoints initiate read / write requests, dynamically adjusting the proportion of message types and load distribution in the Transaction Layer Packet (TLP), while simultaneously monitoring the dynamic adjustment effect of the credit node's control mechanism on throughput. In related technologies, computer RC is typically simulated using a pre-set fixed version of test software. However, this method cannot handle switching between different versions of test software, and the complex and interwoven wiring within the computer's RC makes it inefficient to test the RC's performance parameters using a pre-set fixed version simulation. Summary of the Invention

[0004] This application provides a computer interface testing system to at least solve the problem in related technologies that the performance parameters of RC cannot be efficiently tested by using a preset fixed version simulation method.

[0005] This application provides a computer interface testing system, comprising: The link parameter monitoring module is used to monitor the current link parameters of the root complex under test when it switches to the current test software. The multidimensional indicator monitoring module is used to monitor the multidimensional indicator parameters of the root complex under test within a preset time period. The version switching control module is used to control the link parameter monitoring module and the multi-dimensional indicator monitoring module to stop monitoring based on the current link parameters of the root complex under test and the multi-dimensional indicator parameters of the root complex under test within a preset time, and to switch from the current version of the test software to the target version of the test software. The traffic metrics testing module is used to dynamically test the traffic metrics of the root complex under test in multiple test modes according to a preset test template after the current version of the test software is switched to the target version of the test software. The preset test template is generated based on preset configuration parameters.

[0006] This application utilizes a link parameter monitoring module, a multi-dimensional indicator monitoring module, a traffic indicator testing module, and a version switching control module to work together to test the multi-dimensional indicator parameters of the root complex under test when switching between current test software and to dynamically test the traffic indicators of the root complex under test under various test modes. This solves the problems that using a preset fixed version of the test software for simulation cannot handle switching tests between different versions of the test software, and that using a preset fixed version for simulation cannot efficiently test the performance parameters of the RC (Responsible Controller). Therefore, this invention not only enables testing of the root complex's performance parameters under various different versions of test software, but also improves the efficiency of root complex performance testing without the need for simulation software. Attached Figure Description

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

[0008] Figure 1 A schematic diagram of the structure of a computer interface testing system provided in an embodiment of this application; Figure 2 A schematic diagram of the structure of another computer interface testing system provided in an embodiment of this application; Figure 3This is a schematic diagram of a distributed timestamp marking architecture provided in an embodiment of this application; Figure 4 This is a schematic diagram of the hardware structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0009] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0010] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0011] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0012] This application provides a computer interface testing system, such as... Figure 1 As shown, it includes: a link parameter monitoring module 11, a multi-dimensional indicator monitoring module 12, a traffic indicator testing module 13, and a version switching control module 14.

[0013] Among them, Figure 1 In the middle, the link parameter monitoring module 11 is used to monitor the current link parameters when the root complex under test 15 performs the current test software switch.

[0014] In some specific implementations, the current link parameters include: the start and end times of the current test software performing the switching action. For example... Figure 2 As shown, the link parameter monitoring module 11 includes: a version switching monitoring unit 111, which is used to monitor the start and end times of the switching action performed by the root complex under test 15 in the current version of the software through link training and state machine.

[0015] Specifically, the test software versions include, but are not limited to, Gen3, Gen4, and Gen5. For example, if the current test software for the root complex under test is Gen3, and the Gen3 test software has an error state, it is necessary to switch from Gen3 to Gen4. During this process, the Link Training and Status State Machine (LTSSM) in the version switch monitoring unit is used for analysis, and the state machine transition events are captured in real time.

[0016] For example, when the version switching monitoring unit detects that the link training and state machine have entered the version switching state (Recovery state), it records the initial timestamp of this time, that is, the start time of the root complex under test performing the switching action in the current version of the software, denoted by T_start, which is called the rate switching trigger point.

[0017] For example, when the version switching monitoring unit detects that the current operating speed field of the link in the link control register is stable, it stops and records the end timestamp, which is the end time of the root complex under test performing the switching action in the current version of the software, denoted by T_end, and is called the rate switching completion point.

[0018] For example, the link of the root complex under test entering the switching state (Recovery state) from the normal working state (L0) can indicate that the root complex under test needs to enter the switching state from the normal working state (L0) due to misconfiguration or active version switching.

[0019] In some specific implementations, the current link parameters during the switching of the current test software include: the switching result of the target test software, and the link parameter monitoring module, such as... Figure 2 As shown, it includes: a dynamic polling recording unit 112, which is used to record version field jump events through register dynamic polling control to obtain the switching result of the target test software.

[0020] For example, the dynamic polling recording unit records version field jump events through register dynamic polling control to obtain the switching result of the target test software, specifically including the following steps: Step a1: Continuously poll the Link Control Register -> Current Link Speed ​​field.

[0021] Specifically, it initiates dynamic polling logic on the link control register and the current link rate register, comparing the current value of the current link rate read in each poll with the previous historical value. Once a change in the current value is detected, a "rate jump event" is immediately recorded. The current link parameters recorded in this event at the time of the current test software switch include, but are not limited to: the timestamp of the jump, the rate value before the jump, and the rate value after the jump.

[0022] Step a2: Determine whether polling monitoring is complete.

[0023] 1. The LTSSM state remains stable at L0 for a period of time (e.g., several consecutive polls are all at L0, excluding glitches).

[0024] 2. The value of the Current Link Speed ​​field remains stable at the target rate value and does not change after multiple consecutive polls.

[0025] At this point, the switchover is considered complete.

[0026] Step a3: Record the completion point information.

[0027] Record the final switching result: that is, the stable value of the Current Link Speed ​​field captured last time, and calculate the switching time: Switch_Duration = T_end - T_start, where T_start represents the start time of the switching action, T_end represents the end time of the switching action, and Switch_Duration represents the switching time.

[0028] In some specific implementations, the current link parameters during the current test software switch include: the channel number configuration parameters of the root complex under test. Figure 2 In the middle, the link parameter monitoring module 11 includes: a channel number monitoring unit 113, which is used to monitor the root complex under test when it is performing link training actions. When the link training and state machine configuration of the channel number configuration parameters of the root complex under test ends, the channel number configuration parameters of the root complex under test are frozen and time parameters are generated.

[0029] Specifically, when the root complex under test performs link training actions, it signifies that the root complex has entered the link training phase, a crucial process for establishing physical layer connections in PCIe links. For example, when a link needs to recover or renegotiate parameters, it enters the link training phase. During this phase, the channel count monitoring unit tracks the LTSSM's configuration completion status (Configuration.Complete) in real time. This status indicates that the number of channels in the root complex under test has been completed. At this point, the number of channels in the root complex under test can be frozen accordingly. For example, the number of channels for channel interfaces (x1, x2, x4, x8, x16) can be recorded. The channel count configuration parameter of the root complex under test represents the actual physical width of the link at the current moment. Simultaneously, a timestamp is added to this "freeze" event.

[0030] Among them, Figure 2 In the middle, the multi-dimensional indicator monitoring module 12 is used to monitor the multi-dimensional indicator parameters of the root complex 15 to be tested within a preset time.

[0031] The multi-dimensional parameters of the root complex under test within a preset time period include, but are not limited to: effective bandwidth, transmission delay, resource utilization, and memory write / write per second. In this embodiment, effective bandwidth and transmission delay are mainly used as examples.

[0032] In some specific implementations, in Figure 2 In the middle, the multi-dimensional indicator monitoring module 12 includes: a preset bandwidth determination unit 121, which is used to calculate the preset bandwidth of the root complex 15 under test based on the link rate of the current test software, the number of channels of the root complex under test, and the coding efficiency.

[0033] The preset bandwidth of the root complex to be tested is calculated using the following formula: Preset bandwidth = link rate × number of channels × (128 / 130) × coding efficiency × (1 - protocol overhead ratio).

[0034] For example, taking the current test software version as Gen3x8, with a link rate of 8.0GT / s, 8 channels, and a coding efficiency of 128 / 130, the preset bandwidth calculated using the above formula is: Preset bandwidth = 8.0GT / s × 8 × (128 / 130) ≈ 63.015Gb / s ≈ 7.877GB / s.

[0035] In some other specific implementations, Figure 2 In the middle, the multi-dimensional index monitoring module 12 includes: an effective bandwidth determination unit 122, which is used to determine the effective bandwidth of the root complex 15 under test based on the preset bandwidth, actual load bytes and maximum load bytes of the root complex 15 under test.

[0036] Specifically, when performing actual throughput measurements on the root complex under test, a bandwidth probe is deployed at the transaction layer. For example, a configurable time window of 1 μs is used to count the total number of bytes of all successfully transmitted transport layer packets within the window. To eliminate the impact of protocol overhead, a header parser for each transport layer packet is run synchronously to identify non-payload information such as the header length and checksum of each transport layer packet.

[0037] Specifically, the effective bandwidth of the root complex under test is calculated using the following formula: Effective bandwidth = Actual payload bytes / Maximum payload bytes × Preset bandwidth.

[0038] The window sliding step size in this application can be dynamically adjusted according to the actual situation. This application supports transient bandwidth capture of burst traffic.

[0039] In some specific implementations, in Figure 2 In the middle, the multi-dimensional indicator monitoring module 12 includes: a sending time monitoring unit 123, which is used to mark the sending timestamp when a data packet from the transport layer is injected into any link on the transaction layer sending path.

[0040] Specifically, the transmission time monitoring unit is integrated into the transaction layer transmission path. When a request for a transport layer data packet is injected into the target link, a transmission timestamp T1 is added, which can be stored in the tracking buffer area as metadata appended.

[0041] In some specific implementations, in Figure 2 In the middle, the multi-dimensional indicator monitoring module 12 includes: a receiving time monitoring unit 124, which is used to mark the receiving timestamp when the transaction layer receiving end of the target device receives the transport layer data packet.

[0042] Specifically, the transaction layer receiver or response generation point deployed on the target device (EP) marks the received timestamp when the transport layer data packet is received, for Read requests.

[0043] Specifically, such as Figure 3 The diagram illustrates a distributed timestamp architecture for transmission delay measurement. After link training, a sending timestamp generator is embedded at the transaction initiator, and a receiving time monitoring unit is deployed at the completion end (the target device's response end). The timestamp accuracy must be aligned to the physical layer clock cycle (e.g., 100MHz corresponds to 10ns resolution). For end-to-end delay calculation, precise pairing of request and response transactions is achieved by matching sequence numbers or unique transaction IDs.

[0044] In some specific implementations, in Figure 2 In the middle, the multi-dimensional indicator monitoring module 12 includes: a transmission delay calculation unit 125, which is used to calculate the transmission delay of any link based on the sending timestamp and the receiving timestamp.

[0045] For example, if the transmission timestamp of the target link detected by the transmission time monitoring unit is marked as T1, and the reception timestamp of the target link detected by the reception timestamp is marked as T2, then the transmission delay of the target link is denoted as Tm, and Tm = T1 - T2.

[0046] In some specific implementations, the flow index testing module 13 is used to dynamically test the flow index of the root complex under test in multiple test modes according to a preset test template after the current version of the test software is switched to the target version of the test software. The preset test template is generated based on preset configuration parameters.

[0047] In some specific implementations, in Figure 2 In the middle, the traffic indicator test module 13 includes: a preset parameter configuration unit 131, which is used to pre-configure the preset configuration parameters of the target service message. The preset configuration parameters include: memory read and write parameters, configuration space access parameters, message notification parameters and load size parameters.

[0048] Specifically, the preset configuration parameters pre-configured by the preset parameter configuration unit cover memory read / write (MemRd / Wr), configuration space access (Cfg), and message notification (Msg), etc. These pre-configured parameters ensure all critical transactions that may be encountered in actual operation.

[0049] In some specific implementations, in Figure 2 In the middle, the traffic indicator test module 13 also includes: a configuration template generation unit 132, which is used to generate a preset test template of the root complex to be tested according to the preset configuration parameters of the target service message.

[0050] Specifically, the core of the traffic indicator testing module in this application lies in dynamically simulating complex transaction interaction behaviors in real-world scenarios. When the test starts, the preset parameter configuration unit first loads a predefined format traffic configuration file and parses the layered constraints defined within the file: the message type covers transaction types such as memory read / write (MemRd / Wr), configuration space access (Cfg), and message notification (Msg); the payload size is adjustable within the range of 64B to 4KB according to an exponential or uniform distribution; and the traffic burst density is determined by setting the mean and variance of the burst interval. The aggregation degree of requests is controlled by clock cycles of 1-1000, while virtual channel bandwidth resources are dynamically allocated according to the traffic categories of TC0-TC7. Based on the parsed parameters, the configuration template generation unit 132 generates a preset test template for composable transport layer data packets.

[0051] In some specific implementations, multiple test modes are used, including: preset test mode, burst test mode, and stress test mode. Figure 2 In the middle, the flow index testing module 13 includes: a flow index testing unit 133, which is used to dynamically test the flow index of the root complex under test according to the preset test template of the root complex under test in a preset test mode, a burst test mode, or a stress test mode.

[0052] Specifically, during testing, the traffic metrics testing unit can seamlessly switch between various scenarios, including preset test modes, burst test modes, and stress test modes. In the preset test mode, steady-state traffic is maintained to calibrate theoretical performance boundaries; the burst test mode simulates short-duration peak pulses (such as continuously injecting 256 back-to-back MemWr requests with 4KB effective load) to verify burst processing capabilities; the stress test mode assesses the fairness of the arbitration process and the risk of starvation by forcibly preempting virtual channel resources (such as setting the TC0 bandwidth weight to 95% to suppress other priority traffic). All test modes support dynamic parameter adjustment during runtime.

[0053] In some specific implementations, in Figure 2 In the middle, the multi-dimensional indicator monitoring module 12 includes: a delay time compensation unit 126, which is used to delay the sending time of the flow control update data packet corresponding to the transport layer data packet when the processing of each transport layer data packet of the target link is completed. The target link is the link with the longest transmission delay among at least two links. The flow control update data packet is used to return the credit of the transport layer data packet to the sending end.

[0054] Specifically, in the delay compensation unit, during the link initialization phase, the receiver informs the sender of the size of its internal receive buffer, which is measured in "credit units." One credit unit typically corresponds to one transport layer data packet. The sender maintains a credit counter. Each time a transport layer data packet is sent, a corresponding amount of credit is consumed. If the credit is insufficient, the sender must suspend transmission until it receives credit returned by the receiver. After processing the transport layer data packet and releasing its occupied buffer, the receiver returns credit to the sender by sending a specific type of flow control update data packet. This credit is used by the sender to control the transmission of transport layer data packets.

[0055] In this application, in order to balance the latency of each link, the timing of sending update data packets is controlled by controlling the flow control to ensure the balance of latency of each link.

[0056] In a standard PCIe link, flow control update packets are sent as soon as the buffer is released to maximize link throughput. In the compensation mechanism of this application, the receiver can intentionally delay the time it takes to return credit to the sender, i.e., delay the sending time of the flow control update packets.

[0057] In order to balance the latency of each link, the link with the longest transmission latency among at least two links is selected as the target link, which means that the sending time of its flow control update data packet needs to be delayed.

[0058] Optionally, in this application, the sending time of the flow control update data packet of the non-longest link with transmission delay can be delayed. The compensation delay time can be fixed or determined in real time based on the link, and no specific limitation is made here.

[0059] Optionally, this application can delay the transmission time of the flow control update data packet by introducing a timer. Specifically, after the corresponding transport layer data packet is processed, the corresponding buffer is released, and a timer is started. The timer controls the transmission time of the flow control update data packet, and the flow control update data packet is sent when the timer reaches its set time. The set time is determined based on the compensation delay time of the flow control update data packet.

[0060] When the receiver needs to impose an artificial delay on a low-latency link, after processing the transport layer packets from that link, it does not immediately return credits. Instead, it starts a timer to temporarily suspend the transmission of flow control update packets. During this delay, the computer may be unable to send new transport layer packets due to credit exhaustion; these packets will wait in the computer's transmit buffer. Once the preset delay time has elapsed, the receiver sends a flow control update packet to return credits, and the computer then resumes data transmission.

[0061] By actively pausing at the receiving end and passively waiting at the sending end, the transport layer data packets stay in the sending end's buffer for an extra period of time, thus effectively increasing the end-to-end latency of this low-latency link.

[0062] The delay compensation method of the delay compensation unit described above delays the transmission time of the flow control update data packet corresponding to the transport layer data packet when the processing of each transport layer data packet of the target link is completed. The target link is the link with the non-longest transmission delay among at least two links. By delaying the transmission time of the link with the non-longest transmission delay, the delay time of each link is the same, that is, the delay characteristics between different slots are consistent, thereby ensuring that the service brings serious performance and fairness.

[0063] Among them, Figure 1 In the middle, the version switching control module 14 is used to control the link parameter monitoring module and the multi-dimensional indicator monitoring module to stop monitoring based on the current link parameters of the root complex under test and the multi-dimensional indicator parameters of the root complex under test within a preset time, and to switch from the current version of the test software to the target version of the test software.

[0064] This application focuses on the performance testing of PCIe root complexes, specifically for PCIe root complexes with multiple interfaces under different channel numbers (e.g., x1 / x4 / x8 / x16) and transmission rates (e.g., Gen3 / Gen4 / Gen5). It can also perform performance testing of PCIe root complexes while switching channel numbers and transmission rates.

[0065] The computer interface testing system in this application can perform traditional unified testing based on a fixed version and a fixed number of channels, as well as dynamic reconfiguration testing. This includes performance verification and statistics under conditions such as triggering x16→x8 link degradation or cross-rate switching while maintaining maximum bandwidth; forced switching to Gen4 rate mode under Gen5 burst traffic; simulating multi-interface resource contention testing under the root federation; simultaneously activating 8 EP device endpoints (terminal nodes) for interleaved memory access operations; and performing error recovery performance verification, including performance testing after an error occurs until physical layer retraining.

[0066] This application utilizes a link parameter monitoring module, a multi-dimensional indicator monitoring module, a traffic indicator testing module, and a version switching control module to perform dynamic configuration switching, automated testing, and multi-dimensional performance analysis. This overcomes the limitations of fixed configuration in traditional verification and can cover the dynamic configuration behavior of chips triggered by load fluctuations and error handling in real-world scenarios, calculating the performance of the PCIe root union under these scenarios.

[0067] Furthermore, without interrupting link communication, the current link parameters are monitored in real time when the root complex under test switches to the current test software, simulating the behavior of sudden load changes or device channel failures in real-world scenarios. Secondly, configuration switching is driven by monitoring feedback, reducing manual calculations. In addition, multi-dimensional and traffic metrics are injected to provide a basis for design optimization. Finally, this application is applicable to high-reliability scenarios with massive data volumes, ensuring that the computer chip adapts to complex and changing load requirements throughout its entire lifecycle.

[0068] Embodiments of this application also provide a computer device, such as... Figure 4 As shown, it includes a memory 10 and a processor 20. The memory 10 stores a computer program, and the processor 20 is configured to run the computer program to execute the contents of any of the above-described computer interface testing system embodiments.

[0069] Embodiments of this application also provide a computer-readable storage medium storing a computer program configured to execute the contents of any of the above-described computer interface testing system embodiments at runtime.

[0070] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0071] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the contents of any of the above-described computer interface testing system embodiments.

[0072] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the contents of any of the above-described computer interface testing system embodiments.

[0073] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software 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 beyond the scope of this application.

[0074] The foregoing has provided a detailed description of an embodiment of a computer interface testing system provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A computer interface testing system, characterized in that, include: The link parameter monitoring module is used to monitor the current link parameters of the root complex under test when it switches to the current test software. The multidimensional indicator monitoring module is used to monitor the multidimensional indicator parameters of the root complex under test within a preset time period. The version switching control module is used to control the link parameter monitoring module and the multi-dimensional indicator monitoring module to stop monitoring based on the current link parameters of the root complex under test and the multi-dimensional indicator parameters of the root complex under test within a preset time, and to switch from the current version of the test software to the target version of the test software. The traffic metrics testing module is used to dynamically test the traffic metrics of the root complex under test in multiple test modes according to a preset test template after the current version of the test software is switched to the target version of the test software. The preset test template is generated based on preset configuration parameters.

2. The computer interface testing system according to claim 1, characterized in that, The current link parameters include: the start and end times of the switching action performed by the current test software; the link parameter monitoring module includes: The version switching monitoring unit is used to monitor the start and end times of the switching action performed by the root complex under test in the current version of the software through link training and state machine.

3. The computer interface testing system according to claim 2, characterized in that, The current link parameters during the switching of the current test software include: the switching result of the target test software. The link parameter monitoring module includes: The dynamic polling recording unit is used to record version field jump events through register dynamic polling control to obtain the switching results of the target test software.

4. The computer interface testing system according to claim 2, characterized in that, The current link parameters during the current test software switch include: the channel number configuration parameters of the root complex under test; the link parameter monitoring module includes: The channel number monitoring unit is used to monitor the root complex under test when it is performing link training. When the link training and state machine configuration of the channel number configuration parameters of the root complex under test ends, the channel number configuration parameters of the root complex under test are frozen and time parameters are generated.

5. The computer interface testing system according to claim 1, characterized in that, The multidimensional indicator monitoring module includes: The preset bandwidth determination unit is used to calculate the preset bandwidth of the root complex under test based on the link rate of the current test software, the number of channels of the root complex under test, and the coding efficiency.

6. The computer interface testing system according to claim 5, characterized in that, The multidimensional indicator monitoring module includes: An effective bandwidth determination unit is used to determine the effective bandwidth of the root complex under test based on the preset bandwidth, actual payload bytes, and maximum payload bytes of the root complex under test.

7. The computer interface testing system according to claim 1, characterized in that, The multidimensional indicator monitoring module includes: The transmission time monitoring unit is used to mark the transmission timestamp when a transport layer data packet is received and injected into any link on the transaction layer transmission path; The receiving time monitoring unit is used to mark the receiving timestamp when the transport layer data packet is received at the transaction layer receiving end of the target device.

8. The computer interface testing system according to claim 7, characterized in that, The multidimensional indicator monitoring module includes: A transmission delay calculation unit is used to calculate the transmission delay of any link based on the sending timestamp and the receiving timestamp.

9. The computer interface testing system according to claim 1, characterized in that, The traffic flow indicator testing module includes: The preset parameter configuration unit is used to pre-configure preset configuration parameters for target service messages. The preset configuration parameters include: memory read / write parameters, configuration space access parameters, message notification parameters, and load size parameters.

10. The computer interface testing system according to claim 9, characterized in that, The traffic flow indicator testing module also includes: The configuration template generation unit is used to generate a preset test template for the root complex to be tested based on the preset configuration parameters of the target service message.

11. The computer interface testing system according to claim 10, characterized in that, The various test modes include: preset test mode, burst test mode, and stress test mode; The flow rate indicator testing module includes: a flow rate indicator testing unit, used to dynamically test the flow rate indicator of the root complex under test according to the preset test template of the root complex under test in the preset test mode, the burst test mode, or the stress test mode.

12. The computer interface testing system according to claim 8, characterized in that, The multidimensional indicator monitoring module includes: The delay time compensation unit is used to delay the transmission time of the flow control update data packet corresponding to the transport layer data packet when the processing of each transport layer data packet of the target link is completed. The target link is the link with the longest transmission delay among at least two links. The flow control update data packet is used to return the credit for controlling the transmission of the transport layer data packet to the sending end.

Images