Hardware Verification Method, Device, Electronic Device, Storage Medium and Product

Abstract

The present application provides a hardware verification method, apparatus, electronic device, storage medium, and product, including: obtaining a verification environment platform for testing a circuit design file to be tested, where multiple interaction functions are encapsulated in the verification environment platform; obtaining a reference model including all call statements; the call statements are used to call associated interaction functions through hook functions, and the call statements are generated by the verification environment platform according to preset verification specification definitions and the association relationship between the interaction functions and the hook functions; in response to an input call event, executing a target call statement that matches the call event, so as to call a target interaction function through the target hook function in the target call statement for execution, and obtaining a first verification result; obtaining a second verification result obtained by the verification environment platform simulating and running the circuit design file to be tested, and comparing the first verification result with the second verification result to obtain a verification result. The present application uses hook functions to capture the interaction between the verification code and the DUT.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular, to a hardware verification method, apparatus, electronic device, storage medium, and product. Background Art

[0002] Network-on-chip (NOC) is a key technology for multi-processor architectures. It is the internal interconnection path and communication network of a processor, responsible for message passing and the basis for processors to work together. At the same time, to ensure the operational stability of the network-on-chip, it is necessary to verify the design of the network-on-chip.

[0003] Hardware verification uses methods such as simulation to verify the functional correctness of a design under test (DUT) to avoid the failure of tape out caused by introducing functional errors. In the Toffee framework, a modeling scheme based on asynchronous functions is used to abstract the behavior of hardware designs. In this way, driver functions are used to actively drive the verification code for the DUT, and monitor functions are used to passively monitor the DUT.

[0004] In hardware verification, a reference model is often needed to compare whether the output of the DUT is correct. However, there is no way to directly obtain the interaction between the verification code and the DUT in existing reference models. Summary of the Invention

[0005] Embodiments of this application provide a hardware verification method, apparatus, electronic device, storage medium, and product to solve the problems in related technologies.

[0006] In a first aspect, embodiments of this application provide a hardware verification method, the method including:

[0007] Obtain a verification environment platform for testing a circuit design file under test, where multiple interaction functions are encapsulated in the verification environment platform;

[0008] Obtain a reference model including all call statements; the call statements are used to call associated interaction functions through hook functions, and the call statements are generated by the verification environment platform according to preset verification specifications and the association relationship between the interaction functions and the hook functions;

[0009] In response to an input call event, execute a target call statement that matches the call event, so as to call a target interaction function through a target hook function in the target call statement for execution, and obtain a first verification result;

[0010] Obtain the second verification result obtained by simulating and running the to-be-tested circuit design file on the verification environment platform, and compare the first verification result with the second verification result to obtain the verification result.

[0011] In a second aspect, an embodiment of the present application provides a hardware verification device, which includes:

[0012] A first acquisition module, configured to acquire a verification environment platform for testing a to-be-tested circuit design file, where a plurality of interaction functions are encapsulated in the verification environment platform;

[0013] A second acquisition module, configured to acquire a reference model including all call statements; the call statements are used to call associated interaction functions through hook functions, and the call statements are generated by the verification environment platform according to preset verification specification definitions and the association relationship between the interaction functions and the hook functions;

[0014] A call execution module, configured to, in response to an input call event, execute a target call statement that matches the call event, so as to call a target interaction function through a target hook function in the target call statement for execution, and obtain a first verification result;

[0015] A result comparison module, configured to obtain the second verification result obtained by simulating and running the to-be-tested circuit design file on the verification environment platform, and compare the first verification result with the second verification result to obtain the verification result.

[0016] In a third aspect, an embodiment of the present application further provides an electronic device, including a processor;

[0017] A memory for storing executable instructions of the processor;

[0018] Wherein, the processor is configured to execute the instructions to implement the method of the first aspect.

[0019] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device can execute the method of the first aspect.

[0020] In a fifth aspect, an embodiment of the present application further provides a computer product, including one or more processors; one of the processors is configured to run computer instructions to execute the method of the first aspect.

[0021] In the embodiments of the present application, on the one hand, due to the reference model written using hook functions, it can capture the interaction between the verification code and the DUT, making the writing of the reference model more flexible without the need for complex interface connections. On the other hand, the hook functions will be automatically triggered and can also automatically perform result comparison, improving the verification efficiency of the verification environment platform.

