Chip testing method and related device

Abstract

The embodiment of the invention provides a chip test method and a related device, and the chip test method is applied to a host and comprises the steps: obtaining an excitation instruction sent by a test case; converting an excitation instruction sent by the test case into a test instruction code in a preset format; the preset format is a data format which can be identified by a hardware acceleration simulator; sending the test instruction code to a hardware acceleration simulator through an instruction queue cache mechanism; the instruction queue caching mechanism comprises the steps of storing the test instruction code in a preset file, and sending the test instruction code to a hardware acceleration simulator when a preset transmission condition is met. According to the invention, the test instruction code can be transmitted in a centralized manner with a large amount of data at a time and can be transmitted for multiple times, so that the data transmission frequency between the host and the hardware acceleration simulator is reduced, the chip test speed is increased, and the verification efficiency is improved.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computer technologies, and particularly to a chip testing method and related devices. Background Art

[0002] In chip production and manufacturing, the accuracy and efficiency of chip verification are very important for chip production and manufacturing. In the existing chip simulation verification methods, the simulation speed of the chip is slow, which in turn leads to poor chip verification efficiency. Therefore, how to improve the chip testing speed and the chip verification efficiency has become an urgent problem to be solved by those skilled in the art. Summary of the Invention

[0003] In view of this, the embodiments of the present application provide a chip testing method and related devices to improve the chip verification efficiency.

[0004] To achieve the above object, the embodiments of the present invention provide the following technical solutions:

[0005] In a first aspect, the embodiments of the present application provide a chip testing method applied to a host, including:

[0006] Obtaining an instruction for the excitation sent by a test case; the test case is used to simulate an actual application scenario for the chip and verify the chip

[0007] Converting the instruction for the excitation sent by the test case into a test instruction code in a preset format; the preset format is a data format recognizable by a hardware acceleration emulator;

[0008] Sending the test instruction code to the hardware acceleration emulator through an instruction queue caching mechanism; the instruction queue caching mechanism includes storing the test instruction code in a preset file and sending the test instruction code to the hardware acceleration emulator when a preset transmission condition is reached.

[0009] In a second aspect, the embodiments of the present application provide a chip testing method applied to a hardware acceleration emulator, including:

[0010] Obtaining an instruction packet in a preset format, where the instruction packet includes a test instruction code for an instruction for excitation, and storing the test instruction code in a preset space;

[0011] Parsing and executing the test instruction code according to the preset format;

[0012] Driving a test object to perform a state jump to implement access to a chip data register and an instruction register;

[0013] Obtaining test data of the test object and returning it to the host.

[0014] In a third aspect, an embodiment of the present application provides a chip testing device, which is applied to a host and includes:

[0015] A test case, which is used to simulate an actual application scenario for the chip and verify the chip;

[0016] An instruction encoding module, which is used to obtain the stimulating instructions sent by the test case and convert the stimulating instructions sent by the test case into test instruction encodings in a preset format; the preset format is a data format recognizable by a hardware acceleration emulator;

[0017] A first instruction queue caching module, which is used to send the test instruction encodings to the hardware acceleration emulator through an instruction queue caching mechanism; the instruction queue caching mechanism includes storing the test instruction encodings in a preset file and sending the test instruction encodings to the hardware acceleration emulator when a preset transmission condition is met.

[0018] In a fourth aspect, an embodiment of the present application provides a chip testing device, which is applied to a hardware acceleration emulator and includes:

[0019] A second instruction queue caching module, which is used to obtain an instruction packet in a preset format. The instruction packet includes test instruction encodings of stimulating instructions and stores the test instruction encodings in a preset space.

[0020] An instruction decoding module, which is used to parse and execute the test instruction encodings according to the preset format.

[0021] A test object, which is used as a carrier for accessing the chip data register and instruction register and returns the test data of the test object.

[0022] In a fifth aspect, an embodiment of the present application further provides a computing device, which includes a processor and a memory. The memory stores computer instructions, and the processor executes the computer instructions to implement the chip testing method for software testing as described above, or the chip testing method for a hardware acceleration emulator as described above.

[0023] In a sixth aspect, an embodiment of the present application further provides a computer program product, which includes computer instructions. When the computer instructions are executed, they implement the chip testing method for software testing as described above, or the chip testing method for a hardware acceleration emulator as described above.

[0024] In a seventh aspect, an embodiment of the present application further provides a storage medium. The storage medium stores a design program for a chip. When the design program is executed, it implements the chip testing method for software testing as described above, or the chip testing method for a hardware acceleration emulator as described above.

[0025] In an eighth aspect, an embodiment of the present application further provides a computer system, including a host and a hardware acceleration emulator. The host runs the host chip testing method as described above, and the hardware acceleration emulator runs the hardware acceleration emulator chip testing method as described above.

[0026] The chip testing method provided by the embodiment of the present application, which is applied to a host, includes: obtaining an instruction of an incentive issued by a test case; the test case is used to simulate an actual application scenario for the chip and verify the chip. Converting the instruction of the incentive issued by the test case into a test instruction code in a preset format; the preset format is a data format recognizable by the hardware acceleration emulator; sending the test instruction code to the hardware acceleration emulator through an instruction queue caching mechanism; the instruction queue caching mechanism is: storing the test instruction code in a preset file, and sending the test instruction code to the hardware acceleration emulator when a preset transmission condition is reached.

[0027] It can be seen that by converting the instruction of the incentive issued by the test case into a test instruction code in a preset format, and the preset format is a data format recognizable by the hardware acceleration emulator, all the instructions of the incentive can run in the hardware acceleration emulator. Thus, when the instruction of the incentive runs, it can be executed only in the hardware acceleration emulator, without being alternately executed between the host and the hardware acceleration emulator, thereby reducing the number of interactions of data between the host and the hardware acceleration emulator. At the same time, through the instruction queue caching mechanism, the test instruction code can be transmitted in a large amount at one time, avoiding transmitting the test instruction code multiple times, thereby reducing the number of data transmissions between the host and the hardware acceleration emulator, and further improving the chip testing speed and verification efficiency. Description of the Drawings

[0028] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only the embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained according to the provided drawings without creative efforts.

[0029] Figure 1 It is a schematic structural diagram of a chip testing device;

[0030] Figure 2 It is a schematic flowchart of the chip testing method provided by the embodiment of the present application;

[0031] Figure 3 It is another schematic diagram of the chip testing method provided by the embodiment of the present application;

[0032] Figure 4Schematic flowchart of instructions for a chip testing method;

[0033] Figure 5 Schematic flowchart of instructions for the chip testing method provided by the embodiments of the present application;

[0034] Figure 6 Schematic structural diagram of the chip testing device provided by the embodiments of the present application;

[0035] Figure 7 Schematic flowchart of the jump process of the test access port state machine provided by the embodiments of the present application;

[0036] Figure 8 Bar chart comparing the number of hardware interactions between the existing solution and the solution provided by the embodiments of the present application. Detailed implementation manners

[0037] Next, the technical solutions in the embodiments of the present application will be clearly and completely described with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments of the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0038] The accuracy and efficiency of chip verification are very important for chip production and manufacturing. A chip verification technology is realized through simulation verification based on electronic design automation tools, that is, a software simulation tool (Simulator) is used for verification. However, this method requires a large amount of computing resources, including CPU, memory, disk space, etc. Especially when dealing with large-scale data or complex algorithms, the resource consumption will be more significant, resulting in a sharp drop in the simulation speed and unable to meet the requirements of rapid iterative development of chips.

