Verification Method, Device, Electronic Device and Storage Medium for Chip Function

Abstract

The present disclosure provides a method, an apparatus, an electronic device, and a storage medium for verifying chip functions. The method includes: obtaining function description information of a chip to be verified and a memory access model; where the memory access model is generated by a preset programming language and is used to simulate providing an interface connected to the chip to be verified and simulating a memory access operation to a memory through the interface; based on the function description information and the memory access model, simulating the chip to be verified to obtain a simulation result of the chip to be verified; and obtaining a verification result of the chip to be verified based on the simulation result and a true result corresponding to the chip to be verified.

Description

Technical Field

[0001] The present disclosure relates to the technical field of chip design, and in particular, to a method, device, electronic device, and storage medium for verifying the functions of a chip. Background Art

[0002] With the increasing integration of chips, the complexity of digital logic chips has been continuously increasing. A System on Chip (SoC) is the mainstream of current chip technology development. It can integrate functions that originally required several chips and form a powerful chip through various functional components. Inside an SoC, many complex data processing modules also have multiple sub-modules. During the research and development process of such a complex SoC chip or system-level data processing module, chip verification engineers need to verify the functions of the design code written by designers. The increasing design complexity has also raised the requirements for function verification. Therefore, there is a problem of low verification efficiency in the way of chip function verification. Summary of the Invention

[0003] Embodiments of the present disclosure at least provide a method, device, electronic device, and storage medium for verifying the functions of a chip.

[0004] In a first aspect, an embodiment of the present disclosure provides a method for verifying the functions of a chip verification, including:

[0005] Obtain the function description information of the chip to be verified and a memory access model; wherein, the memory access model is generated by a preset programming language and is used to simulate providing an interface connected to the chip to be verified and simulating memory access operations to a memory through the interface;

[0006] Based on the function description information and the memory access model, perform simulation on the chip to be verified to obtain a simulation result of the chip to be verified;

[0007] Based on the simulation result and the real result corresponding to the chip to be verified, obtain a verification result of the chip to be verified.

[0008] In an optional implementation, the function description information includes: the memory access method of a function module in the chip to be verified and the function code of the chip to be verified;

[0009] The performing simulation on the chip to be verified based on the function description information and the memory access model to obtain a simulation result of the chip to be verified includes:

[0010] Based on the memory access method, instantiate the memory access model to obtain a memory access model instance corresponding to the function module;

[0011] Based on the memory access model instance and the functional code, simulate the chip to be verified to obtain the simulation result of the chip to be verified.

[0012] In an alternative embodiment, the memory access model includes: an interface model and a memory model;

[0013] Among them, the interface model is defined by a first code file implementing the memory access behavior of the interface to the memory and a second code file implementing the interface;

[0014] The memory model is defined by a third code file simulating the memory function.

[0015] In an alternative embodiment, the interface model includes: a read interface model;

[0016] In the first code file, a class simulating the read interface is defined, and the class simulating the read interface is used to simulate the memory response after the corresponding functional module initiates a read operation;

[0017] In the class simulating the read interface, at least one of the following variables is declared: a first variable: used to simulate the read interface connected to the corresponding functional module; a second variable, used to simulate the memory; a third variable, used to represent the read data sent by the read interface model to the corresponding functional module; a fourth variable, used to represent the address sent by the corresponding functional module to the read interface model;

[0018] In the class simulating the read interface, at least one of the following methods is included: a first reset method, used to reset the class simulating the read interface after receiving a reset signal; a first driving method, used to implement the behavior of the class simulating the read interface after receiving a read request;

[0019] In the second code file, the read interface model, a first address signal, and a first data signal are defined;

[0020] The first address signal includes at least one of the following: a read address valid signal, which arrives at the read interface model simultaneously with the valid address, used to indicate that the read address of this read request is valid; a read address ready signal, used to indicate that the read interface model is ready to receive a read request; a read address, which represents the address sent by the corresponding functional module to the read interface model;

[0021] The first data signal includes at least one of the following: a read data valid signal, which arrives at the read model simultaneously with the valid data, used to indicate that the read data of this read request is valid; a read data ready signal, used to indicate that the read model is ready to receive a read request; a read data, which represents the data sent by the corresponding functional module to the read interface model.

[0022] In an alternative embodiment, the interface model includes: a write interface model;

[0023] In the first code file, a class for simulating a write interface is defined. The class for simulating a write interface is used to simulate the memory response after a write operation is initiated by a corresponding functional module.

[0024] In the class for simulating a write interface, at least one of the following variables is declared: a fifth variable: used to simulate a write interface for connecting to a corresponding functional module; a second variable, used to simulate a memory; a sixth variable, used to represent the write data sent by the write interface model to a corresponding functional module; a seventh variable, used to represent the address sent by a corresponding functional module to the write interface model.

[0025] In the class for simulating a write interface, at least one of the following methods is included: a second reset method, used to reset the class for simulating a write interface after receiving a reset signal; a second drive method, used to implement the behavior of the class for simulating a write interface after receiving a write request.

[0026] In the second code file, the write interface model, as well as a second address signal and a second data signal, are defined.

[0027] The second address signal includes at least one of the following: a write address valid signal, which arrives at the write interface model simultaneously with a valid address, and is used to indicate that the write address of the current write request is valid; a write address ready signal, used to indicate that the write interface model is ready to receive a write request; a write address, representing the address sent by a corresponding functional module to the write interface model.

[0028] The second data signal includes at least one of the following: a write data valid signal, which arrives at the write model simultaneously with valid data, and is used to indicate that the write data of the current write request is valid; a write data ready signal, used to indicate that the write model is ready to receive a write request; a write data, representing the data sent by a corresponding functional module to the write interface model.

[0029] In an alternative embodiment, the third code file defines a class for simulating a memory; in the class for simulating a memory, the following variables are declared:

[0030] A data address sequence, where the index of the data address sequence is used to represent the address of the memory; each element corresponding to an index represents one byte of data stored in the corresponding memory address.

[0031] In an alternative embodiment, the interface model includes: a read interface model and a write interface model;

[0032] Instantiating the memory access model based on the memory access method to obtain memory access model instances corresponding to the functional modules respectively includes:

[0033] In response to the memory access mode indicating that the corresponding functional module performs a read operation on the memory, instantiate the read interface model and the memory model to obtain a read interface model instance and a memory model instance corresponding to the functional module;

[0034] In response to the memory access mode indicating that the corresponding functional module performs a write operation on the memory, instantiate the write interface model and the memory model to obtain a write interface model instance and a memory model instance corresponding to the functional module;

[0035] In response to the memory access mode indicating that the corresponding functional module performs a read operation and a write operation on the memory, instantiate the read interface model, the write interface model instance, and the memory model to obtain a read interface model instance, a write interface model instance, and a memory model instance corresponding to the functional module.

[0036] In an optional implementation manner, there are multiple functional modules, and instantiating the memory access model based on the memory access mode to obtain a memory access model instance corresponding to the functional module includes:

[0037] Instantiate the memory access model based on the memory access modes respectively corresponding to the multiple functional modules to obtain memory access model instances respectively corresponding to the multiple functional modules.

[0038] In an optional implementation manner, the functional description information further includes: address information of storage spaces that the multiple functional modules can respectively access;

[0039] The instantiating the memory access model based on the memory access modes respectively corresponding to the multiple functional modules to obtain memory access model instances respectively corresponding to the multiple functional modules includes:

[0040] In response to the address information of different functional modules indicating that the storage spaces that the different functional modules can respectively access overlap, instantiate different memory model instances for the different functional modules; and, instantiate the interface model based on the memory access modes respectively corresponding to the functional modules to obtain interface model instances respectively corresponding to the functional modules; wherein, the interface model instance corresponding to each functional module is connected to the memory model instance corresponding to this functional module;

[0041] In response to the address information of different functional modules indicating that the storage spaces that the different functional modules can access respectively do not overlap, based on the interface information corresponding to the different functional modules respectively, instantiate the same memory model instance for the different functional modules; and, based on the memory access methods corresponding to the respective functional modules, instantiate the interface model to obtain the interface model instances corresponding to the respective functional modules, wherein the interface model instances corresponding to the different functional modules respectively are connected to the same memory model instance.

[0042] In an alternative implementation, the simulating the chip to be verified based on the memory access model instance and the functional code to obtain the simulation result of the chip to be verified includes:

[0043] Use the simulator to execute the functional code, and in response to any functional code indicating a memory access operation on the memory using a target interface, execute the memory access model instance corresponding to the memory access operation to respond to the memory access operation;

[0044] Based on the execution result of the functional code, obtain the simulation result of the chip to be verified.

[0045] In an alternative implementation, the using the simulator to execute the functional code, and in response to any functional code indicating a memory access operation on the memory using a target interface, execute the memory access model instance corresponding to the memory access operation to respond to the memory access operation includes:

[0046] In the simulator, generate a first thread corresponding to the functional code and a second thread corresponding to the memory access model instance;

[0047] Use the first thread to execute the functional code, and in response to any functional code indicating a memory access operation on the memory using a target interface, use the first thread to send a memory access instruction to the second thread;

[0048] In response to the second thread receiving the memory access instruction sent by the first thread, use the second thread to respond to the memory access instruction based on the memory access model instance corresponding to the target interface.

[0049] In an alternative implementation, the obtaining the verification result of the chip to be verified based on the simulation result and the real result corresponding to the chip to be verified includes:

[0050] Compare the real result corresponding to the chip to be verified with the simulation result to obtain a comparison result;

[0051] Based on the comparison result, generate the verification result of the chip to be verified.

[0052] In an alternative implementation, before obtaining the function description information of the chip to be verified and the memory access model, the following steps are further included:

[0053] Based on the communication protocol adopted by the functional modules in the chip to be verified during external interaction and the interface information of the functional modules in the chip to be verified during external interaction, construct the memory access model.

[0054] In a second aspect, an embodiment of the present disclosure further provides a functional verification device for a chip, including: an acquisition module, a simulation module, and a processing module.

[0055] The acquisition module is configured to obtain the function description information of the chip to be verified and the memory access model; wherein, the memory access model is generated by a preset programming language and is used to simulate providing an interface connected to the chip to be verified and simulating the memory access operation to the memory through the interface;

[0056] The simulation module is configured to simulate the chip to be verified based on the function description information and the memory access model to obtain a simulation result of the chip to be verified;

[0057] The processing module is configured to obtain a verification result of the chip to be verified based on the simulation result and the real result corresponding to the chip to be verified.

[0058] In an alternative implementation, the function description information includes: the memory access method of the functional modules in the chip to be verified and the function code of the chip to be verified;

[0059] When the simulation module simulates the chip to be verified based on the function description information and the memory access model to obtain a simulation result of the chip to be verified, it is configured to:

[0060] Instantiate the memory access model based on the memory access method to obtain a memory access model instance corresponding to the functional module;

[0061] Simulate the chip to be verified based on the memory access model instance and the function code to obtain a simulation result of the chip to be verified.

[0062] In an alternative implementation, the memory access model includes: an interface model and a memory model;

[0063] Among them, the interface model is defined by a first code file implementing the memory access behavior of the interface to the memory and a second code file implementing the interface;

[0064] The memory model is defined by a third code file simulating the function of the memory.

[0065] In an alternative embodiment, the interface model includes: a read interface model;

[0066] In the first code file, a class for simulating a read interface is defined, and the class for simulating a read interface is used to simulate the memory response after a read operation is initiated by a corresponding functional module;

[0067] In the class for simulating a read interface, at least one of the following variables is declared: a first variable: used to simulate a read interface for connecting to a corresponding functional module; a second variable, used to simulate a memory; a third variable, used to represent the read data sent by the read interface model to a corresponding functional module; a fourth variable, used to represent the address sent by a corresponding functional module to the read interface model;

[0068] In the class for simulating a read interface, at least one of the following methods is included: a first reset method, used to reset the class for simulating a read interface after receiving a reset signal; a first driving method, used to implement the behavior of the class for simulating a read interface after receiving a read request;

[0069] In the second code file, the read interface model, as well as a first address signal and a first data signal, are defined;

[0070] The first address signal includes at least one of the following: a read address valid signal, which arrives at the read interface model simultaneously with a valid address, and is used to indicate that the read address of the current read request is valid; a read address ready signal, used to indicate that the read interface model is ready to receive a read request; a read address, representing the address sent by a corresponding functional module to the read interface model;

[0071] The first data signal includes at least one of the following: a read data valid signal, which arrives at the read model simultaneously with valid data, and is used to indicate that the read data of the current read request is valid; a read data ready signal, used to indicate that the read model is ready to receive a read request; read data, representing the data sent by a corresponding functional module to the read interface model.

[0072] In an alternative embodiment, the interface model includes: a write interface model;

[0073] In the first code file, a class for simulating a write interface is defined, and the class for simulating a write interface is used to simulate the memory response after a write operation is initiated by a corresponding functional module;

[0074] In the class for simulating a write interface, at least one of the following variables is declared: a fifth variable: used to simulate a write interface for connecting to a corresponding functional module; a second variable, used to simulate a memory; a sixth variable, used to represent the write data sent by the write interface model to a corresponding functional module; a seventh variable, used to represent the address sent by a corresponding functional module to the write interface model;

[0075] In the class of the analog write interface, it includes at least one of the following methods: a second reset method, used to reset the class of the analog write interface after receiving a reset signal; a second drive method, used to implement the behavior of the class of the analog write interface after receiving a write request.

[0076] In the second code file, the write interface model, as well as a second address signal and a second data signal are defined.

[0077] The second address signal includes at least one of the following: a write address valid signal, which arrives at the write interface model simultaneously with the valid address, used to indicate that the write address of the current write request is valid; a write address ready signal, used to indicate that the write interface model is ready to receive a write request; a write address, which represents the address sent by the corresponding functional module to the write interface model.

[0078] The second data signal includes at least one of the following: a write data valid signal, which arrives at the write model simultaneously with the valid data, indicating that the write data of the current write request is valid; a write data ready signal, indicating that the write model is ready to receive a write request; a write data, which represents the data sent by the corresponding functional module to the write interface model.

[0079] In an alternative embodiment, the third code file defines a class for simulating a memory; in the class for simulating the memory, the following variables are declared:

[0080] A data address sequence, where the index of the data address sequence is used to represent the address of the memory; each element corresponding to the index represents one byte of data stored in the corresponding memory address.

[0081] In an alternative embodiment, the interface model includes: a read interface model and a write interface model.

[0082] In an alternative embodiment, when the simulation module instantiates the memory access model based on the memory access method to obtain the memory access model instances corresponding to the functional modules respectively, it is used for:

[0083] In response to the memory access method indicating that the corresponding functional module performs a read operation on the memory, instantiate the read interface model and the memory model to obtain the read interface model instance and the memory model instance corresponding to the functional module;

[0084] In response to the memory access method indicating that the corresponding functional module performs a write operation on the memory, instantiate the write interface model and the memory model to obtain the write interface model instance and the memory model instance corresponding to the functional module;

[0085] In response to the memory access mode indicating that the corresponding functional module performs read and write operations on the memory, instantiate the read interface model, the write interface model instance, and the memory model to obtain the read interface model instance, the write interface model instance, and the memory model instance corresponding to the functional module.

[0086] In an alternative embodiment, there are multiple functional modules. When the simulation module instantiates the memory access model based on the memory access mode to obtain the memory access model instances corresponding to the functional modules, it is used for:

[0087] Instantiate the memory access model based on the memory access modes respectively corresponding to the multiple functional modules to obtain the memory access model instances respectively corresponding to the multiple functional modules.

[0088] In an alternative embodiment, the functional description information further includes: address information of the storage spaces that the multiple functional modules can respectively access;

[0089] When the simulation module instantiates the memory access model based on the memory access modes respectively corresponding to the multiple functional modules to obtain the memory access model instances respectively corresponding to the multiple functional modules, it is used for:

[0090] In response to the address information of different functional modules indicating that the storage spaces that the different functional modules can respectively access overlap, instantiate different memory model instances for the different functional modules; and, instantiate the interface model based on the memory access modes respectively corresponding to each functional module to obtain the interface model instances respectively corresponding to each functional module; wherein, the interface model instance corresponding to each functional module is connected to the memory model instance corresponding to this functional module;

[0091] In response to the address information of different functional modules indicating that the storage spaces that the different functional modules can respectively access do not overlap, instantiate the same memory model instance for the different functional modules based on the interface information respectively corresponding to the different functional modules; and, instantiate the interface model based on the memory access modes respectively corresponding to each functional module to obtain the interface model instances respectively corresponding to each functional module, wherein, the interface model instances respectively corresponding to the different functional modules are connected to the same memory model instance.

