Hardware verification method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a hardware verification method and device, electronic equipment and a storage medium, and relates to the technical field of hardware verification. The method comprises the following steps: compiling a to-be-verified hardware module into a first dynamic library; in the in-heap space of the process, creating the first dynamic library as a plurality of isolated objects; starting a verification program corresponding to the to-be-verified hardware module; creating a plurality of threads in the process; and matching a thread and an object for the verification case, and running the thread to perform hardware verification. According to the method and the device, one hardware module in the in-heap space of the process is instantiated into multiple objects, on one hand, the same hardware module can be accessed by different threads at the same time, that is, parallel hardware verification is realized by adopting multiple threads in one process, the hardware verification efficiency is higher, the utilization rate of computing resources is higher, and the hardware verification efficiency is improved. Waste of computing resources is avoided; on the other hand, verification cases can be flexibly combined, and the flexibility of hardware verification is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of hardware verification, and in particular to a hardware verification method, a hardware verification device, an electronic device and a storage medium. Background Art

[0002] Hardware verification refers to the method of verifying that a hardware design works as expected. In this process, a hardware design (usually a circuit, chip, or processor design) can be simulated through computer simulation software to detect potential errors and verify the functionality, performance, and correctness of the design. Simulation tools help engineers discover design problems and debug them by simulating the behavior of hardware under different conditions.

[0003] At present, during the hardware verification process, the solution for parallel hardware verification is to start multiple verification processes at the same time. In this case, the verification program can only start hardware verification through inter-process communication. Cross-process communication leads to low operating efficiency, and starting multiple processes brings waste of computing resources. Summary of the invention

[0004] In view of the above problems, an embodiment of the present invention is proposed to provide a hardware verification method that overcomes the above problems or at least partially solves the above problems, so as to improve the efficiency of hardware verification and avoid wasting computing resources.

[0005] In a first aspect, the present invention provides a hardware verification method, comprising: Compile the hardware module to be verified into a first dynamic library; In the heap space of the process, the first dynamic library is created as a plurality of isolated objects; Starting a verification program corresponding to the hardware module to be verified; the verification program includes: a verification use case; creating a plurality of threads in the process; The thread and the object are matched for the verification case, and the thread is run to perform hardware verification.

[0006] In a second aspect, the present invention provides a hardware verification device, comprising: A compiling module, used for compiling the hardware module to be verified into a first dynamic library; An object creation module, used to create the first dynamic library as a plurality of isolated objects in the heap space of the process; A startup module, used to start the verification program corresponding to the hardware module to be verified; the verification program includes: a verification case; A thread creation module, used for creating multiple threads in the process; The verification module is used to match the thread and the object for the verification case and run the thread to perform hardware verification.

[0007] In a third aspect, the present invention provides an electronic device, comprising: a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-mentioned hardware verification method when executing the program.

[0008] In a fourth aspect, the present invention provides a readable storage medium, which, when instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to execute the above-mentioned hardware verification method.

[0009] In a fifth aspect, the present invention provides a computer program product, comprising instructions, which, when executed by a processor in an electronic device, enable the electronic device to execute any one of the aforementioned hardware verification methods.

[0010] The present invention includes at least the following advantages: In the present invention, the hardware module to be verified is compiled into a first dynamic library, the first dynamic library is created as multiple isolated objects, and the multiple isolated objects are stored in the heap space of the process, which is equivalent to instantiating multiple objects of a hardware module in the heap space of the process. On the one hand, it is achieved that the same hardware module can be accessed by different threads at the same time, that is, parallel hardware verification is achieved by using multiple threads in a process. Since the heap space of the process is shared, the communication efficiency between the threads in the process is higher, that is, the efficiency of hardware verification is higher, and the utilization rate of computing resources is higher, thereby avoiding the waste of computing resources. On the other hand, since the heap space of the process is shared, objects can be flexibly assigned to a thread, and verification use cases are not isolated from each other, so verification use cases can be flexibly combined, thereby improving the flexibility of hardware verification. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0012] Figure 1 A flowchart showing a hardware verification method embodiment of the present invention is shown; Figure 2 A flowchart showing another embodiment of a hardware verification method of the present invention is shown; Figure 3 A structural block diagram of an embodiment of a hardware verification device of the present invention is shown; Figure 4 It is a structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0013] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0014] This application provides a hardware verification method, referring to Figure 1 , the hardware verification method may specifically include the following steps.