[0039] Another chip verification technology is realized through chip simulation verification based on a field programmable gate array (FPGA, Field-Programmable Gate Array). Although using FPGA verification has the advantages of high speed and flexibility, when facing the verification tasks of very large scale integrated circuits, such as the verification tasks of multi-core SOC (system-on-chip), the problem of hardware resource limitation of FPGA is obvious, and it is difficult to meet the verification requirements of high-complexity very large scale chips.

[0040] In addition, chip simulation and verification can also be carried out based on a hardware-accelerated emulator (EMU). Using a functional hardware-accelerated emulator for chip verification can achieve the same functions of discovering, locating, and fixing problems as electronic design automation tools, and also has a high simulation speed. Since the hardware-accelerated emulator is large in scale, it can achieve simulation verification of complex multi-core systems. In addition, the hardware-accelerated emulator platform also supports various simulation tools such as ICE (In-Circuit Emulator) and Virtual (virtual debugging / simulation), which can meet various simulation verification requirements.

[0041] The simulation verification based on the hardware-accelerated emulator usually also needs to cooperate with the JTAG (Joint Test Action Group) access technology. The JTAG access technology is an efficient debugging means. By connecting the target chip using a standard JTAG interface and relying on the scan chain mechanism, it allows developers to read and write the registers and memory inside the chip through a JTAG debugger, realizing remote monitoring and operation of the internal state of the chip. The entire process does not require direct physical contact with the internal components of the chip. The JTAG access technology can complete the debugging and testing tasks of the chip without damaging the chip package and internal structure. The hardware-accelerated emulator platform using the JTAG can achieve remote access and control of the target circuit through a predefined API interface, greatly simplifying the debugging process and improving the development efficiency.

[0042] A chip simulation verification scheme is as Figure 1 shown. This scheme is divided into two parts: the software side (Host side) and the hardware side (Emulator side). Among them, the software side is the Figure 1 host 10 in Figure 1 . A test case 1 and an API function 2 are set in the host. Through the host, the chip simulation verification scheme can be run. The hardware side is the hardware-accelerated emulator 20 in Figure 1 , and the method on the hardware side is run through the hardware-accelerated emulator 20. Test cases 1 (Testcase) are formed based on SystemC, C, or SystemV languages. The main function of these codes is to generate excitation signals for the DUT (Device Under Test) and send the excitation signals by calling the API function 2 at the transaction level. At the same time, the API function 2 receives the response data returned by the DUT, converts the response data into a data format that the test case 1 can process, and then the API function 2 sends the converted response data to the test case 1 for the test case 1 to process the response data.

[0043] The host 10 includes API functions or a verification IP library based on transaction-level modeling. These functions can communicate at the transaction level with the JTAG Transactor (hardware-side transaction processor) in the hardware acceleration emulator 20. The JTAG Transactor is a module based on JTAG for the software-hardware interaction of the transaction-level model. When transaction-level messages are transmitted from the host 10 to the JTAG Transactor, these messages are parsed and converted into a series of multi-cycle signals, which in turn drive the DUT connected to the hardware acceleration emulator 20 to perform corresponding operations. At the same time, the JTAG Transactor captures the feedback generated by the DUT and transmits it back to the test case in the host through transaction-level communication again, thus completing a closed-loop test process.

[0044] The API functions 2 of the host 10 communicate with the JTAG Transactor in the hardware acceleration emulator 20 mainly through the SCE-MIDPI (Standard Co-Emulation Modeling Interface, the direct programming interface of the standard co-emulation modeling interface). These API functions 2 usually contain JTAG low-level commands, such as IR_SCAN (Instruction Register Scan), DR_SCAN (Data Register Scan), GET_RESPONSE_SCAN (acquire response scan), etc.

[0045] Each time the test case 1 calls these API functions 2, it triggers a communication interaction between the host 10 and the hardware acceleration emulator 20 through the SCE-MIDPI. If the test case 1 frequently executes these API functions 2, it will cause a significant increase in the number of interactions between the host 10 and the hardware acceleration emulator 20, thus consuming a large amount of time and making the JTAG debugging process slow.

[0046] In addition, the cost of using the Virtual JTAG model is relatively high, and the parameters and functions of the API functions 2 cannot be modified and customized, which is not conducive to secondary development. Furthermore, the same test case 1 cannot be cross-platform and applicable to all EMU systems, resulting in problems such as poor test case compatibility, difficult maintenance, and high usage costs.

[0047] To solve the above problems, an embodiment of the present application provides a chip testing method. The host sends data to the hardware acceleration emulator by using an instruction queue caching mechanism, reducing the number of interactions between the host and the hardware acceleration emulator. As an optional implementation, Figure 2The flowchart of the chip testing method provided by the embodiment of the present application is shown. As Figure 2 shown, the chip testing method provided by the embodiment of the present application includes the following steps.

[0048] The host executes step S11: Obtain the instruction of the stimulus sent by the test case. The test case is used to simulate the actual application scenario for the chip and verify the chip. It should be noted that the foregoing test case is configured in the test case, and the test case is a systematic tool for organizing, executing, managing, and reporting test cases.

[0049] The host executes step S12: Convert the instruction of the stimulus sent by the test case into a test instruction code in a preset format.

[0050] Since the API function has poor scalability and high modification cost. Moreover, the instruction code of the JTAGTestcase generated by the API function is relatively complex, and directly using it in chip verification will make the data processing flow complex and reduce the verification efficiency. Therefore, it is necessary to convert the instruction code of the JTAG Testcase into a custom and unified preset format of test instruction code to simplify the complexity of data and data transmission, while ensuring the integrity and accuracy of data.

[0051] In an optional implementation, the test instruction code in the preset format includes a test instruction code based on the TCL (Tool Command Language) language. That is, replace the test instruction code developed based on System C, C, or System Verilog language with an instruction code based on the TCL language. Since JTAG Testcase is implemented using the TCL language, using the TCL language to implement the test instruction code can directly call the test instruction code during the verification process; at the same time, the hardware acceleration emulator has good adaptability to the TCL language, and using the TCL language can improve the model compatibility, which greatly promotes the efficient communication between the instruction code and the hardware acceleration emulator.

[0052] In this way, by converting the instruction of the stimulus into a test instruction code in a preset format, not only the function of the instruction of the stimulus is completely retained, but also the instruction function is easy to expand. Furthermore, the test instruction code can be encapsulated into a unified instruction package, so as to simplify the data processing flow, improve the data reliability, enhance the scalability of the test instruction code, and reduce the implementation cost.

[0053] In addition, to facilitate the use of the test instruction code, after converting the instruction of the stimulus sent by the test case into a test instruction code in a preset format, it is also necessary to package the test instruction code in the preset format into an instruction package in a preset format.

[0054] The host executes step S13: The host sends the test instruction encoding to the hardware acceleration emulator through an instruction queue caching mechanism. The instruction queue caching mechanism is: storing the test instruction encoding in a preset file, and sending the test instruction encoding to the hardware acceleration emulator when a preset transmission condition is met.

