Testing Methods for Chip Simulation Models

Abstract

The present invention provides a chip simulation model testing method, which is applied to an automatic testing framework and includes: receiving command line parameters transmitted by a control script; parsing the command line parameters into a command line for executing the chip simulation model; starting the chip simulation model so that the chip simulation model executes a target test case according to the command line; monitoring the execution status of the chip simulation model until a flag indicating the end of the chip simulation model execution is obtained; obtaining an output result of the chip simulation model and comparing it with a target result of the target test case to obtain a test result of the test case. The chip simulation model testing method provided by the present invention can automatically execute the test of the chip design solution, thereby improving testing efficiency.

Description

Technical Field

[0001] The present invention relates to the technical field of chip design, and in particular to a testing method for a chip simulation model. Background Art

[0002] Chips have become crucial components of various electronic devices, and the operation of most electronic devices relies on the implementation of their internal chips. Chip implementation involves two stages: chip design and chip manufacturing. The primary step in chip manufacturing is tapeout based on the chip design results. However, once a chip is taped out, its internal logic cannot be altered. If problems arise during the chip design phase, the chip must be re-taped, resulting in significant losses. The high cost of chip tapeout places higher demands on chip design to ensure its correctness. Therefore, during the chip design process, chip simulation models are typically constructed to verify the correctness of the chip's logical functions. However, existing methods for automatically verifying chip logic functions are currently unavailable. Summary of the Invention

[0003] The chip simulation model testing method provided by the present invention can realize the testing of chip design solutions in an automatic execution manner, thereby improving the testing efficiency.

[0004] In a first aspect, the present invention provides a chip simulation model testing method, which is applied to an automatic testing framework, comprising:

[0005] Receive command line parameters sent by the control script;

[0006] Parsing the command line parameters into a command line for executing a chip simulation model;

[0007] Starting a chip simulation model so that the chip simulation model executes a target test case according to the command line;

[0008] Monitoring the execution status of the chip simulation model until obtaining a flag indicating that the execution of the chip simulation model is completed;

[0009] The output result of the chip simulation model is obtained and compared with the target result of the target test case to obtain the test result of the test case.

[0010] Optionally, monitoring the execution status of the chip simulation model until obtaining a flag indicating that the execution of the chip simulation model is completed includes:

[0011] According to the predetermined time, the target memory address is read cyclically until a flag indicating the end of the subprocess execution is obtained from the target memory address.

[0012] Optionally, parsing the command line parameters into a command line for executing the chip simulation model includes:

[0013] According to the command line parameters, the executable file and input data corresponding to the command line parameters are determined, and the executable file and the input data are combined to form a command line.

[0014] Optionally, obtaining the output result of the chip simulation model and comparing it with the target result of the target test case includes:

[0015] The assertions of the automatic testing framework are used to compare the output results of the chip simulation model with the target results byte by byte.

[0016] Optionally, before starting the chip simulation model, the following steps are also included:

[0017] Determine whether the target test case is a multi-core program;

[0018] When the target test case is a multi-core program, the number of cores required by the current program is determined and sent to the chip simulation model, so that the chip simulation model creates threads in a one-to-one correspondence with the cores required by the multi-core program.

[0019] Optionally, it also includes: specifying an independent memory for the stack of each thread during execution.

[0020] Optionally, the method further includes: designating one of the multiple threads as a main thread, so that the execution results of the multiple threads are synchronized to the main thread, and the main thread transfers the results to the target storage address.

[0021] Optionally, monitoring the execution status of the chip simulation model until a flag indicating that the chip simulation model execution is completed further includes:

[0022] End the execution of the chip simulation model and reclaim resources.

[0023] Optionally, starting a chip simulation model so that the chip simulation model executes a target test case according to the command line includes:

[0024] Execute the fork function to create a child process to start the chip simulation model;

[0025] The execl function is used to replace the context of the subprocess so that the chip simulation model executes the target test case according to the command line.

[0026] In a second aspect, the present invention provides a chip simulation model testing method, which is applied to a control script, comprising:

[0027] Traversing each test case and the multiple input data corresponding to each test case, and forming command line parameters to pass to the automatic test framework; so that the automatic test framework executes any one of the above-mentioned chip simulation model test methods;

[0028] Obtaining test results of the automatic testing framework for each set of input data for each test case;

[0029] Store and count the test results output by the automatic testing framework.