[0015] Step 101: compile the hardware module to be verified into a first dynamic library.

[0016] The hardware module here may include: actual hardware devices, or simulate the hardware design through computer software, the purpose of which is to verify the correctness of the hardware function, performance and timing. The simulation here allows the hardware circuit or system to be tested through simulation tools without actual hardware, helping to discover potential design problems. Hardware simulation usually uses hardware description language to write the design, and uses simulation software to run the test, simulate various working environments and input conditions, and ensure that the design meets the expected functional requirements. This step 101 may refer to: compiling the hardware module to be simulated into a first dynamic library through hardware simulation.

[0017] The first dynamic library here can be one or more. Generally, one hardware module is compiled into one dynamic library, or multiple hardware modules can be compiled into one dynamic library. After multiple hardware modules are compiled into one dynamic library, these multiple hardware modules can be regarded as one hardware module. The hardware module can be one or more.

[0018] The dynamic library (also called shared library, shared object) mentioned in this application is a library file that is loaded and linked when the verification program is running. Unlike static libraries, which are embedded into the executable file when the program is compiled, dynamic libraries exist independently of the verification program and are loaded by the dynamic linker of the operating system when the verification program is running. The dynamic linker here refers to the system component responsible for loading and linking dynamic libraries when the verification program is running. The dynamic linker resolves symbolic dependencies and connects the verification program with the shared libraries it requires, thereby supporting code reuse, memory saving, and modular design.

[0019] Step 102: Create the first dynamic library as multiple isolated objects in the heap space of the process.

[0020] The purpose of step 102 is mainly to instantiate multiple objects of a hardware module in the heap space of the process, so that the same hardware module can be accessed by different threads at the same time without interfering with each other. That is to say, for the same first dynamic library, they do not interfere with each other, so that parallel hardware verification can be implemented using multiple threads in a process.

[0021] In this application, a process refers to an instance of program execution in an operating system and is the basic unit of resource allocation and scheduling. Each process has independent memory space and system resources.

[0022] Here, in the heap space of the process, the first dynamic library is created as multiple isolated objects. The objects can be isolated by address space or by naming, and there is no specific limitation on this.

[0023] Optionally, the aforementioned step 102 may include steps 1021 to 1022. Step 1021, in the constructor, according to the isolation characteristics of the memory namespace, load the first dynamic library into different address spaces of the heap space; step 1022, in the different address spaces of the heap space, instantiate the first dynamic library into multiple objects. Here, steps 1021 to 1022 isolate objects by address space. Specifically, a package compatibility layer can be constructed, for example, a software class (Class) wrapper is constructed, and in the constructor of the class, the first dynamic library is loaded into different address spaces in the heap space of the process according to the isolation characteristics of the memory namespace, and the dynamic library with the same symbol is loaded into different address spaces in the heap space of the process, so that the same first dynamic library (hardware module) can be instantiated multiple times, so that these hardware modules can be accessed by different threads at the same time, thereby achieving the requirement of multi-instance parallel hardware verification without the need for multiple processes, and only using multiple threads.

[0024] It should be noted that when the operating system is Linux, due to the limitation of the current Glibc (C runtime or C standard) library, only 16 conflicting dynamic libraries can be instantiated for the same dynamic library. This can be achieved by modifying the underlying Glibc library of the Linux operating system, and instantiating more conflicting dynamic libraries for the same dynamic library. Glibc is an open source C standard library that provides basic functions required for program operation, including input and output, memory management, string processing, mathematical operations, process management, file operations, etc. It is one of the core components of the Linux operating system, and almost all C programs rely on the interface it provides. Glibc not only implements the C language standard library functions, but also includes related functions such as threads and networks.

