Test method and device of SOC system, computer equipment and storage medium

Abstract

The application relates to integrated chip testing technology and discloses a test method for an SOC system, which comprises the following steps: deploying a test scene on an SOC system and generating a first test case corresponding to the test scene, wherein the test scene comprises at least one of a verification IP, a virtual machine compiler and an FPGA platform compiler; determining a test function according to a test requirement and generating a second test case corresponding to the test function according to the first test case, wherein the test function comprises at least one of a connection line detection, a timing detection, simulation information control, simulation waveform control, coverage control and DUT code control; and executing all the second test cases on the SOC system to obtain a test result. The application further discloses a test device for the SOC system, a computer device and a computer readable storage medium. The application aims to improve the test efficiency of the SOC system.

Description

Technical Field

[0001] This application relates to the field of integrated chip testing technology, and in particular to a testing method, apparatus, computer equipment, and computer-readable storage medium for a System-on-a-Chip (SOC) system. Background Technology

[0002] A System on Chip (SOC) is a product, an integrated circuit with a specific purpose, containing a complete system and embedded software. Currently, SOCs are widely used in consumer electronics, high-end manufacturing, network communications, home appliances, the Internet of Things, and many other fields. Due to the high technical barriers and long design cycles associated with SOCs, SOC verification is an indispensable and crucial part of the modern digital integrated circuit design flow.

[0003] Currently, when validating a SOC system, if the test environment is complex and there are many test functions involved, the relevant engineers need to perform various functional tests for each test environment one by one, which is inefficient.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main objective of this application is to provide a testing method, a testing apparatus, a computer device, and a computer-readable storage medium for a System-on-a-Chip (SOC) system, with the aim of improving the testing efficiency of an SOC system.

[0006] To achieve the above objectives, this application provides a testing method for a SOC system, comprising the following steps:

[0007] Deploy a test scenario on the SOC system and generate a first test case corresponding to the test scenario. The test scenario includes at least one of a verification IP, a virtual machine compiler, and an FPGA platform compiler.

[0008] The test functions are determined according to the test requirements, and a second test case corresponding to the test function is generated according to the first test case. The test function includes at least one of the following: connection detection, timing detection, simulation information control, simulation waveform control, coverage control, and DUT code control.

[0009] Execute all the second test cases for the SOC system to obtain the test results.

[0010] Optionally, after the step of executing all the second test cases for the SOC system and obtaining the test results, the method further includes:

[0011] The SOC system is iteratively updated based on the test results.

[0012] Optionally, the step of iteratively updating the SOC system based on the test results includes:

[0013] The test results are analyzed using a pre-trained neural network model to obtain corrected data;

[0014] The SOC system is iteratively updated using the corrected data;

[0015] The neural network model is pre-trained based on multiple training samples, each of which includes a test result sample and corresponding correction data.

[0016] Optionally, the testing method for the SOC system further includes:

[0017] Check whether the test values ​​in the test results match the expected values ​​in the second test case;

[0018] If not, proceed with the step of iteratively updating the SOC system based on the test results.

[0019] Optionally, after the step of iteratively updating the SOC system based on the test results, the method further includes:

[0020] Based on the updated SOC system, return to the steps of deploying the test scenario on the SOC system and generating the first test case corresponding to the test scenario.

[0021] To achieve the above objectives, this application also provides a testing apparatus for a SOC system, comprising:

[0022] The test scenario management module is used to deploy test scenarios on the SOC system and generate the first test cases corresponding to the test scenarios. The test scenarios include at least one of verification IP, virtual machine compiler and FPGA platform compiler.

[0023] The test function module is used to determine the test function according to the test requirements and generate a second test case corresponding to the test function according to the first test case. The test function includes at least one of the following: connection detection, timing detection, simulation information control, simulation waveform control, coverage control and DUT code control.

[0024] The verification module is used to execute all the second test cases for the SOC system and obtain the test results.

[0025] To achieve the above objectives, this application also provides a computer device, the computer device comprising: a memory, a processor, and a test program for a System-on-a-Chip (SOC) system stored in the memory and executable on the processor, wherein when the test program for the SOC system is executed by the processor, it implements the steps of the test method for the SOC system described above.

[0026] To achieve the above objectives, this application also provides a computer-readable storage medium storing a test program for a System-on-a-Chip (SOC) system, wherein when the test program for the SOC system is executed by a processor, it implements the steps of the test method for the SOC system described above.