[0055] It should be noted that when using the API function to generate and send the excitation signal, the interaction times between the API function and the Emulator are excessive, which limits the speed of the Emulator accessing the JTAG Testcase in the Host. Therefore, a new interaction method between the host and the hardware acceleration emulator is needed to reduce the interaction times between the host and the hardware acceleration emulator to improve the access speed.

[0056] Furthermore, the inventors of this application considered introducing an instruction queue caching mechanism to replace multiple small-data-volume transmissions with a single large-data-volume centralized transmission to reduce the interaction times between the host and the hardware acceleration emulator. The instruction queue caching mechanism caches the test instruction encoding to be executed in a preset file, and when the preset transmission condition is met, the test instruction encoding cached in the preset file is batch-transmitted to the hardware acceleration emulator at one time, thereby improving the data transmission efficiency and the overall system performance.

[0057] It should be noted that the instruction queue caching mechanism needs to be implemented in cooperation with the host and the hardware acceleration emulator. In the host, the preset file is a HEX (Hexadecimal) file. In the instruction queue caching mechanism, the test instruction encoding processed into a preset format is packaged into an instruction packet and stored in a HEX file. The HEX file integrates multiple instruction packets, and each instruction packet includes a test instruction encoding, thereby realizing the batch preprocessing and encapsulation of data. Subsequently, through the hardware acceleration emulator command, the HEX file containing multiple instruction packets is directly sent to the hardware acceleration emulator, significantly reducing the interaction times between the host and the hardware acceleration emulator. The HEX file is a text format file that stores the hexadecimal representation format of binary data in text form. That is, the original binary file (such as machine code) is represented and encapsulated in a readable pure text form (such as hexadecimal characters) for easy viewing, editing, or transmission. Using the HEX file as the storage medium for instruction packets can facilitate cross-platform and cross-language data transmission.

[0058] Furthermore, as Figure 3 shown, in an alternative implementation, the preset file is a cache file, and step S13 includes the following steps.

[0059] The host executes step S131: The host creates a blank cache file.

[0060] It should be noted that the cache file is the HEX file described above. In order to avoid the existing data in the cache file affecting the operation of the test instruction encoding, it is necessary to ensure that the cache data is blank, that is, there is no data, after the test instruction encoding runs.

[0061] Specifically, when creating a blank cache file, it is necessary to check whether there is an existing cache file on the host. If there is an existing cache file, it can be directly used in the instruction queue cache mechanism. At this time, it is necessary to clear the existing cache file to ensure that the cache file is in a blank state. If there is no cache file in the host, it indicates that the cache file has not been defined in the current host. Therefore, a new cache file needs to be created for the current and subsequent tasks. It should be noted that the newly created cache files are all blank cache files.

[0062] The host executes step S132: The host stores the instruction packets in the cache file in the order of the call time of the test instruction encoding and performs real-time counting; and, based on the instruction type and data length of the test instruction encoding, calculates the total time required to execute the test instruction encoding.

[0063] To ensure the integrity and orderliness of the instruction packets, during the operation of the instruction queue cache mechanism, the instruction packets need to be sorted and stored in the order of the call time of the instructions to keep the original execution order of the instructions from being disrupted.

[0064] In addition, in the instruction queue cache mechanism, it is necessary to check whether the number of instruction packets in the cache file has reached the maximum data depth limit set by the storage space of the hardware acceleration emulator, for example, no more than 1024 instruction packets, to avoid the loss of instruction packets due to the full storage of the cache file. If this limit is not reached, the instruction queue cache mechanism will store the instruction packets in the cache file in the order of the call time of the instructions according to the call time of the excitation instructions. At the same time, to ensure the coherence of data processing, it is also necessary to perform real-time counting on the number of stored instruction packets, and based on the instruction type and data length, accumulate the total time consumed by each instruction task during the execution of the hardware acceleration emulator, and calculate the total time required for the hardware acceleration emulator to execute these instructions.

[0065] The host executes step S133: The host detects the preset transmission condition of the cache file. Then, when the preset transmission condition appears subsequently, the cache file is sent to the hardware acceleration emulator.

[0066] It should be noted that the preset transmission condition is used to indicate the timing for the instruction queue caching mechanism to send instruction packets to the hardware acceleration emulator. After the preset transmission condition is met, the host will initiate the transmission process of the cache file and send the cache file. Sending instruction packets according to the preset transmission condition can maximize the transmission efficiency while ensuring the timeliness of data transmission.

[0067] Further, in an alternative implementation, the preset transmission condition includes: when the accumulated number of instruction packets reaches the maximum data depth limit (for example, 1024). At this time, the number of instruction packets that can be stored in the cache file reaches the upper limit. If new instruction packets continue to be stored, the new instruction packets cannot be stored in the cache file. Therefore, it is necessary to send the instruction packets in the cache file to the hardware acceleration emulator and then obtain new instruction packets.

[0068] In other alternative implementations, the preset transmission condition includes: detecting a return parameter. When the test case requires the return value of the DUT, or when the currently executed test needs to rely on the return value of the DUT to run, the instruction packets in the cache file need to be executed to obtain the return value of the DUT. When the above situation occurs, a return parameter can be added to the parameters of the test instruction encoding to instruct the instruction queue caching mechanism to send the cache file, so that the instruction packets are executed and the return value of the DUT is obtained.

[0069] In other alternative implementations, the preset transmission condition includes: detecting an active trigger instruction. The active trigger instruction is a predefined instruction. When the test case has special requirements or is manually controlled, the sending of the cache file can be controlled through the active trigger instruction.

[0070] S134: When the host reaches the preset transmission condition, it sends the instruction packets in the cache file, the number of sent instruction packets, and the specified running time of the instruction packets to the hardware acceleration emulator.

[0071] When one of the above three conditions is met, the instruction queue caching mechanism will respond to the preset transmission condition and pause caching the instruction packets to the cache file. Immediately afterwards, using the TCL instructions supported by the hardware acceleration emulator, the instruction packets stored in the host cache file are sent to the hardware acceleration emulator. In addition, it is also necessary to additionally transmit the current number of instruction packets and the key information of the time for controlling the hardware acceleration emulator to run the instruction packets (i.e., the specified running time of the instruction packets).

[0072] S135: After the instruction packets are sent, the host clears the cache file.

[0073] After the data transmission is completed, cache cleaning and resetting are required. The cache file is immediately emptied to free up space for the next data caching task. This step ensures the continuous and efficient operation of the cache mechanism, avoiding data aliasing and ineffective occupation of storage space.