[0030] Optionally, obtaining the test result of the automatic testing framework for each set of input parameters of each test case includes:

[0031] Monitor the test results of the automatic testing framework;

[0032] When the automatic testing framework outputs the test results within a predetermined time, the test results output by the automatic testing framework are saved;

[0033] When the automatic testing framework does not output a test result within a predetermined time, it is determined that the current test case has failed.

[0034] Optionally, traversing each test case and multiple input data corresponding to each test case and forming command line parameters to pass to the automatic testing framework includes:

[0035] Each time a test case is traversed, the input data corresponding to the current test case is traversed;

[0036] Whenever an input data corresponding to the current test case is traversed, the command line options corresponding to the current test case and the command line options corresponding to the current input data are combined to form command line parameters, and transmitted to the automatic testing framework.

[0037] Optionally, before traversing each test case and the multiple input data corresponding to each test case, the following steps are further included:

[0038] Get the directory of test cases and input data for the test cases;

[0039] Create a new directory for output files and log files.

[0040] Optionally, after traversing each test case and the multiple input data corresponding to each test case, the following steps are further included:

[0041] Determine whether the input data meets the data requirements of the test case.

[0042] In the technical solution provided by the present invention, command line parameters are passed to an automatic test framework through script control. The automatic test framework then parses the command line parameters to form a command line executable by the chip simulation model. After the chip simulation model executes the command line, the automatic test framework compares the execution result with the expected target result to determine whether the chip simulation model has been executed correctly. In the technical solution provided by the present invention, by controlling the automatic test framework through the control script, automatic testing of the chip simulation model can be achieved, thereby improving testing efficiency and accuracy. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 This is a flow chart of a method for testing a chip simulation model according to an embodiment of the present invention;

[0044] Figure 2 A schematic diagram illustrating a compilation principle of a chip simulation model testing method according to another embodiment of the present invention;

[0045] Figure 3 This is a flowchart of executing multi-core test cases in a chip simulation model testing method according to another embodiment of the present invention. DETAILED DESCRIPTION

[0046] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.

[0047] The embodiment of the present invention provides a chip simulation model testing method, which is applied to an automatic testing framework, such as Figure 1 Shown, including:

[0048] Receive command line parameters sent by the control script;

[0049] In some embodiments, the control script is used to control the logic of the entire test process. In order to achieve the purpose of batch testing, the control script needs to traverse all test case cases, as well as the different inputs in each test case case. Different inputs and related command line parameters are used to start different cases. If the command line is typed for each case, it will not only be time-consuming and laborious, but the error rate will be greatly increased. Based on the above reasons, in this step, the control script does the following work: traverse each test case, and each time a test case is traversed, the corresponding input data is traversed under the test case, and the command line options corresponding to the test case are combined with the command line options corresponding to the input data into command line parameters. In order to realize the traversal of test cases and input data, the control script needs to perform the following steps: 1) Initialization: obtain the path of the case, create a new output file directory, log path, etc., and determine whether the parameters are legal; 2) Outer loop, traverse one by one according to the name of the case; 3) Inner loop, according to the different inputs in the case, such as different feature maps, different weights, different offsets, etc.

[0050] Parsing the command line parameters into a command line for executing a chip simulation model;

[0051] In some embodiments, the command line parameters point to the executable file of the test case and the file where the input parameters are located. The automatic testing framework obtains the command line in the executable file and the specific parameters in the input parameters based on the command line parameters, combines the command line and the specific parameters to form a command line executable by the chip simulation model.

[0052] Starting a chip simulation model so that the chip simulation model executes a target test case according to the command line;

[0053] In some embodiments, since the test goal is to determine whether the chip simulation model is fully functional, in this step, the automatic test framework starts a subprocess, which is the running process of the chip simulation model, and then uses the chip simulation model to execute the corresponding command line. Based on the execution result of the chip simulation model, it can be determined whether the chip simulation model is fully functional. For example, the automatic test framework can use the Gtest test framework, and the chip simulation model can be implemented using Qemu; the Gtest test framework uses the fork function to start a subprocess, that is, to start the chip simulation model, and then uses the execl function to implement context replacement, so that the chip simulation model executes the target test case according to the command line.

[0054] Monitoring the execution status of the chip simulation model until obtaining a flag indicating that the execution of the chip simulation model is completed;