[0022] The above description is only an overview of the technical solution of the present application. In order to understand the technical means of the present application more clearly, it can be implemented according to the content of the specification. And in order to make the above and other purposes, features, and advantages of the present application more obvious and understandable, the following specifically describes the specific embodiments of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0024] Figure 1 It is a schematic diagram of an application environment provided by the embodiments of the present application;

[0025] Figure 2 It is a flowchart of the steps of a hardware verification method provided by the embodiments of the present application;

[0026] Figure 3 It is a specific flowchart of the steps of a hardware verification method provided by the embodiments of the present application;

[0027] Figure 4 It is a schematic diagram of a hardware verification architecture provided by the embodiments of the present application;

[0028] Figure 5 It is a block diagram of a hardware verification device provided by the embodiments of the present application;

[0029] Figure 6 It is a block diagram of an electronic device provided by the embodiments of the present invention;

[0030] Figure 7 It is a block diagram of another electronic device provided by another embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0031] The following will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are some, but not all, of the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of the present application.

[0032] The terms "first", "second", etc. in the description and claims of this application are used to distinguish similar objects, rather than to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of this application can be implemented in an order other than those illustrated or described herein, and the objects distinguished by "first", "second", etc. are generally of the same category, and the number of objects is not limited. For example, the first object can be one or more. In addition, the term "and / or" in the description and claims is used to describe the association relationship between associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. The character " / " generally indicates that the associated objects before and after are in an "or" relationship. In the embodiments of this application, the term "plurality" refers to two or more, and other quantifiers are similar.

[0033] In practical applications, with the increase in the scale of the chip and the number of modules in the chip, the proportion of verification in the hardware development process increases, and the workload of verification also increases significantly, requiring a more efficient method to complete the verification.

[0034] The Toffee framework uses the coroutines of Python (a computer language) to manage asynchronous programs, and can establish an event loop on a single thread to manage multiple concurrently running coroutines. The coroutines can wait for each other and switch through the event loop, greatly improving the generation efficiency of the test platform.

[0035] See Figure 1 , the Toffee framework splits the behavioral responsibilities of the DUT into multiple agent modules (Agents) to obtain a standardized verification environment. A set of matching specifications for the reference model is defined in the Toffee framework. Only by writing the reference model call interface according to this specification can the automatic forwarding and comparison of the reference model be realized. At the same time, to facilitate the association of the reference model with the entire verification environment, the concept of verification environment (Env) is provided in the Toffee framework to package the entire verification environment. After writing the reference model, only by associating it with the Env can the automatic synchronization of the reference model be realized.

[0036] It should be noted that, according to whether the verification code actively initiates an interaction and the directionality of the interface, the interactions are divided into the following two categories: the verification code actively initiates and the verification code passively receives. Among them, the verification code actively initiating includes the verification code actively reading the values of input / output ports and the verification code actively assigning values to input ports, and the verification code passively receiving includes the verification code passively receiving the values of output / output ports. For the interactions actively initiated by the verification code, the Toffee framework stipulates that functions are used to complete them. The functions in the Toffee framework used for the interactions actively initiated by the verification code are called driver methods and are marked with the driver_method decorator. For the interactions passively received by the verification code, the Toffee framework also standardizes the use of functions as carriers to complete such interactions. This function has no input parameters and is not actively controlled by the verification code. When the state of the DUT changes, this function will be called to complete the reading operation of the interface signals and convert them into upper-layer semantic information. The Toffee framework calls such functions used for the interactions passively received by the verification code monitoring methods and marks such functions with the monitor_method decorator.

[0037] Therefore, the Toffee framework uses functions to complete all interactions of the Agent, which are divided into driver methods and monitoring methods. Writing an Agent is to write driver methods and monitoring methods.

[0038] In the verification environment of the Toffee framework, there are two implementation methods for the reference model: the function call mode and the independent execution flow mode. The function call mode is to define the external interface as a series of functions and drive the reference model through the functions; the independent execution flow mode defines the behavior of the reference model as an independent execution flow, which has the ability to actively obtain input data and actively output data. When data is sent to the reference model externally, the reference model will not respond immediately, but save this data and wait for its execution logic to actively obtain this data.

[0039] However, the above methods cannot directly obtain the interactions between the verification code and the DUT. To solve the above problems, this application provides a hardware verification method, device, electronic device, storage medium and product, which can capture the interactions between the verification code and the DUT, make the writing of the reference model more flexible, without complex interface connections, and can also automatically perform result comparison, improving the verification efficiency of the verification environment platform.