[0074] In this way, by converting the incentive instructions issued by the test cases into test instruction encodings in a preset format, and the preset format is a data format recognizable by the hardware acceleration emulator, all the incentive instructions can run on the hardware acceleration emulator. Thus, when the test instruction encoding runs, it can be executed only within the hardware acceleration emulator and does not need to be alternately executed between the host and the hardware acceleration emulator, thereby reducing the number of data interactions between the host and the hardware acceleration emulator. At the same time, through the instruction queue cache mechanism, the test instruction encoding can be transmitted in a large amount at one time, avoiding multiple transmissions of the test instruction encoding, thereby reducing the number of data transmissions between the host and the hardware acceleration emulator, and further improving the chip test speed and verification efficiency. Further, in an optional implementation, the instruction types of the incentive instructions include any one of common instructions, long data instructions, custom instructions, or hardware acceleration instructions. Among them, the common instructions, such as IR_SCAN (Instruction Register Scan), DR_SCAN (Data Register Scan), JTAG_RESET (JTAG Reset) instructions, these JTAG low-level commands are commonly used instructions in the JTAG debugging process. The long data instruction is an instruction whose instruction data length exceeds the bit width of a single instruction packet. When sending the long data instruction, it needs to be divided into two or more instruction packets and sent sequentially. The custom instruction is an instruction that allows users to customize the task name and task function according to their needs. The hardware acceleration instruction is an instruction that originally runs on the host but is moved to the hardware acceleration emulator to run in the embodiment of the present application; for example, for some test instruction encodings, they originally only execute on the host and do not directly trigger hardware operations, but the input or output of these instructions spans both software and hardware sides and depends on the data interaction between both sides to ensure the normal operation of the instructions; in order to improve the running speed of these test instruction encodings, in the embodiment of the present application, the implementation of these test instruction encodings is transferred to the hardware acceleration emulator, and the transferred test instruction encoding is the hardware acceleration instruction.

[0075] Furthermore, the instruction packet in the preset format can encapsulate the above-mentioned instruction type data, and the data structure of the instruction packet in the preset format is shown in Table 1. The data structure of each test instruction code consists of four data words. In Table 1, N represents the maximum bit width of the instruction packet, and its value is equal to the data width of the preset space in the hardware acceleration emulator - 1. The lower 6-bit bits [5:0] of the data structure are used to represent the operation codes (op) of different test instruction codes. As shown in Table 1, the operation code 000000 represents instruction register scan (irscan), and the operation code 000100 represents data register scan (drscan); the operation codes 001000 to 011111 are the operation codes of hardware acceleration instructions; the operation codes 100000 to 101111 are the operation codes of long data instructions; the operation codes 110000 to 111111 are the operation codes of custom instructions.

[0076]

[0077] Table 1

[0078] The 4-bit bits [9:6] before the lower 6-bit bits [5:0] are the branch execution flag signals of the test instruction code. For example, instructions such as IR_SCAN and DR_SCAN trigger the execution of corresponding branch functions by selecting different branch execution flag signals, so as to implement diversified functional logics. As shown in Table 1, for example, 0000 is the run / idle flag signal; 0100 is the flag signal for data register scan, and 0001 is the flag signal for instruction register scan; 0000 to 1111 are the flag signals reserved for other functional functions.

[0079] The bits [25:10] before the bits [9:6] are used to record and transmit the data length (len) of the operation data carried by the test instruction code. The remaining high-order bits [N:26] are all used to carry the operation data. This encoding format ensures efficient and accurate communication between the instruction code and the hardware acceleration emulator.

[0080] Inside the instruction packet in the preset format, the operation data is preferentially placed at the lower bits of the instruction packet bits. For example, when the operation data is placed in the [N:26] bits of the instruction packet field, the operation data is preferentially stored at the lower bits of the [N:26] bits, and the remaining high-order bits without operation data are filled with 0 to reduce the data transmission volume. The data representing the data length of the test instruction code stored in the [25:10] bits is also preferentially placed at the lower bits.

[0081] For hardware acceleration instructions and custom instructions, these instruction types include a relatively large number of implementable functional logics, and correspondingly, there are also a relatively large number of branch execution flag signals. Therefore, the host needs to reserve sufficient space to define the branch execution flag signals of specific functional logic functions.

[0082] For long data instruction tasks containing a large amount of data, they need to be split into two or more secondary instruction packets for transmission during transmission. The data length information in each secondary instruction packet is the length information of the data carried by the secondary instruction packet itself. Multiple secondary instruction packets are distinguished by the instruction packet identification signals defined in bits [9:6] (for example, the instruction packet identification signal of the first secondary instruction packet is 0000, and the instruction packet identification signal of the second secondary instruction packet is 0001). A long data instruction task can be split into at most 16 secondary instruction packets.

[0083] Further, as Figure 3 shown, in an alternative implementation, after step S11, the host further executes step S111: perform a compliance check on the stimulated instruction. Among them, the content of the compliance check includes checking whether the data length of the stimulated instruction exceeds the preset maximum data width limit, and whether the necessary parameters of the stimulated instruction have been provided completely. If any non-compliant situation is detected, the host will output the corresponding error prompt message and instruct the test case to provide the stimulated instruction again.

[0084] Further, as Figure 3 shown, in an alternative implementation, step S12 includes the host executing step S121: convert the stimulated instruction that passes the compliance check into a test instruction encoding in a preset format and package it into an instruction packet. Since the instruction data sent by the test case cannot be directly used by the hardware acceleration emulator, for the instructions that pass the compliance check, further parsing is required to convert the stimulated instruction into the preset format specified in Table 1 above, so as to convert the stimulated instruction into a data structure that the hardware acceleration emulator can recognize.

[0085] Back to Figure 2 shown, the embodiment of the present application also provides a chip testing method that is also applied to a hardware acceleration emulator. The chip testing method executed by the hardware acceleration emulator includes the following steps.

[0086] The hardware acceleration emulator executes step S31: The hardware acceleration emulator obtains an instruction packet in a preset format. The instruction packet includes the test instruction encoding of the stimulated instruction, and stores the test instruction encoding in a preset space.

[0087] It should be noted that the test instruction encoding is the test instruction encoding in the preset format within the instruction packet in the cache file sent by the software test. The operation of storing the test instruction encoding into the preset space is the operation of the instruction queue caching mechanism in the hardware acceleration emulator. In an optional implementation, the preset space includes an instruction queue cache space for caching the instruction packets in the form of a queue.

[0088] The hardware acceleration emulator executes step S32: Parse and execute the test instruction encoding according to the preset format.

[0089] It should be noted that, similar to the host, the instruction types of the stimulating instructions include any one of common instructions, long data instructions, custom instructions, or hardware acceleration instructions. The test instruction encoding in the preset format includes: an operation code, a branch execution flag signal, a data length, and operation data.

[0090] Furthermore, in an optional implementation, step S32 includes obtaining the operation code of the test instruction encoding and executing the test instruction encoding based on the operation code, the branch execution flag signal, the data length, and the operation data.

[0091] The hardware acceleration emulator parses the test instruction encodings in the instruction packets in the cache file one by one according to the preset format in Table 1 to obtain the operation code, the branch execution flag signal, the data length, and the operation data of the test instruction encoding. Then, according to the obtained operation code of the test instruction encoding, corresponding instruction operations implemented using Verilog or System Verilog languages are performed, for example, JTAG scan operations such as executing instruction register scanning and data register scanning.

[0092] When the stimulating instruction is a long data instruction, the hardware acceleration emulator needs to parse the test instruction encodings of different instruction packets according to the branch execution flag signal of the long data instruction, then splice the test instruction encodings in the original order, and then execute the test instruction encoding of the long data instruction.

[0093] In this way, the hardware acceleration emulator receives the data parsed from the instruction packet and the output data at the output end of the instruction module for processing the instruction packet as inputs, and the output of the hardware acceleration emulator is directly fed to the input end of the instruction module for processing the instruction packet, realizing non-direct interaction with the host, thereby significantly improving the execution efficiency of the overall task. This design ensures that all task modules can operate efficiently in the hardware acceleration environment.