[0055] In some embodiments, the automated testing framework monitors the execution status of the subprocess, that is, the running status of the chip simulation model. When the chip simulation model completes executing the target test case, it sends an end flag. The automated testing framework can monitor whether the end flag is written. When the end flag is written, it determines that the subprocess has completed executing the target test case.

[0056] The output result of the chip simulation model is obtained and compared with the target result of the target test case to obtain the test result of the test case.

[0057] In some embodiments, when the automatic test framework receives the command line parameters of the control script, it can obtain the target result of executing the current test case based on the current input data in the process of obtaining data according to the command line parameters. When the output result of the chip simulation model is obtained, the target result is compared with the output result to determine whether the execution of the current test case is successful or failed. For the automatic test framework, the test results are output to the control script, and the control script saves and prints the comparison results of the individual test cases. After multiple test cases are executed, the control script will also output a total test report.

[0058] In the technical solution provided by this embodiment, command line parameters are passed to the automatic test framework through script control. The automatic test framework then parses the command line parameters to form a command line executable by the chip simulation model. After the chip simulation model executes the command line, the automatic test framework compares the execution result with the expected target result to determine whether the chip simulation model has been executed correctly. In the technical solution provided by this embodiment, the control of the automatic test framework by the control script can realize automatic testing of the chip simulation model, thereby improving testing efficiency and accuracy.

[0059] Before executing the above-mentioned implementation method, preparation work is required to prepare the test program and test data. Figure 2As shown, the preparation work mainly includes the test code writing of the host / server side and the data and executable files required for the RISC-V processor simulated by QEMU. The host / server side code mainly uses the principle of the GTEST test framework. Each test case will be registered as a TEST. Using the assertions that come with the test framework, the results of the simulator run are compared byte by byte with the prepared reference results to give the test results. The QEMU side needs to prepare the input data. Since it is a simulation for an AI chip, the input given by the present invention is the feature map of the data, weights, and offsets. At the same time, it is also necessary to write the case that needs to be tested. If the addition instruction needs to be tested, a test case for the addition instruction needs to be added. Each instruction or model can have multiple inputs, and each case and input will be executed by the test framework. After the above program and data are ready, the program is compiled into an executable file and placed in the compiled folder together with the input data for standby use. Among them, the test registered in GTEST is used to call the executable file of each case.

[0060] As an optional implementation manner, monitoring the execution status of the chip simulation model until obtaining a flag indicating that the execution of the chip simulation model is completed includes:

[0061] According to the predetermined time, the target memory address is read cyclically until a flag indicating the end of the subprocess execution is obtained from the target memory address.

[0062] In this embodiment, a fixed time interval is set, and every predetermined time, the target address memory is read in sequence. When there is no end mark in the target address memory, the time interval timing of the next cycle continues. When there is an end mark, the execution result of the chip simulation model executing the target test case is obtained.

[0063] As an optional implementation, parsing the command line parameters into a command line for executing the chip simulation model includes:

[0064] According to the command line parameters, the executable file and input data corresponding to the command line parameters are determined, and the executable file and the input data are combined to form a command line.

[0065] In some embodiments, the command line parameters specify the executable file and input data of the target test case. During execution, the automated testing framework extracts the executable command line and specific input data of the chip simulation model from the executable file based on the command line parameters. The executable command line and the specific input data are combined to form a command line. After the combined command line is transmitted to the chip simulation model, the chip simulation model can directly execute it.

[0066] As an optional implementation manner, obtaining the output result of the chip simulation model and comparing it with the target result of the target test case includes:

[0067] The assertions of the automatic testing framework are used to compare the output results of the chip simulation model with the target results byte by byte.

[0068] In some embodiments, automated testing frameworks typically have a rich set of assertions that can return different prompts for different test cases. For example, in the Gtest testing framework, assertions with multiple functions can be used to implement multiple testing purposes. In this embodiment, assertions in the automated testing framework can be used to determine the execution results of the chip simulation model.

[0069] In some embodiments, as Figure 3 As shown, before starting the chip simulation model, it also includes:

[0070] Determine whether the target test case is a multi-core program;

[0071] In some embodiments, a test case may require multiple cores to work together. The resources and data output methods required for multiple cores working together are generally different from those required for a single core. Therefore, in this embodiment, the target test case is also determined before executing the test case.

[0072] When the target test case is a multi-core program, the number of cores required by the current program is determined and sent to the chip simulation model, so that the chip simulation model creates threads in a one-to-one correspondence with the cores required by the multi-core program.

