Automated testing methods, systems, and platforms for user service terminal hardware platforms

Abstract

This invention provides an automated testing method, system, and platform for user service terminal hardware platforms, relating to the field of platform testing technology. The method includes: receiving Ethernet data packets sent by a test host and performing Ethernet frame header parsing and routing decisions; if the routing control signal is an IP packet, forwarding the Ethernet data packet directly to the external network interface; if the routing control signal is an MC packet or a TMC packet, performing protocol conversion and interactive testing on the Ethernet data packets, outputting multiple test response data streams; a data stream management module performing polling, arbitration, and merging of the multiple test response data streams, outputting a single data stream; and transmitting the single data stream back to the test host through a dual Ethernet interface module. This invention solves the technical problems of complex system structure, low testing efficiency, and low accuracy in existing user service terminal hardware platform testing technologies. It achieves the technical effect of improving the automation level of multi-interface collaborative testing and improving overall testing efficiency and accuracy.

Description

Technical Field

[0001] This invention relates to the field of platform testing technology, specifically to automated testing methods, systems, and platforms for user service terminal hardware platforms. Background Technology

[0002] As the integration and interface types of user service terminals and their hardware platforms continue to increase, hardware interface testing is gradually shifting from single-interface functional verification to multi-interface parallel and interactive testing. Existing hardware interface testing systems typically employ a discrete approach, designing separate test modules for different hardware interfaces. This results in complex system structures, high resource consumption, and low testing efficiency. Especially in scenarios requiring simultaneous testing and data interaction of multiple hardware interfaces, the interfaces are independent in protocol type, clock speed, and data processing methods, leading to a complex overall system structure and low resource reuse. Furthermore, the different reset timing requirements of multiple hardware interfaces make unified, phased reset management difficult using existing technologies, easily resulting in interface initialization failures or timing conflicts, affecting test reliability. In actual testing, frequent data interaction and collaborative verification between different interfaces are required, but the decentralized testing architecture struggles to achieve unified data management and scheduling, limiting testing efficiency and accuracy and failing to meet the application requirements of high-speed, multi-interface collaborative testing.

[0003] Existing technology for testing user service terminal hardware platforms suffers from technical problems such as complex system structure, low testing efficiency, and low accuracy. Summary of the Invention

[0004] The purpose of this application is to provide an automated testing method, system, and platform for user service terminal hardware platforms, in order to solve the technical problems of complex system structure, low testing efficiency, and low accuracy in the testing of existing user service terminal hardware platforms.

[0005] In view of the above problems, this application provides an automated testing method, system and platform for user service terminal hardware platforms.

[0006] The first aspect of this application provides an automated testing method for a user service terminal hardware platform. This automated testing method includes: a packet classification and routing module receiving Ethernet packets sent by a test host, performing hardware-level Ethernet frame header parsing and routing decisions to obtain a routing control signal; if the routing control signal is an IP packet, then forwarding the Ethernet packet directly to the external network interface; if the routing control signal is an MC packet or a TMC packet, then sending the Ethernet packet to an interface protocol conversion module for protocol conversion and interactive testing, outputting multiple test response data streams; a data stream management module performing polling, arbitration, and merging of the multiple test response data streams, outputting a single data stream; and transmitting the single data stream back to the test host through a dual Ethernet interface module.

[0007] Optionally, when the Ethernet interface on the internal network CPU side receives the Ethernet data packet sent by the test host, the data packet classification and routing module is activated; when the data packet classification and routing module writes the Ethernet data packet into the data packet buffer FIFO, it simultaneously extracts the first 14 bytes of the Ethernet frame header; it extracts the EtherType field from the Ethernet frame header to make a routing decision and generates a routing decision result; it generates a routing control signal based on the routing decision result, reads it from the data packet buffer FIFO, and forwards it to the corresponding processing module.

[0008] Optionally, the multi-channel arbitrator in the data stream management module receives the multiple test response data streams, wherein each test response data stream includes a data signal, a valid signal, an end signal, and a tready signal; the multi-channel arbitrator uses a polling arbitration algorithm to sequentially check the valid signals of the multiple test response data streams according to a preset priority order to determine their validity status; when the Kth test response data stream is detected as a valid data stream, the Kth test response data stream is connected to the output port; when the transmission of the Kth test response data stream is completed, the system switches to the next valid data stream based on the end signal of the Kth test response data stream, wherein the multi-channel arbitrator merges the multiple test response data streams into the single data stream for output.

[0009] Optionally, if the Kth test response data stream is connected to the output port and the output port cannot receive data, the transmission of the Kth test response data stream is paused by the first tready signal.

[0010] Optionally, the packet classification and routing module, interface protocol conversion module, data flow management module, and dual Ethernet interface module are managed by the clock management module for PLL-based multi-clock domain synchronization.

