Hardware verification method, device, electronic device, storage medium and product

Abstract

The present application provides a hardware verification method, device, electronic device, storage medium and product, including: obtaining a verification environment platform for testing a circuit design file to be tested, wherein a plurality of interactive functions are encapsulated in the verification environment platform; obtaining a reference model including all call statements; the call statement is used to call the associated interactive 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 interactive function and the hook function; in response to an 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 present application adopts a hook function to capture the interaction between the verification code and the DUT.

Description

Technical Field

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

[0002] The network-on-chip (NOC) is a key technology of multi-processor architecture. It is the interconnection path and communication network inside the processor, responsible for message transmission, and is the basis for the collaborative work of processors. At the same time, in order to ensure the operational stability of the network-on-chip, the design of the network-on-chip needs to be verified.

[0003] Hardware verification uses simulation and other methods to verify the functional correctness of the Design Under Test (DUT) to avoid introducing functional errors that lead to tape-out failure. In the Toffee framework, an asynchronous function-based modeling scheme is used to abstract the behavior of the hardware design. This method uses a driver function to complete the active driving of the DUT by the verification code, and a monitoring function to complete the passive monitoring of 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 the existing reference model. Summary of the invention

[0005] The embodiments of the present application provide a hardware verification method, device, electronic device, storage medium and product to solve the problems in the related art.

[0006] In a first aspect, an embodiment of the present application provides a hardware verification method, the method comprising: 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; A second verification result obtained by simulating and running the circuit design file to be tested on the verification environment platform is obtained, and the first verification result is compared with the second verification result to obtain a verification result.

[0007] In a second aspect, an embodiment of the present application provides a hardware verification device, the device comprising: 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; The 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.

[0008] In a third aspect, an embodiment of the present application further provides an electronic device, including a processor; a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the method of the first aspect.

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

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

[0011] In the embodiment of the present application, on the one hand, the reference model written by the hook function can capture the interaction between the verification code and the DUT, making the reference model writing more flexible without the need for complex interface connections. On the other hand, the hook function will be automatically triggered and the results can be automatically compared, which improves the verification efficiency of the verification environment platform.

[0012] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0014] Figure 1 is a schematic diagram of an application environment provided by an embodiment of the present application; Figure 2 It is a flowchart of the steps of a hardware verification method provided by an embodiment of the present application; Figure 3 It is a flowchart of the specific steps of a hardware verification method provided by an embodiment of the present application; Figure 4 is a schematic diagram of a hardware verification architecture provided in an embodiment of the present application; Figure 5 is a block diagram of a hardware verification device provided in an embodiment of the present application; Figure 6 is a block diagram of an electronic device provided by an embodiment of the present invention; Figure 7 is a block diagram of another electronic device according to another embodiment of the present invention. DETAILED DESCRIPTION

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

[0016] The terms "first", "second", etc. in the specification and claims of the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than those illustrated or described here, and the objects distinguished by "first", "second", etc. are generally a class, 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 specification and claims is used to describe the association relationship of associated objects, indicating that three kinds of relationships can exist, for example, A and / or B can be represented: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the front and back associated objects are a kind of "or" relationship. In the embodiment of the present application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0017] In practical applications, as the chip scale increases and the number of modules in the chip increases, 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.

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

[0019] See also Figure 1 The Toffee framework splits the behavioral responsibilities of the DUT into multiple agent modules (Agent) to obtain a standardized verification environment. The Toffee framework defines a set of reference model matching specifications. You only need to write the reference model call interface according to this specification to realize the automatic forwarding and comparison of the reference model. At the same time, in order to facilitate the association of the reference model with the entire verification environment, the Toffee framework provides the concept of verification environment (Env) to package the entire verification environment. After writing the reference model, you only need to associate it with Env to realize the automatic synchronization of the reference model.

[0020] It should be noted that, according to whether the verification code actively initiates the interaction, the interaction with the directionality of the interface is divided into the following two categories: active initiation by the verification code and passive reception by the verification code. Among them, active initiation by the verification code includes the verification code actively reading the value of the input / output port and the verification code actively assigning a value to the input port, and passive reception by the verification code includes the verification code passively receiving the value of the output / output port. For the interaction actively initiated by the verification code, the Toffee framework stipulates the use of functions to complete it. The Toffee framework calls such functions used by the verification code to actively initiate the interaction a driver method, which is marked with the driver_method decorator. For the interaction passively received by the verification code, the Toffee framework also specifies 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 DUT state changes, the function will be called to complete the reading operation of the interface signal and convert it into upper-level semantic information. The Toffee framework calls such functions used for the verification code to passively receive the interaction a monitoring method, and uses the monitor_method decorator to mark such functions.

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

