A chip verification method and device

Abstract

The present application provides a chip verification method and apparatus. The chip includes multiple CPUs, and the multiple CPUs include a main control CPU and at least one slave CPU. The main control CPU starts at least one slave CPU and obtains the entry address of the debug interface list. For each slave CPU among the at least one slave CPU, the entry address of the debug interface list is sent to the slave CPU, so that when the slave CPU runs the verification application program corresponding to the slave CPU, the verification application program obtains the absolute address of the debug application program interface function to be called from the debug interface list based on the entry address and the function identifier of the debug application program interface function to be called, and uses the obtained absolute address to call the corresponding debug application program interface function to verify the chip. Since each debug API function is not written into each debug API, the loading time and running time of the verification APP are saved, and further the time for verifying the chip using each verification APP is saved.

Description

Technical Field

[0001] This application relates to the field of integrated circuit technology, and particularly to a chip verification method and device. Background Art

[0002] Multi-core is the current trend in the development of CPU chips. Currently, mainstream CPU chip manufacturers support multi-core, heavy-core, and even super-heavy-core architectures, and the corresponding software operating systems (OS) will become more large and complex. During the development of CPU chips, a large number of verifications are required. On the verification platform, due to requirements for time and efficiency, it is impossible to run a large and complex operating system. A new program is needed to replace the OS as the verification software platform. A program running in a logical environment (Bare-Metal, BM) is a chip software verification platform solution widely used in the industry. This is mainly because its refined and fast startup characteristics can meet the verification requirements of the chip. In the BM verification platform, since there is no operating system to manage and schedule application programs (APP), a CPU (usually CPU numbered 0) can be used as the control CPU to control other CPUs to complete operations such as resource allocation, startup boot, and verification application program (Application, APP) loading and running.

[0003] Due to the limitations of the resources of the chip verification platform itself (low frequency and slow speed), even running the refined BM takes more than 10 minutes. Coupled with the time overhead brought by the operation of the verification application program (verification use case), the time consumption will be even longer. To further improve the verification efficiency and debuggability of the chip, on a multi-core CPU chip, each CPU runs different verification APPs or designates a certain CPU to run a specific verification APP to achieve the purpose of verifying the chip, so as to improve the verification speed and flexibility.

[0004] However, in the prior art, in order to improve the verification efficiency and save the verification time, generally, a method of adding a debug program library to each verification APP is adopted to reduce the verification complexity (time complexity and space complexity). However, this method will cause the verification APP to be too large in size, resulting in an extended loading time and running time of the verification application program, and thus a longer chip verification time.

[0005] Therefore, how to improve the verification efficiency of the chip and save the chip verification time is one of the technical problems worthy of consideration. Summary of the Invention

[0006] In view of this, this application provides a chip verification method and device to improve the verification efficiency of the chip and save the chip verification time.

[0007] Specifically, this application is implemented through the following technical solutions:

[0008] According to a first aspect of the present application, a chip verification method is provided. The chip includes multiple CPUs, and the multiple CPUs include a master CPU and at least one slave CPU. The method includes:

[0009] The master CPU starts the at least one slave CPU and obtains the entry address of a debug interface list, where the debug interface list includes the association relationship between the function identifier of a debug application programming interface function and the absolute address of the debug application programming interface function;

[0010] For each slave CPU among the at least one slave CPU, the entry address of the debug interface list is sent to the slave CPU, so that when the slave CPU runs the verification application corresponding to the slave CPU, the verification application obtains the absolute address of the debug application programming interface function to be called from the debug interface list based on the entry address and the function identifier of the debug application programming interface function to be called, and uses the obtained absolute address to call the corresponding debug application programming interface function to verify the chip.

[0011] According to a second aspect of the present application, a chip verification device is provided. The chip includes multiple CPUs, and the multiple CPUs include a master CPU and at least one slave CPU. The device includes:

[0012] A start module, configured to start the at least one slave CPU and obtain the entry address of a debug interface list, where the debug interface list includes the association relationship between the function identifier of a debug application programming interface function and the absolute address of the debug application programming interface function;

[0013] A sending module, configured to send the entry address of the debug interface list to each slave CPU among the at least one slave CPU, so that when the slave CPU runs the verification application corresponding to the slave CPU, the verification application obtains the absolute address of the debug application programming interface function to be called from the debug interface list based on the entry address and the function identifier of the debug application programming interface function to be called, and uses the obtained absolute address to call the corresponding debug application programming interface function to verify the chip.