[0011] Optionally, an asynchronous FIFO is used to buffer the data transmitted between different clock domains divided by the clock management module. The asynchronous FIFO uses a Gray code counter to synchronize the read and write pointers across clock domains. During the cross-clock domain transmission, a complete packet filter is used to detect the start and end flags of the Ethernet data packets and intercept incomplete data packets.

[0012] Optionally, the packet classification and routing module, interface protocol conversion module, data flow management module, and dual Ethernet interface module are managed in stages via a reset control module.

[0013] Optionally, after the PLL locking is completed and the locking signal is valid, the system reset signal is released and the reset delay counter is started; the PHY interface is kept in the reset state until the reset delay counter reaches the first preset threshold, and then the PHY reset signal is released according to the control signal provided by the VIO interface; when the count value of the reset delay counter reaches the delay target value, the TCM reset signal is released; after the PHY interface, TCM interface, MC interface and DDR3 memory interface are all reset, the system enters the ready state.

[0014] A second aspect of this application provides an automated testing system for a user service terminal hardware platform, the automated testing system for the user service terminal hardware platform comprising: a clock management module, a dual Ethernet interface module, a packet classification and routing module, an interface protocol conversion module, a data flow management module, and a reset control module.

[0015] A third aspect of this application provides an automated testing platform for a user service terminal hardware platform, comprising: an FPGA; an intranet CPU that communicates with the FPGA via Gigabit Ethernet; an extranet CPU that communicates with the FPGA via Gigabit Ethernet; a TCM measurement unit that communicates with the FPGA via a proprietary protocol interface; a main control unit that communicates with the FPGA via GPIO; and a DDR that communicates with the FPGA using a DDR3 standard interface.

[0016] One or more technical solutions provided in this application have at least the following technical effects or advantages: The method provided in this application embodiment receives Ethernet packets sent by the test host through a packet classification and routing module, performs hardware-level Ethernet frame header parsing and routing decisions to obtain routing control signals. If the routing control signal is an IP packet, the Ethernet packet is forwarded directly to the external network interface. If the routing control signal is an MC packet or a TMC packet, the Ethernet packet is sent to an interface protocol conversion module for protocol conversion and interactive testing, outputting multiple test response data streams. The data stream management module performs polling, arbitration, and merging of the multiple test response data streams, outputting a single data stream. The single data stream is then transmitted back to the test host through a dual Ethernet interface module. This achieves the technical effect of improving the automation level of multi-interface collaborative testing, thereby improving the overall testing efficiency and accuracy.

[0017] The above description is merely an overview of the technical solution of this application. To better understand the technical means of this application and to facilitate its implementation according to the description, and to make the above and other objects, features, and advantages of this application more apparent, specific embodiments of this application are described below. It should be understood that the content described in this section is not intended to identify key or important features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent through the following description. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are merely exemplary. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0019] Figure 1 A flowchart illustrating the automated testing method for the user service terminal hardware platform provided in this application.

[0020] Figure 2 A schematic diagram of the structure of the automated testing system for the user service terminal hardware platform provided in this application.

[0021] Figure 3 A schematic diagram of the framework of the automated testing platform for the user service terminal hardware platform provided in this application.

[0022] Explanation of reference numerals in the attached diagram: Clock management module 11, Dual Ethernet interface module 12, Packet classification and routing module 13, Interface protocol conversion module 14, Data flow management module 15, Reset control module 16. Detailed Implementation

[0023] This application provides an automated testing method, system, and platform for user service terminal hardware platforms. It addresses the technical problems of complex system structure, low testing efficiency, and low accuracy in existing user service terminal hardware platform testing technologies, thereby improving the automation level of multi-interface collaborative testing and thus enhancing overall testing efficiency and accuracy.

[0024] The technical solutions of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. It should be understood that the present invention is not limited to the exemplary embodiments described herein. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention. It should also be noted that, for ease of description, only the parts related to the present invention are shown in the accompanying drawings, not all of them.

[0025] Example 1, as Figure 1 As shown, this application provides an automated testing method for a user service terminal hardware platform, wherein the automated testing method for the user service terminal hardware platform is applied to an automated testing system for the user service terminal hardware platform, and the automated testing method for the user service terminal hardware platform includes: After receiving Ethernet packets sent by the test host, the packet classification and routing module performs hardware-level Ethernet frame header parsing and routing decisions to obtain routing control signals.

[0026] Furthermore, after receiving the Ethernet data packet sent by the test host, the packet classification and routing module performs hardware-level Ethernet frame header parsing and routing decision-making to obtain a routing control signal. The method includes: when the Ethernet interface on the internal network CPU side receives the Ethernet data packet sent by the test host, the packet classification and routing module starts; when the packet classification and routing module writes the Ethernet data packet into the packet buffer FIFO, it simultaneously extracts the first 14 bytes of the Ethernet frame header; it extracts the EtherType field from the Ethernet frame header to perform routing decision-making and generates a routing decision result; it generates a routing control signal based on the routing decision result, reads it from the packet buffer FIFO, and forwards it to the corresponding processing module.