[0073] In some embodiments, in order to be able to start multiple cores, a parameter of the number of cores to be started is added to Linux, that is, the host program. The host program is responsible for parsing and passing the parameter in the command line for starting the QEMU program. QEMU will create a thread for each processor core and start it according to the parameter.

[0074] As an optional implementation, it further includes: specifying an independent memory for the stack of each thread during execution.

[0075] In some embodiments, to ensure the correct operation of multi-core programs, the runtime stack must be stored in a separate memory. Stacks are typically used to store information such as local variables and function call addresses during program execution. Since multi-core programs execute in parallel, storing the stack in the same location can lead to confusion among the stack's contents, thus impacting the program's normal operation. This embodiment addresses this issue by assigning the stack's location to different physical storage addresses during runtime. Furthermore, if the processor supports multi-core applications using symbols stored in data segments, such as global variables, this data segment also presents issues when running multi-core programs in parallel. If data segments are stored in the same location, there is a risk of data conflicts, such as read-after-write and write-after-write operations on data at the same address, impacting the correct operation of the program. There are two solutions to this problem: one is to compile separate ELF files for each core and assign the data segment storage addresses to different physical memories during compilation. The other is to run the same ELF file on multiple cores and assign the same virtual address segment to the program's data segment during compilation. However, this address segment actually corresponds to a unique address segment for each core, i.e., a different physical address segment. Solution 2 also relies on the implementation of on-chip memory for each core in QEMU. It also requires modifying the code for loading ELF files in QEMU, because QEMU currently does not support parsing data segments and automatically copying them to the on-chip memory of each core at this stage.

[0076] As an optional implementation, the method further includes: designating one of the multiple threads as a main thread, so that the execution results of the multiple threads are synchronized to the main thread, and the main thread transfers the results to the target storage address.

[0077] In some embodiments, in order to efficiently complete the automatic comparison of multi-core programs, this embodiment also designs a suitable solution for the multi-core testing framework. In combination with the application scenario of the multi-core processor targeted by this embodiment, it can be found that the final result data of the multi-core program is usually stored in the public DDR storage, so the multi-core testing work only needs to compare the final DDR results. The present invention specifies a master core in the multi-core mode and utilizes the multi-core synchronization mechanism. After confirming that all core programs have completed running, the master core triggers the dump function and finally compares the results.

[0078] As an optional implementation manner, monitoring the execution status of the chip simulation model until a flag indicating that the chip simulation model execution is completed is obtained further includes:

[0079] End the execution of the chip simulation model and reclaim resources.

[0080] In some embodiments, after reading the flag indicating the end of the chip simulation model execution, it indicates that the current test case has been executed and completed. In order to save resources, the execution of the chip simulation model is ended. For example, the execution of the chip simulation model can be stopped by killing the subprocess, and the resources occupied during the execution of the chip simulation model can be recovered.

[0081] As an optional implementation manner, starting the chip simulation model so that the chip simulation model executes the target test case according to the command line includes:

[0082] Execute the fork function to create a child process to start the chip simulation model;

[0083] In some embodiments, the fork function can be used to divide the currently executed process into two processes, that is, the fork function can be used to create a child process.

[0084] The execl function is used to replace the context of the subprocess so that the chip simulation model executes the target test case according to the command line.

[0085] In some embodiments, the child process created using the fork function will inherit the execution variables and environment parameters of the parent process. In order to enable the chip simulation model to execute the target test case, the execl function is used to replace the context of the child process and change the variables and environment parameters of the child process.

[0086] The embodiment of the present invention also provides a chip simulation model testing method, which is applied to the control script, such as Figure 1 Shown, including:

[0087] Traversing each test case and the multiple input data corresponding to each test case, and forming command line parameters to pass to the automatic test framework; so that the automatic test framework executes any one of the above-mentioned chip simulation model test methods;

[0088] In some embodiments, in order to achieve the purpose of batch testing, it is necessary to traverse all test cases and the different inputs in each test case. Different inputs and related command line parameters are used to start different cases. If the command line is typed for each case, it will not only be time-consuming and laborious, but the error rate will also be greatly increased. In the script, the following tasks are performed: first, case traversal; second, command line combination. The control script is mainly used to implement logical control during the automatic testing process. The control script traverses the test cases and the input data of each test case, and combines the command line options corresponding to the test cases with the command line options corresponding to the input data. After combination, the command line parameters are formed and passed to the automatic testing framework. Specifically, the traversal process of the control script is as follows: 1) Outer loop, traversing one by one according to the name of the case; 2) Inner loop, according to the different inputs in the case, such as different feature maps, different weights, different offsets, etc. After the automatic testing framework receives the command line parameters, it will execute the test case according to the test method of the aforementioned chip simulation model.