[0014] According to a third aspect of the present application, an electronic device is provided, including a processor and a machine-readable storage medium. The machine-readable storage medium stores a computer program that can be executed by the processor, and the processor is caused by the computer program to execute the method provided in the first aspect of the embodiments of the present application.

[0015] According to a fourth aspect of the present application, there is provided a machine-readable storage medium storing a computer program which, when called and executed by a processor, causes the processor to execute the method provided in the first aspect of the embodiments of the present application.

[0016] Advantageous effects of the embodiments of the present application:

[0017] For the chip verification method and device provided by the embodiments of the present application, the main control CPU starts at least one of the slave CPUs and obtains the entry address of the debug interface list, where the debug interface list includes the association relationship between the function identifier of the debug application program interface function and the absolute address of the debug application program interface function; for each of the at least one slave CPU, the entry address of the debug interface list is sent to the slave CPU, so that when the slave CPU runs the verification application program corresponding to the slave CPU, the verification application program obtains the absolute address of the debug application program interface function to be called from the debug interface list based on the entry address and the function identifier of the debug application program interface function to be called, and uses the obtained absolute address to call the corresponding debug application program interface function to verify the chip. By adopting the above method, since the debug application program interface functions represented by the debug interface list are not in each verification application program, that is, each debug application program interface function is stored independently of the verification application program, when verifying the chip using the verification application program, compared with the method of adding a debug program library to each verification application program in the prior art, the method provided by the present application saves the loading and running time of the verification application program, thereby saving the chip verification time, that is, improving the chip verification efficiency. Description of the Drawings

[0018] Figure 1 is a schematic diagram of the logical architecture of chip verification shown in the embodiments of the present application;

[0019] Figure 2 is a flowchart of a chip verification method shown in the embodiments of the present application;

[0020] Figure 3a is a flowchart of a method for generating a debug interface list shown in the embodiments of the present application;

[0021] Figure 3b is a schematic diagram of the logical architecture for generating a debug interface list shown in the embodiments of the present application;

[0022] Figure 4 is a schematic diagram of an application scenario of a chip verification method shown in the embodiments of the present application;

[0023] Figure 5 is a block diagram of a chip verification device shown in the embodiments of the present application;

[0024] Figure 6 This is a schematic diagram of the hardware structure of an electronic device shown in an embodiment of the present application. Detailed implementation manners

[0025] Here, exemplary embodiments will be described in detail, and examples thereof are shown in the drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementation manners described in the following exemplary embodiments do not represent all implementation manners consistent with the present application. On the contrary, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0026] The terms used in the present application are for the purpose of describing specific embodiments only and are not intended to limit the present application. The singular forms "a", "the", and "said" used in the present application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more of the corresponding listed items.

[0027] It should be understood that although the terms first, second, third, etc. may be used in the present application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of the present application, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "when" or "while" or "in response to determining".

[0028] The inventor found that currently, when verifying a chip, generally, a debugging application programming interface function is stored in a debugging program library, referring to Figure 1As shown, the debugging program library is then written into each verification application (verification APP) respectively, and then packaged and compiled together with the verification application to obtain the executable file of the verification application. Then, the executable file of the verification application is used to verify the chip. During verification, the debugging application interface function in the debugging program library stored by itself is directly called to verify the functional logic of the chip. Considering chip verification, it is generally required that each verification APP reduces its own complexity as much as possible while ensuring the debugging function, such as time complexity and space complexity, etc. However, in the above scheme of the debugging program library in each verification APP, since the scale of the debugging program library is relatively large, it will inevitably occupy a large amount of storage space. In an actual scenario, the scale of the debugging program library after compilation can reach about 50 kByte, while the verification APP itself is only 30 kByte in size. In this case, the verification APP will be extremely large, resulting in code redundancy. If different verification APPs need to be run simultaneously on dozens or even thousands of CPU cores to verify the chip, due to the significant increase in the scale of the verification APP, the loading time and running time of the verification APP will be prolonged, and thus the chip verification will take a long time and the chip verification efficiency will be low.

[0029] The inventors also found that in the debugging program library, some debugging application interface functions need to frequently access a certain hardware resource (such as serial port uart / bus resource). When the debugging program library is added to each verification APP, it will cause each verification APP to include the interface function for accessing the hardware resource, and thus have the condition to access a certain hardware resource simultaneously. Since the verification APPs on each CPU exist independently, and the corresponding debugging program libraries also exist independently, there will be a situation where different verification APPs use the same debugging application interface function to access the same hardware resource, resulting in resource conflicts.