[0040] The following will elaborate on the hardware verification method provided by this application.

[0041] Figure 2 It is a flowchart of the steps of a hardware verification method provided by an embodiment of this application. As Figure 2 shown, the method may include the following steps.

[0042] Step 101: Obtain a verification environment platform for testing the circuit design file to be tested.

[0043] In the embodiments of the present application, multiple interaction functions are encapsulated in the verification environment platform.

[0044] In some embodiments, the interaction functions include a driving function and a monitoring function. Among them, the driving function is a function called when the verification code actively initiates an interaction, and the monitoring function is a function called when the verification code passively receives an interaction. Optionally, if a value is returned after the monitoring function is called, it indicates that an event has been successfully monitored.

[0045] It should be noted that in the field of the design of the intellectual property module (IP) of an integrated circuit, a designer can use Verilog (a hardware description language) to write a circuit design to obtain a circuit design file to be tested, and the circuit design file to be tested can be used to describe the constituent units of the circuit, the interconnection relationship between the constituent units, and other contents.

[0046] In some embodiments, step 101 may include: obtaining a circuit design file to be tested and building a verification environment platform based on the Universal Verification Methodology (UVM). Among them, UVM is a set of class libraries built using the System Verilog language to implement a verification methodology based on coverage-driven stimulus random constraints. UVM aims to unify and standardize the verification specifications in the industry.

[0047] Exemplarily, the verification environment platform encapsulates several Agents, each Agent contains multiple interaction functions, and each Agent is obtained by splitting the behavioral responsibilities of the DUT.

[0048] In some embodiments, the circuit design file to be tested includes task descriptions of different functional modules in the chip to be tested and / or hardware definitions of each functional module.

[0049] In the embodiments of the present application, the hardware definition corresponding to each functional module includes: the hardware definition of at least one of a wire, a register, and a state. Among them, the wire belongs to the interface information between this functional module and other functional modules, and the register and the state belong to the interface information between this functional module and the software.

[0050] Step 102: Obtain a reference model including all call statements.

[0051] In the embodiments of the present application, the call statement is used to call the associated interaction function through the hook function, and the call statement is generated by the verification environment platform according to the preset verification specification definition and the association relationship between the interaction function and the hook function.

[0052] Exemplarily, the preset verification specification definition can be the specification definition of the Toffee framework.

[0053] It can be understood that a hook function (Hook) intercepts messages using the hook mechanism when the system is performing message passing and processing, and can process some specific messages. For example, some system development functions can be based on the message processing mechanism to initialize messages, dynamically create and allocate space, and then forward the messages, and monitor the messages of each module in real time. The hook function is the operation when monitoring the message when it is passed to the specified module window. If the message does not meet the conditions, the hook function can process it and prevent it from finally reaching the destination successfully. If the conditions are met, it can continue to be passed backward.

[0054] In some embodiments, the association relationship between the interaction function and the hook function includes: the association relationship between the driver function and the hook function, the association relationship between the monitoring function and the hook function, and the association relationship between the Agent and the hook function.

[0055] It should be noted that the association relationship between the hook function and the hooked function is one-to-one. The present application proposes a hook mechanism. By writing the corresponding hook in the reference model and specifying the hooked function, the behavior of the monitoring function and the monitoring function can be obtained. Specifically, there are the following three types of hooks: 1. Driver function hook: The driver function hook is used to capture the call of the driver function. When the user calls a driver function once, the driver function hook is triggered simultaneously and the parameters passed by the user to the driver function are obtained. 2. Monitoring function hook: The monitoring function hook is used to capture the call of the monitoring function. When the monitoring function successfully monitors an event, the monitoring function hook is triggered and the monitored event is obtained. 3. Agent hook: The Agent hook is used to capture any interaction in an Agent. A set of driver functions and monitoring functions can be specified. When the functions in the set are triggered, the Agent hook is triggered and the transmitted data is obtained.

[0056] Step 103: In response to the input call event, execute the target call statement that matches the call event, so as to call the target interaction function through the target hook function in the target call statement for execution, and obtain the first verification result.

[0057] In the embodiments of the present application, the input call event can be a call event triggered by the user.

[0058] In some embodiments, the target hook function in the target call statement may include a Func function or a Port function.