[0027] Specifically, the packet classification and routing module is the core starting point for realizing automated testing of the hardware platform. Its main function is to receive Ethernet packets from the test host, perform hardware-level parsing of the Ethernet packets, and generate routing control signals. Specifically, when the internal network CPU-side Ethernet interface receives an Ethernet packet sent by the test host, the packet classification and routing module is triggered to start. The internal network CPU-side Ethernet interface refers to the Ethernet interface connected to the CPU inside the hardware platform, used to receive data streams sent by the test host.

[0028] After startup, the packet classification and routing module writes the received Ethernet packets into a packet buffer FIFO (First-In-First-Out queue). The FIFO temporarily stores packets, allowing subsequent processing modules to read data sequentially, ensuring the stability and integrity of the data stream. Simultaneously with writing to the FIFO, the first 14 bytes of the Ethernet frame header are extracted for EtherType field identification. The EtherType field is extracted from bytes 12-13 of the Ethernet frame header. This field identifies the packet type; for example, 0x0800 represents an IPv4 packet, 0x1000 represents a master control packet, and 0x1600 represents a TCM packet. Routing decisions are made based on the extracted EtherType field value. Through a hardware lookup table or logical decision circuit, the EtherType value is mapped to the corresponding routing decision result. This routing decision result indicates which processing path the packet should take, such as direct access to the external network, entry into the protocol conversion module, or discard / ignore. It can be represented by a fixed-width binary code, for example: 00 for IP direct access, 01 for MC / TMC protocol conversion, and 10 for reservation / other processing.

[0029] After generating the routing decision result, hardware logic circuits, such as decoders / multiplexers, encode and decode the result into a routing control signal. This signal is a hardware control signal used to instruct subsequent processing modules how to handle the data packet. For example, if EtherType=0x0800, the generated control signal indicates that the data packet should be directly routed to the external network interface. Based on the routing control signal, the buffered data packet content is read from the FIFO and forwarded to the corresponding processing module. This ensures that data packets can be classified and initially routed at the hardware level, thereby reducing the CPU load, improving response speed and processing throughput, and achieving a latency of less than 10 clock cycles, meeting the real-time requirements of high-speed data packet processing.

[0030] If the routing control signal is an IP packet, then the Ethernet data packet is forwarded directly to the external network interface.

[0031] If the routing control signal is an MC packet or a TMC packet, the Ethernet data packet is sent to the interface protocol conversion module for protocol conversion and interaction testing, and multiple test response data streams are output.

[0032] Specifically, if the Ethernet interface on the internal CPU side receives an IP packet, the routing control signal indicates that the packet is an IP packet, meaning the routing control signal corresponds to a direct connection to the external network. The IP packet is then directly forwarded to the external CPU Ethernet interface without any processing module. The external CPU Ethernet interface then sends the IP packet out. The external CPU packet processing flow includes an external CPU reception flow and an external CPU processing flow. The external CPU reception flow is as follows: the external CPU Ethernet interface receives the packet and forwards it directly to channel 1 of the multi-arbitrator. The multi-arbitrator merges the packets and sends them to the internal CPU Ethernet interface. The external CPU transmission flow is as follows: the IP packet received by the internal CPU is directly connected to the transmit port of the external CPU Ethernet interface, and the external CPU Ethernet interface sends the IP packet out.

[0033] If the routing control signal is an MC (Master Controller) packet or a TMC (Telecommunications Module) packet, the packet is guided into the interface protocol conversion module for protocol conversion and interaction testing. The interaction test refers to bidirectional, request-response communication with external devices, the Master Controller MC, and the TCM encryption chip. The MC packet processing flow is as follows: If the routing control signal is an MC packet, the Ethernet packet is sent to the interface protocol conversion module for protocol conversion and interaction testing. The converted data is sent to the external master controller through the master controller interface. The response data from the external master controller is received through the master controller interface. The converted packet is output through channel 0 of the multi-arbitrator. The multi-arbitrator merges the packets and sends them to the Ethernet interface on the internal network CPU side.

[0034] The TCM packet processing flow is as follows: If the routing control signal is a TCM packet, the MAC address and payload are extracted from the packet. Communication with the TCM encryption chip is then established via the TCM bus. After processing, the TCM encryption chip returns response data via the TCM bus and encapsulates the response data into an Ethernet packet format. The encapsulated packet is output through channel 2 of the multi-arbitrator. The multi-arbitrator merges the packets and sends them to the Ethernet interface on the internal network CPU side. Through processing, multiple test response data streams are output, including the external network CPU-side forwarding data stream, the MC response data stream, and the TCM response data stream. Each data stream includes a data signal, a valid signal, a termination signal, and a tready signal, ensuring that the subsequent data stream management module can correctly receive, poll, and merge the data.

[0035] The data flow management module performs polling, arbitration, and merging of the multiple test response data streams, and outputs a single data stream.