[0092] In an alternative embodiment, when the simulation module simulates the chip to be verified based on the memory access model instance and the functional code to obtain the simulation result of the chip to be verified, it is used for:

[0093] Execute the function code using the emulator. In response to any function code indicating a memory access operation on the memory using the target interface, execute the memory access model instance corresponding to the memory access operation to respond to the memory access operation;

[0094] Based on the execution result of the function code, obtain the simulation result of the chip to be verified.

[0095] In an alternative implementation, when the simulation module executes the function code using the emulator and, in response to any function code indicating a memory access operation on the memory using the target interface, executes the memory access model instance corresponding to the memory access operation to respond to the memory access operation, it is used for:

[0096] In the emulator, generate a first thread corresponding to the function code and a second thread corresponding to the memory access model instance;

[0097] Execute the function code using the first thread, and in response to any function code indicating a memory access operation on the memory using the target interface, send a memory access instruction from the first thread to the second thread;

[0098] In response to the second thread receiving the memory access instruction sent by the first thread, use the second thread to respond to the memory access instruction based on the memory access model instance corresponding to the target interface.

[0099] In an alternative implementation, when the processing module obtains the verification result of the chip to be verified based on the simulation result and the real result corresponding to the chip to be verified, it is used for:

[0100] Compare the real result corresponding to the chip to be verified with the simulation result to obtain a comparison result;

[0101] Generate the verification result of the chip to be verified based on the comparison result.

[0102] In an alternative implementation, before the simulation module obtains the function description information of the chip to be verified and the memory access model, it is also used for:

[0103] Construct the memory access model based on the communication protocol adopted by the functional modules in the chip to be verified during external interaction and the interface information of the functional modules in the chip to be verified during external interaction.

[0104] In a third aspect, an optional implementation of the present disclosure further provides an electronic device, including a processor and a memory. The memory stores machine-readable instructions executable by the processor. The processor is configured to execute the machine-readable instructions stored in the memory. When the machine-readable instructions are executed by the processor, the machine-readable instructions execute the steps in the first aspect, or any possible implementation manner in the first aspect.

[0105] In a fourth aspect, an optional implementation of the present disclosure further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is run, it executes the steps in the first aspect, or any possible implementation manner in the first aspect.

[0106] For the effect description of the above chip verification device, electronic device, and computer-readable storage medium, refer to the description of the chip function verification method above, which will not be elaborated here.

[0107] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and do not limit the technical solutions of the present disclosure.

[0108] The chip function verification method, device, electronic device, and storage medium provided by the embodiments of the present disclosure establish a memory access model. The memory access model is composed of a preset programming language and is used to simulate the behavior of the interface connected to the chip to be verified and simulate the memory access operation of the interface to the virtual memory. Thus, the memory access model simulates the real hardware logic, which does not have actual hardware significance. Through software, the memory access operation of the chip to be tested to the memory can be responded more quickly, improving the verification efficiency during chip function verification.

[0109] To make the above objects, features, and advantages of the present disclosure more obvious and understandable, the following specific embodiments are given in conjunction with the accompanying drawings and are described in detail as follows. Description of the Drawings

[0110] To more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings required for the embodiments will be briefly introduced below. The drawings herein are incorporated into the specification and constitute a part of this specification. These drawings show embodiments consistent with the present disclosure and are used together with the specification to explain the technical solutions of the present disclosure. It should be understood that the following drawings only show some embodiments of the present disclosure and should not be regarded as limiting the scope. For those of ordinary skill in the art, other related drawings can be obtained based on these drawings without creative efforts.

[0111] Figure 1 Shows a flowchart of a chip function verification method provided by an embodiment of the present disclosure;

[0112] Figure 2 shows a specific example of verifying a single functional module provided by an embodiment of the present disclosure;

[0113] Figure 3 shows a specific example of verifying multiple functional modules provided by an embodiment of the present disclosure;

[0114] Figure 4 shows another specific example of verifying multiple functional modules provided by an embodiment of the present disclosure;

[0115] Figure 5 shows a schematic diagram of a functional verification device for a chip provided by an embodiment of the present disclosure;

[0116] Figure 6 shows a schematic diagram of an electronic device provided by an embodiment of the present disclosure. Detailed implementation manners

[0117] To make the objectives, technical solutions, and advantages of the embodiments of the present disclosure clearer, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present disclosure. Apparently, the described embodiments are only some of the embodiments of the present disclosure, rather than all the embodiments. The components of the embodiments of the present disclosure described and illustrated herein can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present disclosure is not intended to limit the scope of the present disclosure claimed, but merely represents selected embodiments of the present disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of the present disclosure without creative efforts fall within the scope of protection of the present disclosure.

[0118] It has been found through research that there are many data processing modules with complex functions in a system-on-chip (SoC), that is, IP cores (an IP core refers to a mature design of a circuit module with independent functions in a chip). And there are also multiple sub-modules inside each data processing module. As the design complexity of the SoC chip or system-level data processing module increases, the requirements for functional verification also increase. To verify the SoC or data processing module, usually the required physical interface module and physical memory are integrated in the emulator; when verifying the chip function, the threads used for simulation in the emulator execute the relevant design code of the chip to be verified, and when the design code indicates that a memory access operation needs to be performed on the memory, through the bus, the interface module is used to perform the corresponding memory access operation on the memory and obtain the response result of the memory access operation, and then the response result is returned to the thread used for simulation. Since this method will actually access the memory using the physical interface module, and the actual memory access process requires a large amount of memory access time, there is a problem of low verification efficiency in verifying the chip function.

[0119] In addition, in the current verification method, since the required physical interface module and physical memory are directly integrated in the emulator, but there may be differences in the communication protocols between different chips and communication interfaces, the current verification method has problems of poor generality and small scalability.

[0120] Based on the above research, the present disclosure provides a method for verifying the functions of a chip. By establishing a memory access model, the memory access model is generated by a preset programming language and is used to simulate the behavior of the interface connected to the chip to be verified and simulate the memory access operation of the interface to a virtual memory. Thus, the real hardware logic is simulated through the memory access model, which does not have actual hardware significance. Through software, the memory access operation of the chip to be tested can be responded to more quickly, improving the verification efficiency when verifying the functions of the chip.

[0121] In addition, for different chips, a corresponding memory access model can be selected for the chip according to the communication protocol between the chip and the communication interface. Therefore, this verification method has stronger generality and scalability.

[0122] All the defects existing in the above solutions are the results obtained by the inventor after practice and careful research. Therefore, the process of discovering the above problems and the solutions proposed by the present disclosure below for the above problems should be the contributions made by the inventor to the present disclosure during the process of the present disclosure.

[0123] It should be noted that similar reference numerals and letters denote similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings.

[0124] To facilitate the understanding of this embodiment, first, a method for verifying the functions of a chip disclosed in the embodiments of the present disclosure will be introduced in detail. The execution subject of the method for verifying the functions of a chip provided in the embodiments of the present disclosure is generally an emulator; in the emulator, relevant functional modules for verifying the functions of the chip are deployed, such as a processor, a memory, etc. In some possible implementation manners, the method for verifying the functions of the chip can be implemented by the processor calling computer-readable instructions stored in the memory.

[0125] The method for verifying the functions of a chip provided in the embodiments of the present disclosure will be described below.

[0126] See Figure 1 As shown in the flowchart of the method for verifying the functions of a chip provided in the embodiments of the present disclosure, the method includes steps S101 to S103, where:

[0127] S101: Obtain the functional description information of the chip to be verified and the memory access model; wherein, the memory access model is generated by a preset programming language and is used to simulate the behavior of providing an interface connected to the chip to be verified and to simulate the memory access operation to the memory through the interface.

[0128] S102: Based on the functional description information and the memory access model, perform simulation on the chip to be verified to obtain the simulation result of the chip to be verified.

[0129] S103: Based on the simulation result and the real result corresponding to the chip to be verified, obtain the verification result of the chip to be verified.