[0059] For example, in the implementation of Func, to complete a hook function, a Func function needs to be implemented. When the interaction function hooked by Func is triggered, this Func function is also triggered. In the implementation of Port, the hook function is implemented as an interface, and there is a queue structure in the structure for storing the captured events. Combined with Figure 4 as shown, the Func function corresponds to the implementation of Reference Model 1. After Reference Model 1 is triggered, the Func function executes the logic of Reference Model 1.

[0060] Again, for example, in the implementation of Port, when the driver function is called, the Port hook corresponding to the driver function packs the call parameters into a single structure and places it in the queue of the Port interface; when the monitoring function detects an event, the Port hook corresponding to the monitoring function places the detected data in the queue of the Port interface; when the specified event in the Agent occurs, the Agent hook packs the type of the event and the corresponding data and places it in the queue of the Port interface. Combined with Figure 4 as shown, Port corresponds to the implementation of Reference Model 2. The events stored in Reference Model 2 will be actively retrieved by Reference Model 2.

[0061] In some embodiments, the first verification result is the return value of the Func function implemented by the hook function, that is, the running result of the reference model.

[0062] Step 104, obtain the second verification result obtained by simulating and running the circuit design file to be tested on the verification environment platform, and compare the first verification result with the second verification result to obtain the verification result.

[0063] In the embodiments of the present application, the implementation scenario of the solution may be to test the circuit design. The circuit design is a file obtained by programming. Importing the circuit design into the hardware circuit for operation can achieve the test of the circuit design. Among them, the hardware circuit may include: Field Programmable Gate Array (FPGA), System on Chip (SOC), etc.

[0064] In some embodiments, comparing the first verification result with the second verification result in step 104 to obtain the verification result may include: when the return values of the first verification result and the second verification result are the same, the verification result is verification passed; when the return values of the first verification result and the second verification result are different, the verification result is verification failed.

[0065] In summary, in the embodiments of the present application, on the one hand, since the reference model written using the hook function can capture the interaction between the verification code and the DUT, making the reference model writing more flexible without complex interface connections. On the other hand, the hook function will be automatically triggered and can also automatically perform result comparison, improving the verification efficiency of the verification environment platform.

[0066] Figure 3 is a specific step flowchart of a hardware verification method provided by the embodiments of the present application, as Figure 3 shown, the method may include the following steps.

[0067] Step 201, obtain a verification environment platform for testing a circuit design file to be tested.

[0068] In the embodiments of the present application, a plurality of interaction functions are encapsulated in the verification environment platform.

[0069] The method of this step has been described in the foregoing step 101 and will not be elaborated here.

[0070] Step 202, obtain a reference model including all call statements.

[0071] In the embodiments of the present application, the call statement is used to call an associated interaction function through a hook function, and the call statement is generated by the verification environment platform according to a preset verification specification definition and the association relationship between the interaction function and the hook function.

[0072] The method of this step has been described in the foregoing step 102 and will not be elaborated here.

[0073] Step 203, in response to an input call event, determine a hooked driver function through a target hook function in the target call statement.

[0074] In some embodiments, step 203 may include the following sub-steps.

[0075] Sub-step A1, in response to an input call event, determine the hooked function according to the identification field in the target call statement.

[0076] Step 204, execute the hooked driver function as the target function.

[0077] Step 205, intercept the interaction data when the target function is executed and obtain the first verification result.

[0078] In the embodiments of the present application, for steps 204 to sub-step 205, when the hooked driver function is a driver function, the driver function hook should have the same parameter and return value structure as its corresponding driver function. When the driver function is called, the driver function hook is called simultaneously and the same parameters are passed in. After both functions finish running, the Toffee verification framework will automatically compare the return values of the two functions to check whether the behavior of the DUT is correct.

[0079] In the embodiments of the present application, the identification field characterizes the function that the target hook function can call.

[0080] Exemplarily, in the Python version implementation, the "@driver_hook" decorator is used to identify the function version of the driver function hook.

[0081] Optionally, step 203 may further include the following sub-steps.

[0082] Sub-step 2031: In response to the input call event, call a preset monitoring function for execution.

[0083] Sub-step 2032: Intercept the interaction data during the execution of the target function and obtain a first verification result.

[0084] In the embodiments of the present application, for sub-steps 2031 to 2032, when the hooked driver function is a monitoring function, the monitoring function hook is used to capture an event of a monitoring function. Its parameter structure is fixed, with one parameter for passing in the event captured by the monitoring function and no return value. When the monitoring function monitors an event, the function will be automatically called and the monitored event will be passed in. In the function, the writer of the reference model can determine whether the event content meets the expectations, thereby checking the behavior of the DUT.