[0025] In this application, the aforementioned memory namespace refers to the logical organization of the memory area allocated by the operating system to a process or thread, which is used to identify and access specific memory resources. It can provide an abstract representation of physical memory or virtual memory in the form of variable names, addresses, or handles. In this application, the memory namespace specifically refers to an independent loading space created by the dynamic linker, which is used to isolate the symbol resolution and loading behaviors of different first dynamic libraries. By creating an independent namespace for each first dynamic library, symbol conflicts are avoided and the simultaneous loading of multiple versions of the first dynamic library is supported.

[0026] In this application, the aforementioned address space refers to the memory address range allocated to the program in the computer system for storing instructions and data. Each process has an independent address space, which usually includes code segment, data segment, heap and stack areas to ensure memory isolation and security between processes.

[0027] In this application, the aforementioned constructor is a special function that is automatically called when an object is created to initialize the state of the object or allocate resources. In object-oriented programming, the main function of the constructor is to ensure that the object enters a valid state when it is created. The constructor usually has the same name as the class and does not return any value.

[0028] Optionally, the aforementioned step 102 may include steps 1023 to 1025. Step 1023, using a binary modification method, modify the first dynamic library to obtain multiple second dynamic libraries; step 1024, load the multiple second dynamic libraries into the heap space; step 1025, in the heap space, instantiate the second dynamic library into multiple objects. Here, steps 1023 to 1025 are to isolate objects by naming. Specifically, binary modification (BinaryPatching) refers to directly modifying the binary file of the first dynamic library to change its behavior or fix problems, which can be used to patch, modify functions or bypass certain restrictions. More specifically, the binary symbol table in the binary file of the first dynamic library can be modified so that they do not produce symbol conflicts. It should be noted that after the binary modification is completed here, although the functions are almost the same, due to the difference in the symbol table (for example, it can be a function name), if these modifications are applied during loading, the modification operation needs to be performed on site, and this operation will take a long time, because the entire first dynamic library needs to be scanned word by word and modified, so the operating efficiency may be poor. In other words, compared with the aforementioned step 1021 to step 1022, the operation efficiency of step 1023 to step 1025 here may be slightly lower.

[0029] Step 103: Start a verification program corresponding to the hardware module to be verified; the verification program includes: a verification use case.

[0030] There is no specific limit on the number of verification cases in the verification program. The verification program here refers to the entire verification framework, and the verification cases are to verify whether the various functions of the hardware module are correct. For example, to verify the addition, multiplication, and division of the hardware module, the entire program that tests these functions is called a verification program. Here, an addition is a verification case, a subtraction is a verification case, a multiplication is a verification case, and a division is also a verification case.

[0031] Step 104: Create multiple threads in the process.

[0032] A thread is an execution unit within a process and the basic unit of processor scheduling. Threads within the same process share the resources of the process but execute independently, which can improve the concurrency and efficiency of the verification program. There is no limit on the number of threads within a process.

[0033] Step 105: Match the thread and the object for the verification case, and run the thread to perform hardware verification.

[0034] The thread here is the running resource, and the object is the verification resource. The matching here means that there is a matching relationship between which hardware module needs to perform which verification cases. Usually, a hardware module may only be able to perform one verification case at the same time. Here, it can be an object or hardware module that needs to perform the verification case for verification case matching, has not yet run the verification case, and is idle at the moment. The thread here can also be an idle thread at the moment.

[0035] In the present invention, the hardware module to be verified is compiled into a first dynamic library, the first dynamic library is created as multiple isolated objects, and the multiple isolated objects are stored in the heap space of the process, which is equivalent to instantiating multiple objects of a hardware module in the heap space of the process. On the one hand, it is realized that the same hardware module can be accessed by different threads at the same time, that is, parallel hardware verification is realized by using multiple threads in a process. Since the heap space of the process is shared, the communication efficiency between the threads in the process is higher, that is, the efficiency of hardware verification is higher, and the utilization rate of computing resources is higher, thereby avoiding the waste of computing resources. On the other hand, since the heap space of the process is shared, objects can be flexibly assigned to a thread, and verification use cases will not be isolated from each other. Verification use cases can be flexibly combined, thereby improving the flexibility of hardware verification.