[0036] Furthermore, the data stream management module performs polling arbitration merging of the multiple test response data streams to output a single data stream. The method includes: the multi-channel arbitrator in the data stream management module receives the multiple test response data streams, wherein each test response data stream includes a data signal, a valid signal, an end signal, and a tready signal; the multi-channel arbitrator uses a polling arbitration algorithm to sequentially check the valid signals of the multiple test response data streams according to a preset priority order to determine their validity status; when the Kth test response data stream is detected as a valid data stream, it is connected to the output port; when the transmission of the Kth test response data stream is completed, it switches to the next valid data stream based on the end signal of the Kth test response data stream, wherein the multi-channel arbitrator merges the multiple test response data streams into the single data stream for output.

[0037] Specifically, the multi-channel arbitrator in the data flow management module receives the multiple test response data streams. The multi-channel arbitrator is a hardware module used to receive multiple input data streams and, based on the valid signals and preset priorities of each stream, selects the currently valid data stream for output in a polling manner, thus achieving the orderly merging of multiple data streams into a single output stream. The multi-channel arbitrator supports at least three data stream inputs: the first is the MC response data stream, the second is the external network CPU-side forwarded data stream, and the third is the TCM response data stream. Each test response data stream includes a data signal, a valid signal, a termination signal, and a ready signal. The ready signal indicates the data content, whether the data is valid, whether the data packet has been transmitted completely, and whether the next-level module is ready to receive data.

[0038] The multi-channel arbitrator employs a polling arbitration algorithm to sequentially scan multiple test response data streams. Polling arbitration refers to checking the valid signals of each data stream in a preset priority order to determine if the stream contains usable data. When a valid signal of the Kth data stream is detected to be high, the multi-channel arbitrator temporarily connects this data stream to the output port, making it the current output stream (K is a positive integer). During the connection process, the multi-channel arbitrator monitors the end signal of this data stream in real time to determine if the data packet transmission is complete. When the end signal arrives, it indicates that the data packet has been completely output, and the multi-channel arbitrator automatically switches to the next valid data stream and continues polling and merging. If multiple data streams are valid simultaneously, they are processed according to a preset priority order. In this way, multiple independent response streams are continuously and sequentially merged into a single data stream, which is then output to the next processing module or the feedback interface.

[0039] In addition to using a preset priority order as the polling rule, dynamic scene-aware scheduling can be added. By adding a test scene register group and pre-storing the arbitration strategy configuration of typical test cases, the priority and binding relationship of data streams can be adjusted as needed. For example: configure a preemptive arbitration strategy for TCM throughput testing to elevate the TCM response stream to the highest priority to ensure real-time performance; enable a data stream binding strategy for MC and DDR3 collaborative testing to forcibly associate the MC request stream and the DDR3 response stream to reduce transmission latency, switch scene modes in real time through the VIO interface, and the arbitrator dynamically reconstructs the scheduling logic according to the register configuration.

[0040] By employing a polling arbitration mechanism through a multi-channel arbitrator, each response data is ensured to be output sequentially according to the order of valid and termination signals, achieving complete and continuous transmission of data packets. At the same time, data is only sent when the output port is ready, thereby improving system throughput, ensuring data integrity, and providing the test host with a unified and reliable single-channel return data stream, realizing a closed loop for automated testing, and improving testing efficiency and accuracy.

[0041] Furthermore, if the Kth test response data stream is connected to the output port and the output port cannot receive data, the transmission of the Kth test response data stream is paused by the first tready signal.

[0042] Specifically, the multi-channel arbiter also introduces a backpressure mechanism: if the Kth test response data stream is connected to the output port and the output port cannot receive data, the tready signal is set low (logic 0) to notify the currently processed Kth test response data stream to pause transmission to avoid data loss. The Kth test response data stream will continue to transmit only when the output port is ready and the tready signal returns to high (logic 1).

[0043] The valid signal indicates that the current data at the transmitting end is valid, while the ready signal indicates that the receiving end is ready. The test response data stream is only transmitted when both the valid signal and the ready signal are high. Real-time flow control is achieved at the hardware level without the need for additional CPU intervention, ensuring that the test response data stream is not lost or out of order during multiplexing and cross-clock domain transmission.

[0044] Through the backpressure mechanism, even if the output port is temporarily unavailable or the buffer is full, the multi-channel arbiter and each data stream can dynamically adjust the transmission rhythm to prevent data loss or out-of-order delivery, improve test reliability and data integrity, achieve stable and efficient data flow management, and thus improve test efficiency and accuracy.

[0045] The single data stream is transmitted back to the test host via a dual Ethernet interface module.

[0046] Specifically, a dual Ethernet interface module is adopted, providing two independent Gigabit Ethernet interfaces on the internal network CPU side and the external network CPU side. Each interface can both receive and send data, realizing bidirectional data transmission. Each interface contains two core sub-modules: an RGMII protocol conversion unit and an AXI-Stream data stream conversion unit.