[0085] In some embodiments, sub-step 2032 may include the following sub-steps.

[0086] Sub-step B1: In response to the input call event, determine the hooked function according to the identification field in the target call statement.

[0087] In the embodiments of the present application, the identification field characterizes the function that the target hook function can call.

[0088] Exemplarily, in the Python version implementation, the "@monitor_hook" decorator is used to identify the function version of the monitoring function hook.

[0089] Optionally, step 203 may further include the following sub-steps.

[0090] Sub-step 2033: In response to the input calling event, calling the Agent hook function for execution.

[0091] In the embodiment of the present application, when the event specified in the Agent hook function occurs, the Agent hook is triggered. The parameter structure of the Agent hook is also fixed, one parameter is used to indicate which function is triggered, and the other parameter is used to pass in the data involved in this interaction, and there is no return value.

[0092] Step 206: Obtain a second verification result obtained by simulating the circuit design file to be tested on the verification environment platform, and compare the first verification result with the second verification result to obtain a verification result.

[0093] The method of this step has been described in the aforementioned step 104 and will not be repeated here.

[0094] Optionally, comparing the first verification result with the second verification result in step 206 to obtain the verification result may include the following sub-steps.

[0095] Sub-step 2061: When the return values ​​of the first verification result and the second verification result are the same, the verification result is verification passed;

[0096] Sub-step 2062: When the return values ​​of the first verification result and the second verification result are different, the verification result is verification failure.

[0097] Exemplarily, when the on-chip network simulation corresponding to the on-chip network code file is running, data for the processor core and external devices can be transmitted between the verification platform and the on-chip network by the bridge module, the data for the processor core can be passed into the verification comparison module by the processor core interface implemented by the verification platform, and the data for the external device can be passed into the verification comparison module by the external interface implemented by the verification platform. The verification comparison module is used to compare the data of the processor core, the data of the external device and the data of the verification reference model, so as to obtain the verification result.

[0098] In some embodiments, there are multiple call events input, and the above hardware verification method may further include the following sub-steps.

[0099] Sub-step S1: obtaining an interface reference model, in which captured call events are stored in a queue.

[0100] Sub-step S2: determining the logical order of multiple call events.

[0101] Sub-step S3, execute multiple target call statements that match the call event in a logical order, so as to call multiple target interactive functions through multiple target hook functions in the multiple target call statements to execute, and obtain a first verification result.

[0102] It should be noted that the hook function makes the writing of the reference model become the writing of multiple functions. This way may disrupt the original execution order of the reference model. Therefore, in the case of multiple input call events, another hook implementation method is adopted. In this method, the hook is implemented as an interface (Port), and the reference model is an interface reference model. There is a queue structure in the interface reference model structure for storing the captured events. At the same time, a main coroutine needs to be written in the interface reference model, and in the main coroutine, the data in these interfaces can be actively obtained to complete the functions of the reference model.

[0103] Specifically, the effects of each hook function in the interface reference model are as follows: 1. Driver function hook (Port): When the corresponding driver function is called, the call parameters will be packed into a single structure and placed in the queue of the interface. 2. Monitoring function hook (Port): When the corresponding monitoring function detects an event, the detected data will be placed in the queue of the interface. 3. Agent hook (Port): After the event specified by the Agent hook occurs, the type of the event and the corresponding data will be packed and placed in the queue of the interface.

[0104] In some embodiments, after sub-step S3, the above hardware verification method may further include the following sub-steps.

[0105] Sub-step S4: Store the data generated when multiple target call statements are executed through a preset queue structure.

[0106] Sub-step S5: Pack the generated data according to the logical order and output it in the form of a queue.

[0107] In the embodiments of the present application, the information of the DUT can be output in the form of a queue.

[0108] In summary, in the embodiments of the present application, the problem of difficult writing of the reference model caused by modeling the DUT using asynchronous functions is solved; the writing of the reference model is made more flexible, and only by writing hooks, interactions can be captured without complex interface connections. The reference model also supports two writing methods and can be used in most cases; redundant code is removed, the hooks will be automatically triggered, and the results can be automatically compared.

[0109] Figure 4 It is a schematic diagram of a hardware verification architecture provided by the embodiments of the present application. See Figure 4, in the writing of a reference model, only one type of hook can be used. However, since the hook does not have any impact on the verification environment, multiple different types of reference models can be attached to a verification environment. The arrows in the figure indicate that an attach operation is provided in the verification environment for attaching a reference model to the verification environment. Among them, reference model 1 is written through the Func function, and reference model 2 is written through the Port function.