[0036] The computing resources mentioned in this application may refer to the hardware and software resources required in the execution of computing tasks, including processors (CPU, central processing unit / GPU, graphics processing unit), memory (RAM), storage space, network bandwidth, etc., which are used to support data processing and program execution.

[0037] Optionally, the aforementioned step 105 may include: step 1051, allocating a preset number of threads and a preset number of objects to the verification case at the same time, and running the preset number of threads in parallel to perform hardware verification; the preset number is a natural number greater than 1. Specifically, the preset number here is not limited, for example, it can be 2, 4, 8, 16, 32, etc. This application significantly improves the efficiency of hardware verification by running multiple threads in parallel. That is, an object cannot be reused at the same time, but a verification case can hold multiple objects at the same time, then multiple objects all run the same verification case at the same time, and the running results of the multiple objects for the same verification case can be quickly obtained. That is, this application can be repeatedly instantiated, allowing users to arbitrarily expand the scale of verified objects without repeatedly compiling hardware simulation designs, thereby improving the efficiency of hardware verification, and can also be combined.

[0038] For example, if object A, object B, and object C all need to run verification case 1, then object A, object B, and object C can run verification case 1 in parallel, and the running results of object A, object B, and object C on verification case 1 can be quickly obtained.

[0039] Optionally, after the aforementioned step 105, the method may further include: obtaining the running result of the verification case, and storing the running result in the heap space of the process. Specifically, the running result of the verification case is output in the heap space of the process, and the heap space of the process is shared. Later, it is only necessary to copy these data to the storage area or other memory space in the process to retain the details. This copying process can be done in the operating system through the page table Copy On Write technology, without actually copying the physical page. Compared with other verification frameworks that transmit across processes and need to copy physical pages or even write to disk, this application collects running results faster.

[0040] Optionally, the aforementioned step 104 may include: constructing a thread pool in the heap space of the process, and the thread pool includes: multiple threads. The number of threads contained in a thread pool is not limited. After the aforementioned step 105, the method may also include: recycling the thread to the thread pool after the thread has finished running. Specifically, due to the sharing of the heap space of the process, after the thread has finished running, the thread can be recycled to the thread pool without destroying the thread first, and the thread that is subsequently matched to the verification use case is an idle thread selected from the thread pool. The thread pool realizes thread reuse without repeated destruction and repeated creation, saving the overhead of frequent creation and destruction of threads, as well as the overhead of frequent application and release of running resources. These threads have always existed in the heap space before the verification program is executed, which can improve the efficiency of hardware verification. It should be noted that the present application can destroy all threads in the thread pool created for the verification program after the entire verification program is executed to release resources.

[0041] Figure 2 FIG. 1 is a flowchart showing another embodiment of a hardware verification method of the present invention. Figure 2 , the hardware verification method may specifically include the following steps.

[0042] Step 201: compile the hardware module to be verified into a first dynamic library.

[0043] Step 202: Create the first dynamic library as multiple isolated objects in the heap space of the process.

[0044] Step 203: start the verification program corresponding to the hardware module to be verified; the verification program includes: verification use cases; Step 204: creating multiple threads in the process; Steps 201 to 204 may refer to the aforementioned steps 101 to 104 , and will not be described again here to avoid repetition.

[0045] Step 205: Combine the multiple verification cases in the verification program to obtain a combined verification case that has an execution order and shares the same object.

[0046] Verification cases usually need to be matched to objects or hardware modules. Here, for some interdependent relationships in the entire verification program, or the starting state of an object or hardware module in a subsequent verification case, it is necessary to use the state of the object or hardware module after the previous verification case is executed. In this case, the previous verification case and the subsequent verification case are combined, and the execution order after the combination is to execute the previous verification case first, followed by the subsequent verification case. By analogy, the verification cases in the verification program that share the same object and have the aforementioned interdependent relationships can be combined to obtain a combined verification case with an execution order and sharing the same object.

[0047] Step 206: construct an object pool in the heap space of the process.