[0030] Based on the above problems, the present application provides a chip verification method for verifying a chip. The chip includes multiple CPUs, and the multiple CPUs include a master CPU and at least one slave CPU. The master CPU starts the at least one slave CPU and obtains the entry address of a debug interface list. Among them, the debug interface list includes the association relationship between the function identifier of the debug application program interface function and the absolute address of the debug application program interface function. For each slave CPU among the at least one slave CPU, the entry address of the debug interface list is sent to the slave CPU, so that when the slave CPU runs the verification application program corresponding to the slave CPU, the verification application program, based on the entry address and the function identifier of the debug application program interface function to be called, obtains the absolute address of the debug application program interface function to be called from the debug interface list, and uses the obtained absolute address to call the corresponding debug application program interface function to verify the chip. By adopting the above method, since each debug application program interface function represented by the debug interface list is not in each verification application program, that is, each debug application program interface function is independent of the verification application program. In this way, when verifying the chip using the verification application program, compared with the prior art method of adding a debug program library to each verification application program, the method provided by the present application saves the loading and running time of the verification application program, thereby saving the chip verification time, that is, improving the chip verification efficiency.

[0031] Optionally, the chip verification method provided by the present application is applied to a chip verification platform. The chip verification platform can be, but is not limited to, a chip verification platform based on the BM environment. Since the BM verification platform has no operating system to manage and schedule the verification APP and has a fast startup speed, implementing the chip verification method provided by the present application on the chip verification platform in the BM environment can further improve the chip verification speed.

[0032] The chip verification method provided by the present application will be described in detail below.

[0033] See Figure 2 , Figure 2 is a flowchart of a chip verification method shown in the present application. The chip belongs to a multi-core CPU, that is, the chip includes multiple CPUs. The multiple CPUs include a master CPU and at least one slave CPU. The method may include the following steps:

[0034] S201. The master CPU starts at least one slave CPU and obtains the entry address of the debug interface list.

[0035] Among them, the debug interface list provided by the present application includes the association relationship between the function identifier of the debug application program interface function and the absolute address of the debug application program interface function.

[0036] Specifically, taking the BM verification platform as an example of the verification platform for illustration, the BM main program is set on the main control CPU, and the main control CPU is used to control the operation of the BM main program and manage each slave CPU. In addition, verification application programs APP are respectively run on each slave CPU in this application. It should be noted that the functions of the verification APPs run on each slave CPU can be the same or different, and this application does not limit this. However, in practical applications, in order to be able to test various functions of the chip, verification APPs with different debugging and verification functions can be configured, and then different slave CPUs are made to run different verification APPs with different debugging and verification functions respectively, so as to achieve the debugging and verification of different functions on the chip.

[0037] When verifying a designed chip based on the chip verification platform, the main control CPU of the chip will start and run the BM main program on it. If it can run successfully, it indicates that the design of the main control CPU is okay. And generally, there will be no problem with the execution function of the main control CPU. If the BM main program fails to run successfully, it indicates that there is a problem with the design of the main control CPU, achieving the function verification of the main control CPU. When the main control CPU successfully runs the BM main program, the BM main program will perform the following operations: guide the startup of the main control CPU, execute some program migrations, and initialize the software resources and hardware resources required for the CPU to run (such as memory, bus, and stack, etc.). Program migration generally migrates the programs required in the verification process to the memory. For example, program migration mainly includes the specific implementation code of the debugging application program interface function, peripheral initialization, the driver of relevant hardware modules, and the migration of the BM verification platform software program, etc.

[0038] The designed chip in this application can be, but is not limited to, a chip designed based on the Verilog language and modeled through Register Transfer Level (RTL) and Synthesize.

[0039] After the BM main program runs, it will obtain the entry address of the debugging interface list, and then send the entry address to each slave CPU, and then each slave CPU runs the verification APPs with various functions to complete the verification of the chip.

[0040] Optionally, the above-mentioned debugging interface list is stored in the memory. The debugging interface list is generated based on the debugging application program interface (API) functions in the debugging program library, etc. Specifically, it can refer to Figure 3a the shown process, including the following steps:

[0041] S301. Obtain a debug library that stores various debug application programming interface (API) functions.