[0110] Figure 5 is a block diagram of a hardware verification device provided by an embodiment of the present application. The device 400 includes the following modules.

[0111] The first acquisition module 401 is configured to acquire a verification environment platform for testing a circuit design file to be tested, and multiple interaction functions are encapsulated in the verification environment platform.

[0112] The second acquisition module 402 is configured to acquire a reference model including all call statements; the call statements are used to call associated interaction functions through hook functions, and the call statements are generated by the verification environment platform according to a preset verification specification definition and the association relationship between the interaction functions and the hook functions.

[0113] The call execution module 403 is configured to execute a target call statement matching the input call event in response to the input call event, so as to call and execute a target interaction function through the target hook function in the target call statement to obtain a first verification result.

[0114] The result comparison module 404 is configured to acquire a second verification result obtained by the verification environment platform simulating and running the circuit design file to be tested, and compare the first verification result with the second verification result to obtain a verification result.

[0115] Optionally, the interaction function includes a driving function. The call execution module 403 includes: a first determination sub-module, configured to determine the hooked driving function through the target hook function in the target call statement in response to the input call event; a first execution sub-module, configured to execute the hooked driving function as a target function; a first interception sub-module, configured to intercept interaction data when the target function is executed and obtain a first verification result.

[0116] Optionally, the first determination sub-module includes: a determination unit, configured to determine the hooked function according to an identification field in the target call statement in response to the input call event, and the identification field characterizes the function that the target hook function can call.

[0117] Optionally, the interaction function includes a monitoring function, and the call execution module 403 is invoked, including: a second execution sub-module for invoking a preset monitoring function for execution in response to an input call event; a second interception sub-module for intercepting interaction data during the execution of the target function and obtaining a first verification result.

[0118] Optionally, the result comparison module 404 includes: a first result determination sub-module for determining that the verification result passes when the return values of the first verification result and the second verification result are the same; a second result determination sub-module for determining that the verification result fails when the return values of the first verification result and the second verification result are different.

[0119] Optionally, if there are multiple input call events, the hardware verification device 400 further includes: a third acquisition module for acquiring an interface reference model, where the captured call events are stored in the interface reference model in a queue manner; an order determination module for determining the logical order of the multiple call events; an order execution module for executing multiple target call statements matching the call events in the logical order, so as to execute multiple target interaction functions through multiple target hook functions in the multiple target call statements and obtain a first verification result.

[0120] Optionally, the hardware verification device 400 further includes the following modules.

[0121] A data storage module for storing data generated when multiple target call statements are executed through a preset queue structure.

[0122] A data output module for packing the generated data according to the logical order and outputting it in a queue manner.

[0123] Optionally, the circuit design file to be tested includes task descriptions of different functional modules in the chip to be tested and / or hardware definitions of each functional module.

[0124] In summary, in the embodiments of the present application, on the one hand, due to the reference model written using hook functions, the interaction between the verification code and the DUT can be captured, making the writing of the reference model more flexible without complex interface connections. On the other hand, the hook functions will be automatically triggered and the results can be automatically compared, improving the verification efficiency of the verification environment platform.

[0125] For the device embodiments, since they are basically similar to the method embodiments, the description is relatively simple. For related parts, refer to the partial description of the method embodiments.

[0126] Each embodiment in this specification is described in a progressive manner. Each embodiment focuses on the differences from other embodiments. For the same and similar parts among the embodiments, refer to each other.

[0127] Regarding the device in the above embodiments, the specific manner in which each module performs operations has been described in detail in the embodiments related to the method, and will not be elaborated here.

[0128] An embodiment of the present application provides a hardware verification device, including a memory, and more than one program, where the more than one program is stored in the memory and is configured to be executed by more than one processor, and the more than one program includes instructions for performing the method described in the above one or more embodiments.

[0129] Figure 6 FIG. 600 is a block diagram of an electronic device 600 shown according to an exemplary embodiment. For example, the electronic device 600 may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.

[0130] Referring to Figure 6 , the electronic device 600 may include one or more of the following components: a processing component 602, a memory 604, a power supply component 606, a multimedia component 608, an audio component 610, an input / output (I / O) interface 612, a sensor component 614, and a communication component 616.