[0027] The testing method, testing apparatus, computer equipment, and computer-readable storage medium provided in this application enable the SOC system to achieve full coverage of testing scenarios. Combined with the management of testing function modules, it can complete unified testing of functions such as connection detection, timing detection, simulation information control, simulation waveform control, coverage control, and DUT code control, ultimately realizing a complete SOC testing process. This allows for the rapid extraction of useful key information and the simulation and comparison of different test scenarios to quickly locate problems, thereby improving the efficiency of SOC system testing. Attached Figure Description

[0028] Figure 1 This is a schematic diagram of the testing method steps of a SOC system in one embodiment of this application;

[0029] Figure 2 This is a schematic diagram of a test apparatus for a SOC system in one embodiment of this application;

[0030] Figure 3 This is a schematic block diagram of the internal structure of a computer device according to an embodiment of this application.

[0031] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0032] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0033] Reference Figure 1 In one embodiment, the testing method for the SOC system includes:

[0034] Step S10: Deploy the test scenario on the SOC system and generate the first test case corresponding to the test scenario. The test scenario includes at least one of the verification IP, virtual machine compiler and FPGA platform compiler.

[0035] Step S20: Determine the test functions according to the test requirements, and generate a second test case corresponding to the test functions according to the first test case. The test functions include at least one of connection detection, timing detection, simulation information control, simulation waveform control, coverage control and DUT code control.

[0036] Step S30: Execute all the second test cases for the SOC system to obtain the test results.

[0037] In this embodiment, the terminal can be a SOC system, a control device that has established a communication connection with the SOC system, or a testing device for the SOC system.

[0038] As described in step S10, the terminal can deploy multiple test scenarios on the SOC system, wherein the test scenarios include at least one of verification IP, virtual machine compiler and FPGA (Field Programmable Gate Array) platform compiler.

