Update method for software test library, electronic device and medium

Abstract

The present invention relates to the field of chip technology, and in particular to a method for updating a software test library, an electronic device, and a medium. The method includes: Step S1, obtaining a current software test library, where the current software test library includes N software test library files; Step S2, obtaining a software test library file to be updated; Step S3, running a preset test case in a preset test case set based on the current software test library and the software test library file to be updated: when there is a corresponding A n for the required F q , call the corresponding A q , otherwise call the corresponding F n ; Step S4, if all the preset test cases in the preset test case set pass the test, then update {A1, A2,..., A q ,..., A Q} to {F1, F2,..., F n ,..., F N}. The present invention improves the reliability of software test library update, and thus improves the chip test efficiency.

Description

Technical Field

[0001] The present invention relates to the field of chip technology, and in particular to a method for updating a software test library, an electronic device, and a medium. Background Art

[0002] In the process of chip verification, it is necessary to generate software test cases based on a software test library (Test library), interact with the chip design under test based on the software test cases, and verify the chip design under test. There are different library files in the software test library, and different users have different requirements for generating different test cases. The library files in the software test library are updated relatively frequently. The update of the library files will cause the interfaces to change frequently, and some updates will cause some test cases to fail to run. The reliability of the software test library update is poor, which reduces the chip test efficiency. It can be seen from this that how to improve the reliability of the software test library update and thus improve the chip test efficiency has become a technical problem to be solved urgently. Summary of the Invention

[0003] The purpose of the present invention is to provide a method for updating a software test library, which improves the reliability of the software test library update and thus improves the chip test efficiency.

[0004] According to a first aspect of the present invention, there is provided a method for updating a software test library, including:

[0005] Step S1, obtaining a current software test library, the current software test library including N software test library files {F 1 , F 2 ,..., F n ,..., F N}, where F n is the nth software test library file, and the value range of n is from 1 to N;

[0006] Step S2, obtaining the software test library files to be updated {A 1 , A 2 ,..., A q ,..., A Q}, where A q is the qth software test library file to be updated, the value range of q is from 1 to Q, and N≥Q;

[0007] Step S3, running a preset test case in a preset test case set based on the current software test library and the software test library files to be updated: when there is a corresponding A n for the F q to be called, call the corresponding A q , otherwise call the corresponding F n, the preset test case is a test case in the software test library whose update to the software test library will affect the hardware;

[0008] Step S4. If all the preset test cases in the preset test case set pass the test, then update {A 1 , A 2 ,..., A q ,..., A Q} to {F 1 , F 2 ,..., F n ,..., F N .

[0009] According to the second aspect of the present invention, there is provided an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein, the memory stores instructions executable by the at least one processor, and the instructions are configured to execute the method according to the first aspect of the present invention.

[0010] According to the third aspect of the present invention, there is provided a computer-readable storage medium storing computer-executable instructions, and the computer instructions are used to execute the method according to the first aspect of the present invention.

[0011] Compared with the prior art, the present invention has obvious advantages and beneficial effects. By means of the above technical solutions, a method for updating a software test library, an electronic device and a medium provided by the present invention can achieve considerable technical progressiveness and practicability, and have wide utilization value in the industry, and it has at least the following beneficial effects:

[0012] The present invention provides a set of standardized software test library file update processes. Before updating the software test library, first run test cases that will affect the hardware based on the current software test library and the software test library files to be updated in the updated software test library. If all the tests pass, then update the software test library files to be updated to the current software test library, improving the reliability of software test library updates and thus improving the chip test efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the following drawings are only some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0014] Figure 1 It is a flowchart of the method for updating a software test library provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0015] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0016] An embodiment of the present invention provides a method for updating a software test library, as Figure 1 shown, including:

[0017] Step S1, obtain the current software test library, where the current software test library includes N software test library files {F 1 , F 2 ,..., F n ,..., F N}, where F n is the nth software test library file, and the value range of n is from 1 to N, and N is the total number of software test library files in the current software test library.