[0048] Object Pool is a design pattern for managing objects. It avoids the overhead of frequent creation and destruction of objects by maintaining a collection of pre-created and reused objects. Object pools are usually used in scenarios where resources need to be frequently allocated and released, such as database connections, network connections, thread pools, etc. Object pools can improve system performance and reduce memory and resource consumption. Since the heap space of a process can be shared, the overhead of repeatedly creating and destroying objects is reduced by building an object pool. Before the entire verification program is executed, each object does not need to be destroyed. Objects can be divided into objects in use and idle objects. In the process of matching objects for verification use cases, matching is mainly performed from idle objects.

[0049] Step 207: Match the thread and the same object for the previous verification case in the combined verification case, and run the thread so that the same object is in a first state.

[0050] The previous verification case in the combined verification case referred to here specifically refers to any verification case in the combined verification case except the last verification case. Each verification case in the entire combined verification case shares the same object. Therefore, here the same object is matched to the previous verification case, and after matching the thread to the previous verification case, the thread is executed. During the execution of the thread, the state of the same object is usually changed. The first state here refers to the state of the same object at the moment when the thread is executed.

[0051] Step 208: Recycle the same object in the first state into the object pool.

[0052] Since the first state of the same object is retained in the process of recycling the same object to the object pool, the first object in the first state here is the initial state of the same object matched by the next verification case adjacent to the previous verification case in the combined verification case. Before the next verification case runs, there is no need to re-process the same object, so that the same object is in the first state, thereby facilitating the running of the next verification case and improving the efficiency of hardware verification. At the same time, verification cases can be flexibly combined to improve the flexibility of hardware verification.

[0053] Step 209: match the thread for the next verification case that is adjacent to the previous verification case in the combined verification case in the execution order, match the same object in the first state for the next verification case from the object pool, and run the thread to perform hardware verification.

[0054] Since the initial state of the same object matched by the next verification case adjacent to the previous verification case in the combined verification case is the first state, the same object in the first state is matched for the next verification case from the object pool, and a thread is matched for the next verification case, and the thread is run to perform hardware verification.

[0055] For example, in the entire verification program, for object A, verification case 1, verification case 2, verification case 3 and verification case 4 need to be executed, and the execution of verification case 1 needs to match the original state of object A, the execution of verification case 2 needs to match the first state of object A after executing verification case 1, the execution of verification case 3 needs to match the first state of object A after executing verification case 2, the execution of verification case 3 needs to match the first state of object A after executing verification case 2, the execution of verification case 4 needs to match the first state of object A after executing verification case 3, then, verification case 1, verification case 2, verification case 3 and verification case 4 can be combined into a combined verification case, and the execution order of the combined verification case is: first verification case 1, then verification case 2, then verification case 3 and finally verification case 4. After verification case 1 is executed, Object A does not need to reset its state, but is directly recycled into the object pool in the first state after executing verification case 1, and runs verification case 2 in the first state after executing verification case 1. After verification case 2 is executed, object A does not need to reset its state, but is directly recycled into the object pool in the first state after executing verification case 2, and runs verification case 3 in the first state after executing verification case 2. After verification case 3 is executed, object A does not need to reset its state, but is directly recycled into the object pool in the first state after executing verification case 3, and runs verification case 4 in the first state after executing verification case 3. Before executing verification cases 2, 3 and 4, no processing is required on object A, so that the same object is in the corresponding first state, thereby facilitating the operation of the subsequent verification case and improving the efficiency of hardware verification.

[0056] It should be noted that the initial state of the same object matched by the previous verification case here may also depend on the state of the previous verification case in the combined verification case after the thread execution is completed. In this case, the previous verification case here is the latter verification case relative to the previous verification case in the combined verification case, and the same applies to the aforementioned steps 207 to 209. Alternatively, if the initial state of the same object matched by the previous verification case here is the original state of the same object, then the previous verification case in the combined verification case resets the state of the same object after the thread execution is completed, so that the same object is restored to its original state. In this application, all of the above situations are supported.

[0057] In the present application, through the aforementioned improvements, on the one hand, the same hardware module can be accessed by different threads at the same time, which improves the efficiency of hardware verification and the utilization rate of computing resources and avoids the waste of computing resources; on the other hand, due to the sharing of the in-heap space of the process, objects can be flexibly assigned to a thread, and verification cases will not be isolated from each other, so verification cases can be flexibly combined, which improves the flexibility of hardware verification.