[0022] In the verification environment of the Toffee framework, there are two ways to implement the reference model: function call mode and 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 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 the external sends data to the reference model, the reference model will not respond immediately, but save the data and wait for its execution logic to actively obtain the data.

[0023] However, the above methods do not have a way to directly obtain the interaction between the verification code and the DUT. In order to solve the above problems, the present application provides a hardware verification method, device, electronic device, storage medium and product, which can capture the interaction between the verification code and the DUT, make the reference model writing more flexible, without the need for complex interface connections, and can automatically compare results, thereby improving the verification efficiency of the verification environment platform.

[0024] The hardware verification method provided by this application is described in detail below.

[0025] Figure 2 is a flowchart of a hardware verification method provided by an embodiment of the present application, such as Figure 2 As shown, the method may include the following steps.

[0026] Step 101: Acquire a verification environment platform for testing a circuit design file to be tested.

[0027] In the embodiment of the present application, a plurality of interactive functions are encapsulated in the verification environment platform.

[0028] In some embodiments, the interaction function includes a driving function and a monitoring function. The driving function is a function called when the verification code actively initiates the interaction, and the monitoring function is a function called when the verification code passively receives the interaction. Optionally, if a value is returned after the monitoring function is called, it means that an event has been successfully monitored.

[0029] It should be noted that in the design field of the intellectual property module (IP) of integrated circuits, designers can use Verilog (a hardware description language) to write circuit designs and obtain design files of the circuit to be tested. The design files of the circuit to be tested can be used to describe the constituent units of the circuit, the interconnection relationships between the constituent units, and other contents.

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

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

[0032] 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.

[0033] In the embodiment of the present application, the hardware definition corresponding to each functional module includes: hardware definition for at least one of a connection, a register, and a state. The connection belongs to the interface information between the functional module and other functional modules, and the register and the state belong to the interface information between the functional module and the software.

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

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

[0036] Exemplarily, the preset verification specification definition may be a specification definition of a Toffee framework.

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

[0038] In some embodiments, the association relationship between the interaction function and the hook function includes: the association relationship between the driving 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.

[0039] It should be noted that the association relationship between the hook function and the hooked function is one-to-one. This application proposes a hook mechanism. By writing a hook corresponding to the hook in the reference model and specifying the hooked function, the monitoring function and the behavior of 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 the driver function once, the driver function hook is triggered at the same time and obtains the parameters passed by the user to the driver function. 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 obtains the monitored event. 3. Agent hook: The Agent hook is used to capture any interaction in an Agent. You can specify a set of driver functions and monitoring functions. When the function in the set is triggered, the Agent hook is triggered and the passed data is obtained.

[0040] Step 103: In response to the input calling event, execute the target calling statement that matches the calling event, so as to call the target interactive function through the target hook function in the target calling statement to execute, and obtain a first verification result.

[0041] In the embodiment of the present application, the input calling event may be a calling event triggered by a user.

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

[0043] For example, in the implementation of Func, a hook function needs to be implemented. When the interactive function hooked by Func is triggered, the 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 to store the captured events. Figure 4 As shown, the Func function corresponds to the implementation method of reference model 1. After reference model 1 is triggered, the Func function executes the logic of reference model 1.

[0044] For example, in the implementation of Port, when the driver function is called, the Port hook corresponding to the driver function will package the call parameters into a separate structure and place it in the queue of the Port interface; when the monitoring function detects an event, the Port hook corresponding to the monitoring function will place the detected data in the queue of the Port interface; when the event specified in the Agent occurs, the Agent hook will package the event type and the corresponding data and place them in the queue of the Port interface. Figure 4 As shown, Port corresponds to the implementation method of reference model 2, and the events stored in reference model 2 will be actively obtained by reference model 2.

[0045] 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.

[0046] Step 104 , obtaining a second verification result obtained by simulating 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.

[0047] In the embodiment of the present application, the implementation scenario of the scheme can be to test the circuit design, the circuit design is a file obtained by programming, and the circuit design is imported into the hardware circuit for operation, so as to realize the test of the circuit design. Among them, the hardware circuit may include: Field Programmable Gate Array (FPGA), System on Chip (SOC), etc.