[0018] Specifically, the software test library may be an existing MQL test library or a GQL test library, etc. The software test library files include a drawing library file, a handling database file, a general computing library file, a matrix operation library file, a model analysis library file, etc.

[0019] Step S2, obtain the software test library files to be updated {A 1 , A 2 ,..., A q ,..., A Q}, where A q is the qth software test library file to be updated, and the value range of q is from 1 to Q, and Q is the total number of software test library files to be updated, and N≥Q.

[0020] Step S3, run the preset test cases in the preset test case set based on the current software test library and the software test library files to be updated: when there is a corresponding A n for the required F q , call the corresponding A q , otherwise call the corresponding F n , and the preset test cases are the test cases for testing that the updated software test library of the software test library will affect the hardware.

[0021] Step S4, if all the preset test cases in the preset test case set pass the test, then {A 1 , A 2 ,..., A q ,..., A Q} Update to {F 1 , F 2 ,..., F n ,..., F N}.

[0022] It should be noted that the software test library file to be updated is written based on the software language and usually aligns with the software code. That is, the update generally does not affect the software verification interface. If the preset test cases pass the verification, it means that the current software test library file to be updated will neither affect the hardware verification interface nor the software verification interface. If all the preset test cases in the preset test case set pass the test, it means that the update of the software test library file to be updated will not affect the verification. Therefore, {A 1 , A 2 ,..., A q ,..., A Q} can be updated to {F 1 , F 2 ,..., F n ,..., F N}. By steps S1 - S4, the update process of the software test library file can be standardized, the reliability of the software test library update is improved, and thus the chip test efficiency is enhanced.

[0023] As an embodiment, in step S4, if there are preset test cases that fail in the preset test case set, then step S5 is executed;

[0024] Step S5: Determine whether both the software code and the hardware code are aligned with the software test library file to be updated. If not aligned with the hardware code, then step S6 is executed. If not aligned with the software code, then step S7 is executed.

[0025] It should be noted that the alignment of the software code with the software test library file to be updated means that the software test library file to be updated is generated without affecting the software verification interface. The alignment of the hardware code with the software test library file to be updated means that the software test library file to be updated is generated without affecting the hardware verification interface.

[0026] Step S6: Update the code service layer based on the preset test cases that fail. The code service layer is used to call the software test library to generate software test cases, and then return to execute step S1.

[0027] It should be noted that the failure of the preset test cases caused by the non - alignment with the hardware code is usually due to the update of the hardware interface. In this case, by updating the code service layer, both the software interface and the hardware interface can be made to match the preset test cases, so that the preset test cases can run through.

[0028] Step S7. Update {A 1 , A 2 ,..., A q ,..., A Q} based on the preset test cases that fail, and return to execute Step S1.

[0029] It should be noted that if {A 1 , A 2 ,..., A q ,..., A Q} is not aligned with the software code, the update is usually unreasonable. Therefore, it is necessary to re-obtain {A 1 , A 2 ,..., A q ,..., A Q}.

[0030] As an embodiment, the code service layer is implemented based on software code, and the software code can specifically be code implemented in C language, C++ language, etc. The code service layer includes a global function module, a command packet creation and distribution module, a queue wake-up module, a multi-process scheduling module, and a running result check module. Each module of the code service layer is bound to at least one F n . It should be noted that each module of the code service layer may be bound to one F n , or may be bound to multiple Fs n . The same F n may be bound to multiple different modules in the code service layer. After binding, when the user generates software test cases, there is no need to directly interface with a large number of test library files. Instead, the user only needs to call the relevant function modules based on simple parameter configurations. Each module in the code service layer is provided with an application programming interface for configuring each module. Step S3 includes:

[0031] Step S31. Generate an option parameter file based on each preset test case.