[0130] In the example of the present disclosure, after obtaining the functional description information of the chip to be verified and the memory access model, based on the functional description information and the memory access model, perform simulation on the chip to be verified to obtain the simulation result of the chip to be verified. Based on the simulation result and the real result corresponding to the chip to be verified, obtain the verification result of the chip to be verified. In this process, the memory access model is generated by a preset programming language and is used to simulate the behavior of the interface connected to the chip to be verified and to simulate the memory access operation of the interface to the memory, so as to construct a memory access model by software, simulate the real hardware logic, and implement the memory access operation of the chip to be verified to the memory, thereby reducing the simulation time.

[0131] In addition, for different chips, a corresponding memory access model can be selected for the chip according to the communication protocol between the chip and the communication interface. Since the memory access model itself has strong portability, this verification method has stronger versatility and scalability.

[0132] The above S101 - S103 will be described separately below.

[0133] Regarding the above S101: In the example of the present disclosure, the verification method of chip functions can be applied to different scenarios; for example, it can be applied to scenarios where all functions of the entire chip need to be verified or to scenarios where partial functions of the entire chip need to be verified. Among them, the functions to be verified can include one or more modules, and this method is equally applicable.

[0134] The module that performs memory access operations on the memory can be at least part of the modules in the chip; and the memory access operation permissions of different modules can be different; among them, the memory access operation permission of any module to the memory includes, for example, any one of the following: read-only, write-only, both readable and writable.

[0135] The functional description information of the chip to be verified may include the functional description information of a single Design Under Test (DUT), or the functional description information of multiple DUTs; each DUT may include: at least one functional module.

[0136] The functional description information includes: the memory access mode of the functional modules in the chip to be verified, and the functional code of the chip to be verified.

[0137] The functional code may include, for example: Hardware Description Language (HDL) code, or Register Transfer Level (RTL) code.

[0138] The preset programming language that constitutes the memory access model may include, for example: SystemVerilog (SV) language. Memory access is used to simulate the behavior of the interface connected to the chip to be verified and to simulate the memory access operation of the interface.

[0139] In a specific implementation, different models in the entire memory access model may include, but are not limited to: an interface model and a memory model; for different functions corresponding to different models, they can be implemented through multiple SV code files.

[0140] Among them, the interface model includes: a read interface model and a write interface model; the read interface model and the write interface model are constructed in the same way. For example, they may include: a first code file for implementing the memory access behavior of the interface to the memory, and a second code file for implementing the interface; the memory model may include: a third code file for simulating the memory function.

[0141] Exemplarily, the read interface model may include:

[0142] File 1: rd_model.sv, a first code file for implementing the memory access behavior of the read interface to the memory. In this first code file, a class for simulating the read interface is defined. This class is named rd_model, also known as the read model. rd_model is used to simulate the memory response after the RTL initiates a read operation.

[0143] In this class, the following variables are declared:

[0144] The first variable rd_intf: used to simulate the read interface connected to the RTL.

[0145] The second variable glb_source: used to simulate the memory.

[0146] The third variable readdata: The read data sent by the read model to the RTL and received by the RTL.

[0147] The fourth variable readaddr: The address sent by the RTL to the read model rd_model and received by the read model.

[0148] In this class, the following methods are included:

[0149] The first reset method do_reset: Responsible for resetting and implementing the behavior after the reset signal arrives at the write model.

[0150] The first drive method do_drive: Responsible for driving and implementing the behavior after the read request arrives at the read model.

[0151] File 2: rd_intf.sv, the second code file for implementing the read interface. In this file, a read interface named rd_intf is defined. In addition, address signals and data signals are also defined. Among them:

[0152] The address signals include:

[0153] The read address valid signal read_addr_valid: Arrives at the read model simultaneously with the valid address, meaning to prove that the read address of this read request is valid.

[0154] The read address ready signal read_addr_ready: Indicates that the read model is ready to receive the read request;

[0155] The read address read_addr: Sent by the RTL to the read model rd_model and received by the read model.

[0156] The data signals include:

[0157] The read data valid signal read_data_valid: Arrives at the read model simultaneously with the valid data, indicating that the read data of this read request is valid.

[0158] The read data ready signal read_data_ready: Indicates that the read model is ready to receive the read request;

[0159] The read data read_data: Sent by the read model to the RTL and received by the RTL.

[0160] The write interface model includes, for example:

[0161] File 3: wr_model.sv, the first code file for implementing the memory access behavior of the read interface to the memory. In this first code file, a class for simulating the write interface is defined. This class is named wr_model and is also called the write model. wr_model is used to simulate the memory response after the RTL initiates a write operation.

[0162] In this class, the following variables are declared:

[0163] The fifth variable wr_intf: used to simulate the write interface that connects to the RTL.

[0164] The second variable glb_source: used to simulate the memory.

[0165] The sixth variable writedata: the write data sent from the write model to the RTL and received by the RTL.

[0166] The seventh variable writeaddr: the address sent from the RTL to the write model wr_model and received by the write model.

[0167] In this class, the following methods are included:

[0168] The second reset method do_reset: responsible for resetting and implementing the behavior after the reset signal arrives at the write model.

[0169] The second drive method do_drive: responsible for driving and implementing the behavior after the read request arrives at the write model.

[0170] File 4: wr_intf.sv, the second code file for implementing the write interface. In this file, a write interface named wr_intf is defined. In addition, address signals and data signals are defined. Among them:

[0171] The address signals include:

[0172] The write address valid signal write_addr_valid: arrives at the write model simultaneously with the valid address, meaning to prove that the write address of this write request is valid.

[0173] The write address ready signal write_addr_ready: indicates that the write model is ready to receive the write request;

[0174] The write address write_addr: the address sent from the RTL to the write model wr_model and received by the write model.

[0175] The data signals include:

[0176] Write data valid signal write_data_valid: It arrives at the write model simultaneously with the valid data, meaning to prove that the write data of this write request is valid.

[0177] Write data ready signal write_data_ready: It indicates that the write model is ready to receive the write request;

[0178] Write data write_data: It is sent from the write model to the RTL, and it is the write data received by the RTL.

[0179] The memory model includes:

[0180] File 5: glb_source.sv, which is the third code file for simulating the memory RTL. This file defines the class of glb_source and declares an associative array named data_addr_q, which is used to simulate the memory.

[0181] In this class, the following variables are declared:

[0182] Data address sequence data_addr_queue: The index of this data represents the address of the memory, and each element within the index represents one byte of data stored at this memory address. The read-write model uses this associative array to fully simulate the behavior of the DUT reading and writing the memory.

[0183] In another embodiment, a macro file can also be included in the memory access model. This macro file is used to write relevant information during the instantiation of the memory access model, such as the number of read interfaces, the number of write interfaces, the address bit width of the interfaces, the data bit width, etc. Exemplarily, this macro file is, for example, the following File 6:

[0184] File 6: glb_define.sv, which is used to define macros, including: the number of write interfaces RD_NUM, the number of read interfaces WR_NUM, and the address bit width ADDR_WIDTH and data bit width DATA_WIDTH of the interfaces, etc.

[0185] During the execution of the interface model, here taking the execution of the read interface model as an example, the write interface model can adopt the same execution method:

[0186] When the read model rd_model receives the reset signal from the read interface rd_intf, do_reset will set signals such as data_valid and addr_ready in rd_intf to 0. When the read model rd_model receives a request with a memory access mode of read, it reads the associated array data_addr_q in the object instantiated from the class glb_source, and at the same time returns the read data to rd_intf according to the timing specified by the protocol, thus implementing the read task.

[0187] When the read interface model is executing, signal transmission is carried out through the second code file. The read address valid signal read_addr_valid: the read address valid signal is used to prove that the read address of this read request is valid. If the address for which the read request needs to perform a read operation is invalid, the execution will not continue; the read address ready signal read_addr_ready: the read address ready signal is used to indicate that the read model rd_model is ready and can receive read requests.

[0188] Regarding the above S102: The function description information may include, for example: the memory access mode of the function module in the chip to be verified, and the function code of the chip to be verified.

[0189] When simulating the chip to be verified based on the function description information and the memory access model to obtain the simulation result of the chip to be verified, the following steps 21 to step 22 can be executed:

[0190] Step 21: Instantiate the memory access model based on the memory access mode to obtain the memory access model instance corresponding to the function module.

[0191] Step 22: Simulate the chip to be verified based on the memory access model instance and the function code to obtain the simulation result of the chip to be verified.

[0192] In a specific implementation:

