Chip verification system based on code service layer

Abstract

The present invention relates to the field of chip technology, and in particular to a chip verification system based on a code service layer, comprising: a code service layer, a software test library, a driver module, a conversion interface and a chip design to be tested connected in sequence, wherein the code service layer and the software test library are implemented based on software code, the chip design to be tested is implemented based on hardware code, and the conversion interface is implemented based on software code and hardware code; the software test library includes N software test library files {F1, F2, ..., F n ,...,F N}, where F n is the nth software test library file, and the value range of n is 1 to N; 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, and each module of the code service layer is bound to at least one F n The present invention improves the efficiency of generating software test cases, thereby improving the chip verification efficiency.

Description

Technical Field

[0001] The present invention relates to the field of chip technology, and in particular to a chip verification system based on a code service layer. Background Art

[0002] In the process of chip verification, it is necessary to generate software test cases based on the software test library, and to verify the chip design based on the interaction between the software test cases and the chip design to be tested. There are different library files in the software test library, and different users have different needs for generating different test cases. In addition, the number of library files is large, the library files have poor reusability, lack of scheduling mechanism, and it is difficult to implement parallelization and multi-process operations. Each user needs to select library files according to specific application scenarios, and the efficiency of building software test cases is low, which leads to low chip verification efficiency. Therefore, how to improve the efficiency of generating software test cases and thus improve the efficiency of chip verification has become a technical problem that needs to be solved urgently. Summary of the invention

[0003] The purpose of the present invention is to provide a chip verification system based on a code service layer, which improves the efficiency of generating software test cases and further improves the chip verification efficiency.

[0004] According to a first aspect of the present invention, a chip verification system based on a code service layer is provided, comprising: a code service layer, a software test library, a driver module, a conversion interface and a chip design to be tested, which are connected in sequence, wherein the code service layer and the software test library are implemented based on software code, the chip design to be tested is implemented based on hardware code, and the conversion interface is implemented based on software code and hardware code;

[0005] The software test library 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;

[0006] 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 of the code service layer is bound to at least one F n ;

[0007] Each module of the code service layer is used to call the bound F n Transmitting corresponding functional instructions to the chip under test through the driving module and the conversion interface;

[0008] The conversion interface is used to convert the functional instructions implemented in the software language issued by each module of the code service layer into functional instructions implemented in the hardware language, and send them to the chip design to be tested;

[0009] The global function module is used to generate a preset function on or off instruction;

[0010] The command packet creation and distribution module is used to create 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;

[0011] The queue wake-up module is used to wake up the queue through a doorbell operation according to the queue execution order;

[0012] The multi-process scheduling module is used to set at least one process. 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 in the queue through the corresponding process, and the chip under test generates an execution result;

[0013] The operation result checking module is used to obtain the execution result, and compare the execution result with the target result. If they are consistent, the verification passes; otherwise, the verification fails.

[0014] Compared with the prior art, the present invention has obvious advantages and beneficial effects. By means of the above technical solution, the chip verification system based on the code service layer provided by the present invention can achieve considerable technical advancement and practicality, and has wide industrial utilization value, and has at least the following beneficial effects:

[0015] The present invention constructs a code service layer, sets a common function module, and binds the function module to a software test library file. The user can generate software test cases by calling the function module corresponding to the code service layer through simple parameter control, thereby improving the efficiency of software test case generation and further improving chip verification efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0017] Figure 1 A schematic diagram of a chip verification system based on a code service layer provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0018] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions 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 those skilled in the art without creative work are within the scope of protection of the present invention.

[0019] The embodiment of the present invention provides a chip verification system based on a code service layer, such as Figure 1 As shown, it includes: a code service layer, a software test library, a driver module, a conversion interface and a chip design to be tested that are connected in sequence, and the code service layer and the software test library are implemented based on software code, and the software code can specifically be a code implemented by C language, C++ language, etc. The chip design to be tested is implemented based on hardware code, and the conversion interface is implemented based on software code and hardware code, and the hardware code can specifically be a code implemented by Verilog language, SystemVeriliog language, etc. It should be noted that in the chip verification process, software test cases can usually be directly run in the system-level verification and / or software-level verification stage, and run on a real hardware accelerator or physical chip. If problems are found again in the system-level verification stage and the software verification stage, a large amount of update costs will be consumed, which reduces the chip development efficiency. If some system-level verification and / or software-level verification can be performed in advance based on the chip RTL code, some problems in the RTL code can be solved before the hardware accelerator or physical chip is generated, which can improve the chip development efficiency and reduce the chip development cost. Therefore, the system described in the embodiment of the present invention runs the generated software test cases on the chip design to be tested, so as to implement some system-level verification and / or software-level verification in advance.