[0042] Specifically, when the BM main program runs, to facilitate the call of debug API functions, the debug API functions of various debug functions are pre-configured, and then the implementation codes of the debug API functions of various debug functions are stored in the debug library, so that the BM main program can obtain the above debug library.

[0043] S302. Compile and link the debug library to generate the absolute addresses of various debug application programming interface functions.

[0044] In this step, a compilation tool and a link processing tool can be called to compile and link the debug library, so as to obtain the absolute addresses of various debug API functions. The absolute address in this application is the address of the implementation code of the debug API function in the memory. It should be noted that when the verification platform is a verification platform in the BM environment, since the BM environment does not support the MMU, etc., the absolute addresses of various debug API functions in the memory need to be solidified.

[0045] S303. Establish an association relationship between the function identifiers and the absolute addresses of various debug application programming interface functions, and generate a debug interface list based on the association relationship.

[0046] In this step, since during the compilation process, generally a compilation file named after the function identifier will be generated for each debug API function, the function identifier of each debug API function can be obtained after compilation. Then, combined with the absolute address of each debug API function obtained by compilation and linking in step S302, by traversing the function identifiers and absolute addresses of each debug API function one by one, an association relationship between the function identifier of each debug API function and the absolute address of the debug API function can be established, and then stored in the debug interface list.

[0047] Optionally, based on any of the above embodiments, when compiling and linking the debug library, executable files of various debug application programming interface functions can also be generated; then, according to the absolute addresses of various debug application programming interface functions, the executable files of various debug application programming interface functions are respectively written to the corresponding positions in the memory.

[0048] Specifically, the code can only run after being compiled into a language that the machine can recognize. Therefore, it is necessary to compile the implementation code of the debugging API functions stored in the debugging program library into an executable file, and then write it into the memory. Specifically, when writing into the memory, the executable files of each debugging API function can be written into the storage space location corresponding to each absolute address in the memory according to the absolute address of each debugging API function. That is to say, even after being written into the memory, the absolute addresses of each debugging API function will not change. Specifically, when loading into the memory, the executable file can be loaded into the corresponding code segment and data segment in the memory. The executable file is stored in a fixed area in the memory to facilitate searching and calling.

[0049] Optionally, based on any of the above embodiments, the debugging interface list provided in the embodiments of the present application is a list in the form of a singly linked list. The above application program interface list includes multiple linked list nodes, and each linked list node includes a function identifier of a debugging application program interface function and the absolute address of the debugging application program interface function.

[0050] Specifically, for the convenience of querying, the BM main program on the main control CPU 0 will create a singly linked list including multiple linked list nodes, and then use this singly linked list specifically to store the association relationship between the function identifier of each debugging API function and the absolute address of the debugging API function. This singly linked list is the debugging interface list in the present application. Specifically, the number of the above multiple linked list nodes can be the number of debugging API functions included in the debugging program library. That is, each linked list node includes a function identifier of a debugging API function and the absolute address of the debugging API function, then this linked list node represents an association relationship, and multiple linked list nodes represent multiple association relationships.

[0051] Optionally, the function identifier of the debugging API function in any embodiment of the present application can be but is not limited to the function name.

[0052] For a better understanding of this embodiment, in combination with Figure 3b for illustration, Figure 3b is a logical schematic diagram of the formation of the debugging interface list, Figure 3b The debugging program library in includes M debugging API functions. The present application does not limit the number of debugging API functions, and the debugging API functions in the debugging program library can be dynamically updated, etc. The main program on the main control CPU can perform compilation and linking processing on the Figure 3b debugging program library in, so as to obtain executable files of M debugging API functions, and also refer to Figure 3bAs shown, then load M executable files into the memory. After compilation and linking, the absolute addresses of M debug API functions and the function names of the debug API functions are also generated. Then the main program creates a debug interface list in the format of a singly linked list. There are M linked list nodes in this list, namely node 1 to node M. Each linked list node points to the function name of a debug API function and the absolute address of this debug API function. For example Figure 3b in the linked list node 1 (node 1) points to the function name of debug API 1 and the absolute address of debug API 1, thus forming an association relationship between the function name and the absolute address of debug API 1.

[0053] S202. For each slave CPU among at least one slave CPU, send the entry address of the debug interface list to the slave CPU, so that when the slave CPU runs the verification application corresponding to the slave CPU, the verification application can obtain the absolute address of the debug application interface function to be called from the debug interface list based on the entry address and the function identifier of the debug application interface function to be called, and use the obtained absolute address to call the corresponding debug application interface function to verify the chip.