[0193] Regarding step 21, instantiating the memory access model, for example, is to pass the relevant parameter values of the interface into the class defined in the memory access model, and then allocate specific memory space for it in the simulator. The relevant parameters may include, for example: the interface name, the signal names sent to the interface, etc.

[0194] The memory access mode may include at least one of the following: the function module performs a read operation on the memory, the function module performs a write operation on the memory, the function module performs both a read operation and a write operation on the memory. Based on the differences in the memory access mode, the specific methods for instantiating the memory access model are also different. Exemplary:

[0195] A1: When the memory access mode indicates that the corresponding functional module performs a read operation on the memory, instantiate the read interface model corresponding to the read operation and instantiate the memory model to obtain the read interface model instance corresponding to the functional module and the memory model instance.

[0196] Exemplarily, the read interface model can be instantiated using the first code file 1: rd_model.sv and the second code file 2: rd_intf.sv; the memory model can be instantiated using the third code file 5: glb_source.sv.

[0197] A2: When the memory access mode indicates that the corresponding functional module performs a write operation on the memory, instantiate the read interface model corresponding to the write operation and instantiate the memory model to obtain the write interface model instance corresponding to the functional module and the memory model instance.

[0198] Exemplarily, the write interface model can be instantiated using the first code file 3: wr_model.sv and the second code file 4: wr_intf.sv; the memory model can be instantiated using the third code file 5: glb_source.sv.

[0199] A3: When the memory access mode indicates that the corresponding functional module performs both a read operation and a write operation on the memory, instantiate the read interface model and the write interface model corresponding to the read operation and the write operation, and instantiate the memory model to obtain the read interface model instance, the write interface model instance, and the memory model instance corresponding to the functional module.

[0200] Exemplarily, for example, the read interface model can be instantiated using the first code file 1: rd_model.sv and the second code file 2: rd_intf.sv; the write interface model can be instantiated using the first code file 3: wr_model.sv and the second code file 4: wr_intf.sv; the memory model can be instantiated using the third code file 5: glb_source.sv.

[0201] In a specific implementation, for the case where there is one functional module, for this functional module, based on the memory access mode corresponding to this functional module, use the instantiation method corresponding to the memory access mode in A to A3 above to perform the operation of instantiating the memory access model for this functional module.

[0202] In addition, for the case where there are multiple functional modules, for the memory access modes corresponding to the multiple functional modules respectively, instantiate the memory access model to obtain the memory access model instances corresponding to the multiple functional modules respectively.

[0203] Then, based on the memory access model instances corresponding to multiple functional modules respectively, and the functional code, the chip to be verified can be simulated to obtain the simulation result of the chip to be verified.

[0204] In addition, when instantiating the memory access model for each functional module separately, in order to automate the simulation process, that is, instantiate the memory access model in an automated manner, the interface type and the number of interfaces can be specified in File 6: glb_define.sv.

[0205] Exemplarily, Figure 2 Shows a specific example of instantiating a memory access model for a functional module to obtain the corresponding memory access model instance when verifying a single functional module. Among them, the functional module is design_IP. For this functional module, its corresponding read / write interfaces rd / wrintf can be any protocol, including custom bus protocols and standard protocols; the instantiated memory access model instance is: sv_model. If the functional module only needs to perform read operations, then it is necessary to specify RD_NUM = 1 in File 6: glb_define.sv, and a group of rd_intf and rd_model will be instantiated during the simulation process; similarly, if the functional module needs to perform write operations, it is necessary to specify WR_NUM = 1 in File 6: glb_define.sv, and a group of wr_intf and wr_model will be instantiated during the simulation process. If both read and write are required, then both RD_NUM and WR_NUM are specified as 1, and a group of rd_intf and rd_model, and a group of wr_intf and wr_model will be instantiated during the simulation process. At the same time, a memory model glb_source is instantiated for this functional module. After instantiating the memory access model, based on the memory access model instance and design_IP, the simulator testbench is used for simulation.

[0206] Figure 3Shows a specific example of instantiating a memory access model for a functional module to obtain a corresponding memory access model instance when verifying multiple functional modules. Among them, there are 3 functional modules, namely design_0, design_1, and design_2. The memory access model instances generated by instantiation are: sv_model. Among them, design_0 can only perform read operations, design_1 can only perform write operations, and design_2 can perform both read and write operations. Furthermore, there are 2 read interface model instances that need to be instantiated, and there are also 2 write interface models that need to be instantiated. Then, it is necessary to specify RD_NUM = 2 in file 6: glb_define.sv. When instantiating during the simulation process, 2 groups of rd_intf and rd_model will be instantiated for design_0 and design_2 respectively; at the same time, specify WR_NUM = 2 in file 6: glb_define.sv. When instantiating during the simulation process, 2 groups of wr_intf and wr_model will be instantiated for design_1 and design_2 respectively. At the same time, instantiate a memory model glb_source for each functional module, which are: glb_source0, glb_source1, and glb_source2 respectively.

[0207] In another embodiment, the functional description information further includes: address information of the storage spaces that multiple functional modules can respectively access for memory. When instantiating a memory access model including multiple functional modules, different functional modules will access the storage spaces with corresponding addresses in the memory according to the corresponding address information; there are at least one of the following two situations B1 and B2 for the storage spaces accessed by different functional modules:

[0208] B1: The storage spaces that different functional modules can respectively access for memory indicated by the address information of different functional modules overlap. For example, it may include at least one of the following situations: the storage spaces required for different functional modules to perform read operations overlap, the storage spaces required for different functional modules to perform write operations overlap, and the storage spaces required for different functional modules to perform write and read operations overlap. In the above situations, it can be regarded that the storage space address is accessed by multiple functional modules. In order to avoid data errors and storage space address conflicts, etc., different memory model instances need to be instantiated for different functional modules respectively during the instantiation process. For each functional module, the interface model will also be instantiated based on the memory access method corresponding to the functional module to obtain the interface model instances corresponding to each functional module; among them, the interface model instances corresponding to each functional module are connected to the memory model instance corresponding to the functional module.

[0209] B2: The storage spaces that can be accessed by different functional modules indicated by the address information of different functional modules do not overlap. In this case, it can be considered that the storage space corresponding to each address information in this storage space will only be accessed by one functional module. Therefore, there will be no situation of storage space address conflict. During the instantiation process, in order to reduce the memory occupation of the memory model instance, the same memory model instance can be instantiated for different functional modules; at the same time, according to the memory access methods corresponding to each functional module, the interface models are instantiated for each functional module respectively to obtain the interface model instances corresponding to each functional module; among them, the interface model instances corresponding to each functional module are connected to the same memory model instance.

[0210] Exemplarily, Figure 4 It shows a specific example of instantiating a memory access model for a functional module to obtain a corresponding memory access model instance when verifying multiple functional modules. In this example, there are 3 functional modules, namely design_0, design_1, and design_2. The instantiated memory access model instance is: sv_model. Among them, design_0 can only perform read operations, design_1 can only perform write operations, and design_2 can perform both read and write operations. Among them, the address information of design_0 and the address information of design_1 indicate that the storage spaces they can access respectively do not overlap. Therefore, the same memory model instance glb_source0 can be instantiated for design_0 and design_1. At the same time, since the memory access method of design_0 is read-only, the read interface model instances rd_intf_0 and rd_model_0 are instantiated for it. The memory access method of design_1 is write-only, and the read-write interface model instances wr_intf_0 and wr_model_0 are instantiated for it.

[0211] In addition, the address information of design_2 and the address information of design_1 indicate that the storage spaces they can access respectively overlap. Therefore, a separate memory model instance glb_source1 needs to be instantiated for design_2. At the same time, since the memory access method of design_2 is both readable and writable, the read interface model instances rd_intf_1 and rd_model_1 are instantiated for it. And the write interface model instances wr_intf_1 and wr_model_1 are instantiated for it.

[0212] Regarding the above step 22: After instantiating the memory access model based on the memory access method to obtain the memory access model instance corresponding to the functional module, the simulation of the chip to be verified can be performed based on the memory access model instance and the functional code to obtain the simulation result of the chip to be verified.

[0213] When simulating the chip to be verified based on the memory access model instance and the functional code to obtain the simulation result of the chip to be verified, for example, the following method can be adopted:

[0214] Execute the functional code through the simulator; in response to any functional code indicating a memory access operation on the memory using the target interface, execute the corresponding memory access model instance for the memory access operation to respond to the memory access operation. Based on the execution result of the functional code, obtain the simulation result of the chip to be verified.

[0215] Here, during the instantiation of the memory access model, the relevant parameter values of the interface have been passed into the class defined in the memory access model, and then specific memory space is allocated for it in the simulator, and the generated memory access model instance is loaded into the corresponding memory space.

[0216] When any functional code indicates a memory access operation on the memory using the target interface, a corresponding memory access instruction will be issued. In the memory access instruction, the relevant parameters of the used interface and the memory access signal are carried. The simulator can read the corresponding memory access model instance from the memory space according to the relevant parameters of the interface carried in the memory access instruction, and use the memory access signal carried in the memory access instruction as the input of the memory access model instance, and execute the code related to the method corresponding to the memory access model instance to obtain the response result of the memory access instruction, so as to respond to the memory access operation.

[0217] Among them, a first thread for executing the functional code and a second thread for executing the memory access model instance can be generated in the simulator.

[0218] During simulation, when the first thread executes the functional code, if any functional code indicates a memory access operation on the memory using the specified target interface, send a memory access instruction from the first thread to the second thread; in response to the second thread receiving the memory access instruction sent by the first thread, use the second thread to respond to the memory access instruction based on the memory access model instance corresponding to the target interface.

[0219] That is, when the first thread executes the functional code, if the execution result of any functional code is a memory access operation on the memory, a memory access instruction is generated and sent to the second thread.

[0220] After receiving a memory access instruction, the second thread reads the corresponding memory access model instance from the memory space based on the relevant parameters of the interface carried in the memory access instruction, uses the memory access signal carried in the memory access instruction as the input of the memory access model instance, executes the method-related code corresponding to the memory access model instance, obtains the response result of the memory access instruction, and sends the response result to the first thread.

[0221] After receiving the response result, the first thread continues to execute the function code of the chip under test.

[0222] Exemplarily, taking Figure 2 as an example, when any function code indicates that the designIP in the figure needs to perform a read or write operation on the memory through the target interface, the first thread sends a memory access instruction corresponding to the read operation or write operation to the second thread for executing the memory access model instance; after receiving the memory access instructions of the read operation and write operation sent by the first thread, the second thread retrieves rd_intf_0 and the connected rd_model_0 from the memory, and executes the method defined in rd_model_0 to respond to the memory access instruction of the read operation or write operation to meet the simulation requirements.

[0223] Regarding the above S103: For example, the following method can be adopted to obtain the verification result of the integrated circuit to be verified based on the simulation result and the real result corresponding to the integrated circuit to be verified:

[0224] Compare the real result corresponding to the chip to be verified with the simulation result to obtain a comparison result;

[0225] Generate the verification result of the chip to be verified based on the comparison result.

[0226] Among them, using the chip verification method in the embodiments of the present disclosure, the function verification result of the entire chip under test, the verification results of single or multiple functions in the chip under test can be obtained; multiple modules may be included in different functions, and this method is also applicable.

[0227] Those skilled in the art can understand that in the above method of the specific embodiment, the writing order of each step does not mean a strict execution order and does not constitute any limitation to the implementation process. The specific execution order of each step should be determined according to its function and possible internal logic.

[0228] Based on the same inventive concept, an apparatus for verifying the function of a chip corresponding to a method for verifying the function of a chip is further provided in the embodiments of the present disclosure. Since the principle of solving problems by the apparatus in the embodiments of the present disclosure is similar to that of the above method for verifying the function of a chip in the embodiments of the present disclosure, the implementation of the apparatus can refer to the implementation of the method, and the repeated parts will not be described again.

[0229] Reference Figure 5 As shown, it is a schematic diagram of a function verification device for a chip provided by an embodiment of the present disclosure. The device includes: an acquisition module 51, a simulation module 52, and a processing module 53; wherein,

[0230] The acquisition module 51 is configured to acquire function description information of the chip to be verified and a memory access model; wherein, the memory access model is generated by a preset programming language and is used to simulate providing an interface connected to the chip to be verified and simulating memory access operations to the memory through the interface;

[0231] The simulation module 52 is configured to simulate the chip to be verified based on the function description information and the memory access model to obtain a simulation result of the chip to be verified;

[0232] The processing module 53 is configured to obtain a verification result of the chip to be verified based on the simulation result and a real result corresponding to the chip to be verified.

[0233] In an optional implementation manner, the function description information includes: the memory access method of the function module in the chip to be verified and the function code of the chip to be verified;

[0234] When the simulation module 52 simulates the chip to be verified based on the function description information and the memory access model to obtain a simulation result of the chip to be verified, it is configured to:

[0235] Instantiate the memory access model based on the memory access method to obtain a memory access model instance corresponding to the function module;

[0236] Simulate the chip to be verified based on the memory access model instance and the function code to obtain a simulation result of the chip to be verified.

[0237] In an optional implementation manner, the memory access model includes: an interface model and a memory model;

[0238] Wherein, the interface model is defined by a first code file implementing the memory access behavior of the interface and a second code file implementing the interface;

[0239] The memory model is defined by a third code file simulating the memory function.

[0240] In an optional implementation manner, the interface model includes: a read interface model;

[0241] In the first code file, a class for simulating a read interface is defined, and the class for simulating a read interface is used to simulate the memory response after a corresponding function module initiates a read operation;

[0242] In the class of the simulated read interface, at least one of the following variables is declared: First variable: used to simulate the read interface for connecting to the corresponding functional module; Second variable, used to simulate the memory; Third variable, used to represent the read data sent by the read interface model to the corresponding functional module; Fourth variable, used to represent the address sent by the corresponding functional module to the read interface model;

[0243] In the class of the simulated read interface, at least one of the following methods is included: First reset method, used to reset the class of the simulated read interface after receiving a reset signal; First driving method, used to implement the behavior of the class of the simulated read interface after receiving a read request;

[0244] In the second code file, the read interface model, as well as the first address signal and the first data signal, are defined;

[0245] The first address signal includes at least one of the following: Read address valid signal, which arrives at the read interface model simultaneously with the valid address, used to indicate that the read address of this read request is valid; Read address ready signal, used to indicate that the read interface model is ready to receive a read request; Read address, which represents the address sent by the corresponding functional module to the read interface model;

[0246] The first data signal includes at least one of the following: Read data valid signal, which arrives at the read model simultaneously with the valid data, indicating that the read data of this read request is valid; Read data ready signal, indicating that the read model is ready to receive a read request; Read data, which represents the data sent by the corresponding functional module to the read interface model.

[0247] In an alternative embodiment, the interface model includes: a write interface model;

[0248] In the first code file, a class for simulating a write interface is defined, and the class for simulating a write interface is used to simulate the memory response after the corresponding functional module initiates a write operation;

[0249] In the class of the simulated write interface, at least one of the following variables is declared: Fifth variable: used to simulate the write interface for connecting to the corresponding functional module; Second variable, used to simulate the memory; Sixth variable, used to represent the write data sent by the write interface model to the corresponding functional module; Seventh variable, used to represent the address sent by the corresponding functional module to the write interface model;

[0250] In the class of the simulated write interface, at least one of the following methods is included: Second reset method, used to reset the class of the simulated write interface after receiving a reset signal; Second driving method, used to implement the behavior of the class of the simulated write interface after receiving a write request;

[0251] In the second code file, the write interface model, as well as a second address signal and a second data signal, are defined.

[0252] The second address signal includes at least one of the following: a write address valid signal, which arrives at the write interface model simultaneously with the valid address and is used to indicate that the write address of the current write request is valid; a write address ready signal, which is used to indicate that the write interface model is ready to receive a write request; and a write address, which is the address sent by the corresponding functional module to the write interface model.

[0253] The second data signal includes at least one of the following: a write data valid signal, which arrives at the write model simultaneously with the valid data and is used to indicate that the write data of the current write request is valid; a write data ready signal, which indicates that the write model is ready to receive a write request; and write data, which is the data sent by the corresponding functional module to the write interface model.

[0254] In an alternative embodiment, the third code file defines a class for simulating a memory. In the class for simulating the memory, the following variables are declared:

[0255] A data address sequence, where the index of the data address sequence is used to represent the address of the memory; and each element corresponding to an index represents one byte of data stored at the corresponding memory address.