[0039] Optionally, the Verification IP is implemented through a virtual interface, replacing the host (CPU (central processing unit) and DMA (Direct Memory Access, etc.), and utilizing UVM (Universal Verification Methodology) to verify test cases and implement different path scenario tests. The test environment corresponding to the Verification IP exhibits good constrained randomness and can be applied to the debugging of minimal SOC systems, from the initial testing process to the complete testing process.

[0040] Optionally, the virtual machine compiler uses a Linux emulation tool to compile and build C code, which is then executed by the CPU using test cases. Based on this verification method, relevant testers can easily expand the test cases they are responsible for. If the minimum SOC system is confirmed through IP verification and preparation is complete, waveform comparisons can be performed using the virtual machine compiler, thus improving the progress of the virtual machine compilation environment.

[0041] Optionally, the FPGA platform compiler is built using software like Keil, which compiles the C program and then programs it onto the FPGA platform for simulation and debugging. If problems arise during FPGA simulation or the simulation platform requires further verification, the relevant program can be loaded into the CPU to execute this scenario, thereby accelerating the simulation process.

[0042] Optionally, the terminal can be configured by default to deploy the verification IP, virtual machine compiler, and FPGA platform compiler on the SOC system for all test scenarios; of course, relevant testers can also select at least one test scenario for deployment according to actual test needs.

[0043] Optionally, based on the various test scenarios deployed on the SOC system, corresponding test cases can be created for each test scenario. It should be noted that a test case is a description of a testing task for a specific software product, reflecting the test plan, methods, techniques, and strategies; its content includes test objectives, test environment, input data, test steps, expected results, test scripts, etc., ultimately forming a document. Simply put, a test case is a set of test inputs, execution conditions, and expected results compiled for a specific goal, used to verify whether a specific software requirement is met.

[0044] Optionally, after a test scenario is deployed on the SOC system, the terminal can detect the test environment corresponding to that test scenario. Furthermore, relevant testers can pre-write test case templates and test scripts for each test scenario. Therefore, based on the test environment, test case templates, and test scripts for each test scenario, the terminal can generate test cases (marked as the first test case) for each test scenario.

[0045] It should be noted that the first test case is not a complete test case, as it is missing key elements such as test objectives, test steps, and expected results. Therefore, the first test case needs to be completed by executing step S20.

[0046] As described in step S20, multiple corresponding test function modules can be set according to the type of test function provided by the terminal. The types of test functions include at least one of connection detection, timing detection, simulation information control (simulation information may include simulation time), simulation waveform control, coverage control, and DUT code control.

[0047] Optionally, a first test function module can be established for the connection detection test function. The test logic of the first test function module is as follows: using UVM syntax, a specific sequence of signals is input at the source end, and the specific sequence is detected at the destination end, thereby establishing the correct connection relationship; then, combined with the test script, the bit width of all signals to be checked, the source signal path, and the corresponding destination signal path are determined; through the first test function module, the correct connection of the expected signals can be ensured, and the testing of the entire SOC system can be checked as needed, especially in the early stages of verification and when integrating new IP, it can quickly eliminate bugs caused by connection problems.

[0048] Optionally, a second test module can be established for timing detection testing. The test logic of this second module is as follows: using a scripting language, it excludes timing violations caused by asynchronous reasons and other verifiable violations, while retaining the actual violation information to achieve rapid extraction of useful information. This second test module can be enabled during post-simulation.

[0049] Optionally, a third test function module can be established for the simulation information control testing function. The test logic of the third test function module is as follows: output information at key nodes (helping to improve the understanding of the simulation process), promptly understand the verification status, and then control the simulation time in a timely manner based on the key nodes; moreover, when the third test function module is combined with the first test function module, UVM can be used to provide powerful simulation information control, allowing the simulation to be stopped in a timely manner when necessary; since both the second and third test function modules are written in C language, it is necessary to add necessary simulation information to the C language when writing the scenario. The third test function module can detect specific CPU behaviors, output information in a timely manner to facilitate understanding of the simulation process and determine the simulation results based on node information, and update verification information to obtain verification result reports (feedback), thereby quickly achieving accurate collection of verification results, reducing unnecessary manual intervention, and improving the efficiency of automated information management.

[0050] Optionally, a fourth test function module can be established for the test function of simulated waveform control. The test logic of the fourth test function module is as follows: extract waveform information of useful modules according to test needs to reduce unnecessary simulation resources; different parameters are pre-set to control the effective RTL (Real-Time Logistics) information of the dump file, so as to facilitate flexible scheduling during system simulation.

[0051] Optionally, a fifth test function module can be established for coverage control testing. The test logic of this fifth module is as follows: extract coverage information of useful modules according to testing needs (e.g., select coverage information for some modules or the entire system as needed); furthermore, this module can manage and control functional and code coverage, and based on the coverage information, facilitate verifiers in completing verification test items, thereby improving the completeness of the SOC system testing.

[0052] Optionally, a sixth test function module can be established for the testing functions controlled by the DUT code. The test logic of this sixth test function module is as follows: Since the DUT code can be flexibly controlled as needed, it can provide minimum system code, FPGA code, system simulation code, and synthesized netlist, etc. The minimum system is a simple, adjustable system (comprising a CPU, bus, and memory modules), thus serving as the minimum module for basic FPGA engineering development. For the FPGA code, some simulation modules may have different interfaces, which are distinguished using this Define. The system simulation code is the code actually used in the design. The netlist code is the code used by the synthesis backend and can be used for netlist verification of the SOC system.

[0053] Optionally, the terminal will determine the functions that the SOC system needs to test in each test scenario based on the test requirements. The default test requirement is to perform full-function testing on each test scenario; of course, relevant testers can also select the functions to be tested in each test scenario (at least one function to be tested in each test scenario) and write the corresponding test requirements according to actual needs.

[0054] Optionally, the selected test functions can be the same or different for different test scenarios. For example, for the test scenario combination of verification IP and virtual machine compiler, the connection detection test function can be selected for verification IP, while the connection detection and timing detection test functions can be selected for virtual machine compiler; or, for the test scenario combination of verification IP and virtual machine compiler, connection detection, timing detection, simulation information control, simulation waveform control, coverage control, and DUT code control test functions can be selected for both.

[0055] Optionally, after the terminal determines the test functions corresponding to each test scenario based on the test requirements, the first test cases corresponding to each test scenario are improved based on the test functions corresponding to each test scenario to generate the second test cases corresponding to each test scenario.

[0056] It should be understood that, based on the attributes and test logic corresponding to the test function, key information such as the test objective, test steps, and expected results (including expected values) for the test cases can be obtained. For example, for connection detection, the corresponding test objective is a certain expected signal, the test steps are the test process described by the test logic, and the expected value is that the expected signal is connected correctly.

[0057] It should be noted that since different test scenarios correspond to different test environments, even if the test functions are the same, some of the values ​​obtained may be the same or different for different test scenarios (such as the expected values ​​obtained may be the same or may not be the same).

[0058] Optionally, when the same test scenario corresponds to multiple test functions, multiple second test cases can be written based on the corresponding first test case (e.g., for test functions a, b, and c, second test cases A+a, A+b, and A+c can be written based on the first test case A); or, multiple test functions can be written into one second test case based on the first test case (e.g., for test functions a, b, and c, second test case A+(a, b, c) can be written based on the first test case A).

[0059] As described in step S30, after obtaining the second test cases corresponding to each test scenario, the terminal can summarize all the second test cases into a test case list and execute the second test cases sequentially by executing the test case list. During the execution of each second test case, related test functions can be associated with it, and the relevant test function modules can be called for testing.

[0060] Optionally, after the second test case is executed, the terminal can obtain the test value obtained by each second test case, as well as the expected value written in the second test case, compare and output, and generate test results.

[0061] In one embodiment, a flexible combination of test scenario management and test function module management is achieved through scripts (relevant testers can independently select the appropriate test scenarios and test function combinations based on their script proficiency). This solution uses Makefiles for scheduling and management control, and builds test lists for the SOC system under three test scenarios based on the test list in the verification plan. Moreover, if problems are found during the simulation process, the relevant testers only need to return to the test list to confirm that the code modifications are correct, without affecting the existing SOC functions, which greatly improves the testing efficiency of the SOC system. Furthermore, this method can accelerate the convergence of the SOC system and quickly locate problems at different stages, greatly shortening the verification time and improving testing efficiency.

[0062] This allows the SOC system to achieve sufficient test scenario coverage. Combined with test function module management, it can complete functional tests such as checking the correctness of integrated wiring, verifying the correctness of timing, outputting valid log signals and controlling the flexible scheduling of simulation processes, controlling useful layered waveform files, achieving complete collection of functional and code coverage, and flexibly controlling the effective code DUTs at different stages of SOC integration. Ultimately, it realizes a complete SOC testing process, thereby quickly extracting useful key information and simulating different test scenarios for comparison to quickly locate problems, thus improving the efficiency of SOC system testing.

[0063] In one embodiment, based on the above embodiment, after the step of executing all the second test cases for the SOC system and obtaining the test results, the method further includes:

[0064] The SOC system is iteratively updated based on the test results.

[0065] In this embodiment, after the terminal receives the test results of the SOC system, the test results can be output to the associated devices of the relevant testers for their review. Thus, when testers discover problems with the SOC system based on the test results (such as a function failing a test), they only need to return to the test list, correct the corresponding system code, and iterate and update the SOC system. By repeatedly iterating the SOC system verification environment, the SOC system convergence is accelerated, enabling rapid connection between the minimum system, SOC code simulation, and netlist simulation. This improves the verification efficiency of each process and allows for timely and rapid identification of problems at different stages, significantly shortening verification time and improving testing efficiency.

[0066] Alternatively, the step of iteratively updating the SOC system based on the test results includes:

[0067] The test results are analyzed using a pre-trained neural network model to obtain corrected data;

[0068] The SOC system is iteratively updated using the corrected data;

[0069] The neural network model is pre-trained based on multiple training samples, each of which includes a test result sample and corresponding correction data.

[0070] In one embodiment, the terminal may be pre-trained with a neural network model based on artificial intelligence technology. This neural network model is obtained through multiple iterations of training based on multiple training samples (e.g., thousands of training samples).

[0071] Optionally, each training sample includes at least one test result sample, which is divided into test pass samples and test failure samples. In the test pass samples, the test value meets the expected value; in the test failure samples, the test value does not meet the expected value.

[0072] Optionally, for test failure samples, corresponding corrective data can also be included. It should be noted that test engineers can pre-analyze the causes of test failures based on various test failure samples, find ways to resolve the failures, and write corresponding corrective code as corrective data for the SOC system.

[0073] Optionally, the ratio of the number of samples that pass the test to the number of samples that fail the test can be 1:1, 1:2, or 1:3 (preferably 1:3).

[0074] In this way, when the neural network model undergoes multiple iterations of training based on a certain number of training samples, it can continuously learn the correlation features of the corrected data corresponding to various test results. Once the model training converges, the neural network model will have the ability to generate corresponding corrected data based on the input test results.

[0075] Optionally, after obtaining the test results of the SOC system at the terminal, the test results can also be input into a pre-trained neural network model to analyze the test results and generate corresponding correction data.

[0076] Optionally, after the terminal obtains the corrected data output by the neural network model, the SOC system can be iteratively updated based on the corrected data.

[0077] In this way, the test problems can be automatically located in the test results of the SOC system, and the corresponding correction data can be automatically generated. This data is then used to iterate and update the SOC system, thereby saving the cost of manually locating test problems and modifying code. In scenarios where multiple iterations of testing of the SOC system are required, the testing efficiency can also be improved (i.e., after each test, the system can be quickly corrected and updated so that it can quickly enter the next test).

[0078] In one embodiment, based on the above embodiments, the testing method for the SOC system further includes:

[0079] Check whether the test values ​​in the test results match the expected values ​​in the second test case;

[0080] If not, proceed with the step of iteratively updating the SOC system based on the test results.

[0081] In this embodiment, after the terminal obtains the test results of the SOC system, it can first check whether each test value in the test results matches the expected value in the corresponding second test case.

[0082] Optionally, if the terminal detects that at least one test value does not match the corresponding expected value, the step of iteratively updating the SOC system based on the test results can be executed. By outputting the test results with non-compliant test values ​​and the corresponding second test cases together, testers can view them to quickly locate problems at different stages, return to the test list, and correct the corresponding system code to iteratively update the SOC system. Alternatively, the test results with non-compliant test values ​​can be input into a pre-trained neural network system to generate corresponding correction data, thereby iteratively updating the SOC system.

[0083] Optionally, if the terminal detects that the test values ​​of all test results match the corresponding expected values, the SOC system test can be considered passed (i.e., the SOC system has reached convergence).

[0084] In one embodiment, based on the above embodiment, after the step of iteratively updating the SOC system according to the test results, the method further includes:

[0085] Based on the updated SOC system, return to the steps of deploying the test scenario on the SOC system and generating the first test case corresponding to the test scenario.

[0086] In this embodiment, after the terminal performs system iterative updates to the SOC system based on the test results, it can return to the step of deploying the test scenario on the SOC system and generating the first test case corresponding to the test scenario (i.e., returning to the execution step S10) based on the updated SOC system until the SOC system reaches convergence. In this way, the SOC system verification environment can be iterated repeatedly, thereby accelerating the convergence of the SOC system, realizing the rapid connection of the process from the minimum system to SOC code simulation, and then to netlist simulation, improving the verification efficiency of each process, thereby improving the overall testing efficiency, and continuously improving the SOC system.

[0087] Reference Figure 2 This application also provides a testing device Z10 for a SOC system, comprising:

[0088] The test scenario management module Z11 is used to deploy test scenarios on the SOC system and generate the first test cases corresponding to the test scenarios. The test scenarios include at least one of verification IP, virtual machine compiler and FPGA platform compiler.

[0089] Test function module Z12 is used to determine test functions according to test requirements and generate second test cases corresponding to the test functions according to the first test cases. The test functions include at least one of connection detection, timing detection, simulation information control, simulation waveform control, coverage control and DUT code control.

[0090] The verification module Z13 is used to execute all the second test cases for the SOC system and obtain the test results.

[0091] Reference Figure 3 This application also provides a computer device whose internal structure can be as follows: Figure 3 As shown, the computer device includes a processor, memory, communication interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system, computer programs, and the database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores test programs for the SOC system. The communication interface is used for data communication with external terminals. The input device receives signals from external devices. When the computer program is executed by the processor, it implements a test method for the SOC system as described in the above embodiment.

[0092] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer equipment on which the present application is applied.

[0093] Furthermore, this application also proposes a computer-readable storage medium comprising a test program for a System-on-a-Chip (SOC) system. When executed by a processor, the test program implements the steps of the SOC system test method as described in the above embodiments. It is understood that the computer-readable storage medium in this embodiment can be either a volatile readable storage medium or a non-volatile readable storage medium.

[0094] In summary, the testing method, testing apparatus, computer equipment, and computer-readable storage medium for the SOC system provided in this application embodiment enable the SOC system to achieve sufficient test scenario coverage. Combined with test function module management, unified testing of functions such as connection detection, timing detection, simulation information control, simulation waveform control, coverage control, and DUT code control can be completed, ultimately realizing a complete SOC testing process. This allows for the rapid extraction of useful key information and the simulation and comparison of different test scenarios to quickly locate problems, thereby improving the efficiency of SOC system testing.

[0095] 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. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media provided in this application and in the embodiments may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual-speed SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0096] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, apparatus, article, or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, apparatus, article, or method. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, apparatus, article, or method that includes that element.