[0094] The hardware acceleration emulator executes step S33: The hardware acceleration emulator drives the test object to perform a state jump to achieve access to the chip data register and instruction register.

[0095] The DUT is driven by the encoded test instructions, and then the TAP (Test Access Port) state machine inside the DUT will perform state jumps according to the received instructions to achieve access to the chip data register (DR) and instruction register (IR).

[0096] Specifically, the process of accessing the instruction register includes: the TAP Controller (Test Access Port Controller) first enters the Test-Logic Reset state, and then sequentially goes through the Run-Test / Idle state, Select-DR-Scan state, Select-IR-Scan state, Capture-IR state (capturing the instruction register state, in this state, a specific logic sequence is loaded into the IR), Shift-IR (shifting the instruction register) state, Exit1-IR (exiting the instruction register scan) state, Update-IR state (updating the instruction register state, this state updates the IR content), and finally returns to the Run-Test / Idle state to complete the access to the IR. In Shift-IR, under the drive of TCK (Test Clock), in each clock cycle, the instruction register between TDI (Test Data In, test data input pin) and TDO (Test Data Out, test data output pin) will receive one bit of data from TDI and output one bit of data through TDO at the same time.

[0097] The currently accessible data register is determined by the current instruction in the instruction register. The access to the DR starts from the Run-Test / Idle state, followed by Select-DR-Scan, Capture-DR (preparing to capture the data in the DR or load new data), Shift-DR (loading new data into the DR or capturing the data in the DR through TCK and TDI / TDO), Exit1-DR, Update-DR (updating the DR content), and finally returns to the Run-Test / Idle state again. During this process, the selected DR is effectively connected between TDI and TDO, realizing two-way data transmission, that is, loading new data into the DR or capturing data from it, thus realizing the access and control functions of JTAG.

[0098] The hardware acceleration emulator executes step S34: The hardware acceleration emulator obtains the test data of the test object and returns it to the host.

[0099] Specifically, the test data from the TDO (Test Data Out) port of the DUT is sampled so that the test cases can access this test data at any time. When a test case needs to obtain the test data for the test instruction encoding operation, the test case can directly access the test data in the hardware-side transaction processor through the TCL data acquisition instruction supported by the hardware emulation accelerator.

[0100] In this way, by converting the incentive instructions issued by the test cases into test instruction encodings in a preset format, and the preset format is a data format recognizable by the hardware acceleration emulator, all the test instruction encodings can run in the hardware acceleration emulator. Thus, when the incentive instructions are running, they can be executed only within the hardware acceleration emulator, without the need to execute alternately between the host and the hardware acceleration emulator, thereby reducing the number of data interactions between the host and the hardware acceleration emulator. At the same time, through the instruction queue caching mechanism, the test instruction encodings can be transmitted in a large amount at one time, avoiding multiple transmissions of the test instruction encodings, thereby reducing the number of data transmissions between the host and the hardware acceleration emulator, and further improving the chip test speed and verification efficiency. To implement the instruction queue caching mechanism, the hardware acceleration emulator uses its own storage space as the preset space to cache the test instruction encodings. The size (data width and data depth) of this preset space is related to the balance between data transmission efficiency and resource consumption. For the data width parameter, it is necessary to ensure that this parameter can meet the data lengths required by the vast majority of instruction operations, thereby avoiding unnecessary data segmentation. The data depth parameter determines the amount of data that the cache can accommodate. Excessive data depth will lead to resource redundancy, while too small data depth will increase the frequency of data transmission and affect the overall performance.

[0101] The transmission efficiency of the instructions of the hardware acceleration emulator is affected by the data width of the software-hardware co-model (Comodel) channel. The size of the software-hardware co-model channel is defined by the number of data words (Words) included in a transaction (Transaction WordsNumber), where the size of the data word is 32bit. The software-hardware co-model channel is a communication channel used to connect the data and control signals between the hardware acceleration emulator and the host during software-hardware co-simulation or verification.

[0102] The Transaction Words Number parameter is configurable in the hardware acceleration emulator, and the parameter range is from 1 to 256. For example, when the Transaction Words Number is configured with the default value of 64, 2048 bits (32bit * 64) of data are transferred each time. By adjusting this parameter, the amount of data transferred per single transmission can be increased, thereby enhancing the efficiency of the hardware acceleration emulator in utilizing the software-hardware co-model channel when executing test instruction encoding, and thus improving the data throughput rate. It should be noted that increasing the Transaction Words Number will also consume chip gate counts. Since the minimum unit of the channel bandwidth is 32bit, in order to maximize the bandwidth utilization, the data width of the preset space should be set as an integer multiple of 32bit.

[0103] Furthermore, considering the above factors and the actual project scenario, as an example, the parameter value of the Transcation Words Num is set to 128, the data width of the preset space is set to 256 bits, and the data depth is set to 1024 bits.

[0104] Furthermore, as Figure 3 shown, in an alternative implementation, before the step S31, the hardware acceleration emulator further executes the step S311: the hardware acceleration emulator initializes the size of the preset space and initializes the number of current test instruction encodings to 0.

[0105] Specifically, the size of the preset space, that is, the initialized size of the preset space is 256bit * 1024bit.

[0106] The hardware acceleration emulator executes the step S312: the hardware acceleration emulator monitors the number of the test instruction encodings. When the number of the test instruction encodings changes, it indicates that a test instruction encoding is received. Once it is detected that the number of instruction packets changes, it indicates that the test instruction encoding of the host has been successfully transmitted to the hardware acceleration emulator. If the data sent by the software is an instruction packet including the test instruction encoding, the number of the test instruction encodings is the number of instruction packets.

[0107] Furthermore, as Figure 3 shown, in an alternative implementation, the step S32 includes the hardware acceleration emulator executing the step S321: after the number of the instruction packets changes, the hardware acceleration emulator identifies the type of the current instruction according to the operation code in the instruction packet, and parses out the branch execution flag signal and operation data of the instruction from the instruction packet.

[0108] The decoding of the instruction packet is the reverse operation of the instruction encoding. It can parse out the parameter set necessary for the operation of the instruction module from the received instruction packet. The parameters in the parameter set include the operation code, branch execution flag signal, data length, and operation data.

[0109] The decoding process for common instructions, hardware acceleration instructions, and extended instructions is as follows: First, identify the instruction type according to the operation code of the [5:0] bits of the instruction packet, and then decode the operation data, data length, and branch execution flag signal in sequence. After decoding is completed, all the parsed parameters will be passed to the instruction module in the hardware acceleration emulator. The instruction module will execute the corresponding instruction operation of the test instruction encoding according to these parameters.

[0110] The decoding process for the instruction packet of the long data instruction is slightly different. First, decode each data slice of the instruction packet according to the long instruction packet identification signal, and temporarily cache the decoded data slices in sequence; when the decoding of the last long instruction packet is completed, it will be uniformly passed to the long data instruction module for subsequent execution processing.

[0111] Furthermore, in an alternative implementation, when the stimulated instruction is a common instruction, a custom instruction, or a hardware acceleration instruction, as an alternative implementation of performing step S33, the embodiments of the present application may call the instruction module corresponding to the test instruction encoding to drive the test object to execute the corresponding instruction operation of the test instruction encoding.