[0054] Specifically, when any slave CPU receives the entry address of the debug interface list sent by the master CPU, it will pass the entry address to the verification APP as a parameter when loading the verification APP on it. When the verification APP starts and runs, the verification APP on this slave CPU will obtain the absolute address corresponding to the function identifier of the debug API that needs to be accessed during the operation of the verification APP from the debug interface list based on the above entry address and the function identifier of the debug API function that the verification APP itself needs to access. Then, the executable file of the above debug API function is obtained from the memory through this absolute address, thereby achieving the verification of the chip during the operation of the verification APP. Since the implementation code of the debug API function in this application is stored in the memory and is stored independently of the verification APP, in this way, the loading time and running time are effectively saved when loading and running the verification APP, thereby saving the verification time of the chip and improving the verification efficiency of the chip.

[0055] Optionally, based on any of the above embodiments, the chip verification method provided in this application further includes:

[0056] When the debug application interface function called by the verification application on any slave CPU needs to operate on hardware resources, perform a locking operation on the debug application interface function; when the debug application interface function finishes running, perform an unlocking operation.

[0057] In specific implementation, since some debugging APIs involve operations on the hardware resources of the chip, in the verification platform, as multiple CPUs need to execute verification tasks simultaneously, there may be a situation where verification APPs on multiple CPUs need to call the same debugging API function to access the same hardware resources, which may cause resource conflicts. To avoid this problem, the present application proposes to add hardware resource protection. That is, when the debugging API function called by the verification APP on any slave CPU needs to operate on the hardware resources, a locking mechanism is executed. When the debugging API function finishes accessing the hardware resources, a lock release operation is executed. That is, when encapsulating each debugging API, spin lock protection is added when it comes to hardware operations. For example, when encapsulating the debugging print API, through the locking operation, the occurrence of deadlocks caused by resource competition can be avoided. By adopting the locking and lock release mechanisms, the access conflicts of hardware resources are effectively avoided.

[0058] To better understand the chip verification method provided by the present application, taking the verification scenario of the chip shown in Figure 4 as an example for description. The chip includes CPUs 0 to N, where CPU 0 is the main control CPU, and CPUs 1 to N are N slave CPUs. Then, N verification APPs with different debugging and verification functions are configured so that the N verification APPs with different debugging functions run on CPUs 1 to N respectively. Since the verification chip is a multi-core CPU, generally, the BM main program is fixed to run on CPU 0, and CPU 0 is defaulted as the main control CPU. At startup, it also starts from CPU 0 by default. Then CPU 0 starts to run the BM main program. After initialization, the BM main program on CPU 0 configures the resources required for the operation of CPUs 1 to N, and then sequentially boots CPUs 1 to N. Then, the entry address of the debugging interface list is sent to CPUs 1 to N so that CPUs 1 to N run the verification APPs on them respectively, thereby completing the verification of the chip functions. Specifically, taking CPU 1 as an example for description, when CPU 1 obtains the entry address of the debugging interface list, when loading the verification APP on it, the entry address will be passed as a parameter to the verification APP. In this way, the verification APP can find the Figure 4 debugging interface list in it. The verification APP itself knows the function identifier of the debugging API function that needs to be called. Therefore, based on the above list and the function identifier known by itself, the absolute address of the debugging API function that needs to be called is found from the list, and then the executable file of the debugging API function that needs to be called is obtained from the memory, so as to realize the operation of the verification APP, and further achieve the verification of the chip.

[0059] For example, in a multi-core chip including N CPUs, the external memory space for storing the verification APP (APP including a debugging library) using the existing technology is K, the average size of the verification APP is a, and the size of the debugging library is b. When implementing the call of the debugging API function based on the debugging interface list according to the chip verification method provided in this application, the size of the generated debugging interface list and related content is c, and c is much smaller than b. In this way, if the verification APP is moved from the external memory space to the memory at a rate of v, the required external memory space is only L = N * a + b, and the moving time T = L / v, which occupies (N - 1) * b less external memory space than the existing technology. Similarly, the moving time will also be reduced by (N - 1) * b / v. In addition, in a superheavy-core CPU architecture, such as a CPU chip with more than 1000 CPUs, when the size K of the external memory space is fixed, since the debugging library of this application is not written into each verification APP, the number of verification APPs with other functions can be increased, thus achieving a comprehensive verification of the chip. In addition, by providing a debugging interface list in this application, the complexity and workload of chip design are reduced, and the scalability of the debugging API interface is improved.