[0020] The software test library includes N software test library files {F1, F2, ..., F n ,...,F N}, where F n is the nth software test library file, the value range of n is 1 to N, and N is the total number of software test library files in the software test library. The software test library can be an existing MQL test library or a GQL test library, etc. The software test library files include drawing library files, transport database files, general calculation library files, matrix operation library files, and model analysis library files, etc.

[0021] As an embodiment, 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 of the code service layer is bound to at least one F n It should be noted that each module in the code service layer may be bound to a Fn , it is also possible to bind multiple F n The same F n It may be bound to multiple different modules in the code service layer. After binding, users no longer need to directly connect to a large number of test library files when generating software test cases. They only need to call related functional modules based on simple parameter configuration.

[0022] As an embodiment, each module of the code service layer is used to call the bound F n The corresponding functional instructions are transmitted to the chip design under test through the driver module and the conversion interface. The conversion interface is used to convert the functional instructions implemented in software language issued by each module of the code service layer into functional instructions implemented in hardware language, and send them to the chip design under test. It should be noted that the code service layer and the software test library are implemented based on software code, and the chip design under test is implemented based on hardware code. Therefore, a conversion interface is required to convert the functional instructions implemented in software language issued by each module of the code service layer into functional instructions implemented in hardware language before they can run in the chip design under test.

[0023] As an embodiment, the conversion interface can be implemented through an existing direct programming interface (DPI). 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 the software language and the SystemVerilog language can be realized, which will not be described in detail here.

[0024] As an embodiment, each module in the code service layer is provided with an application program interface for configuring each module; the system includes an option library file generated by a user, and the system extracts parameter options in the code service layer through the option library file, and respectively calls the corresponding application program interface to configure the parameter options to the corresponding module of the code service layer.

[0025] As an embodiment, the global function module is used to generate preset function on or off instructions, and the preset functions include virtualization function, virtual address translation function and multi-card interconnection function. The preset function on or off instructions are set through the global function module and are effective for the same test case without the need to set them separately at each location involving the preset function.

[0026] As an embodiment, the command packet creation and distribution module is used to create a command packet and randomly map the command packet to a single or multiple queues according to user requirements, 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. The command packet creation and distribution module includes M command packet templates {R1, R2, ..., R m ,...,R M}, R m is the mth command package template, and the value range of m is 1 to M; the command package creation and distribution module is used to call the corresponding command package template based on the corresponding parameter options, and update the corresponding parameters in the command package template based on the corresponding parameter options to generate the corresponding command package. It should be noted that a test case can create one or more command packages. If multiple command packages are created, the multiple command packages can be the same command package or different command packages.

[0027] As an embodiment, the queue wake-up module is used to wake up the queue through a doorbell operation 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 virtualization queue wake-up unit, and a queue wake-up unit in multi-GPU mode. The physical function queue wake-up unit, the virtualization queue wake-up unit, and the queue wake-up unit in multi-GPU mode are bound to different F n The physical function queue wake-up unit is used to call the bound F n The wake-up unit physical function queue; the virtualized queue wake-up unit is used to call the bound F n Wake up the virtualization queue; the queue wake-up unit in the multi-GPU mode is used to call the bound F n Wake up the queue in multi-GPU mode.

[0028] As an embodiment, the multi-process scheduling module is used to set at least one process. If there are multiple processes, the multiple processes can be set to be executed in order or in parallel according to user needs, and a mapping relationship between each process and the queue is constructed. When the queue is awakened, the command package corresponding to the chip under test design is executed through the corresponding process execution queue, and the chip under test design generates an execution result.

[0029] As an embodiment, the operation result checking module is used to obtain the execution result, and compare the execution result with the target result. If they are consistent, the verification is passed; otherwise, the verification fails. After the chip under test is designed to generate the execution result, the execution result is stored in the target address, and the target address is sent to the operation result checking module; the operation result checking module is used to obtain the execution result based on the target address, and compare the execution result with the target result. If they are consistent, the verification is passed; otherwise, the verification fails. It should be noted that the embodiment of the present invention, by setting up the operation result checking module, only needs to pass the target address to obtain the execution result, and compare the execution result with the target result, without the need to design a complex monitoring module, thereby reducing the chip verification cost and improving the chip verification efficiency.