[0089] Obtaining test results of the automatic testing framework for each set of input data for each test case;

[0090] In some embodiments, in order to realize the automation of testing, the test results need to be collected and processed in an automatic manner. In this step, the control script obtains the test results of each set of input data of each test case without manual processing.

[0091] Store and count the test results output by the automatic testing framework.

[0092] In some embodiments, the previous step is to obtain the test results of a single test case, and in this step, all test results are stored and counted, and a concise and clear test report can be given.

[0093] In the technical solution provided by this embodiment, command line parameters are passed to the automatic test framework through script control. The automatic test framework then parses the command line parameters to form a command line executable by the chip simulation model. After the chip simulation model executes the command line, the automatic test framework compares the execution result with the expected target result to determine whether the chip simulation model has been executed correctly. In the technical solution provided by this embodiment, the control of the automatic test framework by the control script can realize automatic testing of the chip simulation model, thereby improving testing efficiency and accuracy.

[0094] As an optional implementation manner, obtaining the test result of the automatic testing framework for each set of input parameters of each test case includes:

[0095] Monitor the test results of the automatic testing framework;

[0096] When the automatic testing framework outputs the test results within a predetermined time, the test results output by the automatic testing framework are saved;

[0097] When the automatic testing framework does not output a test result within a predetermined time, it is determined that the current test case has failed.

[0098] In this embodiment, the test results output by the automatic testing framework are monitored. However, for some test cases with errors, it is often difficult to execute them for a long time. In order to improve the test efficiency, a time limit is also set in this embodiment. When the test results are not output after the predetermined time, the test case is determined to have failed.

[0099] As an optional implementation, traversing each test case and the multiple input data corresponding to each test case and forming command line parameters to pass to the automatic testing framework includes:

[0100] Each time a test case is traversed, the input data corresponding to the current test case is traversed;

[0101] Whenever an input data corresponding to the current test case is traversed, the command line options corresponding to the current test case and the command line options corresponding to the current input data are combined to form command line parameters, and transmitted to the automatic testing framework.

[0102] In this embodiment, the combination of test cases and input data is realized through two layers of loops. The outer loop traverses the test cases, and the inner loop traverses the input data of the test cases. It is possible to test a test case with different test data in a centralized manner, which makes it easier to discover problems with the test cases.

[0103] As an optional implementation, before traversing each test case and the multiple input data corresponding to each test case, the following steps are further included:

[0104] Get the directory of test cases and input data for the test cases;

[0105] Create a new directory for output files and log files.

[0106] This embodiment is usually executed during the initialization of the script, and is a key setting for determining the source of test cases, the source of input data, the location of output files, and the location of log files.

[0107] As an optional implementation, after traversing each test case and the multiple input data corresponding to each test case, the following steps are further included:

[0108] Determine whether the input data meets the data requirements of the test case.

[0109] In some embodiments, the validity of input data is a key factor in ensuring the accuracy of test results of test cases. In this embodiment, the validity of data is judged before the test begins, which can ensure the accuracy of the test results.

[0110] For the purpose of flexibility in the testing process, each control script in the aforementioned embodiments should also support customized command lines, such as the running time of the case, the amount of data dumped at the end for comparison, etc.

[0111] In each embodiment provided by the present invention, a control script is used to control the transmission of command line parameters to the automatic test framework, and then the automatic test framework parses the command line parameters to form a command line that can be executed by the chip simulation model, which can realize the automatic testing of the chip simulation model. In summary, as soon as the command line is started, the test program begins. First, the host / server side will start a process related to GTEST, which can be called a parent process. The parent process will first obtain the command line parameters given by the control script, and then create a child process. After the child process is created, the parent process starts a loop waiting mode, and in the process of waiting, it keeps querying the flag of whether the child process has ended. The child process is the case that needs to be tested. The context of the process is replaced by the excel function, and the program of the child process is executed. When the child process is executed, the commands called in the case will be executed one by one to obtain the calculated result. When all the instructions are executed, an end flag will be written to the file. After the parent process reads the entire flag, it will recycle the child process, and a case is executed at this point.