[0032] Step S32. Extract the parameter options corresponding to each module of the code service layer from the option parameter file, and respectively call the corresponding application programming interfaces to configure the parameter options into the corresponding modules of the code service layer.

[0033] Step S33. Each module of the code service layer is used to call the bound F n to generate corresponding function instructions, convert the function instructions corresponding to each module into function instructions implemented in hardware language, and send them to the chip design under test. The chip design under test executes the received function instructions implemented in hardware language to generate an execution result, and compares the execution result with the target result. If they are consistent, the verification passes; otherwise, the verification fails.

[0034] It should be noted that during the chip verification process, software test cases can usually be directly run in the system-level verification and / or software-level verification phase, running on real existing hardware accelerators or physical chips. If problems are found again in the system-level verification phase and software verification phase, it will consume a large amount of update costs and reduce the chip development efficiency. If some system-level verification and / or software-level verification can be carried out in advance based on the chip RTL code, and some problems existing in the RTL code are solved before the generation of the hardware accelerator or physical chip, the chip development efficiency can be improved and the chip development cost can be reduced. Therefore, the software test cases generated in the embodiments of the present invention are run on the chip design to be tested to achieve some system-level verification and / or software-level verification in advance. The chip design to be tested is implemented based on hardware code, and the hardware code can specifically be code implemented in Verilog language, SystemVeriliog language, etc.

[0035] Specifically, a conversion interface can be used to convert the function instructions corresponding to each module into function instructions implemented in hardware language. As an embodiment, the conversion interface can specifically be implemented through an existing Direct Programming Interface (DPI for short). DPI is a standard interface that allows SystemVerilog code to directly call C or C++ functions, and vice versa. DPI allows data and control information to be transferred between the two languages. Therefore, based on DPI, the conversion between software language and SystemVerilog language can be realized, which will not be elaborated here.

[0036] As an embodiment, step S33 includes:

[0037] Step S331: Based on the global function module, generate preset function enable or disable instructions.

[0038] The preset functions include virtualization function, virtual address translation function, and multi-card interconnection function. By setting the preset function enable or disable instructions through the global function module, it takes effect on the same test case, and there is no need to set them separately at each position involving the preset functions.

[0039] Step S332: Based on the command packet creation and distribution module, the command packet creation and distribution module is used to create command packets, and according to user requirements, randomly map the command packets to a single or multiple queues, or map each command packet to the corresponding queue one by one according to a preset mapping relationship, and distribute the command packets to the corresponding queues after the queue corresponding to the command packet is awakened.

[0040] As an embodiment, the command packet creation and distribution module includes M command packet templates {R 1 , R 2,...,R m ,...,R M},R m is the m-th command packet template, where the value range of m is from 1 to M, and M is the total number of command packet templates. In step S332, the distribution module for creating command packets based on command packets is used to create command packets, including:

[0041] Step S3321: The distribution module for creating command packets calls the corresponding command packet template based on the corresponding parameter options, and updates the corresponding parameters in the command packet template based on the corresponding parameter options to generate the corresponding command packet.

[0042] It should be noted that one test case can create one or more command packets. If multiple command packets are created, the multiple command packets can be the same command packet or different command packets.

[0043] Step S333: The queue wake-up module wakes up the queue through doorbell operations according to the queue execution order.

[0044] The queue wake-up module is used to wake up the queue through doorbell operations according to the queue execution order. It should be noted that the queue wake-up module can wake up the queue by type. The queue wake-up module includes a physical function queue wake-up unit, a virtualized queue wake-up unit, and a queue wake-up unit in the multi-GPU mode. The physical function queue wake-up unit, the virtualized queue wake-up unit, and the queue wake-up unit in the multi-GPU mode are bound to different F n . The physical function queue wake-up unit is used to call the bound F n to wake up the physical function queue of the wake-up unit; the virtualized queue wake-up unit is used to call the bound F n to wake up the virtualized queue; the queue wake-up unit in the multi-GPU mode is used to call the bound F n to wake up the queue in the multi-GPU mode.