[0112] For the instruction packet of the long data instruction, a two-step parsing method is required. Specifically, when the stimulated instruction is a long data instruction, as an alternative implementation of performing step S33, the embodiments of the present application may parse the data in the instruction packet one by one according to the long instruction packet identification signal, then merge the parsed multiple instruction packets, and then call the corresponding long data instruction module to drive the test object to test and execute the corresponding instruction operation of the instruction.

[0113] The hardware acceleration emulator executes the steps as described above. Each time an instruction packet is parsed, an instruction operation is executed until all the instruction packets in the cache are processed, that is, the number of instruction packets in the preset space is 0. After all the instruction packets are processed, the hardware acceleration emulator continues to detect the status of the change in the number of instruction packets to prepare for receiving and processing the next instruction packet.

[0114] Furthermore, in an alternative implementation, the instructions that meet the hardware acceleration conditions have the following characteristics: The instructions were originally only executed on the host and do not directly drive hardware operations, and the input or output of the instructions involves data interaction on both sides of the host and the hardware acceleration emulator.

[0115] Specifically, Figure 4Shows a schematic diagram of the operation process of a typical instruction that meets the conditions for hardware acceleration (Instruction 41 in the figure). Figure 4 In Figure 4 , the host includes Instruction 40, Instruction 41, and Instruction 42, and the hardware acceleration emulator includes Instruction Module 43 and Instruction Module 44. As can be seen from the figure, Instruction 41 does not have a corresponding hardware execution module on the hardware side, and the input includes the input data on both the host and the hardware acceleration emulator sides, and the output is transmitted to the hardware side. Executing Instruction 1 requires a process of sending data from the hardware acceleration emulator to the host, executing the software instruction content, and then sending the result back to the hardware acceleration emulator. The total time taken to execute Instruction 41 includes the time for two software and hardware data interactions, data input 46 and data output 47, and the time for the software to execute Instruction 41.

[0116] A simplified example of the hardware acceleration instruction scheme proposed in this solution is as Figure 5 shown. In the embodiment of this application, the instructions originally executed on the host are implemented through instruction modules in the hardware acceleration emulator. As Figure 5 shown in Figure 5 , the host includes Instruction 50, Instruction 51, and Instruction 52, and the hardware acceleration emulator includes Instruction Module 53, Instruction Module 54, and Instruction Module 55. The instruction packets of Instruction 50, Instruction 51, and Instruction 52 are sequentially sent to the hardware acceleration emulator through the instruction queue caching mechanism proposed above, and then are parsed and sequentially sent to Instruction Module 53, Instruction Module 54, or Instruction Module 55 for execution. After adopting this solution, the execution time of Instruction 1 mainly consists of the caching time of the instruction packets and the execution time of Instruction Module 53, Instruction Module 54, or Instruction Module 55. It should be noted that the data packet caching time is much less than the software and hardware interaction time, and the execution speed of the instruction module is also faster than the speed of the software executing Instruction 1.

[0117] To solve the above problems, the embodiment of this application provides a chip testing device, which is applied to the host and reduces the number of interactions between the host and the hardware acceleration emulator by using the instruction queue caching mechanism to send data to the hardware acceleration emulator. As an optional implementation, Figure 6 shows a schematic diagram of the process of the chip testing device provided by the embodiment of this application. As Figure 6 shown, the chip testing device provided by the embodiment of this application includes the following structure.

[0118] Test case 100, used to verify the chip function and performance.

[0119] Instruction encoding module 200, used to obtain the instructions of the stimuli sent by the test case 100, and convert the instructions of the stimuli sent by the test case 100 into test instruction encodings in a preset format; the preset format is a data format recognizable by the hardware acceleration emulator.

[0120] The first instruction queue caching module 300 is used to send the test instruction encoding to the hardware acceleration emulator through an instruction queue caching mechanism. The instruction queue caching mechanism includes storing the test instruction encoding in a preset file and sending the test instruction encoding to the hardware acceleration emulator when a preset transmission condition is met.

[0121] In this way, by converting the stimulating instructions sent by the test case 100 into test instruction encodings in a preset format, and the preset format is a data format recognizable by the hardware acceleration emulator, all the test instruction encodings can run on the hardware acceleration emulator. Thus, when the test instruction encoding is running, it can be executed only within the hardware acceleration emulator and does not need to be alternately executed between the host and the hardware acceleration emulator, thereby reducing the number of data interactions between the host and the hardware acceleration emulator. At the same time, through the instruction queue caching mechanism, the test instruction encodings can be centrally transmitted in a large amount of data at one time, avoiding multiple transmissions of the test instruction encodings, thereby reducing the number of data transmissions between the host and the hardware acceleration emulator, and further improving the chip test speed and verification efficiency. Further, as Figure 6 shown, in an optional implementation, the instruction encoding module 200 is used to perform compliance checks on the stimulating instructions. Among them, the content of the compliance check includes checking whether the data length of the stimulating instruction exceeds the preset maximum data width limit, and whether the necessary parameters of the stimulating instruction have been provided completely. If any non-compliant situation is detected, the system will output the corresponding error prompt message and instruct the test case 100 to provide the stimulating instruction again. After that, the instruction encoding module 200 will convert the stimulating instruction that passes the compliance check into a test instruction encoding in a preset format and package it into an instruction packet. Further, as Figure 6 shown, in an optional implementation, the instruction encoding module 200 includes:

[0122] The common instruction encoding module 210 is used to obtain the common instructions sent by the test case 100 and convert the common instructions sent by the test case 100 into test instruction encodings in a preset format.

[0123] The long data instruction encoding module 220 is used to obtain the long data instructions sent by the test case 100 and convert the long data instructions sent by the test case 100 into test instruction encodings in a preset format.

[0124] The hardware acceleration instruction encoding module 230 is used to obtain the hardware acceleration instructions sent by the test case 100 and convert the hardware acceleration instructions sent by the test case 100 into test instruction encodings in a preset format.

[0125] The custom instruction encoding module 240 is used to obtain the custom instructions sent by the test case 100 and convert the custom instructions sent by the test case 100 into test instruction encodings in a preset format.

[0126] Further, as Figure 6 shown, in an optional implementation, the first instruction queue caching module 300 is used to create a blank cache file, store the instruction packets in the cache file in the call time order of the stimulated instructions, and perform real-time counting; and, calculate the total time required to execute the test instruction encoding based on the instruction type and data length of the test instruction encoding; detect whether the cache file reaches a preset transmission condition. When the preset transmission condition is reached, send the cache file to the hardware acceleration emulator; when the preset transmission condition is reached, send the instruction packets in the cache file, the number of sent instruction packets, and the specified running time of the instruction packets to the hardware acceleration emulator; after the instruction packets are sent, clear the cache file.

[0127] The chip test device provided by the embodiment of the present application further includes: a transaction-level transmission channel 400, which is used to connect the software test and the hardware acceleration emulator to transmit data.