[0058] It should be noted that, for the sake of simplicity, the method embodiments are described as a series of action combinations, but those skilled in the art should be aware that the embodiments of the present invention are not limited by the order of the actions described, because according to the embodiments of the present invention, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of the present invention.

[0059] Reference Figure 3 , Figure 3 A structural block diagram of an embodiment of a hardware verification device of the present invention is shown, and the device may specifically include the following modules: a compilation module 301, used to compile the hardware module to be verified into a first dynamic library; an object creation module 302, used to create the first dynamic library into multiple isolated objects in the heap space of the process; a startup module 303, used to start the verification program corresponding to the hardware module to be verified; the verification program includes: a verification case; a thread creation module 304, used to create multiple threads in the process; a verification module 305, used to match the thread and the object for the verification case, and run the thread to perform hardware verification.

[0060] Optionally, the object creation module 302 includes: A first loading submodule, used to load the first dynamic library into different address spaces of the heap space according to the isolation characteristics of the memory namespace in the constructor; The first instantiation submodule is used to instantiate the first dynamic library into multiple objects in different address spaces of the heap space.

[0061] Optionally, the object creation module 302 includes: A modification submodule, used to modify the first dynamic library by using a binary modification method to obtain a plurality of second dynamic libraries; A second loading submodule, configured to load the plurality of second dynamic libraries into the in-heap space; The second instantiation submodule is used to instantiate the second dynamic library into multiple objects in the heap space.

[0062] Optionally, the device further comprises: A combination module, used for combining a plurality of the verification cases in the verification program to obtain a combined verification case having an execution order and sharing the same object; An object pool construction module, used to construct an object pool in the heap space of the process; The verification module 305 includes: A first running submodule, configured to match the thread and the same object for a previous verification case in the combined verification case, and to run the thread so that the same object is in a first state; A recycling submodule, used for recycling the same object in the first state into the object pool; The first verification submodule is used to match the thread for the subsequent verification case that is adjacent to the previous verification case in the combined verification case in accordance with the execution order, match the same object in the first state for the subsequent verification case from the object pool, and run the thread to perform hardware verification.

[0063] Optionally, the verification module 305 includes: The second verification submodule is used to simultaneously allocate a preset number of the threads and the preset number of the objects to the verification case, and run the preset number of the threads in parallel to perform hardware verification; the preset number is a natural number greater than 1.

[0064] Optionally, the device further comprises: The result processing module is used to obtain the running result of the verification case and store the running result in the heap space of the process.

[0065] Optionally, the thread creation module 304 includes: The thread pool creation submodule is used to construct a thread pool in the heap space of the process; the thread pool includes: a plurality of threads; The device also includes: The thread recycling module is used to recycle the thread to the thread pool after the thread has finished running.

[0066] It should be noted that the hardware verification device can refer to the related aspects of the aforementioned hardware verification method, and both have the same or similar beneficial effects. In order to avoid repetition, they will not be described here.

[0067] Figure 4 is a structural diagram of an electronic device provided by an embodiment of the present invention. Figure 4 The present invention also provides an electronic device, see Figure 4 , including: a processor 501, a memory 502, and a computer program 5021 stored in the memory and executable on the processor, wherein the processor implements the steps of the above-mentioned hardware verification embodiments when executing the program.

[0068] The present invention also provides a readable storage medium. When the instructions in the storage medium are executed by a processor of an electronic device, the electronic device can execute the steps of each embodiment of the above-mentioned hardware verification method.

[0069] The present invention also provides a computer program product, comprising instructions, which, when executed by a processor in an electronic device, enable the electronic device to execute any step of the aforementioned hardware verification method embodiments.