[0097] The above description is only a preferred embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural changes made based on the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A testing method for a System-on-Chips (SOC) system, characterized in that, include: Deploy test scenarios on the SOC system, and generate first test cases based on the test environment, test case templates and test scripts corresponding to the test scenarios. The test scenarios include at least one of verification IP, virtual machine compiler and FPGA platform compiler. Based on the testing requirements, determine the test functions required by the SOC system in each of the test scenarios, and select at least one test function for each test scenario; and based on the attributes and test logic corresponding to the test function, obtain the test objectives, test steps and expected results corresponding to the test cases, improve the first test case, and generate the second test case corresponding to the test function, wherein the test function includes connection detection, timing detection, simulation information control, simulation waveform control and coverage control; For the test function modules corresponding to the test functions determined in each test scenario of the SOC system, execute all the second test cases to obtain the test results; wherein, The test logic of the first test function module corresponding to the connection detection is as follows: using UVM syntax, a specific sequence signal is input at the source end, and a specific sequence is detected at the destination end; then, combined with the test script, the bit width of all the signals to be checked, the source signal path, and the corresponding destination signal path are determined. The test logic of the second test function module corresponding to the timing detection is: using a scripting language to exclude violations caused by asynchronous reasons and retain the real violation information to achieve rapid extraction of useful information; The test logic of the third test function module corresponding to the simulation information control is as follows: output information to key nodes, understand the verification status, and then control the simulation time according to the key nodes. The test logic of the fourth test function module corresponding to the simulation waveform control is: extract waveform information of useful modules according to test needs to reduce simulation resources; The test logic of the fifth test function module corresponding to the coverage control is: extract the coverage information of useful modules according to test needs.