[0030] As an embodiment, the code service layer further includes a parallel operation module, and the parallel operation module is used to issue multiple virtual device parallel operation instructions and set multiple virtualized devices to work in parallel.

[0031] In some application scenarios, multiple engines are required to work together. As an embodiment, the code service layer also includes engine collaborative work instructions, which are used to issue collaborative work instructions between multiple engines in sequence according to the engine working order and execution quality type, thereby supporting multiple engines to work together. Specifically, engine 0 may write data first, engine 2 and engine 3 may read data, and so on.

[0032] The abnormality of the chip circuit is also part of the abnormal test. As an embodiment, the code service layer also includes an exception handling module for issuing abnormal test instructions. When the target test abnormality is obtained in the chip design to be tested, it means that it meets the abnormal test expectations and can continue to the next step. The abnormality clearing instruction can be issued to continue running. If the target test abnormality does not occur, it means that the abnormal test has not passed, and a prompt message can be generated.

[0033] In order to make the update of the software test library more reliable, an embodiment of the present invention provides a method for updating the software test library, including:

[0034] 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, the value range of n is 1 to N, and N is the total number of software test library files in the current software test library.

[0035] Step S2: Obtain the software test library file to be updated {A1, A2, ..., A q ,...,A Q}, Aq is the qth software test library file to be updated, the value range of q is 1 to Q, Q is the total number of software test library files to be updated, N≥Q.

[0036] 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.

[0037] 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.

