Network-based FPGA (Field Programmable Gate Array) software code automatic physical test method and system
The networked FPGA test platform enables automated closed-loop testing from hardware self-test to report generation, solving the challenges of test environment setup and cross-platform integration in FPGA testing, and improving test efficiency and result reliability.
Patent Information
- Application Number
- CN202511502472.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-21
- Publication Date
- 2026-01-23
AI Technical Summary
Existing FPGA testing technologies face technical challenges in setting up test environments, reproducing faults, and cross-platform debugging in highly integrated, high-speed interface, and complex system designs, making it difficult to achieve full-process, multi-level automated testing.
By connecting the server, terminal device, test card, and the daughter card under test to the same network, automated physical testing of FPGA software code is achieved. The automated process of closed-loop testing from hardware self-test to report generation includes hardware inspection, design analysis, file compilation, test stimulus loading, and data acquisition, and supports remote control and analysis.
It achieves full automation and remote operation of the testing process, improves equipment utilization, reduces manual intervention, ensures consistency of test conditions and comparability of results, and provides an efficient and reliable testing solution.
Smart Images
Figure CN121387732A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of automated testing and measurement technology, and in particular relates to a network-based automated physical testing method and system for FPGA software code. Background Technology
[0002] Currently, FPGA software physical testing technology has evolved from primarily functional verification to a comprehensive, multi-layered testing system covering functionality, performance, timing, power consumption, and reliability. Testing is typically performed on FPGA prototype systems or actual hardware platforms, using logic analyzers for real-time signal observation and high-speed oscilloscopes, protocol analyzers, and other instruments to verify interface timing and electrical characteristics. With the deepening application of FPGAs in 5G, AI, and autonomous driving, testing is gradually incorporating automated testing frameworks, hardware-software co-simulation, and FPGA-based hardware-in-the-loop (HIL) testing technologies to improve verification efficiency and coverage. Simultaneously, the establishment of modular test fixtures and standardized testing processes has significantly enhanced the design-for-testability (DFT) of FPGAs in the R&D, pilot-scale, and mass production stages. However, setting up test environments, reproducing faults, and cross-platform integration remain technical challenges when facing high integration, high-speed interfaces, and complex system designs.
[0003] Based on this, the present invention proposes a network-based automated physical testing platform for FPGA software code. Summary of the Invention
[0004] To address the above technical problems, this invention provides a network-based automated physical testing method and system for FPGA software code.
[0005] The technical solution adopted by this invention to solve its technical problem is:
[0006] A network-based automated physical testing method for FPGA software code connects a server, terminal device, test card, and daughter card under test to the same network. The test card includes the test FPGA and peripheral circuitry, and the daughter card under test includes the FPGA under test and peripheral circuitry. The test card and the daughter card under test are connected via connectors. The method includes the following steps:
[0007] S100: Starts the test card and the tested sub-card, performs hardware self-test, connectivity verification and identity recognition, and reports the device's working status to the server;
[0008] S200: Import the complete project, testbench, and test stimulus files of the FPGA design under test through the terminal device; the system parses the project and constraint files, and generates and configures the port signal attributes of the FPGA design under test.
[0009] S300: The system automatically compiles the imported files, generates the test FPGA project and test stimuli adapted to the physical test environment, and calls third-party tools to synthesize and compile the test FPGA project to generate the test FPGA bitstream file;
[0010] S400: Remotely loads the test FPGA bitstream file to the test FPGA via network, loads the FPGA under test bitstream file to the FPGA under test, loads the test stimulus to the storage device of the test card, then remotely starts the test process, and monitors and controls the test process;
[0011] S500: The test FPGA collects interface data online during the test process and caches or feeds it back to the server; the server or terminal device analyzes the collected data and generates a test report.
[0012] Preferably, S100 includes:
[0013] S110: Basic hardware checks are performed by the management unit on the test card, including power checks, critical chip status checks, clock and reset checks;
[0014] S120: Check the connectivity and identification of the module. The processor reads the memory on the tested daughter card to obtain the unique identification code of the tested daughter card, and performs continuity test or loopback test on the key signal path on the connector.
[0015] S130: Perform read / write mode tests on the external memory mounted on the test card; verify the high-speed communication interface between the test card and the server;
[0016] S140: Generate a self-test status report and upload it to the server via the network for visualization.
[0017] Preferably, S200 includes:
[0018] S210: Analyze the imported FPGA project under test and analyze its design hierarchy to determine the top-level module and its ports;
[0019] S220: Extract the names, directions, and physical pin numbers of all signals to be tested from the project's constraint file;
[0020] S230: The imported testbench file contains the test stimulus file and the timing and control logic for injecting the test stimulus into the design under test;
[0021] S240: Based on the physical connection relationship determined between the test FPGA pins and connectors, and between the connectors and the FPGA pins under test, the system automatically generates the position constraints, level parameters, and port protocol configurations of the corresponding pins of the test FPGA according to the extracted FPGA pin configuration information and port protocol type.
[0022] Preferably, after automatically generating the pin and protocol configuration of the test FPGA, manual operation of the configuration can be performed through the terminal device to check and adjust it.
[0023] Preferably, S300 includes:
[0024] S310: Analyze the source code, constraint file and configured port attributes of the FPGA under test, extract the pin configuration information of the FPGA under test, and map the extracted pin configuration information to the physical resources of the test platform;
[0025] S320: Based on the signal type and test requirements, it automatically instantiates the corresponding test IP module in the test FPGA project and constrains the corresponding pins; it also automatically instantiates the test control module and sampling module in the test FPGA project. The test control module is used for the management and control of test stimulus input, and the sampling module is used for the acquisition of data returned by the test interface.
[0026] S330: Calls third-party tools to synthesize and compile the test FPGA project, generating the final test FPGA bitstream file.
[0027] Preferably, S400 includes:
[0028] S410: The user sends the bitstream file of the test FPGA to the onboard processor on the test card via the server through the client operation. The processor then writes the bitstream file to the test FPGA through the JTAG interface or SelectMap configuration mode of the test FPGA to complete the configuration of the test FPGA. At the same time, the user also sends the bitstream file of the FPGA under test to the onboard processor on the daughter card under test remotely via the server. The processor then writes the bitstream file to the FPGA under test through the JTAG interface or SelectMap configuration mode of the FPGA under test.
[0029] S420: Imports the test stimulus data into the external DDR memory of the test FPGA via the Ethernet interface of the test FPGA;
[0030] S430: Users can remotely issue commands through the client to start the test process.
[0031] Preferably, the remote start test process in S430 includes:
[0032] Users send commands remotely to the onboard processor of the FPGA under test via the server through the client to reset the FPGA under test and start the test process.
[0033] Meanwhile, the user sends commands remotely from the client to the test control module in the test FPGA via the server to start the test process;
[0034] After receiving the start command, the test control module reads the test stimulus from the external DDR memory of the test FPGA and, according to the timing and method defined by the testbench, loads the test stimulus into the corresponding interface of the FPGA under test.
[0035] Preferably, S500 includes:
[0036] S510: During the test, the interface signals of the FPGA under test are collected in real time through the sampling module automatically instantiated in the test FPGA, and the collected test data is stored in the onboard DDR memory of the test card for caching, or directly fed back to the server through a high-speed dedicated channel.
[0037] S520: The test process will automatically end after the test control module in the test FPGA has completed sending all test stimuli.
[0038] S530: The server-side or client-side software analyzes the collected test data, compares the results with the expected data, and automatically generates a test report.
[0039] A network-based automated physical testing system for FPGA software code includes:
[0040] The server contains server-side software that has been deployed with the testing system.
[0041] Multiple terminal devices, each with client software deployed;
[0042] The test card includes a test FPGA, onboard processor, DDR4 memory, Ethernet interface, and high-speed serial interface;
[0043] The daughter card under test includes the FPGA under test, the onboard processor, and the connectors;
[0044] A switching network connects servers, terminal devices, test cards, and the daughter cards under test to the same network.
[0045] The test card and the sub-card under test are connected via a connector; the system is configured to execute the steps of a network-based FPGA software code automated physical testing method.
[0046] A computer device includes a memory and a processor, the memory storing a computer program, characterized in that the processor executes the computer program to implement the steps of a network-based FPGA software code automated physical testing method.
[0047] The aforementioned network-based automated physical testing method and system for FPGA software code achieves full automation and remote operation of the testing process by connecting test equipment to the network and defining the test flow. This method integrates traditionally fragmented testing processes that rely on dedicated instruments and on-site operations into a unified online workflow, significantly improving testing efficiency. Its core benefits are twofold: firstly, it enables centralized management and remote sharing of test resources, greatly improving equipment utilization; secondly, through standardized automated processes, it effectively reduces manual intervention, lowering operational difficulty and the risk of human error, while ensuring consistency of test conditions and comparability of results, providing an efficient, reliable, and easy-to-implement solution for FPGA physical testing. Attached Figure Description
[0048] Figure 1 This is a system composition diagram of a network-based FPGA software physical testing cloud platform according to an embodiment of the present invention;
[0049] Figure 2 This is a flowchart of a network-based automated physical testing method for FPGA software code according to one embodiment of the present invention;
[0050] Figure 3 This is a system composition diagram of a network-based FPGA software physical testing cloud platform according to another embodiment of the present invention. Detailed Implementation
[0051] To enable those skilled in the art to better understand the technical solution of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings.
[0052] In one embodiment, such as Figure 1 and 2 As shown, a network-based automated physical testing method for FPGA software code is characterized by connecting a server, a terminal device (e.g., a PC), a test card, and a daughter card under test to the same network. The test card includes the test FPGA and its peripheral circuits, and the daughter card under test includes the FPGA under test and its peripheral circuits. The test card and the daughter card under test are connected via connectors. The method includes the following steps:
[0053] S100: Starts the test card and the tested sub-card, performs hardware self-test, connectivity verification and identity recognition, and reports the device's working status to the server;
[0054] S200: Import the complete project, testbench, and test stimulus files of the FPGA design under test through the terminal device; the system parses the project and constraint files, and generates and configures the port signal attributes of the FPGA design under test.
[0055] S300: The system automatically compiles the imported files, generates the test FPGA project and test stimuli adapted to the physical test environment, and calls third-party tools to synthesize and compile the test FPGA project to generate the test FPGA bitstream file;
[0056] S400: Remotely loads the test FPGA bitstream file to the test FPGA via network, loads the FPGA under test bitstream file to the FPGA under test, loads the test stimulus to the storage device of the test card, then remotely starts the test process, and monitors and controls the test process;
[0057] S500: The test FPGA collects interface data online during the test process and caches or feeds it back to the server; the server or terminal device analyzes the collected data and generates a test report.
[0058] Specifically, this invention constructs a complete networked FPGA testing solution. By networking test equipment, it achieves centralized management and remote sharing of test resources, significantly improving equipment utilization and testing convenience. The defined five core steps form an automated closed-loop testing process from hardware preparation to report generation, systematically integrating the traditionally manual, discrete steps, greatly improving testing efficiency, reducing human intervention, and ensuring the consistency and repeatability of the testing process.
[0059] In one embodiment, S100 includes:
[0060] S110: Basic hardware checks are performed by the management unit on the test card (e.g., onboard controller), including power checks, critical chip status, clock and reset checks;
[0061] S120: Check the connectivity and identification of the module. The processor reads the memory (FLASH or EEPROM) on the tested daughter card to obtain the unique identification code of the tested daughter card, and performs continuity test or loopback test on the key signal path on the connector to confirm that the physical connection is reliable and there is no open circuit or short circuit.
[0062] S130: Perform read / write mode tests on the external storage (DDR memory) mounted on the test card; verify the high-speed communication interface between the test card and the server (host computer);
[0063] S140: Generates a self-test status report and uploads it to the server via the network (Ethernet), where it is visualized.
[0064] Specifically, through a hierarchical inspection strategy, from basic hardware status to interconnectivity, and then to external storage and high-speed channels, a comprehensive diagnosis of the test platform's health status is achieved. The automatic generation and visualization of status reports enable operations and maintenance personnel to quickly and intuitively grasp the system status, greatly simplifying pre-test preparation, effectively preventing test failures due to hardware or connectivity issues, and improving the test startup success rate and reliability.
[0065] In one embodiment, S200 includes:
[0066] S210: Analyze the imported FPGA project under test and analyze its design hierarchy to determine the top-level module and its ports;
[0067] S220: Extract the name, direction (input / output), and physical pin number of all signals to be tested from the project's constraint file;
[0068] S230: The imported testbench file contains the test stimulus file and the timing and control logic for injecting the test stimulus into the design under test;
[0069] S240: Based on the physical connection relationship determined between the test FPGA pins and connectors, and between the connectors and the FPGA pins under test, the system automatically generates the position constraints, level parameters, and port protocol configurations of the corresponding pins of the test FPGA according to the extracted FPGA pin configuration information and port protocol type.
[0070] Specifically, this solution achieves intelligent and precise mapping from the design under test (DUT) to the test hardware. By automatically parsing engineering files and constraints, it accurately extracts test interface information and automatically generates the configuration of the test FPGA based on the defined physical connection relationships, completely freeing engineers from the tedious and error-prone manual pin matching and protocol configuration work. This not only significantly shortens test setup time but also eliminates test deviations caused by configuration errors at the source, ensuring test accuracy.
[0071] In one embodiment, after automatically generating the pin and protocol configuration of the test FPGA, manual operation of the configuration via a terminal device is also supported for checking and adjusting the configuration.
[0072] Specifically, necessary human-computer interaction is introduced on top of a high degree of automation. It supports manual inspection and adjustment of automatically generated configurations, providing flexibility for handling complex, non-standard, or potentially flawed interface protocols. This "automation-centric, human-assisted" model ensures high efficiency while also considering the system's adaptability and fault tolerance, enabling it to cope with a wider range of testing scenarios and design requirements.
[0073] In one embodiment, S300 includes:
[0074] S310: Analyze the source code, constraint file and configured port attributes of the FPGA under test, extract the pin configuration information of the FPGA under test, and map the extracted pin configuration information to the physical resources of the test platform;
[0075] S320: Based on the signal type and test requirements, it automatically instantiates the corresponding test IP module in the test FPGA project and constrains the corresponding pins; it also automatically instantiates the test control module and sampling module in the test FPGA project. The test control module is used for the management and control of test stimulus input, and the sampling module is used for the acquisition of data returned by the test interface.
[0076] S330: Calls third-party tools to synthesize and compile the test FPGA project, generating the final test FPGA bitstream file (test FPGA configuration file).
[0077] Specifically, by automatically mapping resources and instantiating test IPs and control modules, a "one-click build" of the test environment is achieved, significantly reducing the complexity and time cost of manually creating test projects. Utilizing a mature third-party toolchain for compilation ensures the professionalism and quality of the generated bitstream files. This solution shifts the focus of test preparation from low-level implementation to high-level definition, improving overall efficiency.
[0078] In one embodiment, S400 includes:
[0079] S410: The user sends the bitstream file of the test FPGA to the onboard processor on the test card via the server through the client operation. The processor then writes the bitstream file to the test FPGA through the JTAG interface or SelectMap configuration mode of the test FPGA to complete the configuration of the test FPGA. At the same time, the user also sends the bitstream file of the FPGA under test to the onboard processor on the daughter card under test remotely via the server. The processor then writes the bitstream file to the FPGA under test through the JTAG interface or SelectMap configuration mode of the FPGA under test.
[0080] S420: Imports the test stimulus data into the external DDR memory of the test FPGA via the Ethernet interface of the test FPGA;
[0081] S430: Users can remotely issue commands through the client to start the test process.
[0082] Specifically, by remotely loading bitstream files and test stimuli over the network, users can complete all test configurations without being physically present at the equipment site, greatly improving testing flexibility and resource accessibility. This process encapsulates complex hardware configuration operations into simple remote commands, reducing the technical requirements for operators and enabling distributed teams to easily share and use the test platform.
[0083] In one embodiment, the remote start test process in S430 includes:
[0084] Users send commands remotely to the onboard processor of the FPGA under test via the server through the client to reset the FPGA under test and start the test process.
[0085] Meanwhile, the user sends commands remotely from the client to the test control module in the test FPGA via the server to start the test process;
[0086] After receiving the start command, the test control module reads the test stimulus from the external DDR memory of the test FPGA and, according to the timing and method defined by the testbench, loads the test stimulus into the corresponding interface of the FPGA under test.
[0087] Specifically, by sending commands to both the FPGA under test and the test control module, the system under test is ensured to be in a known initial state (reset startup), and test stimuli are applied according to a preset precise timing sequence. This controlled startup method ensures the consistency of test conditions, which is crucial for scenarios requiring precise timing verification, thereby guaranteeing the reliability and comparability of test results.
[0088] In one embodiment, S500 includes:
[0089] S510: During the test, the interface signals of the FPGA under test are collected in real time through the sampling module automatically instantiated in the test FPGA, and the collected test data is stored in the onboard DDR memory of the test card for caching, or directly fed back to the server through a high-speed dedicated channel.
[0090] S520: The test process will automatically end after the test control module in the test FPGA has completed sending all test stimuli.
[0091] S530: The server-side or client-side software analyzes the collected test data, compares the results with the expected data, and automatically generates a test report.
[0092] Specifically, real-time data acquisition and flexible caching or transmission mechanisms ensure complete capture of test data; automatic termination logic based on stimulus delivery completion enables intelligent process control; and final automatic data analysis and report generation transform raw data into intuitive test conclusions. The entire solution significantly accelerates the testing and verification cycle and provides immediate and reliable data for decision-making.
[0093] The network-based FPGA software physical testing cloud platform constructed in this invention achieves full automation, remote access, and intelligence of the FPGA testing process by integrating servers, terminals, test cards, and the cards under test into a unified network. Its core benefits are as follows: First, it greatly improves testing efficiency and resource utilization, integrating the traditional fragmented process that relies on multiple physical instruments and manual operation into a remotely executable automated test pipeline. Users can complete the entire process from project import to report generation via the network, significantly shortening the testing cycle and supporting flexible scheduling and sharing of test resources across regions. Second, it significantly reduces testing complexity and the risk of human error. The system automatically parses design files, intelligently maps physical pins, and generates test projects with one click, transforming complex hardware configuration and signal connection work into a standardized software process, reducing reliance on professional instruments and personnel while improving configuration accuracy. Third, it comprehensively enhances test controllability and result reliability. From equipment self-testing, stimulus loading, process control to data acquisition and analysis, it forms a closed-loop testing system that is monitorable and controllable across the entire chain, ensuring consistent test conditions and complete and traceable data. This provides an efficient, reliable, and reusable system-level solution for the functional, performance, and reliability verification of highly complex FPGA designs.
[0094] In one embodiment, such as Figure 3 As shown, a network-based automated physical testing system for FPGA software code is also provided, including:
[0095] The server contains server-side software that has been deployed with the testing system.
[0096] Multiple terminal devices, each with client software deployed;
[0097] The test card includes a test FPGA, onboard processor, DDR4 memory, Ethernet interface, and high-speed serial interface;
[0098] The daughter card under test includes the FPGA under test, the onboard processor, and the connectors;
[0099] A switching network connects servers, terminal devices, test cards, and the daughter cards under test to the same network.
[0100] The test card and the sub-card under test are connected via a connector; the system is configured to execute the steps of a network-based FPGA software code automated physical testing method.
[0101] Specific limitations regarding a network-based automated physical testing system for FPGA software code can be found in the limitations of a network-based automated physical testing method for FPGA software code described above, and will not be repeated here. Each module in the aforementioned network-based automated physical testing system for FPGA software code can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independent of the processor in a computer device, or stored in software in the memory of a computer device, so that the processor can call and execute the corresponding operations of each module.
[0102] A computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of a network-based FPGA software code automated physical testing method.
[0103] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, or optical storage, etc. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.
[0104] The above provides a detailed description of a network-based automated physical testing method and system for FPGA software code provided by this invention. Specific examples have been used to illustrate the principles and implementation methods of this invention, and the descriptions of the embodiments are merely for the purpose of helping to understand the core ideas of this invention. It should be noted that those skilled in the art can make various improvements and modifications to this invention without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this invention.
Claims
1. A network-based automated physical testing method for FPGA software code, characterized in that, The server, terminal equipment, test card, and daughter card under test are connected to the same network. The test card includes a test FPGA and peripheral circuits, and the daughter card under test includes the FPGA under test and peripheral circuits. The test card and the daughter card under test are connected via connectors. The method includes the following steps: S100: Starts the test card and the tested sub-card, performs hardware self-test, connectivity verification and identity recognition, and reports the device's working status to the server; S200: Import the complete project, testbench, and test stimulus files of the FPGA design under test through the terminal device; the system parses the project and constraint files, and generates and configures the port signal attributes of the FPGA design under test. S300: The system automatically compiles the imported files, generates the test FPGA project and test stimuli adapted to the physical test environment, and calls third-party tools to synthesize and compile the test FPGA project to generate the test FPGA bitstream file; S400: Remotely loads the test FPGA bitstream file to the test FPGA via network, loads the FPGA under test bitstream file to the FPGA under test, loads the test stimulus to the storage device of the test card, then remotely starts the test process, and monitors and controls the test process; S500: The test FPGA collects interface data online during the test process and caches or feeds it back to the server; the server or terminal device analyzes the collected data and generates a test report.
2. The method according to claim 1, characterized in that, S100 includes: S110: Basic hardware checks are performed by the management unit on the test card, including power checks, critical chip status checks, clock and reset checks; S120: Check the connectivity and identification of the module. The processor reads the memory on the tested daughter card to obtain the unique identification code of the tested daughter card, and performs continuity test or loopback test on the key signal path on the connector. S130: Perform read / write mode tests on the external memory mounted on the test card; verify the high-speed communication interface between the test card and the server; S140: Generate a self-test status report and upload it to the server via the network for visualization.
3. The method according to claim 2, characterized in that, S200 includes: S210: Analyze the imported FPGA project under test and analyze its design hierarchy to determine the top-level module and its ports; S220: Extract the names, directions, and physical pin numbers of all signals to be tested from the project's constraint file; S230: The imported testbench file contains the test stimulus file and the timing and control logic for injecting the test stimulus into the design under test; S240: Based on the physical connection relationship determined between the test FPGA pins and connectors, and between the connectors and the FPGA pins under test, the system automatically generates the position constraints, level parameters, and port protocol configurations of the corresponding pins of the test FPGA according to the extracted FPGA pin configuration information and port protocol type.
4. The method according to claim 3, characterized in that, After automatically generating the pin and protocol configurations for the test FPGA, manual operation via terminal devices is also supported to check and adjust the configuration.
5. The method according to claim 4, characterized in that, The S300 includes: S310: Analyze the source code, constraint file and configured port attributes of the FPGA under test, extract the pin configuration information of the FPGA under test, and map the extracted pin configuration information to the physical resources of the test platform; S320: Based on the signal type and test requirements, it automatically instantiates the corresponding test IP module in the test FPGA project and constrains the corresponding pins; it also automatically instantiates the test control module and sampling module in the test FPGA project. The test control module is used for the management and control of test stimulus input, and the sampling module is used for the acquisition of data returned by the test interface. S330: Calls third-party tools to synthesize and compile the test FPGA project, generating the final test FPGA bitstream file.
6. The method according to claim 5, characterized in that, The S400 includes: S410: The user sends the bitstream file of the test FPGA to the onboard processor on the test card via the server through the client operation. The processor then writes the bitstream file to the test FPGA through the JTAG interface or SelectMap configuration mode of the test FPGA to complete the configuration of the test FPGA. At the same time, the user also sends the bitstream file of the FPGA under test to the onboard processor on the daughter card under test remotely via the server. The processor then writes the bitstream file to the FPGA under test through the JTAG interface or SelectMap configuration mode of the FPGA under test. S420: Imports the test stimulus data into the external DDR memory of the test FPGA via the Ethernet interface of the test FPGA; S430: Users can remotely issue commands through the client to start the test process.
7. The method according to claim 6, characterized in that, The remote start test process in S430 includes: Users send commands remotely to the onboard processor of the FPGA under test via the server through the client to reset the FPGA under test and start the test process. Meanwhile, the user sends commands remotely from the client to the test control module in the test FPGA via the server to start the test process; After receiving the start command, the test control module reads the test stimulus from the external DDR memory of the test FPGA and, according to the timing and method defined by the testbench, loads the test stimulus into the corresponding interface of the FPGA under test.
8. The method according to claim 7, characterized in that, The S500 includes: S510: During the test, the interface signals of the FPGA under test are collected in real time through the sampling module automatically instantiated in the test FPGA, and the collected test data is stored in the onboard DDR memory of the test card for caching, or directly fed back to the server through a high-speed dedicated channel. S520: The test process will automatically end after the test control module in the test FPGA has completed sending all test stimuli. S530: The server-side or client-side software analyzes the collected test data, compares the results with the expected data, and automatically generates a test report.
9. A network-based automated physical testing system for FPGA software code, characterized in that, include: The server contains server-side software that has been deployed with the testing system. Multiple terminal devices, each with client software deployed; The test card includes a test FPGA, onboard processor, DDR4 memory, Ethernet interface, and high-speed serial interface; The daughter card under test includes the FPGA under test, the onboard processor, and the connectors; A switching network connects servers, terminal devices, test cards, and the daughter cards under test to the same network. The test card and the sub-card under test are connected via a connector; the system is configured to perform the method according to any one of claims 1 to 8.
10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.