[0128] To solve the above problems, the embodiment of the present application provides a chip test device, which is applied to a hardware acceleration emulator, and reduces the number of interactions between the host and the hardware acceleration emulator by using an instruction queue caching mechanism to send data to the hardware acceleration emulator. As an optional implementation, Figure 6 shows a schematic flowchart of the chip test device provided by the embodiment of the present application. As Figure 6 shown, the chip test device provided by the embodiment of the present application includes the following structure.

[0129] The second instruction queue caching module 500 is used to obtain instruction packets in a preset format. The instruction packets include test instruction encodings of the stimulated instructions, and store the test instruction encodings in a preset space.

[0130] It should be noted that the test instruction encoding is the test instruction encoding in a preset format in the instruction packets in the cache file sent by the software test. The operation of storing the test instruction encoding in the preset space is the operation of the instruction queue caching mechanism in the hardware acceleration emulator.

[0131] The instruction decoding module 600 is used to parse and execute the test instruction encoding according to the preset format.

[0132] The instruction decoding module 600 parses the test instruction codes of the instruction packets in the buffer file one by one according to the preset format in Table 1 to obtain the operation code, branch execution flag signal, data length, and operation data of the test instruction code. Then, according to the operation code of the obtained test instruction code, corresponding instruction operations implemented using Verilog or System Verilog language are performed. For example, JTAG scan operations such as executing instruction register scanning and data register scanning are performed.

[0133] The test object 700 is used as a carrier for accessing the chip data register and instruction register and returns the test data of the test object.

[0134] In this way, by converting the stimulating instructions sent by the test case 100 into test instruction codes in a preset format, and the preset format is a data format recognizable by the hardware acceleration emulator, all the stimulating instructions can run on the hardware acceleration emulator. Thus, when the test instruction code is running, it can be executed only within the hardware acceleration emulator and does not need to be alternately executed between the host and the hardware acceleration emulator, thereby reducing the number of data interactions between the host and the hardware acceleration emulator. At the same time, through the instruction queue caching mechanism, the test instruction codes can be centrally transmitted in a large amount of data at one time and transmitted multiple times, thereby reducing the number of data transmissions between the host and the hardware acceleration emulator, and further improving the chip test speed and verification efficiency.

[0135] Furthermore, the decoding process for common instructions, hardware acceleration instructions, and extended instructions is as follows: First, the instruction type is identified according to the operation code of the [5:0] bits of the instruction packet, and then the operation data, data length, and branch execution flag signal are decoded in sequence. After decoding is completed, all the parsed parameters will be passed to the instruction decoding module 600 in the hardware acceleration emulator. The instruction decoding module 600 will perform the corresponding instruction operations of the test instruction code according to these parameters.

[0136] When the stimulating instruction is a long data instruction, the hardware acceleration emulator needs to parse the test instruction codes of different instruction packets according to the branch execution flag signal of the long data instruction, then splice the test instruction codes in the original order, and then execute the test instruction code of the long data instruction.

[0137] Correspondingly, as Figure 6 shown, in an optional implementation, the instruction decoding module 600 includes:

[0138] The common instruction decoding module 610 is used to drive the test object to perform the corresponding instruction operations of common instructions.

[0139] Among them, when the hardware acceleration instruction is IR_SCAN or DR_SCAN, the common instruction decoding module 610 executes the JTAG standard IEEE 1149.1 protocol and realizes its function by controlling the jump of the JTAG TAP (Test Access Port) state machine in the DUT. This process is as Figure 7 shown.

[0140] The IEEE 1149.1 protocol is a standard of JTAG, which defines a boundary scan test protocol for testing and debugging electronic circuits. As Figure 7 shown, the main states of the state machine include: Test-Logic-Reset for resetting the state; Run-Test / Idle for the idle state or running a test; Shift-IR / DR for the shift operation of the data register (DR) or the instruction register (IR); Capture-IR / DR for capturing data or instructions; Update-IR / DR for updating data or instructions. For the IR_SCAN instruction, first, it enters Select-IR-Scan from Run-Test / Idle; then, new instructions are input via Capture-IR and Shift-IR; finally, the new instruction loading is completed via Exit1-IR and Update-IR. For the DR_SCAN instruction, first, it enters Select-DR-Scan from Run-Test / Idle; then, test data is read or written via Capture-DR and Shift-DR; finally, the data update is completed via Exit1-DR and Update-DR. Through this state jump mechanism, the IEEE 1149.1 protocol realizes flexible and efficient boundary scan test operations while ensuring compatibility and standardization.

[0141] The long data instruction decoding module 620 is used to parse the data in the instruction packet one by one according to the long instruction packet identification signal; merge the multiple parsed instruction packets, and drive the test object to execute the instruction operation corresponding to the stimulated instruction.

[0142] The custom instruction decoding module 630 is used to drive the test object to execute the instruction operation corresponding to the custom instruction.

[0143] The hardware acceleration instruction decoding module 640 is used to drive the test object to execute the instruction operation corresponding to the hardware acceleration instruction.

[0144] It should be noted that as Figure 6As shown, the second instruction queue cache module 500 and the instruction decoding module 600 both belong to the hardware - side transaction processor 800. The hardware - side transaction processor 800 is also used to obtain the test data of the test object. Specifically, the hardware - side transaction processor 800 samples the test data from the TDO (Test Data Out) port of the DUT (Device Under Test) so that the test case 100 can access this test data at any time. When the test case 100 needs to obtain the test data of the instruction operation of the stimulus, it can directly access the test data in the hardware - side transaction processor 800 through the TCL data acquisition instruction supported by the hardware simulation accelerator.

[0145] In addition, when the test object 700 returns the test data, it needs to serially send the test data to the hardware - side transaction processor 800 first, and then the hardware - side transaction processor 800 parallel - sends it to the host.

[0146] By using the instruction queue cache mechanism and the hardware - acceleration instruction method, the embodiments of the present application achieve a significant reduction in the number of data interactions between software and hardware. As Figure 8 shown, by comparing the specific performance of the existing solution and the present solution in terms of the number of hardware interactions, it can be seen that the lines of the number of software - hardware interactions in the existing solution and the lines of the number of software - hardware interactions in the present design solution can both be approximated as a straight line. The slope of the line of the number of software - hardware interactions in the existing solution is much greater than the slope of the line of the number of software - hardware interactions in the present design solution. And when the number of instructions is the same, the number of software - hardware interactions in the present design solution is less than that in the existing solution. Therefore, the chip testing device provided by the embodiments of the present application can reduce the number of software - hardware interactions.

[0147] The embodiments of the present application also provide a computing device, including a processor and a memory. The memory stores computer instructions, and the processor executes the computer instructions to implement the chip testing method of software testing as described above, or the chip testing method of the hardware - acceleration emulator as described above.

[0148] The embodiments of the present application also provide a computer program product, including computer instructions, and when the computer instructions are executed, they implement the chip testing method of software testing as described above, or the chip testing method of the hardware - acceleration emulator as described above.

[0149] The embodiments of the present application also provide a storage medium, and the storage medium stores a design program, and when the design program is executed, it implements the chip testing method of software testing as described above, or the chip testing method of the hardware - acceleration emulator as described above.

[0150] An embodiment of the present application further provides a computer system, including a host and a hardware acceleration emulator. The host runs the chip testing method of the host as described above, and the hardware acceleration emulator runs the chip testing method of the hardware acceleration emulator as described above.