[0131] The processing component 602 generally controls the overall operation of the electronic device 600, such as operations associated with display, telephone calls, data communication, camera operations, and recording operations. The processing component 602 may include one or more processors 620 to execute instructions to complete all or part of the steps of the above method. In addition, the processing component 602 may include one or more modules to facilitate the interaction between the processing component 602 and other components. For example, the processing component 602 may include a multimedia module to facilitate the interaction between the multimedia component 608 and the processing component 602.

[0132] The memory 604 is used to store various types of data to support the operation of the electronic device 600. Examples of such data include instructions for any application or method operating on the electronic device 600, contact data, phone book data, messages, pictures, multimedia, etc. The memory 604 may be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, a magnetic disk, or an optical disk.

[0133] The power supply component 606 provides power for various components of the electronic device 600. The power supply component 606 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the electronic device 600.

[0134] The multimedia component 608 includes a screen that provides an output interface between the electronic device 600 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can not only sense the boundaries of touch or swipe actions, but also detect the duration and pressure associated with the touch or swipe operations. In some embodiments, the multimedia component 608 includes a front camera and / or a rear camera. When the electronic device 600 is in an operating mode, such as a shooting mode or a multimedia mode, the front camera and / or the rear camera can receive external multimedia data. Each of the front camera and the rear camera can be a fixed optical lens system or have focal length and optical zoom capabilities.

[0135] The audio component 610 is used to output and / or input audio signals. For example, the audio component 610 includes a microphone (MIC) that is used to receive external audio signals when the electronic device 600 is in an operating mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signals can be further stored in the memory 604 or transmitted via the communication component 616. In some embodiments, the audio component 610 further includes a speaker for outputting audio signals.

[0136] The I / O interface 612 provides an interface between the processing component 602 and a peripheral interface module, and the peripheral interface module can be a keyboard, a click wheel, buttons, etc. These buttons can include, but are not limited to: a home button, a volume button, a start button, and a lock button.

[0137] The sensor assembly 614 includes one or more sensors for providing a status assessment of various aspects of the electronic device 600. For example, the sensor assembly 614 can detect the on / off state of the electronic device 600, the relative positioning of components, such as the display and keypad of the electronic device 600. The sensor assembly 614 can also detect a change in the position of the electronic device 600 or a component of the electronic device 600, the presence or absence of user contact with the electronic device 600, the orientation or acceleration / deceleration of the electronic device 600, and a change in the temperature of the electronic device 600. The sensor assembly 614 can include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor assembly 614 can also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 614 can also include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0138] The communication component 616 is used to facilitate communication between the electronic device 600 and other devices in a wired or wireless manner. The electronic device 600 can access a wireless network based on communication standards, such as WiFi, a carrier network (such as 2G, 3G, 4G, or 5G), or a combination thereof. In an exemplary embodiment, the communication component 616 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 616 further includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0139] In an exemplary embodiment, the electronic device 600 can be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components for implementing the methods provided in the embodiments of the present application.

[0140] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 604 including instructions, and the above instructions can be executed by a processor 620 of the electronic device 600 to complete the above method. For example, the non-transitory storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, and an optical data storage device, etc.

[0141] Figure 7is a block diagram of an electronic device 700 shown in accordance with an exemplary embodiment. For example, the electronic device 700 may be provided as a server. Referring to Figure 7 , the electronic device 700 includes a processing component 722, which further includes one or more processors, and memory resources represented by a memory 732 for storing instructions executable by the processing component 722, such as application programs. The application programs stored in the memory 732 may include one or more modules each corresponding to a set of instructions. In addition, the processing component 722 is configured to execute instructions to perform the method provided in the embodiments of the present application.

[0142] The electronic device 700 may also include a power component 726 configured to perform power management of the electronic device 700, a wired or wireless network interface 750 configured to connect the electronic device 700 to a network, and an input / output (I / O) interface 758. The electronic device 700 may operate based on an operating system stored in the memory 732, such as Windows ServerTM, MacOS XTM, Unix TM, Linux TM, FreeBSD TM or the like.

[0143] The embodiments of the present application also provide a computer program product, including a computer program, which when executed by a processor implements the method described in the above embodiments.

[0144] Those skilled in the art will readily conceive of other embodiments of the present application after considering the specification and practicing the application disclosed herein. The present application is intended to cover any variations, uses, or adaptations of the present application, which follow the general principles of the present application and include known common knowledge or conventional technical means in the technical field not disclosed in the present disclosure. The specification and embodiments are to be considered as exemplary only, and the true scope and spirit of the present application are pointed out by the following claims.