[0048] In some embodiments, comparing the first verification result and 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.

[0049] In summary, in the embodiments of the present application, on the one hand, the reference model written by the hook function can capture the interaction between the verification code and the DUT, making the reference model writing more flexible and eliminating the need for complex interface connections. On the other hand, the hook function will be automatically triggered and the results can be automatically compared, which improves the verification efficiency of the verification environment platform.

[0050] Figure 3 is a flowchart of the specific steps of a hardware verification method provided by an embodiment of the present application, such as Figure 3 As shown, the method may include the following steps.

[0051] Step 201: Acquire a verification environment platform for testing a circuit design file to be tested.

[0052] In the embodiment of the present application, a plurality of interactive functions are encapsulated in the verification environment platform.

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

[0054] Step 202: Obtain a reference model including all call statements.

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

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

[0057] Step 203: In response to the input calling event, the hooked driver function is determined through the target hook function in the target calling statement.

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

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

[0060] Step 204: Execute the hooked driving function as the target function.

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

[0062] In the embodiment of the present application, for step 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 at the same time and the same parameters are passed in. When both are finished 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.

[0063] In the embodiment of the present application, the identification field represents the function that can be called by the target hook function.

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

[0065] Optionally, step 203 may also include the following sub-steps.

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

[0067] Sub-step 2032: intercepting the interaction data when the target function is executed and obtaining a first verification result.

[0068] In the embodiment of the present application, for sub-steps 2031 to 2032, when the hooked driving 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 a parameter for passing in an event captured by the monitoring function, and no return value. When the monitoring function detects 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 expectations, thereby verifying the behavior of the DUT.

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

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

[0071] In the embodiment of the present application, the identification field represents the function that can be called by the target hook function.

[0072] For example, in the implementation of the Python version, the "@monitor _hook" decorator is used to identify the monitoring function hook of the function version.

[0073] Optionally, step 203 may also include the following sub-steps.

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

[0075] 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.

[0076] 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.

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

[0078] 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.

[0079] 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; 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.

[0080] 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.

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

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

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

[0084] 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.

[0085] It should be noted that the hook function turns the writing of the reference model into the writing of multiple functions. This method may destroy the original execution order of the reference model. Therefore, when there are multiple input call events, another hook implementation method is adopted. This method implements the hook 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 captured events. At the same time, a main coroutine needs to be written in the interface reference model, in which the data in these interfaces can be actively obtained and the functions of the reference model can be completed.

[0086] 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 packaged into a separate 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): When the event specified by the Agent hook occurs, the event type and corresponding data will be packaged and placed in the queue of the interface.

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

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

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

[0090] In the embodiment of the present application, the information of the DUT may be output in a queue manner.

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

[0092] Figure 4 is a schematic diagram of a hardware verification architecture provided in an embodiment 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 will not have any impact on the verification environment, multiple different types of reference models can be attached to a verification environment. The arrow in the figure indicates that the attach operation is provided in the verification environment, which is used to attach a reference model to the verification environment. Among them, reference model 1 is written by Func function, and reference model 2 is written by Port function.

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

[0094] The first acquisition module 401 is used to acquire a verification environment platform for testing the circuit design file to be tested, wherein a plurality of interactive functions are encapsulated in the verification environment platform.

[0095] The second acquisition module 402 is used to acquire a reference model including all call statements; the call statement is used to call the associated interactive 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 interactive function and the hook function.

[0096] The call execution module 403 is used to execute the target call statement matching the call event in response to the input call event, so as to call the target interactive function through the target hook function in the target call statement for execution, and obtain the first verification result.

[0097] The result comparison module 404 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.

[0098] Optionally, the interactive function includes a driver function, calling the execution module 403, including: a first determination submodule, used to determine the hooked driver function in response to the input calling event through the target hook function in the target calling statement; a first execution submodule, used to execute the hooked driver function as the target function; a first interception submodule, used to intercept the interactive data when the target function is executed and obtain a first verification result.

[0099] Optionally, the first determination submodule includes: a determination unit, which is used to determine the hooked function in response to the input call event according to the identification field in the target call statement, and the identification field represents the function that can be called by the target hook function.