[0045] Step S334: The multi-process scheduling module sets at least one process. If there are multiple processes, the multiple processes are set to execute orderly or in parallel according to user requirements, and a mapping relationship between each process and the queue is constructed. When the queue is woken up, the corresponding process is used to execute the command packet corresponding to the queue in the to-be-tested chip design, and the to-be-tested chip design generates an execution result.

[0046] Step S335: The running result checking module obtains the execution result, compares the execution result with the target result. If they are consistent, the verification passes; otherwise, the verification fails.

[0047] As an embodiment, the operation result checking module is used to obtain the execution result, compare the execution result with the target result. If they are the same, the verification passes; otherwise, the verification fails. After the chip under test generates the execution result, it stores the execution result in the target address and sends the target address to the operation result checking module. The operation result checking module is used to obtain the execution result based on the target address, compare the execution result with the target result. If they are the same, the verification passes; otherwise, the verification fails. It should be noted that in the embodiment of the present invention, by setting up the operation result checking module, only the target address needs to be transmitted to obtain the execution result, compare the execution result with the target result, without designing a complex monitoring module, reducing the chip verification cost and improving the chip verification efficiency.

[0048] As an embodiment, the code service layer may further include a parallel operation module. During the execution of step S3, the parallel operation module is used to issue multiple virtual device parallel operation instructions to set multiple virtualized devices to work in parallel.

[0049] In some application scenarios, multiple engines need to work together. As an embodiment, the code service layer further includes engine cooperation work instructions, which are used to sequentially issue cooperation work instructions between multiple engines according to the engine work order and execution quality type during the execution of step S3, so as to support the cooperation of multiple engines. Specifically, engine 0 can write data first, and engines 2 and 3 can read data, etc.

[0050] The abnormal situation of the chip circuit is also part of the abnormal test. As an embodiment, the code service layer further includes an abnormal handling module, which is used to issue abnormal test instructions during the execution of step S3. When it is obtained that the chip design under test has a target test abnormality, it means that it meets the abnormal test expectation and the next step can be continued. An abnormal clearing instruction can be issued to continue running. If there is no target test abnormality, it means that the abnormal test fails, and a prompt message can be generated.

[0051] It should be noted that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe the steps as sequential processes, many of the steps can be implemented in parallel, concurrently, or simultaneously. In addition, the order of the steps can be rearranged. The process can be terminated when its operation is completed, but it can also have additional steps not included in the drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0052] An embodiment of the present invention further provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein, the memory stores instructions executable by the at least one processor, and the instructions are configured to execute the method of the embodiment of the present invention.

[0053] An embodiment of the present invention further provides a computer-readable storage medium storing computer-executable instructions for executing the method of the embodiment of the present invention.

[0054] An embodiment of the present invention provides a set of standardized software test library file update processes. Before updating the software test library, test cases that may affect the hardware are first run based on the current software test library and the software test library files to be updated in the updated software test library. If all tests pass, the software test library files to be updated are updated to the current software test library, improving the reliability of software test library updates and thus improving the chip test efficiency.

[0055] The above are only preferred embodiments of the present invention and do not impose any formal limitations on the present invention. Although the present invention has been disclosed above with preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some changes or modifications to the above-disclosed technical content to form equivalent embodiments with equivalent changes within the scope of the technical solution of the present invention. However, as long as the content does not depart from the technical solution of the present invention, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention still fall within the scope of the technical solution of the present invention.

Claims