[0070] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0071] It will be appreciated by those skilled in the art that the embodiments of the present invention may be provided as methods, devices, or computer program products. Therefore, the embodiments of the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the embodiments of the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0072] The embodiments of the present invention are described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems), and computer program products according to the embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data transmission terminal device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data transmission terminal device generate instructions for implementing the process in the flowchart. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0073] These computer program instructions may also be stored in a computer readable memory capable of directing a computer or other programmable data transmission terminal device to operate in a predictable manner, so that the instructions stored in the computer readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0074] These computer program instructions can also be loaded onto a computer or other programmable data transmission terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable terminal device to implement the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0075] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present invention.

[0076] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or terminal device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or terminal device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or terminal device including the elements.

[0077] The above is a detailed introduction to a hardware verification method and device, an electronic device and a storage medium provided by the present invention. Specific examples are used in this article to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea; at the same time, for general technical personnel in this field, according to the idea of ​​the present invention, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present invention.

Claims

1. A hardware verification method, characterized in that: include: Compile the hardware module to be verified into a first dynamic library; In the heap space of the process, the first dynamic library is created as a plurality of isolated objects; Starting a verification program corresponding to the hardware module to be verified; The verification procedure includes: verifying the use case; creating a plurality of threads in the process; The thread and the object are matched for the verification case, and the thread is run to perform hardware verification.

2. The hardware verification method according to claim 1, characterized in that: The step of creating the first dynamic library as a plurality of isolated objects in the heap space of the process includes: In the constructor, according to the isolation characteristic of the memory namespace, the first dynamic library is loaded into different address spaces of the heap space; In different address spaces of the heap space, the first dynamic library is instantiated into multiple objects.

3. The hardware verification method according to claim 1, characterized in that: The step of creating the first dynamic library as a plurality of isolated objects in the heap space of the process includes: Using a binary modification method, modifying the first dynamic library to obtain multiple second dynamic libraries; Loading the plurality of second dynamic libraries into the in-heap space; In the heap space, the second dynamic library is instantiated into a plurality of objects.

4. The hardware verification method according to claim 1, characterized in that: Before matching the thread and the object for the verification case and running the thread to perform hardware verification, the method further includes: Combining a plurality of the verification cases in the verification program to obtain a combined verification case having an execution order and sharing the same object; In the heap space of the process, an object pool is constructed; The matching of the thread and the object for the verification case and running the thread to perform hardware verification includes: matching the thread and the same object for a previous verification case in the combined verification case, and running the thread so that the same object is in a first state; Recycling the same object in the first state into the object pool; According to the execution order, the thread is matched for the subsequent verification case that is adjacent to the previous verification case in the combined verification case, and the same object in the first state is matched for the subsequent verification case from the object pool, and the thread is run to perform hardware verification.

5. The hardware verification method according to claim 1, characterized in that: The matching of the thread and the object for the verification case and running the thread to perform hardware verification includes: A preset number of threads and a preset number of objects are simultaneously allocated to the verification case, and the preset number of threads are run in parallel to perform hardware verification; the preset number is a natural number greater than 1.

6. The hardware verification method according to any one of claims 1 to 5, characterized in that: Also includes: Obtain the running result of the verification case, and store the running result in the heap space of the process.

7. The hardware verification method according to any one of claims 1 to 5, characterized in that: The step of creating multiple threads in the process includes: In the heap space of the process, a thread pool is constructed; the thread pool includes: a plurality of threads; The method further comprises: After the thread finishes running, the thread is recycled to the thread pool.

8. A hardware verification device, characterized in that: include: A compiling module, used for compiling the hardware module to be verified into a first dynamic library; An object creation module, used to create the first dynamic library as a plurality of isolated objects in the heap space of the process; A startup module, used to start the verification program corresponding to the hardware module to be verified; The verification procedure includes: verifying the use case; A thread creation module, used for creating multiple threads in the process; The verification module is used to match the thread and the object for the verification case and run the thread to perform hardware verification.

9. An electronic device, characterized in that: include: A processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor implements the hardware verification method according to any one of claims 1 to 7 when executing the program.

10. A readable storage medium, characterized in that: When the instructions in the storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the hardware verification method according to any one of claims 1 to 7.

11. A computer program product, characterized in that The method comprises instructions, which, when executed by a processor in an electronic device, enable the electronic device to execute the hardware verification method according to any one of claims 1 to 7.

Images