[0047] The RGMII protocol conversion unit is responsible for converting 4-bit data from the external RGMII (Gigabit Ethernet standard interface) into an 8-bit data stream of the internal AXI-Stream protocol, operating at a frequency of 125MHz. This conversion achieves interface protocol matching, enabling high-speed data exchange between the external Gigabit Ethernet port and the internal high-speed AXI-Stream data bus. The AXI-Stream protocol is an on-chip high-speed data stream interface that supports valid, ready, and stop signals, achieving high throughput and flow control reliability.

[0048] In the data transmission direction, a single data stream is input to the dual Ethernet interface module via the AXI-Stream protocol. After AXI-Stream to RGMII conversion, it is sent to the test host through the external RGMII interface. The test host is a host computer or server device used to initiate test commands, send test data, and receive test response results. It establishes communication with the user service terminal hardware platform through the Ethernet interface for automated control, data interaction, and test result analysis of the hardware interface under test. In the data reception direction, data from the external RGMII interface can be transmitted internally via RGMII to AXI-Stream conversion, supporting bidirectional interactive testing. This enables high-speed, reliable bidirectional communication between the merged single data stream and the test host, allowing automated test data to be successfully transmitted back, achieving a test closed loop. Simultaneously, the RGMII to AXI-Stream protocol conversion ensures compatibility between the test host's internal and external network interfaces, efficiently supporting high-speed data transmission and interaction across multiple modules, improving test reliability and accuracy.

[0049] Furthermore, the packet classification and routing module, interface protocol conversion module, data flow management module, and dual Ethernet interface module perform PLL-based multi-clock domain synchronization management through the clock management module.

[0050] Furthermore, the method also includes: using an asynchronous FIFO to buffer the data transmitted between different clock domains divided by the clock management module, wherein the asynchronous FIFO uses a Gray code counter to synchronize the read and write pointers across clock domains; during the cross-clock domain transmission process, a complete packet filter is used to detect the start and end flags of the Ethernet data packets and intercept incomplete data packets.

[0051] Specifically, multiple modules, such as the packet classification and routing module, interface protocol conversion module, data flow management module, and dual Ethernet interface module, involve multiple different clock domains due to their different processing rates. This is implemented by the clock management module through the PLLIP core. By configuring PLL parameters, including multiplication, division, and phase parameters, the required multiple clock signals are generated for synchronization. The PLL parameter configuration process is as follows: a stable reference clock provided by the board is selected as the PLL input clock, such as a 100MHz crystal oscillator. By setting the PLL's multiplication parameters, the input clock is boosted to a higher internal voltage-controlled oscillation frequency to obtain better frequency resolution and jitter performance. Based on this, the division parameters of different output channels are configured to divide the VCO frequency to generate the target clock. The phase parameters of each output clock are configured according to the interface timing requirements, such as introducing a 90° phase offset for the RGMII interface clock to meet the data and clock setup and hold time requirements. The clock domain partitioning strategy of the clock management module includes: 125MHz clock domain: used for high-speed data processing modules such as Ethernet MAC, packet classifier, and multiplexer; 200MHz clock domain: used for DDR3 controller and LED status indicators; MC clock domain: used for the main controller interface, with the clock frequency provided by the external main controller; TCM clock domain: used for the TCM bus interface, with a configurable clock frequency; and 50MHz clock domain: used for system control and VIO interface.

[0052] Because different modules interact across clock domains, relying solely on a PLL to generate multiple clocks cannot guarantee the secure transmission of data packets between different clock domains. Therefore, an asynchronous FIFO is used to buffer data transmitted between different clock domains defined by the clock management module. The asynchronous FIFO includes a write clock domain and a read clock domain. The write clock domain writes data to the FIFO, and the read clock domain reads data from the FIFO. Internally, a Gray code counter is used to synchronize the read and write pointers across clock domains. The characteristic of Gray code is that only one bit changes between adjacent count values, effectively avoiding transient errors during cross-clock domain pointer transmission. This ensures that the FIFO does not experience data corruption or loss during read and write pointer synchronization, thus preventing metastability issues.

[0053] Meanwhile, to ensure the integrity of data packets transmitted across clock domains, a complete packet filter is introduced during the FIFO read / write process. The complete packet filter detects the start and end flags of Ethernet data packets, allowing only complete data packets to pass and discarding incomplete data packets, thus avoiding data packet corruption caused by cross-clock domain transmission. For example, if only the start flag is received but the end flag is not received, the packet is discarded to prevent incomplete data packets from entering subsequent modules and to ensure the correctness of subsequent processing and data return.

[0054] By employing asynchronous FIFO, secure data transmission and order maintenance across clock domains are achieved, preventing data out-of-order transmission or loss due to different clock domains. Furthermore, incomplete Ethernet packets are intercepted through a complete packet filter, thereby improving the reliability and data integrity of hardware platform testing and ultimately enhancing test accuracy.

