Chip verification methods, apparatus, equipment and storage media
By using kernel stubs to receive and cache test case modules within the chip and dynamically switching control, the time-consuming chip verification problem in existing technologies is solved, achieving an efficient, automated, and unattended verification process.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- 厦门国科安芯科技有限公司
- Filing Date
- 2026-04-22
- Publication Date
- 2026-07-31
AI Technical Summary
Existing chip verification toolchains require relinking and erasing the entire Flash memory when verification test cases are modified, resulting in long processing times and making it difficult to achieve efficient automation and unattended verification processes at night.
The kernel stubs receive pre-compiled test case modules and cache them in volatile memory, dynamically switching control to execute test case modules and collect results, avoiding hardware resets and supporting automated and continuous verification.
This significantly improves the efficiency of chip verification, shortens the verification time, realizes an unattended automated verification process, and reduces the time overhead of hardware reset.
Smart Images
Figure CN122491167A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of chip technology, and in particular to a chip verification method, apparatus, device, and storage medium. Background Technology
[0002] As chip integration continues to increase, the number of CPU cores, peripheral channels, and configurable parameters integrated into a single chip (i.e., SoC) are growing exponentially. For example, some automotive-grade multi-core MCUs contain 6 TriCore cores and more than 200 peripheral instances, and the number of corresponding verification test cases has rapidly expanded from the traditional hundreds to thousands.
[0003] However, existing mainstream chip verification toolchains (such as Lauterbach, PLS, and Infineon MCD) generally adopt a process of "full image compilation, full chip erasure, JTAG download, and hardware reset": each modification to the verification test case requires relinking the complete Executable and Linkable Format (ELF) files, typically several megabytes in size; then, the entire Flash memory is erased via JTAG / USB interface and a new image is written; finally, a chip reset is triggered, restarting the entire system. In a scenario with thousands of verification test case regressions, the total time can exceed 8 hours, severely slowing down chip delivery. Therefore, an efficient chip verification method is urgently needed. Summary of the Invention
[0004] To address or at least partially address the aforementioned technical problems, this disclosure provides a chip verification method, apparatus, device, and storage medium.
[0005] A first aspect of this disclosure provides a chip verification method applied to a target chip, the target chip including a kernel stump and a processing module, wherein the method includes: The kernel stub receives pre-compiled test case modules from the host computer and caches these test case modules in the volatile memory of the target chip. After fully receiving the test case module, the kernel stub is used to transfer control of the processing module to the test case module; The test case module executes the test logic, and after execution, the control of the processing module is returned to the kernel stub. The execution results of the test case module are collected through the kernel stubs; The execution result is returned to the host computer through the kernel stub, so that when the execution result shows that the test case module has been executed successfully, the host computer will send out the pre-compiled next test case module. The kernel stub returns to the step of receiving the pre-compiled test case module sent by the host computer and caching the test case module in the volatile memory of the target chip, until all test case modules have been executed.
[0006] A second aspect of this disclosure provides a chip verification apparatus applied to a target chip, the target chip including a kernel stump and a processing module, wherein the apparatus includes: The caching module is used to receive pre-compiled test case modules from the host computer through the kernel stub, and cache the test case modules in the volatile memory of the target chip. The handover module is used to transfer control of the processing module to the test case module through the kernel stub after fully receiving the test case module; The execution module is used to execute test logic through the test case module, and after execution is completed, return control of the processing module to the kernel stub; The collection module is used to collect the execution results of the test case module through the kernel stubs; The feedback module is used to return the execution result to the host computer through the kernel stub, so that when the execution result shows that the test case module has been executed successfully, the host computer will issue the next pre-compiled test case module. The return module is used to return to the steps of receiving the pre-compiled test case module issued by the host computer and caching the test case module in the volatile memory of the target chip through the kernel stub, until all test case modules have been executed.
[0007] A third aspect of this disclosure provides an electronic device that includes the target chip described in the first aspect.
[0008] A fourth aspect of this disclosure provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the method of the first aspect described above.
[0009] The technical solution provided in this disclosure has the following advantages compared with the prior art: In this embodiment, after caching the test case module, the kernel stub can transfer control of the processing module to the test case module, enabling the test case module to execute test logic. This allows the processing module to dynamically switch to the test case module in volatile memory for execution without resetting or reprogramming. Furthermore, after the test case module completes execution, it can transfer control of the processing module back to the kernel stub, allowing the processing module to re-execute the kernel stub. The entire process does not involve a hardware reset signal, avoiding the time overhead associated with hardware resets. Moreover, the host computer does not need to wait for manual intervention or reset or reconnect the target chip, and can continue sending the next test case module to the target chip. Thus, multiple test case modules can be executed automatically and efficiently in sequence without human intervention, significantly improving the efficiency of chip verification. Attached Figure Description
[0010] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.
[0011] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0012] Figure 1 This is a flowchart of a chip verification method provided in an embodiment of this disclosure; Figure 2 This is a schematic diagram of the structure of a chip verification device provided in an embodiment of this disclosure. Detailed Implementation
[0013] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.
[0014] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.
[0015] As chip integration continues to increase, the number of CPU cores, peripheral channels, and configurable parameters integrated into a single chip (SoC) are growing exponentially. For example, some automotive-grade multi-core MCUs contain six TriCore cores and more than 200 peripheral instances, and the number of corresponding verification test cases has rapidly expanded from the traditional hundreds to thousands. However, existing mainstream chip verification toolchains (such as Lauterbach, PLS, and Infineon MCD) generally adopt a process of "full image compilation, full chip erasure, JTAG download, and hardware reset": each modification to the verification test case requires relinking the complete executable and linkable ELF files, which are usually several megabytes in size; then the entire Flash memory is erased and a new image is written via the JTAG / USB interface; finally, a chip reset is triggered, restarting the entire system. This process takes an average of 3-5 minutes per iteration, and in a scenario with thousands of verification test case regressions, the total time can reach more than 8 hours, seriously slowing down the chip delivery schedule. Furthermore, while RAM debugging supports copying individual functions to RAM for execution, it still has the following limitations: First, it requires manual specification of the load address and data length, lacking a unified verification mechanism; second, it cannot automatically capture exceptions after test cases fail, requiring manual reset; third, it is difficult to integrate with CI systems, making unattended regression testing at night difficult; fourth, it is not friendly to mass production evaluation boards, requiring the JTAG interface to be retained, increasing hardware dependence. In summary, existing chip verification methods have the following main drawbacks: First, high time cost, with full-chip erase, download, and reset operations accounting for over 70% of verification time; second, significant bandwidth waste, with several megabytes transmitted per transfer while only a few thousand bytes are actually modified; third, difficulty in automation, as JTAG reset actions are difficult to be effectively invoked by the CI pipeline; fourth, lack of exception handling, requiring manual reset for test case failures, leading to frequent interruptions in nighttime regression testing; fifth, high hardware dependence, requiring dedicated emulator support, making it unsuitable for direct use on mass production evaluation boards. Therefore, a dynamic verification solution that requires no reset, is hot-swappable, supports automatic retransmission, and integrates with CI is urgently needed.
[0016] Figure 1 This is a flowchart illustrating a chip verification method provided in an embodiment of this disclosure. This method can be executed by a chip. The chip can be exemplarily understood as, for example, an automotive chip.
[0017] like Figure 1 As shown, the method provided in this embodiment includes the following steps: S110: Receives pre-compiled test case modules from the host computer via kernel stubs, and caches the test case modules in the volatile memory of the target chip.
[0018] In this embodiment of the disclosure, the chip verification system includes a target chip and a host computer.
[0019] The target chip consists of a kernel stub and a processing module. The kernel stub is a fixed software program embedded in the target chip's non-volatile memory (such as Flash). It is responsible for downloading and verifying test case modules, jumping (i.e., relinquishing and regaining control of the processing module), and exception handling. A kernel stub can include, but is not limited to, the kernel stub itself. The processing module is the hardware unit in the target chip responsible for executing instructions (such as those passed to it by the kernel stub and test case modules) and performing data operations. A processing module can include, but is not limited to, the CPU.
[0020] The host computer includes a communication module and a control module. The communication module sends test case modules to the target chip via interfaces such as UART, CAN-FD, or USB-DFU, and receives the execution results returned by the target chip. The communication module may include, but is not limited to, host tools. The control module determines the sending order of test case modules according to the test case configuration file, controls the communication module to execute the sending operation, determines whether to trigger data packet retransmission based on the response result, and collects the execution results of each test case module, determining whether to trigger test case module retransmission based on the execution result. The control module may include, for example, a CI plugin, but is not limited to, it.
[0021] The order in which test case modules are sent is defined by the test case configuration file. When adding, deleting, or modifying test items, only the path of the corresponding test case module needs to be added, removed, or updated in the configuration file. If the test case modules are independent of each other, adding, deleting, or modifying test items only requires compiling and executing the affected individual test case modules; other test case modules remain unaffected and do not require retesting. If at least two test case modules are not independent, i.e., there is code sharing, data dependency, or global variable coupling between them, adding, deleting, or modifying test items requires recompiling and executing all related test case modules.
[0022] Specifically, volatile memory may include, for example, RAM, but is not limited to this.
[0023] Specifically, a test case module refers to a pre-compiled binary code unit for a specific test item. For example, a test case module card includes executable code blocks stored in HEX file format, where the size of the HEX file does not exceed 8KB, but is not limited to this.
[0024] Optionally, the test case module includes address information and valid data. The address information includes load address information, start execution address, and data length information. The address information specifies the specific address range where the valid data should be written to volatile memory, and the entry point address for the test case module execution. The load address information refers to the target storage address of the valid data in volatile memory within the test case module. The data length information refers to the number of bytes occupied by the valid data, indicating its actual size. The start execution address refers to the initial value of the program counter when the processing module begins executing the test case module after the entire test case module has been completely received and written to volatile memory. Valid data refers to the binary content in each data packet that actually needs to be written to volatile memory and executed after removing protocol overhead such as address information, length information, and checksums. This includes executable instructions, initialization data, and necessary configuration information, but is not limited to these.
[0025] Accordingly, the test case module is cached in the volatile memory of the target chip, including: writing valid data into the corresponding address area of the volatile memory according to the load address information.
[0026] Optionally, the load address information refers to the target storage address of each data packet in the volatile memory within the test case module, indicating from which the data packet should be written. The data length information refers to the number of bytes occupied by the valid data in each data packet, indicating the actual size of the data in this packet. The starting execution address is carried by the last data packet or a specific control packet of the test case module.
[0027] Correspondingly, the system receives pre-compiled test case modules from the host computer and caches these modules in the target chip's volatile memory, including: S111: Receive the data packet from the test case module sent by the host computer, and perform data verification on the data packet to obtain the first verification code.
[0028] Specifically, data verification performed on data packets may include CRC verification (such as CRC32 cyclic redundancy check), but is not limited to this.
[0029] S112. Compare the first check code with the second check code carried in the data packet.
[0030] Specifically, the second checksum is a check value appended to the end of the data packet, used to verify whether the data packet has experienced bit errors or data loss during transmission.
[0031] S113. If the first check code and the second check code are consistent, the data packet is buffered in the volatile memory, and a successful reception acknowledgment (such as ACK) is sent back to the host computer so that the host computer can send the next data packet.
[0032] Specifically, based on the loading address information corresponding to the data packet, the valid data in the data packet is cached in volatile memory.
[0033] S114. Return to the step of receiving data packets from the test case module sent by the host computer and performing data verification on the data packets to obtain the first verification code, until all data packets from the test case module have been received.
[0034] Optionally, the method further includes: if the first check code and the second check code are inconsistent, sending a reception failure response (such as NACK) to the host computer through the kernel stub, so that the host computer retransmits the data packet until the data packet is successfully received or the number of retransmissions reaches the first preset upper limit value.
[0035] Specifically, if the number of retransmissions of the same data packet reaches the first preset upper limit and the kernel stub still fails to successfully receive the data packet, the host computer can stop sending data packets to the test case module to which the data packet belongs, skip the test case module, record the flag used to characterize the success or failure of the execution result as an execution failure, and continue to send the next test case module. Of course, the host computer can also analyze the reason for the timeout response of the data packet.
[0036] Understandably, by attaching a checksum to each data packet and comparing it in real time with the kernel stub, it can be ensured that the test case module cached in volatile memory is completely consistent with the test case module sent by the host computer, fundamentally eliminating false tests or abnormal chip behavior caused by data corruption. Furthermore, when the checksum fails, the host computer automatically triggers a retransmission, restoring transmission without manual intervention, thus improving communication capabilities and the robustness of the chip verification process.
[0037] S120. After fully receiving the test case module, transfer control of the processing module to the test case module through kernel stubs.
[0038] Optionally, after fully receiving the test case module, the kernel stub saves the current context of the processing module and disables global interrupts, transferring control of the processing module to the test case module.
[0039] Understandably, disabling global interrupts before executing the test case module ensures that the test case module will not be interrupted by any external or internal interrupt events during its execution. This ensures that the test case module runs in an undisturbed environment and avoids unexpected interference from interrupts to the execution logic of the test case module.
[0040] Optionally, control of the processing module can be transferred to the test case module, including: determining whether the start execution address and the end execution address are within the effective address range of the volatile memory; if so, the function pointer can be jumped to the start execution address, where the end execution address is calculated based on the start execution address and the data length.
[0041] Specifically, the total length of valid data is determined based on the data length information, the sum of the starting execution address and the total data length is calculated, and the ending execution address is obtained by subtracting 1 from the sum.
[0042] Specifically, the available address range of volatile memory (including the start and end addresses) is obtained. It is then determined whether the following conditions are met: start execution address ≥ start address and end execution address ≤ end address. If met, the function pointer is jumped to the start execution address. If not, the kernel stub can return address error information (such as an address error exception code) to the host computer and wait to receive the next test case module. Alternatively, if the start execution address ≥ start address and end execution address ≤ end address is met, it can be further determined whether the "address range between the start and end execution addresses" does not overlap with any of the "reserved area, stack area, and kernel stub data area." If so, the function pointer is jumped to the start execution address; otherwise, the kernel stub can return address error information to the host computer and wait to receive the next test case module.
[0043] Understandably, after completing the address range check, the kernel stub assigns the starting execution address to the function pointer and executes the call. This sets the processing module's program counter to that starting execution address, allowing the processing module to leave the kernel stub's code flow and begin fetching and executing instructions from the test case module. This mechanism enables the processing module to dynamically switch to the test case module in volatile memory for execution without resetting or reprogramming.
[0044] S130. Through the test case module, execute the test logic, and after execution, return control of the processing module to the kernel stub.
[0045] Specifically, after the test case module gains control of the processing module, the processing module fetches and executes pre-compiled machine instructions one by one, starting from the initial execution address of the test case module, thereby completing the chip verification operation corresponding to the test case module. This execution process is entirely performed in volatile memory. After execution, the test case module can store the execution results in a preset register or memory location for subsequent collection and reporting by the kernel stubs.
[0046] Optionally, after execution is complete, control of the processing module is returned to the kernel stump, including setting the processing module's program counter to the kernel stump's start address in non-volatile memory.
[0047] Understandably, by setting the program counter to the start address of the kernel stash, the processing module can re-execute the kernel stash from that start address. The entire process does not involve a hardware reset signal, achieving the effect of a software reset while avoiding the time overhead of a hardware reset.
[0048] S140. Collect the execution results of the test case modules through kernel stubs.
[0049] Optionally, after gaining control of the processing module, the kernel stub restarts execution from the startup address, restores the context of the processing module, re-enables interrupts, and collects the execution results of the test case module.
[0050] Specifically, the execution result may include at least one of the following: an indicator of execution success or failure, such as ACK indicating successful execution and NACK or a specific error code indicating failure; an exception code, which is generated by the kernel stub when an exception occurs in the test case module, such as a crash, out-of-bounds access, or illegal instruction, to locate the cause of failure; a return value or key data (such as register values, sampling results, checksums, etc.) for subsequent result comparison or debugging analysis; and an error type classification, such as CRC check failure, address out-of-bounds access, timeout without response, etc., to help quickly distinguish whether it is a transmission problem, an execution problem, or a failure of the function under test, but it is not limited to these.
[0051] S150. The execution result is returned to the host computer through the kernel stub, so that the host computer can send the pre-compiled next test case module when the execution result shows that the test case module has been executed successfully.
[0052] S160. Through the kernel stub, return to the step of receiving the pre-compiled test case module sent by the host computer and caching the test case module in the volatile memory of the target chip, until all test case modules have been executed.
[0053] Specifically, after receiving the successful execution result of the test case module returned by the kernel stub, the host computer immediately and automatically begins to send the next pre-compiled test case module according to the order in the test case configuration file. This achieves continuous automated driving of the chip verification process. The host computer does not need to wait for manual intervention, nor does it need to reset or reconnect the target chip. It only needs to confirm the successful execution of the current test case module before sending the next test case module to the target chip. The kernel stub repeats the complete process of verification, loading, jumping, execution, and return (i.e., operations S110-S150) after receiving the stub. This allows hundreds or thousands of test case modules to be executed automatically and sequentially without human intervention, significantly improving the efficiency of chip verification.
[0054] Of course, the CI plugin in the host computer can generate a test report containing the pass rate, a list of failed test cases and error details based on the execution results of each test case module, providing a complete and traceable basis for the verification of the target chip.
[0055] Optionally, the method further includes: if the execution result shows that the test case module fails to execute, receiving the resent test case module from the host computer, until the execution result shows that the test case module executes successfully, or the number of re-executions reaches a preset second upper limit value.
[0056] Specifically, if the number of resends for the same test case module reaches the second preset upper limit and the test case module still fails to execute successfully, the host computer can stop sending the test case module, skip it, record the flag indicating success or failure in the execution result as failure, and continue sending the next test case module. Of course, the host computer can also analyze the reason for the timeout response of the test case module.
[0057] Understandably, when the test case module fails to execute, the host computer automatically triggers a retransmission, minimizing the need for manual intervention and supporting large-scale chip verification testing without human intervention at night.
[0058] Optionally, during the chip verification process, the target chip remains operational and does not trigger a hardware reset.
[0059] Specifically, throughout the entire process of receiving, writing, verifying, executing, and transmitting, the target chip remains operational without triggering a hardware reset. This means that from the moment the host computer sends the first data packet until the kernel stub completes the result transmission and waits for the next test case module, the target chip remains continuously powered and running without experiencing any hardware reset signals triggered by debugging tools or software. By residing the kernel stub in non-volatile memory, dynamically loading test case modules into non-volatile memory for execution, and alternating control of the processing module between the kernel stub and the test case module, the dependence on hardware reset is eliminated. The target chip does not need to be restarted, thus avoiding the time overhead of tens or even hundreds of milliseconds caused by reset. This not only significantly shortens the iteration cycle of a single test case module but also enables hundreds or thousands of test case modules to be executed sequentially, laying a solid foundation for unattended batch chip verification testing overnight.
[0060] Optionally, ECC check bits can be initialized synchronously when loading test case modules to ensure the integrity of memory data during runtime; interrupt-level test case modules can also be supported, allowing test case modules to enable and respond to interrupts during runtime to verify complex timing logic such as interrupt nesting and real-time response; encryption and signature mechanisms can also be supported, encrypting or digitally signing test case modules before they are distributed, with the kernel stub verifying and decrypting the signature during loading to prevent test code from being stolen or tampered with, thus protecting intellectual property rights and test security.
[0061] Testing revealed that by deploying pre-compiled test case modules to volatile memory for execution, the average time from downloading to receiving the execution result for a single test case module was only 40 milliseconds, more than two orders of magnitude faster than the traditional JTAG full-chip programming method. Furthermore, the entire chip verification process requires no chip reset or Flash erasure, reducing the total testing time for thousands of test case modules to less than 40 minutes (compared to over 8 hours for traditional solutions), improving iteration efficiency by more than 10 times. CRC verification, exception handling, and automatic retransmission mechanisms ensure data transmission reliability and fault tolerance during execution. Moreover, the kernel stub occupies only about 3KB of storage resources, requires zero modification to the chip hardware, and can be directly deployed on ordinary evaluation boards. The CI plugin enables automatic test case traversal, one-click testing, and test report output, achieving unattended batch verification overnight. This disclosed embodiment possesses good versatility and is adaptable to multi-core architectures such as RISC-V, ARM-R, and TriCore, providing complete technical support for the efficient verification of complex SoCs such as automotive-grade chips.
[0062] Figure 2 This is a schematic diagram of a chip verification device provided in an embodiment of this disclosure. This chip verification device can be understood as a portion of the functional modules within the target chip described above. For example... Figure 2As shown, the chip verification device includes: The cache module 210 is used to receive a pre-compiled test case module sent by the host computer through the kernel stub, and cache the test case module in the volatile memory of the target chip; The handover module 220 is used to disable global interrupts in the kernel stub and transfer control of the processing module to the test case module after fully receiving the test case module. The execution module 230 is used to execute test logic through the test case module, and after execution is completed, return the control of the processing module to the kernel stub; The collection module 240 is used to re-enable interrupts through the kernel stubs and collect the execution results of the test case module. Feedback module 250 is used to return the execution result to the host computer through the kernel stub, so that when the execution result shows that the test case module has been executed successfully, the host computer will send out the pre-compiled next test case module; Return module 260 is used to return to the steps of receiving the pre-compiled test case module issued by the host computer and caching the test case module in the volatile memory of the target chip through the kernel stub, until all test case modules have been executed.
[0063] Optionally, the test case module includes address information and valid data, wherein the address information includes load address information, start execution address, and data length information; The cache module 210 includes a first cache submodule, which is used to cache the test case module into the volatile memory of the target chip. Specifically, it is used to write the valid data into the corresponding address area of the volatile memory according to the load address information. The handover module 220 includes a first handover submodule, which is used to hand over control of the processing module to the test case module. Specifically, it is used to determine whether the start execution address and the end execution address are within the effective address range of the volatile memory. If so, the function pointer is jumped to the start execution address. The end execution address is calculated based on the start execution address and the data length information.
[0064] Optionally, the execution module 230 includes a second handover submodule, which is used to return control of the processing module to the kernel stump after execution is completed. Specifically, it is used to set the processing module program counter to the start address of the kernel stump in non-volatile memory.
[0065] Optionally, the cache module 210 is specifically used to receive the data packet of the test case module sent by the host computer, and perform data verification on the data packet to obtain the first verification code; Compare the first checksum with the second checksum carried in the data packet; If the first check code and the second check code match, the data packet is cached in the volatile memory, and a successful reception response is sent back to the host computer, so that the host computer can send the next data packet. Return to the step of receiving data packets from the test case module sent by the host computer and performing data verification on the data packets to obtain the first verification code, until all data packets from the test case module have been received.
[0066] Optionally, the device further includes: a first retransmission module, used to send a reception failure response to the host computer through the kernel stub if the first check code and the second check code are inconsistent, so that the host computer retransmits the data packet until the data packet is successfully received or the number of retransmissions reaches a first preset upper limit value.
[0067] Optionally, the device further includes: a second retransmission module, used to receive the retransmission of the test case module from the host computer if the execution result indicates that the test case module has failed to execute, until the execution result includes successful execution of the test case module or the number of re-executions reaches a preset second upper limit value.
[0068] The apparatus provided in this embodiment can execute the methods of any of the above embodiments, and its execution method and beneficial effects are similar, so they will not be described again here.
[0069] This disclosure also provides an electronic device including a target chip. The electronic device includes, for example, a vehicle, a mobile phone, or a laptop. The electronic device provided in this embodiment can execute the methods of any of the above embodiments, and its execution method and beneficial effects are similar, so they will not be described again here.
[0070] This disclosure also provides a computer-readable storage medium storing a computer program. When the computer program is executed, it can implement the methods of any of the above embodiments. The execution method and beneficial effects are similar, and will not be described again here.
[0071] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0072] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A chip verification method, characterized in that, Applied to a target chip, the target chip including a kernel stump and a processing module, wherein the method includes: The kernel stub receives pre-compiled test case modules from the host computer and caches these test case modules in the volatile memory of the target chip. After fully receiving the test case module, the kernel stub is used to transfer control of the processing module to the test case module; The test case module executes the test logic, and after execution, the control of the processing module is returned to the kernel stub. The execution results of the test case module are collected through the kernel stubs; The execution result is returned to the host computer through the kernel stub, so that when the execution result shows that the test case module has been executed successfully, the host computer will send out the pre-compiled next test case module. The kernel stub returns to the step of receiving the pre-compiled test case module sent by the host computer and caching the test case module in the volatile memory of the target chip, until all test case modules have been executed.
2. The method according to claim 1, characterized in that, The test case module contains address information and valid data. The address information includes load address information, start execution address, and data length information. The step of caching the test case module in the volatile memory of the target chip includes: Based on the load address information, the valid data is written into the corresponding address region of the volatile memory.
3. The method according to claim 2, characterized in that, The step of transferring control of the processing module to the test case module includes: Determine whether the start execution address and end execution address are within the effective address range of the volatile memory. If so, jump the function pointer to the start execution address, wherein the end execution address is calculated based on the start execution address and the data length information.
4. The method according to claim 1, characterized in that, The step of returning control of the processing module to the kernel stub after execution includes: Set the processing module's program counter to the start address of the kernel stub in non-volatile memory.
5. The method according to claim 1, characterized in that, The step of receiving the pre-compiled test case module from the host computer and caching the test case module in the volatile memory of the target chip includes: Receive the data packet from the test case module sent by the host computer, and perform data verification on the data packet to obtain the first verification code; Compare the first checksum with the second checksum carried in the data packet; If the first check code and the second check code match, the data packet is cached in the volatile memory, and a successful reception response is sent back to the host computer, so that the host computer can send the next data packet. Return to the step of receiving data packets from the test case module sent by the host computer and performing data verification on the data packets to obtain the first verification code, until all data packets from the test case module have been received.
6. The method according to claim 5, characterized in that, Also includes: If the first checksum and the second checksum are inconsistent, the kernel stub sends a reception failure response to the host computer, so that the host computer retransmits the data packet until the data packet is successfully received or the number of retransmissions reaches a first preset upper limit.
7. The method according to claim 1, characterized in that, Also includes: If the execution result indicates that the test case module has failed to execute, the host computer will resend the test case module until the execution result indicates that the test case module has executed successfully, or the number of re-executions reaches a preset second upper limit value.
8. A chip verification device, characterized in that, Applied to a target chip, the target chip including a kernel stump and a processing module, wherein the device includes: The caching module is used to receive pre-compiled test case modules from the host computer through the kernel stub, and cache the test case modules in the volatile memory of the target chip. The handover module is used to transfer control of the processing module to the test case module through the kernel stub after fully receiving the test case module; The execution module is used to execute test logic through the test case module, and after execution is completed, return control of the processing module to the kernel stub; The collection module is used to collect the execution results of the test case module through the kernel stubs; The feedback module is used to return the execution result to the host computer through the kernel stub, so that when the execution result shows that the test case module has been executed successfully, the host computer will issue the next pre-compiled test case module. The return module is used to return to the steps of receiving the pre-compiled test case module issued by the host computer and caching the test case module in the volatile memory of the target chip through the kernel stub, until all test case modules have been executed.
9. An electronic device, characterized in that, The target chip includes any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1-7.