[0145] It should be understood that the present application is not limited to the exact structures described above and shown in the drawings, and various modifications and changes may be made without departing from its scope. The scope of the present application is only limited by the appended claims.

Claims

1. A hardware verification method, characterized in that: The method comprises: Acquire a verification environment platform for testing a circuit design file to be tested, wherein the verification environment platform encapsulates a plurality of interactive functions; Acquire a reference model including all call statements; the call statements are used to call the associated interactive function through the hook function, and the call statements are generated by the verification environment platform according to a preset verification specification definition and the association relationship between the interactive function and the hook function; In response to the input call event, executing a target call statement matching the call event, so as to call the target interactive function through the target hook function in the target call statement for execution, and obtaining a first verification result; Obtaining a second verification result obtained by simulating and running the circuit design file to be tested on the verification environment platform, and comparing the first verification result with the second verification result to obtain a verification result; The interactive function includes a driving function, and in response to an input calling event, executing a target calling statement matching the calling event, so as to call a target interactive function through a target hook function in the target calling statement for execution, and obtaining a first verification result, including: In response to the input call event, the hooked driver function is determined through the target hook function in the target call statement; Execute the hooked driving function as a target function; Interaction data during execution of the target function is intercepted and the first verification result is obtained.

2. The method according to claim 1, characterized in that: The step of determining the hooked driver function in response to the input call event through the target hook function in the target call statement includes: In response to the input call event, the hooked function is determined according to the identification field in the target call statement, wherein the identification field represents the function that can be called by the target hook function.

3. The hardware verification method according to claim 1, characterized in that: The interactive function also includes a monitoring function, which executes a target call statement matching the call event in response to an input call event, so as to call the target interactive function through a target hook function in the target call statement for execution, and obtain a first verification result, including: In response to the input call event, calling a preset monitoring function as a target function for execution; Interaction data during execution of the target function is intercepted and the first verification result is obtained.

4. The method according to claim 1, characterized in that: The comparing the first verification result with the second verification result to obtain a verification result includes: When the return values ​​of the first verification result and the second verification result are the same, the verification result is verification passed; When the return values ​​of the first verification result and the second verification result are different, the verification result is verification failure.

5. The method according to claim 1, characterized in that The input call event is multiple, and the method further includes: Acquire an interface reference model, wherein the interface reference model stores captured call events in a queue manner; Determine the logical order of multiple call events; Multiple target call statements matching the call event are executed in the logical order, so as to call multiple target interactive functions through multiple target hook functions in the multiple target call statements to execute and obtain a first verification result.

6. The method according to claim 5, characterized in that After executing the plurality of target call statements matching the call event in the logical order, the method further comprises: storing data generated when the plurality of target call statements are executed through a preset queue structure; The generated data is packaged according to the logical order and output in a queue.

7. The hardware verification method according to claim 1, characterized in that: The circuit design file to be tested includes task descriptions of different functional modules in the chip to be tested and / or hardware definitions of each functional module.

8. A hardware verification device, characterized in that: The device comprises: A first acquisition module is used to acquire a verification environment platform for testing a circuit design file to be tested, wherein the verification environment platform encapsulates a plurality of interactive functions; A second acquisition module is used to acquire a reference model including all call statements; the call statements are used to call the associated interactive functions through the hook functions, and the call statements are generated by the verification environment platform according to a preset verification specification definition and the association relationship between the interactive functions and the hook functions; A calling execution module, configured to execute a target calling statement matching the calling event in response to an input calling event, so as to call a target interactive function through a target hook function in the target calling statement for execution, and obtain a first verification result; A result comparison module is used to obtain a second verification result obtained by simulating and running the circuit design file to be tested on the verification environment platform, and compare the first verification result with the second verification result to obtain a verification result; The interactive function includes a driving function, calling the execution module 403, including: A first determination submodule is used to determine the hooked driver function through the target hook function in the target call statement in response to the input call event; A first execution submodule, used for executing the hooked driving function as a target function; The first interception submodule is used to intercept the interactive data when the target function is executed and obtain the first verification result.

9. An electronic device, characterized in that: include: processor; a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform the method as claimed in any one of claims 1 to 7.

11. A computer product, characterized in that: Comprising one or more processors; one of the processors is configured to execute computer instructions to perform the method as claimed in any one of claims 1 to 7.

Images