[0256] In an alternative embodiment, the interface model includes: a read interface model and a write interface model.

[0257] In an alternative embodiment, when the simulation module 52 instantiates the memory access model based on the memory access mode to obtain the memory access model instances corresponding to the functional modules, it is used for:

[0258] In response to the memory access mode indicating that the corresponding functional module performs a read operation on the memory, instantiate the read interface model and the memory model to obtain the read interface model instance and the memory model instance corresponding to the functional module;

[0259] In response to the memory access mode indicating that the corresponding functional module performs a write operation on the memory, instantiate the write interface model and the memory model to obtain the write interface model instance and the memory model instance corresponding to the functional module;

[0260] In response to the memory access mode indicating that the corresponding functional module performs both a read operation and a write operation on the memory, instantiate the read interface model, the write interface model instance, and the memory model to obtain the read interface model instance, the write interface model instance, and the memory model instance corresponding to the functional module.

[0261] In an alternative embodiment, there are multiple function modules. When the simulation module 52 instantiates the memory access model based on the memory access method to obtain the memory access model instances corresponding to the function modules, it is used for:

[0262] Instantiate the memory access model based on the memory access methods respectively corresponding to multiple function modules to obtain memory access model instances respectively corresponding to the multiple function modules.

[0263] In an alternative embodiment, the function description information further includes: address information of storage spaces that multiple function modules can respectively access;

[0264] When the simulation module 52 instantiates the memory access model based on the memory access methods respectively corresponding to multiple function modules to obtain memory access model instances respectively corresponding to the multiple function modules, it is used for:

[0265] In response to the address information of different function modules indicating that the storage spaces that the different function modules can respectively access overlap, instantiate different memory model instances for the different function modules; and, instantiate the interface model based on the memory access methods respectively corresponding to each function module to obtain interface model instances respectively corresponding to each function module; wherein, the interface model instances corresponding to each function module are connected to the memory model instance corresponding to this function module;

[0266] In response to the address information of different function modules indicating that the storage spaces that the different function modules can respectively access do not overlap, instantiate the same memory model instance for the different function modules based on the interface information respectively corresponding to the different function modules; and, instantiate the interface model based on the memory access methods respectively corresponding to each function module to obtain interface model instances respectively corresponding to each function module, wherein, the interface model instances respectively corresponding to the different function modules are connected to the same memory model instance.

[0267] In an alternative embodiment, when the simulation module 52 simulates the chip to be verified based on the memory access model instance and the function code to obtain the simulation result of the chip to be verified, it is used for:

[0268] Use a simulator to execute the function code. In response to any function code indicating a memory access operation on a memory using a target interface, execute the memory access model instance corresponding to the memory access operation to respond to the memory access operation;

[0269] Obtain the simulation result of the chip to be verified based on the execution result of the function code.

[0270] In an alternative embodiment, when the simulation module 52 executes the function code using the emulator and responds to any function code indicating a memory access operation on the memory using the target interface by executing a memory access model instance corresponding to the memory access operation to respond to the memory access operation, it is configured to:

[0271] In the emulator, generate a first thread corresponding to the function code and a second thread corresponding to the memory access model instance;

[0272] Execute the function code using the first thread, and in response to any function code indicating a memory access operation on the memory using the target interface, send a memory access instruction from the first thread to the second thread;

[0273] In response to the second thread receiving the memory access instruction sent by the first thread, use the second thread to respond to the memory access instruction based on the memory access model instance corresponding to the target interface.

[0274] In an alternative embodiment, when the processing module 53 obtains the verification result of the chip to be verified based on the simulation result and the real result corresponding to the chip to be verified, it is configured to:

[0275] Compare the real result corresponding to the chip to be verified with the simulation result to obtain a comparison result;

[0276] Generate the verification result of the chip to be verified based on the comparison result.

[0277] In an alternative embodiment, before the simulation module 52 obtains the function description information of the chip to be verified and the memory access model, it is further configured to:

[0278] Construct the memory access model based on the communication protocol adopted by the functional modules in the chip to be verified for external interaction and the interface information of the functional modules in the chip to be verified for external interaction.

[0279] For the processing flow of each module in the device and the interaction flow between each module, reference may be made to the relevant descriptions in the above method embodiments, which will not be elaborated here.

[0280] This embodiment of the disclosure further provides an electronic device, as Figure 6 shown, which is a schematic structural diagram of the electronic device provided in this embodiment of the disclosure, including:

[0281] A processor 61 and a memory 62; the memory 62 stores machine-readable instructions executable by the processor 61, and the processor 61 is configured to execute the machine-readable instructions stored in the memory 62. When the machine-readable instructions are executed by the processor 61, the processor 61 executes the following steps:

[0282] Obtain the function description information of the chip to be verified and the memory access model; wherein, the memory access model is generated by a preset programming language and is used to simulate providing an interface connected to the chip to be verified and simulating the memory access operation to the memory through the interface;

[0283] Based on the function description information and the memory access model, simulate the chip to be verified to obtain the simulation result of the chip to be verified;

[0284] Based on the simulation result and the real result corresponding to the chip to be verified, obtain the verification result of the chip to be verified.

[0285] The above-mentioned memory 62 includes a memory 621 and an external memory 622; the memory 621 here is also called the internal memory and is used to temporarily store the operation data in the processor 61 and the data exchanged with the external memory 622 such as a hard disk. The processor 61 exchanges data with the external memory 622 through the memory 621.

[0286] The specific execution process of the above instructions can refer to the steps of a method for verifying the function of a chip described in the embodiments of the present disclosure, which will not be elaborated here.

[0287] The embodiments of the present disclosure also provide a computer-readable storage medium, on which a computer program is stored. When the computer program is run by a processor, it executes the steps of a method for verifying the function of a chip described in the above method embodiments. Wherein, the storage medium can be a volatile or non-volatile computer-readable storage medium.

[0288] The embodiments of the present disclosure also provide a computer program product, which carries program codes. The instructions included in the program codes can be used to execute the steps of a method for verifying the function of a chip described in the above method embodiments. For details, refer to the above method embodiments, which will not be elaborated here.

[0289] Wherein, the above computer program product can be specifically implemented in a manner of hardware, software or a combination thereof. In an alternative embodiment, the computer program product is specifically embodied as a computer storage medium. In another alternative embodiment, the computer program product is specifically embodied as a software product, such as a Software Development Kit (SDK), etc.

[0290] Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the systems and devices described above can refer to the corresponding processes in the foregoing method embodiments, and will not be elaborated herein. In several embodiments provided in the present disclosure, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division, and there can be other division methods in actual implementation. For another example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections to each other can be through some communication interfaces. The indirect couplings or communication connections of the devices or units can be in electrical, mechanical, or other forms.

[0291] The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they can be located in one place, or can be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0292] In addition, in each embodiment of the present disclosure, the functional units can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit.

[0293] If the functions are implemented in the form of software function units and sold or used as independent products, they can be stored in a non-volatile computer-readable storage medium executable by a processor. Based on such an understanding, the technical solution of the present disclosure, in essence, or the part that contributes to the prior art, or a part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in each embodiment of the present disclosure. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROMs), random access memories (RAMs), magnetic disks, or optical discs that can store program codes.

[0294] Finally, it should be noted that the above-described embodiments are only specific embodiments of the present disclosure, which are used to illustrate the technical solutions of the present disclosure, rather than limiting them. The protection scope of the present disclosure is not limited thereto. Although the present disclosure has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that any person skilled in the art within the technical scope disclosed by the present disclosure can still modify the technical solutions recorded in the foregoing embodiments or can easily think of changes, or perform equivalent replacements on some of the technical features; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present disclosure, and should all be covered within the protection scope of the present disclosure. Therefore, the protection scope of the present disclosure should be subject to the protection scope of the claims.

Claims

1. A method for verifying the functions of a chip, characterized in that, Including: Obtain the function description information of the chip to be verified and the memory access model; wherein, the memory access model is generated by a preset programming language and is used to simulate providing an interface connected to the chip to be verified and simulating the memory access operation to the memory through the interface; the function description information includes: the memory access method of the function module in the chip to be verified and the function code of the chip to be verified; Instantiate the memory access model based on the memory access method to obtain a memory access model instance corresponding to the function module; Simulate the chip to be verified based on the memory access model instance and the function code to obtain a simulation result of the chip to be verified; Obtain a verification result of the chip to be verified based on the simulation result and the real result corresponding to the chip to be verified.