[0151] Although the embodiments of the present application are disclosed as above, the present application is not limited thereto. Any person skilled in the art can make various changes and modifications without departing from the spirit and scope of the present application. Therefore, the protection scope of the present application should be subject to the scope defined by the claims.

Claims

1. A chip testing method, characterized in that, Applied to the host, including: Instructions for obtaining the stimuli sent by the test case; the test case is used to simulate the actual application scenario for the chip and verify the chip; Converting the instructions of the stimuli sent by the test case into test instruction encodings in a preset format; the preset format is a data format recognizable by the hardware acceleration emulator; Sending the test instruction encodings to the hardware acceleration emulator through an instruction queue caching mechanism; the instruction queue caching mechanism is: storing the test instruction encodings in a preset file, and sending the test instruction encodings to the hardware acceleration emulator when a preset transmission condition is reached.

2. The chip testing method according to claim 1, wherein, After the step of obtaining the instructions of the stimuli sent by the test case, it further includes: performing compliance checking on the instructions of the stimuli; The step of converting the instructions of the stimuli sent by the test case into test instruction encodings in a preset format includes: Converting the instructions of the stimuli that pass the compliance check into test instruction encodings in a preset format and packing them into an instruction packet.

3. The chip testing method according to claim 2, wherein, The step of sending the test instruction encodings to the hardware acceleration emulator through the instruction queue caching mechanism includes: Creating a blank cache file; Storing the instruction packets in the cache file in the order of the call time of the instructions of the stimuli and performing real-time counting; and calculating the total time required to execute the test instruction encodings based on the instruction type and data length of the test instruction encodings; Detecting the preset transmission condition of the cache file; When the preset transmission condition occurs, sending the instruction packets in the cache file, the number of instruction packets sent, and the specified running time of the instruction packets to the hardware acceleration emulator; Clearing the cache file after the instruction packets are sent.

4. The chip testing method according to claim 3, characterized in that, The preset transmission condition includes: when the cumulative number of instruction packets reaches the maximum data depth limit; Or detecting a return parameter; Or detecting an active trigger instruction.

5. The chip testing method according to claim 1, wherein The instruction type of the instructions of the stimuli includes any one of common instructions, long data instructions, custom instructions, or hardware acceleration instructions; When the instruction type of the instructions of the stimuli is a long data instruction, the step of converting the instructions of the stimuli sent by the test case into test instruction encodings in a preset format includes: dividing the instruction packet of the long data instruction into multiple secondary instruction packets.

6. A chip testing method, characterized in that, Applied to the hardware acceleration emulator, including: Obtaining an instruction packet in a preset format, the instruction packet includes the test instruction encodings of the instructions of the stimuli, and storing the test instruction encodings in a preset space; Parsing and executing the test instruction encodings according to the preset format; Driving the test object to perform a state jump to achieve access to the chip data register and instruction register; Obtaining the test data of the test object and returning it to the host.

7. The chip testing method according to claim 6, wherein, Before the step of obtaining an instruction packet in a preset format, the instruction packet includes the test instruction encodings of the instructions of the stimuli, and storing the test instruction encodings in a preset space, it further includes: Initializing the size of the preset space and initializing the current number of test instruction encodings to 0; Monitoring the number of test instruction encodings, and when the number of test instruction encodings changes, it indicates that a test instruction encoding is received.

8. The chip testing method according to claim 7, wherein The instruction type of the stimulated instruction includes any one of a common instruction, a long data instruction, a custom instruction, or a hardware acceleration instruction; When the stimulated instruction is a common instruction, a custom instruction, or a hardware acceleration instruction, the step of parsing and executing the test instruction code according to the preset format includes: After the number of instruction packets changes, identify the type of the current instruction according to the operation code in the instruction packet, and parse out the branch execution flag signal and operation data of the instruction from the instruction packet; When the stimulated instruction is a long data instruction, the step of parsing and executing the test instruction code according to the preset format includes: Call the instruction module corresponding to the test instruction code to drive the test object to execute the instruction operation corresponding to the test instruction code; Parse the data in the instruction packet one by one according to the long instruction packet identification signal; Merge the multiple parsed instruction packets, and then call the corresponding long data instruction module to drive the test object to execute the instruction operation corresponding to the test instruction code.

9. A chip testing device, characterized in that, Applied to a host, it includes: A test case for simulating an actual application scenario for the chip and verifying the chip; An instruction encoding module for obtaining the stimulated instruction sent by the test case and converting the stimulated instruction sent by the test case into a test instruction code in a preset format; the preset format is a data format recognizable by a hardware acceleration emulator; A first instruction queue caching module for sending the test instruction code to the hardware acceleration emulator through an instruction queue caching mechanism; the instruction queue caching mechanism includes storing the test instruction code in a preset file and sending the test instruction code to the hardware acceleration emulator when a preset transmission condition is met; A transaction-level transmission channel for connecting software testing and the hardware acceleration emulator and transmitting data.

10. The chip testing device according to claim 9, wherein, The instruction type of the stimulated instruction includes any one of a common instruction, a long data instruction, a custom instruction, or a hardware acceleration instruction; The instruction encoding module includes: A common instruction encoding module for obtaining the common instruction sent by the test case and converting the common instruction sent by the test case into a test instruction code in a preset format; A long data instruction encoding module for obtaining the long data instruction sent by the test case and converting the long data instruction sent by the test case into a test instruction code in a preset format; A hardware acceleration instruction encoding module for obtaining the hardware acceleration instruction sent by the test case and converting the hardware acceleration instruction sent by the test case into a test instruction code in a preset format; A custom instruction encoding module for obtaining the custom instruction sent by the test case and converting the custom instruction sent by the test case into a test instruction code in a preset format.

11. A chip testing device, characterized in that, Applied to a hardware acceleration emulator, it includes: A second instruction queue caching module for obtaining an instruction packet in a preset format, where the instruction packet includes the test instruction code of the stimulated instruction, and storing the test instruction code in a preset space; An instruction decoding module for parsing and executing the test instruction code according to the preset format; A test object, which is used as a carrier for accessing the chip data register and instruction register, and returns the test data of the test object.

12. The chip testing device according to claim 11, wherein The instruction types of the stimulated instructions include any one of common instructions, long data instructions, custom instructions, or hardware acceleration instructions; The instruction decoding module includes: A common instruction decoding module, which is used to drive the test object to execute the instruction operations corresponding to the common instructions; A long data instruction decoding module, which is used to parse the data in the instruction packet one by one according to the long instruction packet identification signal; merge the multiple parsed instruction packets, and drive the test object to execute the instruction operations corresponding to the test instruction encoding; A custom instruction decoding module, which is used to drive the test object to execute the instruction operations corresponding to the custom instructions; A hardware acceleration instruction decoding module, which is used to drive the test object to execute the instruction operations corresponding to the hardware acceleration instructions.

13. A computing device, characterized in that, It includes a processor and a memory, the memory stores computer instructions, and the processor executes the computer instructions to implement the chip test method according to any one of claims 1-5, or the chip test method according to any one of claims 6-8.

14. A computer system, characterized in that, It includes a host and a hardware acceleration emulator, the host runs the chip test method according to any one of claims 1-5, and the hardware acceleration emulator runs the chip test method according to any one of claims 6-8.

Images