2. The testing method for the SOC system according to claim 1, characterized in that, After the step of executing all the second test cases and obtaining the test results for the test function modules corresponding to the test functions determined for each test scenario in the SOC system, the method further includes: The SOC system is iteratively updated based on the test results.

3. The testing method for the SOC system according to claim 2, characterized in that, The step of iteratively updating the SOC system based on the test results includes: The test results are analyzed using a pre-trained neural network model to obtain corrected data; The SOC system is iteratively updated using the corrected data; The neural network model is pre-trained based on multiple training samples, each of which includes a test result sample and corresponding correction data.

4. The test method for the SOC system according to claim 2 or 3, characterized in that, The testing method for the SOC system also includes: Check whether the test values ​​in the test results match the expected values ​​in the second test case; If not, proceed with the step of iteratively updating the SOC system based on the test results.

5. The test method for the SOC system according to claim 2 or 3, characterized in that, After the step of iteratively updating the SOC system based on the test results, the method further includes: Based on the updated SOC system, return to the steps of deploying the test scenario on the SOC system and generating the first test case according to the test environment, test case template and test script corresponding to the test scenario.

6. A testing device for a SOC system, characterized in that, include: The test scenario management module is used to deploy test scenarios on the SOC system and generate a first test case based on the test environment, test case template and test script corresponding to the test scenario. The test scenario includes at least one of verification IP, virtual machine compiler and FPGA platform compiler. The testing function module is used to determine the required testing functions of the SOC system in each of the test scenarios according to the testing requirements, and to select at least one testing function for each test scenario; and to obtain the test objectives, test steps and expected results corresponding to the test cases according to the attributes and test logic of the test functions, to improve the first test cases, and to generate the second test cases corresponding to the test functions, wherein the test functions include connection detection, timing detection, simulation information control, simulation waveform control and coverage control; The verification module is used to execute all the second test cases for the test function modules corresponding to the test functions determined for each test scenario in the SOC system, and obtain the test results; wherein, The test logic of the first test function module corresponding to the connection detection is as follows: using UVM syntax, a specific sequence signal is input at the source end, and a specific sequence is detected at the destination end; then, combined with the test script, the bit width of all the signals to be checked, the source signal path, and the corresponding destination signal path are determined. The test logic of the second test function module corresponding to the timing detection is: using a scripting language to exclude violations caused by asynchronous reasons and retain the real violation information to achieve rapid extraction of useful information; The test logic of the third test function module corresponding to the simulation information control is as follows: output information to key nodes, understand the verification status, and then control the simulation time according to the key nodes. The test logic of the fourth test function module corresponding to the simulation waveform control is: extract waveform information of useful modules according to test needs to reduce simulation resources; The test logic of the fifth test function module corresponding to the coverage control is: extract the coverage information of useful modules according to test needs.

7. A computer device, characterized in that, The computer device includes a memory, a processor, and a test program for a System-on-a-Chip (SOC) system stored in the memory and executable on the processor. When the SOC system test program is executed by the processor, it implements the steps of the test method for the SOC system as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a test program for the SOC system, which, when executed by a processor, implements the steps of the test method for the SOC system as described in any one of claims 1 to 5.

Images