2. The method according to claim 1, characterized in that, The memory access model includes: an interface model and a memory model; Wherein, the interface model is defined by a first code file implementing the memory access behavior of the interface to the memory and a second code file implementing the interface; The memory model is defined by a third code file simulating the function of the memory.

3. The method according to claim 2, characterized in that, The interface model includes: a read interface model; In the first code file, a class simulating the read interface is defined, and the class simulating the read interface is used to simulate the memory response after the corresponding function module initiates a read operation; In the class simulating the read interface, at least one of the following variables is declared: a first variable: used to simulate the read interface connected to the corresponding function module; a second variable, used to simulate the memory; a third variable, used to represent the read data sent by the read interface model to the corresponding function module; a fourth variable, used to represent the address sent by the corresponding function module to the read interface model; In the class simulating the read interface, at least one of the following methods is included: a first reset method, used to reset the class simulating the read interface after receiving a reset signal; a first driving method, used to implement the behavior of the class simulating the read interface after receiving a read request; In the second code file, the read interface model, a first address signal, and a first data signal are defined; The first address signal includes at least one of the following: a read address valid signal, which arrives at the read interface model simultaneously with the valid address and is used to indicate that the read address of the current read request is valid; a read address ready signal, which is used to indicate that the read interface model is ready to receive a read request; a read address, which represents the address sent by the corresponding function module to the read interface model; The first data signal includes at least one of the following: a read data valid signal, which arrives at the read model simultaneously with the valid data and is used to indicate that the read data of the current read request is valid; a read data ready signal, which is used to indicate that the read model is ready to receive a read request; a read data, which represents the data sent by the corresponding function module to the read interface model.

4. The method according to claim 2 or 3, characterized in that The interface model includes: a write interface model; In the first code file, a class simulating the write interface is defined, and the class simulating the write interface is used to simulate the memory response after the corresponding function module initiates a write operation; In the class of the simulated write interface, at least one of the following variables is declared: The fifth variable: a write interface used to simulate the connection with the corresponding functional module; the second variable, used to simulate the memory; the sixth variable, used to represent the write data sent by the write interface model to the corresponding functional module; the seventh variable, used to represent the address sent by the corresponding functional module to the write interface model. In the class of the simulated write interface, at least one of the following methods is included: The second reset method, used to reset the class of the simulated write interface after receiving a reset signal; the second drive method, used to implement the behavior of the class of the simulated write interface after receiving a write request. In the second code file, the write interface model, as well as the second address signal and the second data signal, are defined. The second address signal includes at least one of the following: A write address valid signal, which arrives at the write interface model simultaneously with the valid address, used to indicate that the write address of the current write request is valid; a write address ready signal, used to indicate that the write interface model is ready to receive a write request; a write address, representing the address sent by the corresponding functional module to the write interface model. The second data signal includes at least one of the following: A write data valid signal, which arrives at the write model simultaneously with the valid data, indicating that the write data of the current write request is valid; a write data ready signal, indicating that the write model is ready to receive a write request; a write data, representing the data sent by the corresponding functional module to the write interface model.

5. The method according to claim 2, characterized in that, The third code file defines a class for simulating a memory; in the class for simulating the memory, the following variables are declared: A data address sequence, where the index of the data address sequence is used to represent the address of the memory; each element corresponding to the index represents one byte of data stored in the corresponding memory address.

6. The method according to claim 2, wherein The interface model includes: a read interface model and a write interface model. Instantiating the memory access model based on the memory access method to obtain the memory access model instances corresponding to the functional modules respectively includes: In response to the memory access method indicating that the corresponding functional module performs a read operation on the memory, instantiating the read interface model and the memory model to obtain the read interface model instance and the memory model instance corresponding to the functional module. In response to the memory access method indicating that the corresponding functional module performs a write operation on the memory, instantiating the write interface model and the memory model to obtain the write interface model instance and the memory model instance corresponding to the functional module. In response to the memory access method indicating that the corresponding functional module performs a read operation and a write operation on the memory, instantiating the read interface model, the write interface model instance, and the memory model to obtain the read interface model instance, the write interface model instance, and the memory model instance corresponding to the functional module.

7. The method according to claim 1, characterized in that There are multiple functional modules. Instantiating the memory access model based on the memory access method to obtain the memory access model instances corresponding to the functional modules includes: Based on the memory access methods corresponding to the multiple functional modules respectively, instantiating the memory access model to obtain the memory access model instances corresponding to the multiple functional modules respectively.

8. The method according to claim 7, wherein The function description information further includes: the address information of the storage spaces that can be accessed by multiple function modules respectively; Instantiating the memory access model based on the memory access modes respectively corresponding to the multiple function modules to obtain memory access model instances respectively corresponding to the multiple function modules, includes: In response to the address information of different function modules indicating that the storage spaces that can be accessed by the different function modules respectively overlap, instantiating different memory model instances for the different function modules respectively; and, instantiating the interface model based on the memory access modes respectively corresponding to the function modules to obtain interface model instances respectively corresponding to the function modules; wherein, the interface model instances corresponding to the function modules are connected to the memory model instances corresponding to the function modules; In response to the address information of different function modules indicating that the storage spaces that can be accessed by the different function modules respectively do not overlap, instantiating the same memory model instance for the different function modules based on the interface information respectively corresponding to the different function modules; and, instantiating the interface model based on the memory access modes respectively corresponding to the function modules to obtain interface model instances respectively corresponding to the function modules, wherein, the interface model instances respectively corresponding to the different function modules are connected to the same memory model instance.

9. The method according to claim 1, wherein Simulating the chip to be verified based on the memory access model instances and the function code to obtain the simulation result of the chip to be verified, includes: Using a simulator to execute the function code, and in response to any function code indicating a memory access operation on a memory using a target interface, executing the memory access model instance corresponding to the memory access operation to respond to the memory access operation; Obtaining the simulation result of the chip to be verified based on the execution result of the function code.

10. The method according to claim 9, wherein Using a simulator to execute the function code, and in response to any function code indicating a memory access operation on a memory using a target interface, executing the memory access model instance corresponding to the memory access operation to respond to the memory access operation, includes: Generating a first thread corresponding to the function code and a second thread corresponding to the memory access model instance in the simulator; Using the first thread to execute the function code, and in response to any function code indicating a memory access operation on a memory using a target interface, sending a memory access instruction from the first thread to the second thread; In response to the second thread receiving the memory access instruction sent by the first thread, using the second thread to respond to the memory access instruction based on the memory access model instance corresponding to the target interface.

11. The method according to claim 1, characterized in that, Obtaining the verification result of the chip to be verified based on the simulation result and the real result corresponding to the chip to be verified, includes: Comparing the real result corresponding to the chip to be verified with the simulation result to obtain a comparison result; Generating the verification result of the chip to be verified based on the comparison result.

12. The method according to claim 1, wherein Before obtaining the function description information and the memory access model of the chip to be verified, further includes: Construct the memory access model based on the communication protocol adopted by the functional modules in the chip to be verified during external interaction and the interface information of the functional modules in the chip to be verified during external interaction.

13. A functional verification device for a chip, characterized in that, It includes: An acquisition module, a simulation module, and a processing module; The acquisition module is configured to acquire the functional description information of the chip to be verified and the memory access model; wherein, the memory access model is constituted by a preset programming language and is used to simulate the behavior of the interface connected to the chip to be verified and simulate the memory access operation of the interface to the memory; the functional description information includes: the memory access method of the functional modules in the chip to be verified and the functional code of the chip to be verified; The simulation module is configured to instantiate the memory access model based on the memory access method to obtain a memory access model instance corresponding to the functional module; simulate the chip to be verified based on the memory access model instance and the functional code to obtain a simulation result of the chip to be verified; The processing module is configured to obtain a verification result of the chip to be verified based on the simulation result and the real result corresponding to the chip to be verified.

14. An electronic device, characterized in that, It includes: A processor and a memory, the memory stores machine-readable instructions executable by the processor, the processor is configured to execute the machine-readable instructions stored in the memory, and when the machine-readable instructions are executed by the processor, the processor executes the steps of the method for verifying the chip function according to any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, and when the computer program is run by an electronic device, the electronic device executes the steps of the method for verifying the chip function according to any one of claims 1 to 12.

Images