[0060] By implementing the chip verification method provided in this application, since each debugging API function is not written into each debugging API, the loading time and running time of the verification APP are saved, and thus the time for verifying the chip using each verification APP is saved, which improves the verification efficiency of the chip.

[0061] Based on the same inventive concept, this application also provides a chip verification device. The implementation of the chip verification device can specifically refer to the above description of the chip verification method, and will not be elaborated here one by one.

[0062] See Figure 5 , Figure 5 is a chip verification device shown in an exemplary embodiment of this application. The chip includes multiple CPUs, the multiple CPUs include a main control CPU and at least one slave CPU, and the above chip verification device includes:

[0063] A start module 501, configured to start the at least one slave CPU and obtain the entry address of the debugging interface list, where the debugging interface list includes the association relationship between the function identifier of the debugging application program interface function and the absolute address of the debugging application program interface function;

[0064] A sending module 502, configured to send the entry address of the debug interface list to each of the at least one slave CPU, so that when the slave CPU runs the verification application corresponding to the slave CPU, the verification application obtains the absolute address of the debug application interface function to be called from the debug interface list based on the entry address and the function identifier of the debug application interface function to be called, and uses the obtained absolute address to call the corresponding debug application interface function to verify the chip.

[0065] Optionally, the chip verification device provided in the embodiment of the present application further includes: an acquisition module 503, a generation module 504, and an association relationship creation module 505. Please also refer to Figure 5 as shown, where:

[0066] The acquisition module 503 is configured to acquire a debug program library storing various debug application interface functions;

[0067] The generation module 504 is configured to perform compilation and linking processing on the debug program library to generate the absolute addresses of various debug application interface functions;

[0068] The association relationship establishment module 505 is configured to establish an association relationship between the function identifiers and the absolute addresses of various debug application interface functions, and generate the debug interface list based on the association relationship.

[0069] Based on any of the above embodiments, the chip verification device provided in the present application further includes a writing module 506. Please also refer to Figure 5 as shown, where:

[0070] The above-mentioned generation module 504 is further configured to perform compilation and linking processing on the debug program library to generate executable files of various debug application interface functions;

[0071] The above-mentioned writing module 506 is configured to write the executable files of various debug application interface functions to corresponding positions in the memory according to the absolute addresses of various debug application interface functions.

[0072] Based on any of the above embodiments, the debug interface list provided in this embodiment is a list in the form of a singly linked list. The application interface list includes multiple list nodes, and each list node includes a function identifier of a debug application interface function and the absolute address of the debug application interface function.

[0073] Based on any of the above embodiments, the chip verification device provided in this embodiment further includes: a locking module 507 and a lock release module 508. Please also refer to Figure 5 as shown, where:

[0074] A locking module 507 is configured to perform a locking operation on the debug application programming interface (API) function when the debug API function called by the verification application on any slave CPU needs to operate on hardware resources.

[0075] A lock release module 508 is configured to perform a lock release operation when the debug API function finishes running.

[0076] Based on the same inventive concept, an embodiment of the present application provides an electronic device, as Figure 6 shown, including a processor 601 and a machine-readable storage medium 602. The machine-readable storage medium 602 stores machine-executable instructions that can be executed by the processor 601. The processor 601 is prompted by the machine-executable instructions to execute the chip verification method provided by the embodiment of the present application. Optionally, the above-mentioned electronic device may be a network device such as a computer.

[0077] The above-mentioned computer-readable storage medium may include RAM (Random Access Memory), and may also include NVM (Non-volatile Memory), such as at least one disk memory. Optionally, the computer-readable storage medium may also be at least one storage device located far from the aforementioned processor.

[0078] The above-mentioned processor may be a general-purpose processor, including a CPU (Central Processing Unit), an NP (Network Processor), etc.; it may also be a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0079] In addition, an embodiment of the present application provides a machine-readable storage medium. The machine-readable storage medium stores a computer program, which, when called and executed by a processor, prompts the processor to execute the chip verification method provided by the embodiment of the present application.

[0080] For the embodiments of the electronic device and the machine-readable storage medium, since the method content involved is basically similar to that of the foregoing method embodiments, the description is relatively simple. For related parts, refer to the partial description of the method embodiments.