[0055] Furthermore, the packet classification and routing module, interface protocol conversion module, data flow management module, and dual Ethernet interface module are managed in stages through a reset control module.

[0056] Furthermore, the method also includes: after the PLL locking is completed and the locking signal is valid, releasing the system reset signal and starting the reset delay counter; keeping the PHY interface in the reset state until the reset delay counter reaches a first preset threshold, and then releasing the PHY reset signal according to the control signal provided by the VIO interface; releasing the TCM reset signal when the count value of the reset delay counter reaches the delay target value; and entering the ready state after the PHY interface, TCM interface, MC interface and DDR3 memory interface have all been reset.

[0057] Specifically, to ensure that the packet classification and routing module, interface protocol conversion module, data flow management module, and dual Ethernet interface module can stably and orderly enter the working state during system startup and reconfiguration, a reset control module is introduced to manage the phased reset sequence of each functional module. The specific method by which the reset control module implements the phased reset sequence is as follows: PLL locking phase: After the system is powered on, the clock management module drives the PLL to start the locking process. When the PLL locking is completed and the output locking signal is valid, it indicates that the clock outputs have stabilized. At this time, the reset control module releases the system reset signal and simultaneously starts the reset delay counter. The reset delay counter is used to introduce a deterministic time delay after the clock stabilizes, to avoid peripherals being prematurely released and reset before the clock is fully stable.

[0058] During the delay counting phase, the PHY interface remains in a reset state to ensure sufficient initialization time for the external Ethernet physical layer. Once the reset delay counter reaches a first preset threshold, the reset control module releases the PHY reset signal based on the control signal provided by the VIO interface, thus supporting flexible configuration of the PHY reset timing during the debugging phase. Before releasing the PHY reset signal, the identification of the connected device can be read via the I²C / SPI bus, and the optimal reset timing can be automatically matched according to the device characteristics. For example, large-capacity DDR (memory cell) memory extends the initialization time, while high-speed encryption chips shorten the clock stabilization wait time. Power / clock stability monitoring is also performed, and the reset window is dynamically extended in case of anomalies, enabling dynamic generation of reset strategies. The reset delay counter is compared with a configurable delay target value. When the reset delay counter reaches the delay target value, the TCM reset signal is released, putting modules related to test control and protocol interaction into a ready-to-work state. After the PHY interface, TCM interface, MC interface, and DDR3 memory interface have all been reset, the system enters a ready state, allowing data to formally enter each functional module for processing. LED status indicators indicate the system status.

[0059] By implementing phased reset control based on PLL lockout state and reset delay counter, it is ensured that multi-clock domain and multi-interface hardware modules enter the working state in the order of clock stability, peripheral readiness, and core logic startup. This avoids interface abnormalities, data errors, or system instability caused by improper reset timing, thereby significantly improving the startup reliability and operational stability of the entire platform in automated testing scenarios.

[0060] In summary, the automated testing of the user service terminal hardware platform provided in this application has at least the following technical effects: 1. By introducing a packet classification and routing module, an interface protocol conversion module, and a data flow management module within the hardware platform, the TCM interface, DDR3 interface, dual Ethernet interface, and MC interface can work in parallel under a unified architecture. Through hardware-level data splitting and polling arbitration merging of multiple test response data streams, parallel execution of multi-interface test tasks can be achieved. Compared with the serial or discrete test schemes used in existing technologies, the overall test cycle can be shortened and the test efficiency of the hardware platform can be greatly improved.

[0061] 2. The Ethernet frame header is parsed at the hardware level in the packet classification and routing module. Routing control signals are generated directly based on the EtherType field, realizing the pass-through of IP packets and the automatic splitting of MC / TMC test packets. No CPU software is required to participate in routing decisions, so that the test process can automatically complete data distribution, protocol conversion and result feedback, improve the level of test automation and reduce manual intervention.

[0062] 3. By using the interface protocol conversion module to perform protocol conversion and interactive processing on MC packets and TMC packets, and generating multiple test response data streams, combined with the polling arbitration merging mechanism of the data stream management module, this invention can simultaneously support IP pass-through testing, MC data transmission testing, TCM encrypted communication testing, and DDR3 interface-related testing, covering the main functional modules of the user service terminal hardware platform, and improving the overall test coverage and the accuracy of test results.

[0063] 4. Packet classification and routing, protocol conversion, data flow management, and Ethernet interface functions are divided into independent modules and connected through the AXI-Stream standard data flow interface. When new test interfaces or test functions need to be added, only the corresponding functional modules need to be added without modifying the existing system architecture, thus reducing system maintenance and upgrade costs.

[0064] 5. The AXI-Stream protocol is adopted as the unified data stream transmission standard, and bidirectional protocol conversion between RGMII and AXI-Stream is realized through dual Ethernet interface modules, enabling seamless connection between the internal high-speed data processing logic and the external Ethernet interface, improving integration capabilities and data transmission efficiency in complex hardware environments, thereby improving testing efficiency and reliability.