[0100] Optionally, the interactive function includes a monitoring function, calling the execution module 403, including: a second execution submodule, used to call a preset monitoring function for execution in response to an input calling event; a second interception submodule, used to intercept the interactive data when the target function is executed and obtain a first verification result.

[0101] Optionally, the result comparison module 404 includes: a first result determination submodule, which is used to determine that the verification result is passed when the return values ​​of the first verification result and the second verification result are the same; and a second result determination submodule, which is used to determine that the verification result is failed when the return values ​​of the first verification result and the second verification result are different.

[0102] Optionally, there are multiple input call events, and the above-mentioned hardware verification device 400 also includes: a third acquisition module, used to obtain an interface reference model, in which the captured call events are stored in a queue; a sequence determination module, used to determine the logical order of multiple call events; a sequential execution module, used to execute multiple target call statements matching the call events in a logical order, so as to call multiple target interaction functions through multiple target hook functions in the multiple target call statements to execute, and obtain a first verification result.

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

[0104] The data storage module is used to store the data generated when multiple target call statements are executed through a preset queue structure.

[0105] The data output module is used to package the generated data according to the logical order and output it in the form of a queue.

[0106] 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.

[0107] In summary, in the embodiments of the present application, on the one hand, the reference model written by the hook function can capture the interaction between the verification code and the DUT, making the reference model writing more flexible and eliminating the need for complex interface connections. On the other hand, the hook function will be automatically triggered and the results can be automatically compared, which improves the verification efficiency of the verification environment platform.

[0108] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0109] 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.

[0110] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0111] An embodiment of the present application provides a hardware verification device, including a memory and one or more programs, wherein the one or more programs are stored in the memory and are configured to be executed by one or more processors to perform the methods described in one or more of the above embodiments.

[0112] Figure 6is a block diagram of an electronic device 600 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.

[0113] Reference Figure 6 , the electronic device 600 may include one or more of the following components: a processing component 602 , a memory 604 , a power 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 .

[0114] The processing component 602 generally controls the overall operation of the electronic device 600, such as operations associated with display, phone calls, data communications, 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-mentioned 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.

[0115] 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 can 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, magnetic disk or optical disk.

[0116] The power supply component 606 provides power to the 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 to the electronic device 600.

[0117] 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 may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundaries of the touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. 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 may receive external multimedia data. Each front camera and rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

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

[0119] I / O interface 612 provides an interface between processing component 602 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include but are not limited to: a home button, a volume button, a start button, and a lock button.

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

[0121] The communication component 616 is used to facilitate wired or wireless communication between the electronic device 600 and other devices. The electronic device 600 can access a wireless network based on a communication standard, 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 also 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.

[0122] In an exemplary embodiment, the electronic device 600 may 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 to implement the methods provided in the embodiments of the present application.

[0123] 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 instructions can be executed by a processor 620 of an electronic device 600 to perform 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, an optical data storage device, etc.

[0124] Figure 7 is a block diagram of an electronic device 700 according to an exemplary embodiment. For example, the electronic device 700 may be provided as a server. Figure 7 The electronic device 700 includes a processing component 722, which further includes one or more processors, and a memory resource represented by a memory 732 for storing instructions that can be executed by the processing component 722, such as an application. The application 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 embodiment of the present application.

[0125] The electronic device 700 may further include a power supply 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 Server™, MacOS X™, Unix™, Linux™, FreeBSD™, or the like.

[0126] An embodiment of the present application further provides a computer program product, including a computer program, which implements the method described in the above embodiment when executed by a processor.

[0127] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the application disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary techniques in the art that are not disclosed in the present disclosure. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0128] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only 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; A second verification result obtained by simulating and running the circuit design file to be tested on the verification environment platform is obtained, and the first verification result is compared with the second verification result to obtain a verification result.

2. The hardware verification method according to claim 1, characterized in that: 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.

3. The method according to claim 2, 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.

4. The hardware verification method according to claim 1, characterized in that: The interactive function includes a monitoring function, and in response to an input call event, a target call statement matching the call event is executed to call a 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 the preset monitoring function for execution; Interaction data during the execution of the target function is intercepted and the first verification result is obtained.

5. 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.

6. 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.

7. The method according to claim 6, 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.

8. 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.

9. A hardware verification device, characterized in that: The device comprises: A first acquisition module is used to acquire a verification environment platform for testing the 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; The 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.

10. 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 8.

11. 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 8.

12. 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 8.

Images