[0112] Those skilled in the art will appreciate that all or part of the processes in the above method embodiments can be implemented by instructing related hardware through a computer program. The program can be stored in a computer-readable storage medium, and when executed, the program can include the processes in the above method embodiments. The storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0113] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in the present invention should be included in the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. A chip simulation model testing method, characterized in that: Applicable to automated testing frameworks, including: Receive command line parameters sent by the control script; Parsing the command line parameters into a command line for executing a chip simulation model; Starting a chip simulation model so that the chip simulation model executes a target test case according to the command line; Monitoring the execution status of the chip simulation model until obtaining a flag indicating that the execution of the chip simulation model is completed; Obtaining the output result of the chip simulation model and comparing it with the target result of the target test case to obtain the test result of the test case; The step of parsing the command line parameters into a command line for executing the chip simulation model includes: obtaining a command line in an executable file and specific parameters in an input parameter according to the command line parameters, and combining the command line and the specific parameters to form a command line executable by the chip simulation model; The starting of the chip simulation model includes: starting a sub-process, and using the sub-process to run the chip simulation model.

2. The method according to claim 1, characterized in that Monitoring the execution status of the chip simulation model until obtaining a flag indicating that the execution of the chip simulation model is completed includes: According to the predetermined time, the target memory address is read cyclically until a flag indicating the end of the subprocess execution is obtained from the target memory address.

3. The method according to claim 1, characterized in that Parsing the command line parameters into a command line for executing the chip simulation model includes: According to the command line parameters, the executable file and input data corresponding to the command line parameters are determined, and the executable file and the input data are combined to form a command line.

4. The method according to claim 1, wherein Obtaining the output result of the chip simulation model and comparing it with the target result of the target test case includes: The assertions of the automatic testing framework are used to compare the output results of the chip simulation model with the target results byte by byte.

5. The method according to claim 1, wherein Before starting the chip simulation model, it also includes: Determine whether the target test case is a multi-core program; When the target test case is a multi-core program, the number of cores required by the current program is determined and sent to the chip simulation model, so that the chip simulation model creates threads in a one-to-one correspondence with the cores required by the multi-core program.

6. The method according to claim 5, characterized in that Also includes: Assign independent memory to each thread's runtime stack.

7. The method according to claim 5, characterized in that Also includes: One of the multiple threads is designated as a main thread, so that the execution results of the multiple threads are synchronized to the main thread and transferred to the target storage address by the main thread.

8. The method according to claim 1, characterized in that Monitoring the execution status of the chip simulation model until a flag indicating that the chip simulation model has finished executing is obtained further includes: End the execution of the chip simulation model and reclaim resources.

9. The method according to claim 1, characterized in that Starting the chip simulation model so that the chip simulation model executes the target test case according to the command line includes: Execute the fork function to create a child process to start the chip simulation model; The execl function is used to replace the context of the subprocess so that the chip simulation model executes the target test case according to the command line.

10. A chip simulation model testing method, characterized in that: Applicable to control scripts, including: Traversing each test case and the multiple input data corresponding to each test case, and forming command line parameters to be passed to the automatic testing framework; so that the automatic testing framework executes the method of claims 1-9; Obtaining test results of the automatic testing framework for each set of input data for each test case; Store and count the test results output by the automatic testing framework.

11. The method according to claim 10, characterized in that Obtaining the test results of the automatic testing framework for each set of input parameters of each test case includes: Monitor the test results of the automatic testing framework; When the automatic testing framework outputs the test results within a predetermined time, the test results output by the automatic testing framework are saved; When the automatic testing framework does not output a test result within a predetermined time, it is determined that the current test case has failed.

12. The method according to claim 10, characterized in that Traversing each test case and the multiple input data corresponding to each test case, and forming command line parameters to pass to the automatic testing framework includes: Each time a test case is traversed, the input data corresponding to the current test case is traversed; Whenever an input data corresponding to the current test case is traversed, the command line options corresponding to the current test case and the command line options corresponding to the current input data are combined to form command line parameters, and transmitted to the automatic testing framework.

13. The method according to claim 10, characterized in that Before traversing each test case and the multiple input data corresponding to each test case, it also includes: Get the directory of test cases and input data for the test cases; Create a new directory for output files and log files.

14. The method according to claim 10, characterized in that After traversing each test case and the multiple input data corresponding to each test case, it also includes: Determine whether the input data meets the data requirements of the test case.

Images