[0065] 6. The clock management module generates multiple stable clocks based on PLL, and introduces asynchronous FIFO and Gray code counters for synchronization at the cross-clock domain data transmission point. At the same time, it combines a complete packet filter to intercept incomplete data packets, and implements phased reset sequence management based on PLL lock signals through the reset control module. This effectively avoids cross-clock domain transmission anomalies, reset timing conflicts and data errors, and improves the overall operational stability and test accuracy and reliability.

[0066] Example 2, as Figure 2 As shown, this application provides an automated testing system for a user service terminal hardware platform, wherein the automated testing system for the user service terminal hardware platform includes: a clock management module 11, a dual Ethernet interface module 12, a packet classification and routing module 13, an interface protocol conversion module 14, a data flow management module 15, and a reset control module 16.

[0067] The clock management module 11 is used to generate multiple operating clocks of different frequencies from an external reference clock, including: Ethernet clock (125MHz), DDR3 clock (200MHz), TCM interface clock (configurable), DMA clock (configurable), and system control clock (50MHz). The clock management module 11 is implemented using a PLLIP core, which generates the required multiple clock signals by configuring PLL parameters, providing corresponding operating clocks for different hardware interfaces.

[0068] The dual Ethernet interface module 12 is used to implement two independent Gigabit Ethernet interfaces on the internal network CPU side and the external network CPU side. Each interface includes an RGMII protocol conversion unit and an AXI-Stream data stream conversion unit. The RGMII protocol conversion unit converts 4-bit data from the external RGMII interface into an 8-bit data stream of the internal AXI-Stream protocol. The operating frequency is 125MHz. The dual Ethernet interface module supports bidirectional data transmission, that is, receiving data is converted from RGMII to AXI-Stream, and sending data is converted from AXI-Stream to RGMII.

[0069] The packet classification and routing module 13 is used to perform hardware-level classification and routing of Ethernet packets received by the internal network CPU. The packet classification and routing module 13 includes a packet caching unit, an EtherType extraction unit, and a routing decision unit. The packet caching unit uses FIFO to cache the complete packet content. The EtherType extraction unit extracts the EtherType field from the Ethernet frame header. The routing decision unit routes the packet to different processing modules according to the value of the EtherType field: when EtherType is 0x0800, it routes to the IP packet processing path; when EtherType is 0x1000, it routes to the MC packet processing path; and when EtherType is 0x1600, it routes to the TCM packet processing path.

[0070] The interface protocol conversion module 14 includes a TCM interface conversion unit, an MC interface conversion unit, and a DDR3 interface conversion unit. The TCM interface conversion unit is used to implement the TCM bus protocol and communicate with the TCM encryption chip, including TCM clock generation, address bus control, data bus control, and read / write control signal generation. The MC interface conversion unit is used to implement data format conversion between Ethernet packets and the main controller interface, including data width conversion, clock domain conversion, and packet filtering. The DDR3 interface conversion unit is used to implement the DDR3 memory interface protocol and provide DDR3 physical layer interface signals.

[0071] The data stream management module 15 is used to arbitrate and merge multiple data streams. The data stream management module 15 includes a multi-channel arbitrator, which employs a round-robin arbitration algorithm to merge multiple AXI-Stream data streams from different processing modules into a single output data stream. Specifically, the multi-channel arbitrator supports at least three data stream inputs: the first is the MC response data stream, the second is the external network CPU-side forwarded data stream, and the third is the TCM response data stream. The multi-channel arbitrator processes each data stream sequentially according to the principle of fair arbitration, ensuring that each data stream is processed in a timely manner and avoiding data congestion.

[0072] The reset control module 16 is used to implement phased reset sequence management. The reset control module 16 includes a reset delay counter, a reset timing control unit, and a VIO (virtual input / output) interface unit. The reset delay counter starts counting after the system reset is released, and controls the reset release timing of different interfaces based on the counter value. The reset timing control unit controls the reset timing of different interfaces, such as the PHY interface reset and TCM interface reset, according to a preset delay threshold. The VIO interface unit provides a configurable reset parameter interface, supporting dynamic adjustment of reset timing parameters through debugging tools.

[0073] Example 3, as Figure 3 As shown, this application provides an automated testing platform for a user service terminal hardware platform. The automated testing platform for the user service terminal hardware platform includes: an FPGA; an intranet CPU, which communicates with the FPGA via Gigabit Ethernet; an extranet CPU, which communicates with the FPGA via Gigabit Ethernet; a TCM measurement unit, which communicates with the FPGA through a private protocol interface; a main control unit, which communicates with the FPGA through GPIO; and a DDR, which communicates with the FPGA using a DDR3 standard interface.