[0038] It should be noted that the software test library file to be updated is written based on the software language and is usually aligned with the software code, that is, the update usually does not affect the software verification interface. If the preset test case verification passes, it means that the current software test library file to be updated will not affect the hardware verification interface or 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, {A1,A2,...,A q ,...,A Q}Update to {F1,F2,...,F n ,...,F N Through steps S1 to S4, the software test library file update process can be standardized, the reliability of the software test library update is improved, and the chip verification efficiency is further improved.

[0039] As an embodiment, in step S4, if there is a preset test case that fails in the preset test case set, step S5 is executed;

[0040] Step S5, determine whether 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, execute step S6, if not aligned with the software code, execute step S7.

[0041] It should be noted that the alignment of 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 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.

[0042] Step S6: Update 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 return to execute step S1.

[0043] It should be noted that the failure of the preset test cases due to misalignment with the hardware code is usually caused by the update of the hardware interface. In this case, the code service layer can be updated so that both the software interface and the hardware interface match the preset test cases, so that the preset test cases can be run and passed.

[0044] Step S7: Update {A1, A2, ..., A based on the preset test cases that failed q ,...,A Q}, return to execute step S1.

[0045] It should be noted that if {A1,A2,...,A q ,...,A Q} is usually an unreasonable update, so it is necessary to re-acquire {A1,A2,...,A q ,...,A Q}.

[0046] As an embodiment, step S3 includes:

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

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

[0049] 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, and compares the execution results with the target results. If they are consistent, the verification passes, otherwise, the verification fails.

[0050] As an embodiment, step S33 includes:

[0051] Step S331: Generate a preset function on or off instruction based on the global function module.

[0052] The preset functions include virtualization function, virtual address translation function and multi-card interconnection function. The preset function on or off instructions are set through the global function module, which is effective for the same test case without the need to set them separately at each location involving the preset function.

[0053] Step S332, create a distribution module based on the command package. The distribution module is used to create command packages, and randomly map the command packages to a single or multiple queues according to user needs, or map each command package to the corresponding queue one by one according to a preset mapping relationship, and distribute the command package to the corresponding queue after the queue corresponding to the command package is awakened.

[0054] As an embodiment, 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 range of m is 1 to M, and M is the total number of command package templates. In step S332, a distribution module is created based on the command package. A distribution module is used to create a command package, including:

[0055] 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.

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

[0057] Step S333: The queue-based wake-up module wakes up the queue through a doorbell operation according to the queue execution order.

[0058] The queue wake-up module is used to wake up the queue through the doorbell operation 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 virtualization queue wake-up unit and a queue wake-up unit in multi-GPU mode. The physical function queue wake-up unit, the virtualization queue wake-up unit and the queue wake-up unit in multi-GPU mode are bound to different F n The physical function queue wake-up unit is used to call the bound F n The wake-up unit physical function queue; the virtualized queue wake-up unit is used to call the bound F n Wake up the virtualization queue; the queue wake-up unit in the multi-GPU mode is used to call the bound Fn Wake up the queue in multi-GPU mode.

[0059] Step S334, set at least one process based on the multi-process scheduling module. If there are multiple processes, set the multiple processes to be executed in order or in parallel according to user needs, and build a mapping relationship between each process and the queue. When the queue is awakened, the corresponding command packet corresponding to the chip under test design is executed in the queue through the corresponding process, and the chip under test design generates an execution result.

[0060] 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.

[0061] The embodiment of the present invention constructs a code service layer, sets a general functional module, and binds the functional module to a software test library file. The user can generate software test cases by calling the functional module corresponding to the code service layer through simple parameter control, thereby improving the efficiency of generating software test cases and further improving the chip verification efficiency.

[0062] The above description is only a preferred embodiment of the present invention and does not limit the present invention in any form. Although the present invention has been disclosed as a preferred embodiment as above, it is not used to limit the present invention. Any technician familiar with this profession can make some changes or modifications to equivalent embodiments of equivalent changes using the technical contents disclosed above without departing from the scope of the technical solution of the present invention. However, any simple modification, equivalent change and modification made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention still falls within the scope of the technical solution of the present invention.

Claims

1. A chip verification system based on the code service layer, It is characterized in that include: A code service layer, a software test library, a driver module, a conversion interface and a chip design to be tested connected in sequence, wherein the code service layer and the software test library are implemented based on software code, the chip design to be tested is implemented based on hardware code, and the conversion interface is implemented based on software code and hardware code; The software test library 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; 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 of the code service layer is bound to at least one F n ; Each module of the code service layer is used to call the bound F n Transmitting corresponding functional instructions to the chip under test through the driving module and the conversion interface; The conversion interface is used to convert the functional instructions implemented in the software language issued by each module of the code service layer into functional instructions implemented in the hardware language, and send them to the chip design to be tested; The global function module is used to generate a preset function on or off instruction; The command packet creation and distribution module is used to create 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; The queue wake-up module is used to wake up the queue through a doorbell operation according to the queue execution order; The multi-process scheduling module is used to set at least one process. 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 in the queue through the corresponding process, and the chip under test generates an execution result; The operation result checking module is used to obtain the execution result, and compare the execution result with the target result. If they are consistent, the verification passes; otherwise, the verification fails.

2. The system according to claim 1, characterized in that The preset functions include a virtualization function, a virtual address translation function and a multi-card interconnection function.

3. The system 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.

4. The system according to claim 1, characterized in that Each module in the code service layer is provided with an application program interface for configuring each module; The system includes an option library file generated by a user. The system extracts parameter options in the code service layer through the option library file, and calls corresponding application program interfaces to configure the parameter options into corresponding modules of the code service layer.

5. The system according to claim 1, characterized in that The command package creation and distribution module includes M command package templates {R1, R2, ..., R m ,...,R M }, R m The mth command packet template, where the value of m ranges from 1 to M; The command package creation and distribution module is used to call the corresponding command package template based on the corresponding parameter options, and update the corresponding parameters in the command package template based on the corresponding parameter options to generate the corresponding command package.

6. The system according to claim 1, characterized in that The code service layer also includes a parallel operation module, and the parallel operation module is used to issue parallel operation instructions for multiple virtual devices.

7. The system according to claim 1, characterized in that The code service layer also includes engine collaborative work instructions, which are used to issue collaborative work instructions between multiple engines in sequence according to the engine working order and execution quality type.

8. The system according to claim 1, characterized in that The code service layer also includes an exception handling module for issuing an exception test instruction, and issuing an exception clearing instruction when a target test exception occurs in the chip design to be tested.

9. The system according to claim 1, characterized in that After the chip under test is designed to generate an execution result, the execution result is stored in a target address, and the target address is sent to the operation result checking module; The operation result checking module is used to obtain the execution result based on the target address, and compare the execution result with the target result. If they are consistent, the verification passes; otherwise, the verification fails.

10. The system according to claim 1, characterized in that The queue wake-up module includes a physical function queue wake-up unit, a virtualization queue wake-up unit, and a queue wake-up unit in multi-GPU mode. The physical function queue wake-up unit, the virtualization queue wake-up unit, and the queue wake-up unit in multi-GPU mode are bound to different F n ; The physical function queue wake-up unit is used to call the bound F n Wake up the unit physical function queue; The virtualized queue wake-up unit is used to call the bound F n Wake up the virtualization queue; The queue wake-up unit in multi-GPU mode is used to call the bound F n Wake up the queue in multi-GPU mode.

Images