1. A method for updating a software test library, characterized in that: include: Step S1: Obtain the current software test library, which includes N software test library files {F1, F2, ..., F n ,...,F N }, where F n is the nth software test library file, where the value of n ranges from 1 to N; Step S2: Obtain the software test library file to be updated {A1, A2, ..., A q ,...,A Q }, A q is the qth software test library file to be updated, the value range of q is 1 to Q, N ≥ Q; Step S3: Run the preset test cases in the preset test case set based on the current software test library and the software test library file to be updated: n There is a corresponding A q When calling the corresponding A q Otherwise, call the corresponding F n , the preset test cases are test cases in which the update of the software test library will have an impact on the hardware; The code service layer includes a global function module, a command package creation and distribution module, a queue wake-up module, a multi-process scheduling module, and an operation result inspection module. Each module in the code service layer is bound to at least one F n Each module in the code service layer is provided with an application program interface for configuring each module, and the step S3 includes: Step S31, generating an option parameter file based on each preset test case; Step S32, extracting parameter options corresponding to each module of the code service layer from the option parameter file, and calling corresponding application program interfaces to configure the parameter options to the corresponding modules of the code service layer; Step S33: Each module of the code service layer is used to call the bound F n Generate corresponding functional instructions, convert the functional instructions corresponding to each module into functional instructions that should be implemented in hardware language and send them to the chip design under test, the chip design under test executes the received functional instructions implemented in hardware language to generate execution results, compare the execution results with the target results, if they are consistent, the verification is passed, otherwise, the verification fails; Step S4: If all the preset test cases in the preset test case set pass the test, {A1, A2, ..., A q ,...,A Q }Update to {F1,F2,...,F n ,...,F N }middle.

2. The method according to claim 1, characterized in that In step S4, if there is a preset test case that fails in the preset test case set, step S5 is executed; Step S5, determining whether the software code and the hardware code are aligned with the software test library file to be updated, if so, executing step S6, otherwise, executing step S7; Step S6: updating the code service layer based on the preset test cases that have not passed, wherein the code service layer is used to call the software test library to generate software test cases, and returning to execute step S1; Step S7: Update {A1, A2, ..., A based on the preset test cases that failed q ,...,A Q }, return to execute step S1.

3. The method according to claim 1, characterized in that The step S33 comprises: Step S331: Generate a preset function on or off instruction based on the global function module; Step S332: Create a distribution module based on the command packet. Create a distribution module for creating a command packet, and randomly map the command packet to a single or multiple queues, or map each command packet to a corresponding queue one by one according to a preset mapping relationship, and distribute the command packet to the corresponding queue after the queue corresponding to the command packet is awakened; Step S333: Based on the queue wake-up module, the queue is woken up through the doorbell operation according to the queue execution order; Step S334: at least one process is set based on the multi-process scheduling module. If there are multiple processes, the multiple processes are set to be executed in order or in parallel, and a mapping relationship between each process and a queue is constructed. When the queue is awakened, the command packet corresponding to the chip under test is executed through the corresponding process in the queue, and the chip under test generates an execution result; Step S335: Obtain the execution result based on the operation result check module, and compare the execution result with the target result. If they are consistent, the verification passes; otherwise, the verification fails.

4. The method according to claim 3, characterized in that The command package creation and distribution module includes M command package templates {R1, R2, ..., R m ,...,R M }, R m is the mth command package template, where the value of m ranges from 1 to M. In step S332, creating a distribution module based on the command package and building a distribution module for creating a command package include: Step S3321: The command package creation and distribution module calls the corresponding command package template based on the corresponding parameter options, and updates the corresponding parameters in the command package template based on the corresponding parameter options to generate the corresponding command package.

5. The method according to claim 1, characterized in that The software testing library files include drawing library files, transport database files, general calculation library files, matrix operation library files and model analysis library files.

6. An electronic device, characterized in that: include: at least one processor; and, a memory communicatively coupled to the at least one processor; The memory stores instructions executable by the at least one processor, wherein the instructions are configured to execute the method according to any one of claims 1 to 5.

7. A computer-readable storage medium, characterized in that: Computer executable instructions are stored, and the computer executable instructions are used to execute the method according to any one of the preceding claims 1-5.

Images