[0074] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Figure 1 The automated testing method and specific examples of the user service terminal hardware platform in Embodiment 1 are also applicable to the automated testing system of the user service terminal hardware platform in this embodiment. Through the foregoing detailed description of the automated testing method of the user service terminal hardware platform, those skilled in the art can clearly understand the automated testing system of the user service terminal hardware platform in this embodiment. Therefore, for the sake of brevity, it will not be described in detail here.

[0075] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0076] Obviously, those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. An automated testing method for a user service terminal hardware platform, characterized in that, The method includes: After receiving Ethernet packets sent by the test host, the packet classification and routing module performs hardware-level Ethernet frame header parsing and routing decisions to obtain routing control signals. If the routing control signal is an IP packet, then the Ethernet data packet is forwarded directly to the external network interface; If the routing control signal is an MC packet or a TMC packet, the Ethernet data packet is sent to the interface protocol conversion module for protocol conversion and interaction testing, and multiple test response data streams are output. The data stream management module performs polling, arbitration, and merging of the multiple test response data streams, and outputs a single data stream; The single data stream is transmitted back to the test host via a dual Ethernet interface module.

2. The automated testing method for user service terminal hardware platform as described in claim 1, characterized in that, After receiving Ethernet packets sent by the test host, the packet classification and routing module performs hardware-level Ethernet frame header parsing and routing decisions to obtain routing control signals. The method includes: When the Ethernet interface on the CPU side of the internal network receives the Ethernet data packet sent by the test host, the data packet classification and routing module is activated; When the packet classification and routing module writes the Ethernet packet into the packet buffer FIFO, it simultaneously extracts the first 14 bytes of the Ethernet frame header. The EtherType field is extracted from the Ethernet frame header to make routing decisions and generate routing decision results. Based on the routing decision result, a routing control signal is generated, read from the packet buffer FIFO, and forwarded to the corresponding processing module.

3. The automated testing method for user service terminal hardware platform as described in claim 1, characterized in that, The data flow management module performs polling, arbitration, and merging of the multiple test response data streams to output a single data stream. The method includes: The multi-channel arbitrator in the data stream management module receives the multi-channel test response data streams, wherein each test response data stream includes a data signal, a valid signal, a termination signal, and a tready signal; The multi-channel arbitrator uses a polling arbitration algorithm to check the valid signals of the multi-channel test response data streams in a preset priority order and make a valid status judgment. When the Kth test response data stream is detected as a valid data stream, the Kth test response data stream is connected to the output port; When the transmission of the Kth test response data stream is completed, the system switches to the next valid data stream based on the end signal of the Kth test response data stream. The multi-channel arbitrator merges the multiple test response data streams into the single data stream for output.

4. The automated testing method for user service terminal hardware platform as described in claim 3, characterized in that, If the Kth test response data stream is connected to the output port and the output port cannot receive data, the transmission of the Kth test response data stream is paused by the first tready signal.

5. The automated testing method for user service terminal hardware platform as described in claim 1, characterized in that, The packet classification and routing module, interface protocol conversion module, data flow management module, and dual Ethernet interface module are managed by the clock management module for PLL-based multi-clock domain synchronization.

6. The automated testing method for user service terminal hardware platform as described in claim 5, characterized in that, The method further includes: An asynchronous FIFO is used to buffer the data transmitted between different clock domains divided by the clock management module. The asynchronous FIFO uses a Gray code counter to synchronize the read and write pointers across clock domains. During cross-clock domain transmission, a complete packet filter is used to detect the start and end markers of the Ethernet data packets and intercept incomplete data packets.

7. The automated testing method for user service terminal hardware platform as described in claim 1, characterized in that, The packet classification and routing module, interface protocol conversion module, data flow management module, and dual Ethernet interface module are managed in stages through a reset control module.

8. The automated testing method for user service terminal hardware platform as described in claim 7, characterized in that, The method further includes: Once the PLL lock is complete and the lock signal is valid, the system reset signal is released and the reset delay counter is started. The PHY interface remains in the reset state until the reset delay counter reaches the first preset threshold, and then the PHY reset signal is released according to the control signal provided by the VIO interface. When the count value of the reset delay counter reaches the delay target value, the TCM reset signal is released; Once the PHY interface, TCM interface, MC interface, and DDR3 memory interface have all been reset, the system enters the ready state.

9. An automated testing system for user service terminal hardware platforms, characterized in that, The system includes: a clock management module, a dual Ethernet interface module, a packet classification and routing module, an interface protocol conversion module, a data flow management module, and a reset control module.

10. An automated testing platform for user service terminal hardware platforms, characterized in that, The platform includes: FPGA; An internal network CPU communicates with the FPGA via gigabit Ethernet. An external network CPU communicates with the FPGA via gigabit Ethernet. The TCM measurement unit communicates with the FPGA via a proprietary protocol interface. The main control unit communicates with the FPGA via GPIO; The DDR uses the DDR3 standard interface to communicate with the FPGA.

Images