[0081] It should be noted that in this document, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variant thereof are intended to cover non-exclusive inclusion, such that a process, method, article or device comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, article or device comprising said element.

[0082] For the implementation processes of the functions and roles of each unit in the above device, please refer to the implementation processes of the corresponding steps in the above method for details, which will not be elaborated here.

[0083] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the descriptions of the method embodiments. The device embodiments described above are only illustrative. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this application. Those of ordinary skill in the art can understand and implement it without creative efforts.

[0084] The above are only the preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of this application shall be included within the scope of protection of this application.

Claims

1. A chip verification method, characterized in that, The chip includes multiple CPUs, the multiple CPUs include a master CPU and at least one slave CPU, and the method includes: The master CPU starts the at least one slave CPU and obtains the entry address of the debug interface list, wherein the debug interface list includes the association relationship between the function identifier of the debug application interface function and the absolute address of the debug application interface function, and each debug application interface function is stored independently from the verification application; For each slave CPU among the at least one slave CPU, the entry address of the debug interface list is sent to the slave CPU, so that when the verification application corresponding to the slave CPU runs, the verification application obtains the absolute address of the debug application interface function to be called from the debug interface list based on the entry address and the function identifier of the debug application interface function to be called, and uses the obtained absolute address to call the corresponding debug application interface function to verify the chip.

2. The method according to claim 1, wherein The debug interface list is generated by the following method: Obtain the debug program library storing each debug application interface function; Perform compilation and linking processing on the debug program library to generate the absolute address of each debug application interface function; Establish the association relationship between the function identifier and the absolute address of each debug application interface function, and generate the debug interface list based on the association relationship.

3. The method according to claim 2, characterized in that, It further includes: Perform compilation and linking processing on the debug program library to generate the executable file of each debug application interface function; According to the absolute address of each debug application interface function, write the executable file of each debug application interface function into the corresponding position in the memory respectively.

4. The method according to claim 1, wherein The debug interface list is a list in the form of a singly linked list, and the application interface list includes multiple list nodes, and each list node includes the function identifier of a debug application interface function and the absolute address of the debug application interface function.

5. The method according to claim 1, wherein It further includes: When the debug application interface function called by the verification application on any slave CPU needs to operate on the hardware resources, perform a locking operation on the debug application interface function; When the debug application interface function finishes running, perform an unlock operation.

6. A chip verification device, characterized in that, The chip includes multiple CPUs, the multiple CPUs include a master CPU and at least one slave CPU, and the device includes: A startup module, configured to start the at least one slave CPU and obtain the entry address of the debug interface list, wherein the debug interface list includes the association relationship between the function identifier of the debug application interface function and the absolute address of the debug application interface function, and each debug application interface function is stored independently from the verification application; A sending module, configured to send the entry address of the debugging interface list to each of the at least one slave CPU, so that when the slave CPU runs the verification application corresponding to the slave CPU, the verification application obtains the absolute address of the debugging application interface function to be called from the debugging interface list based on the entry address and the function identifier of the debugging application interface function to be called, and uses the obtained absolute address to call the corresponding debugging application interface function to verify the chip.

7. The device according to claim 6, characterized in that, It further includes: An obtaining module, configured to obtain a debug program library storing various debugging application interface functions; A generating module, configured to perform compilation and linking processing on the debug program library to generate the absolute addresses of various debugging application interface functions; An association relationship establishing module, configured to establish an association relationship between the function identifiers and the absolute addresses of various debugging application interface functions, and generate the debugging interface list based on the association relationship.

8. The device according to claim 7, characterized in that, It further includes: A writing module, where: The generating module is further configured to perform compilation and linking processing on the debug program library to generate executable files of various debugging application interface functions; The writing module is configured to write the executable files of various debugging application interface functions to corresponding positions in the memory according to the absolute addresses of various debugging application interface functions.

9. The device according to claim 6, characterized in that, The debugging interface list is a list in the form of a singly linked list, and the application interface list includes multiple list nodes, and each list node includes a function identifier of a debugging application interface function and the absolute address of the debugging application interface function.

10. The device according to claim 6, characterized in that It further includes: A locking module, configured to perform a locking operation on the debugging application interface function when the debugging application interface function called by the verification application on any slave CPU needs to operate on hardware resources; A lock releasing module, configured to perform a lock releasing operation when the debugging application interface function finishes running.

Images