CN117172168A - Method for realizing callback in simulation, electronic equipment and storage medium - Google Patents

Abstract

The application provides a method for realizing callback in simulation. The method comprises the following steps: simulating a logic system design according to a first test case, wherein the logic system design comprises a unified verification method framework, and the first test case comprises a first callback task; receiving a callback request from the unified verification method framework; running a callback adapter corresponding to the unified verification method framework according to the callback request, wherein the callback adapter comprises a first handle corresponding to the first callback task; and executing the first callback task according to the handle.

Description

Method for realizing callback in simulation, electronic equipment and storage medium

Technical Field

The present application relates to the field of computer software technologies, and in particular, to a method, an electronic device, and a storage medium for implementing callback in emulation.

Background

In the field of verification of integrated circuits, simulation may refer to compiling a logic system design followed by running with a simulation tool to perform simulation testing of various functions of the design. The design may be, for example, a design for an integrated circuit (Application Specific Integrated Circuit, abbreviated ASIC) or a System-On-Chip (abbreviated SOC) for a specific application. Thus, a design being tested or verified in simulation may also be referred to as a design under test (Design Under Test, DUT for short).

UVM (Universal Verification Methodology) is a verification environment that is often used in chip verification. UVM provides a framework for authentication and provides many of the usual authentication functions.

In addition to these pre-made functions, a callback (callback) mechanism can be used within the UVM framework when the user designs some personalized functions according to the authentication project needs. The user may use the callback to create a particular function or test case. For example, a user may design a specific callback function to handle a specific situation that occurs during the simulation process when executing a test case.

Disclosure of Invention

The first aspect of the application provides a method for realizing callback in simulation. The method comprises the following steps: simulating a logic system design according to a first test case, wherein the logic system design comprises a unified verification method framework, and the first test case comprises a first callback task; receiving a callback request from the unified verification method framework; running a callback adapter corresponding to the unified verification method framework according to the callback request, wherein the callback adapter comprises a first handle corresponding to the first callback task; and executing the first callback task according to the handle.

A second aspect of the present application provides an electronic device comprising: a memory for storing a set of instructions; and at least one processor configured to execute the set of instructions to cause the electronic device to perform the method of the first aspect.

A third aspect of the application provides a non-transitory computer readable storage medium storing a set of instructions of a computer for, when executed, causing the computer to perform the method of the first aspect.

Drawings

In order to more clearly illustrate the technical solutions of the present application or related art, the drawings that are required to be used in the description of the embodiments or related art will be briefly described below, and it is apparent that the drawings in the following description are only embodiments of the present application, and other drawings may be obtained according to the drawings without inventive effort to those of ordinary skill in the art.

Fig. 1 shows a schematic structural diagram of an exemplary electronic device according to an embodiment of the present application.

FIG. 2 illustrates a schematic diagram of an exemplary simulation tool in accordance with an embodiment of the present disclosure.

FIG. 3 shows a schematic diagram of an exemplary compiler according to an embodiment of the present application.

Fig. 4 shows a schematic diagram of implementing callbacks typically in a UVM framework.

FIG. 5 illustrates a schematic diagram of a callback mechanism according to an embodiment of the present application.

FIG. 6 illustrates an exemplary piece of code of a callback adapter according to an embodiment of the application.

FIG. 7 illustrates an exemplary piece of code for a callback task according to an embodiment of the present application.

FIG. 8 sets forth a flow chart illustrating an exemplary method for implementing callbacks in a simulation according to embodiments of the present application.

Detailed Description

The present application will be further described in detail below with reference to specific embodiments and with reference to the accompanying drawings, in order to make the objects, technical solutions and advantages of the present application more apparent.

It is to be noted that unless otherwise defined, technical or scientific terms used herein should be taken in a general sense as understood by one of ordinary skill in the art to which the present application belongs. The terms "first," "second," and the like, as used herein, do not denote any order, quantity, or importance, but rather are used to distinguish one element from another. The word "comprising" and the like means that elements or items preceding the word are included in the element or item listed after the word and equivalents thereof without precluding other elements or items. The term "coupled" and the like are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect.

Fig. 1 shows a schematic structural diagram of an electronic device 100 according to an embodiment of the application. The electronic device 100 may be an electronic device running a simulation system. As shown in fig. 1, the electronic device 100 may include: processor 102, memory 104, network interface 106, peripheral interface 108, and bus 110. Wherein the processor 102, the memory 104, the network interface 106, and the peripheral interface 108 are communicatively coupled to each other within the electronic device via a bus 110.

The processor 102 may be a central processing unit (Central Processing Unit, CPU), an image processor, a neural Network Processor (NPU), a Microcontroller (MCU), a programmable logic device, a Digital Signal Processor (DSP), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits. The processor 102 may be used to perform functions related to the techniques described herein. In some embodiments, processor 102 may also include multiple processors integrated as a single logical component. As shown in fig. 1, the processor 102 may include a plurality of processors 102a, 102b, and 102c.

The memory 104 may be configured to store data (e.g., instruction sets, computer code, intermediate data, etc.). In some embodiments, the simulation test system used to simulate the test design may be a computer program stored in memory 104. As shown in fig. 1, the data stored by the memory may include program instructions (e.g., program instructions for implementing the callback methods of the present application) as well as data to be processed (e.g., the memory may store temporary code generated during compilation). The processor 102 may also access program instructions and data stored in the memory and execute the program instructions to perform operations on the data to be processed. The memory 104 may include volatile storage or nonvolatile storage. In some embodiments, memory 104 may include Random Access Memory (RAM), read Only Memory (ROM), optical disks, magnetic disks, hard disks, solid State Disks (SSD), flash memory, memory sticks, and the like.

The network interface 106 may be configured to provide communication with other external devices to the electronic device 100 via a network. The network may be any wired or wireless network capable of transmitting and receiving data. For example, the network may be a wired network, a local wireless network (e.g., bluetooth, wiFi, near Field Communication (NFC), etc.), a cellular network, the internet, or a combination of the foregoing. It will be appreciated that the type of network is not limited to the specific examples described above. In some embodiments, network interface 106 may include any combination of any number of Network Interface Controllers (NICs), radio frequency modules, receivers, modems, routers, gateways, adapters, cellular network chips, etc.

The peripheral interface 108 may be configured to connect the electronic apparatus 100 with one or more peripheral devices to enable information input and output. For example, the peripheral devices may include input devices such as keyboards, mice, touchpads, touch screens, microphones, various types of sensors, and output devices such as displays, speakers, vibrators, and indicators.

Bus 110 may be configured to transfer information between the various components of electronic device 100 (e.g., processor 102, memory 104, network interface 106, and peripheral interface 108), such as an internal bus (e.g., processor-memory bus), an external bus (USB port, PCI-E bus), etc.

It should be noted that, although the above electronic device architecture only shows the processor 102, the memory 104, the network interface 106, the peripheral interface 108, and the bus 110, in a specific implementation, the electronic device architecture may also include other components necessary to achieve proper operation. Furthermore, it will be understood by those skilled in the art that the electronic device architecture may include only the components necessary for implementing the embodiments of the present application, and not all the components shown in the drawings.

FIG. 2 illustrates a schematic diagram of an exemplary simulation tool 200 in accordance with an embodiment of the present disclosure. The simulation tool 200 may be a computer program running on the electronic device 100.

In the field of chip design, a design may be simulated, typically with simulation tools. The simulation tool may be, for example, a GalaxSim simulation tool available from Kagaku Co., ltd. The exemplary simulation tool 200 illustrated in FIG. 2 may include a compiler 210 and a simulator 220. Compiler 210 may receive source code 204 (e.g., a hardware description language such as VHDL, verilog, systemVerilog) and compile into execution code 206 (e.g., machine code, assembly code, software code, etc.). It is understood that the description of the logic system design may be in Hardware Description Language (HDL), register transfer level (Register Transfer Level, RTL) language, binary code, assembly code, machine code, or the like. Simulator 220 may simulate in accordance with execution code 206 and output simulation results 208. For example, simulation tool 200 may output simulation results 208 via peripheral interface 108 of FIG. 1 onto an output device (e.g., displayed on a display).

FIG. 3 is a schematic diagram of an exemplary compiler 210 according to an embodiment of the present application. As shown in fig. 3, compiler 210 may include front end 212, middle end 214, and back end 216.

Front end 212 may be used to analyze the lexical, grammatical, semantic of source code according to a particular source language.

After the lexical, grammatical, and semantic analysis of the source code is complete, the middle end 214 may convert the source code into an intermediate representation (or intermediate code) and may optimize the intermediate representation. Intermediate language (intermediate code) is a grammar-oriented, equivalent internal representation code that is easily translated into source code of the target program. The degree of understandability and ease of generating the execution code is intermediate between the source code and the execution code. Common intermediate codes are inverse Polish representations, quaternions, ternary and tree representations, etc. For example, the middle-end 214 may remove unwanted code, remove inaccessible code, clear unused variables, and the like. The optimizations may include machine dependent optimizations and machine independent optimizations. Among other things, machine-related optimization may be, for example, optimization of Test Bench (TB), and may utilize characteristics of some test platforms to assist in the optimization. The machine independent optimization may be, for example, an optimization of the design under test (Design Under Test, DUT). The optimized intermediate representation may then be passed to the back end 126 for further processing.

The backend 216 may further optimize the intermediate representation according to the architecture of the target processor (e.g., the processor 102 of fig. 1) and generate the execution code. Typically, the execution code is machine code.

It is to be appreciated that the structure of the compiler is not limited to the example of fig. 3. For example, front end 212 and middle end 214 may be collectively referred to as the front end of a compiler.

Compiler 210 may generate execution code based on computer code to be compiled. The computer code to be compiled may also be referred to as source code, e.g., written logic system design. Typically, the source language in which the source code is written is a high-level programming language. The high-level programming language may be the software programming language or the hardware programming language described above. The execution code may then be, for example, assembly code, machine code, or the like. In general, compiler 210 may be stored in memory 104 shown in FIG. 1 and executed by processor 102 to compile a logical system design into execution code. Compiler 210 may convert the description of the logic system design from a high-level language description (e.g., HDL language) to a lower-level description (e.g., RTL language or binary code) so that the underlying hardware may run the logic system design.

Fig. 4 shows a schematic diagram 400 of implementing callbacks in a UVM framework in general.

As shown in fig. 4, the logic system design may include a user's design under test 404 and a UVM framework 406 that serves as a test bench (testbench). UVM framework 406 may include a series of command execution flows and authentication IP. Typically, the execution flow is associated with test case 402. When the UVM framework 406 runs multiple test cases, the UVM _do_callbacks () function in the UVM framework 406 may call a callback corresponding to a different test case in the callback pool 408 via a VIP (authentication IP) interface according to the test case. The callbacks in callback pool 408 exist in the form of class (class) of callbacks. The specific function of a callback is typically defined in a class in the form of a task or function (function).

That is, the UVM framework 406 is to continually call callbacks (e.g., callback 1, callback 2 … callback n, etc. in the callback pool 408) at various stages of the test run. The callbacks in callback pool 408 may include callbacks provided by EDA vendors or callbacks designed by the user themselves. Thus, for different test cases 402, the user needs to maintain the test case 402 on the one hand, and to synchronously maintain callbacks corresponding to the test case 402 on the other hand.

It is to be appreciated that there can be different callback pools 408 for different UVM frameworks 406 and callbacks in the callback pools 408.

FIG. 5 illustrates a schematic diagram of a callback mechanism according to an embodiment of the present application.

Fig. 5 illustrates a logical system design 500 including a design under test 404, a UVM framework 406, a callback adapter 504, and a plurality of test cases 501 and 502, among others.

As shown in FIG. 5, embodiments of the present application replace the callback pool 408 of FIG. 4 and the callbacks in the callback pool 408 with a generic callback adapter 504. At the same time, the specific function (task or function) of the callback is integrated into the test case 501 or 502. More specifically, when running to the UVM _do_callbacks () function of the UVM framework 406, the UVM framework 406 issues a callback request 505 to the callback adapter 504 to invoke a callback.

The callbacks exist in the form of virtual functions 503 and may be inherited by one or more test cases (e.g., test cases 501 or 502). Different test cases can add personalized content specific to the test case 501 or 502 by inheriting the callback virtual function 503, thereby forming specific callback tasks 5012 or 5022.

The callback adapter 504, in response to the callback request 505, may ultimately call to a specific callback task 5012 or 5022 to complete the callback request.

The design under test 404 and UVM frame 406 may then remain unchanged, which eliminates the need for the user to make large adjustments to the existing design.

Specifically, some of the underlying functionality is the same for the original callback pool 408 and for the callbacks in the callback pool 408. Thus, in an embodiment of the present application, this portion of the same basic functionality is reformed into callback adapter 504.

FIG. 6 illustrates an exemplary piece of code of the callback adapter 504, according to an embodiment of the application.

As shown in fig. 6, the callback adapter 504 may include a definition 602 of the callback adapter, a description 604 of the commonality function, and a description 606 of the personality callback function.

The callback adapter typically corresponds to a particular VIP (authentication IP). Definition 602 of fig. 6 corresponds to the average's authentication IP. It will be appreciated that the callback adapter may be designed in a similar manner for verification IP of other EDA vendors.

In the description of commonality function 604, the callback adapter provides a description of some commonality function (e.g., tlp_pkt_adapter ()) and related variables related to this callback adapter.

In the description 606 of the personality callback function, the callback adapter provides a handle of the base_test. The handle in this example points to the callback task base_test.tl_post_rx_pkt (). Whereas the tl_post_rx_pkt () task is defined in the base_test in the manner of a virtual function 702, in order to facilitate the reloading of various specific test cases. The test case 502 may reload the virtual function tl_post_rx_pkt () by inheriting from the base_test, and add the personalized content specific to the test case, that is, the callback task 5022 in the test case 502 in fig. 5, so as to associate the tl_post_rx_pkt () task with the base_test in the description 606 of the personalized callback function. It is understood that the specific functions described above are examples.

It is to be appreciated that the callback adapter may include multiple handles that point to different callback tasks.

FIG. 7 illustrates an exemplary piece of code of a callback task 5022 according to an embodiment of the present application.

In callback task 5022, the tl_post_rx_pkt () task can be defined using the virtual function 702, thereby linking the tl_post_rx_pkt () task with the base_test in the description 606 of the personality callback function.

Thus, returning to FIG. 5, during operation of UVM framework 406, callbacks may be called at particular nodes as in the prior art, and callback adapter 504 is executed. During the execution of the callback adapter 504, when the description 606 of the personality callback function is run, the execution of the program jumps to the callback task 5022 in the test case 502 due to the existence of the handle base_test, so that the execution of the specific callback function is completed.

It is to be appreciated that the callback adapter 504 can include descriptions of multiple personality callback functions such that multiple personality callback functions can be supported.

Thus, the callback adapter 504 may be fixed for a particular VIP to the user, without maintenance. The user only needs to correspondingly maintain the callback task 5022 according to the test case 502, so that the maintenance cost of the user is reduced.

FIG. 8 illustrates a flow chart of an exemplary method 800 of implementing callbacks in a simulation in accordance with an embodiment of the present application. The method 800 may be implemented by the electronic device 100 shown in fig. 1, and more particularly, by a compiler/simulation system (e.g., the simulation tool 200 in fig. 2) running on the electronic device 100. The method 800 may include the following steps.

At step 802, a logic system design (e.g., logic system design 500) including a unified verification method framework (e.g., UVM framework 406) is simulated from a first test case (e.g., test case 501 of fig. 5) including a first callback task (e.g., callback task 5012). The first callback task may correspond to the first test case.

In some embodiments, the callback adapter further includes a second handle corresponding to a second callback task (e.g., callback task 5022) corresponding to a second test case (e.g., test case 502).

In some embodiments, the logic system design includes an authentication IP, and the callback adapter corresponds to the authentication IP.

In some embodiments, the logic system design further includes a callback virtual function (e.g., callback virtual function 503). The first test case generates the first callback task based on the virtual function, and the second test case generates the second callback task based on the virtual function. For example, the test case 501 may form a callback task 5012 by inheriting the virtual function 503; the test case 502 may form a callback task 5022 by inheriting the virtual function 503.

At step 804, a callback request (e.g., callback request 505) from the unified verification method framework is received.

At step 806, a callback adapter (e.g., callback adapter 504) corresponding to the unified verification method framework is executed according to the callback request. The callback adapter includes a first handle (e.g., base_test of fig. 6) corresponding to the first callback task.

At step 808, the first callback task is executed according to the handle.

Thus, the callback adapter may be fixed for a particular authentication IP for the user, without maintenance. The user only needs to correspondingly maintain the corresponding callback tasks according to the test cases, so that the maintenance cost of the user is reduced.

The embodiment of the application also provides electronic equipment. The electronic device may be the electronic device 100 of fig. 1. The electronic device 100 may include a memory for storing a set of instructions; and at least one processor configured to execute the set of instructions to cause the electronic device to perform the method 800.

Embodiments of the present application also provide a non-transitory computer readable storage medium. The non-transitory computer readable storage medium stores a set of instructions of a computer that, when executed, are to cause the electronic device to perform the method 800.

The foregoing describes some embodiments of the present application. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

Those of ordinary skill in the art will appreciate that: the discussion of any of the embodiments above is merely exemplary and is not intended to suggest that the scope of the application (including the claims) is limited to these examples; the technical features of the above embodiments or in the different embodiments may also be combined within the idea of the application, the steps may be implemented in any order and there are many other variations of the different aspects of the application as described above, which are not provided in detail for the sake of brevity.

While the application has been described in conjunction with specific embodiments thereof, many alternatives, modifications, and variations of those embodiments will be apparent to those skilled in the art in light of the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may use the embodiments discussed.

The present application is intended to embrace all such alternatives, modifications and variances which fall within the broad scope of the appended claims. Therefore, any omission, modification, equivalent replacement, improvement, etc. of the present application should be included in the scope of the present application.

Claims (7)

1. A method of implementing a callback in a simulation, comprising:

simulating a logic system design according to a first test case, wherein the logic system design comprises a unified verification method framework, and the first test case comprises a first callback task;

receiving a callback request from the unified verification method framework;

running a callback adapter corresponding to the unified verification method framework according to the callback request, wherein the callback adapter comprises a first handle corresponding to the first callback task; and

and executing the first callback task according to the handle.

2. The method of claim 1, wherein the logical system design includes a validation IP, the callback adapter corresponding to the validation IP.

3. The method of claim 1, wherein the first callback task corresponds to the first test case.

4. The method of claim 1, wherein the callback adapter further comprises a second handle corresponding to a second callback task, the second callback task corresponding to a second test case.

5. The method of claim 4, wherein the logic system design further comprises a callback virtual function, the first test case generates the first callback task based on the virtual function, and the second test case generates the second callback task based on the virtual function.

6. An electronic device, comprising:

a memory for storing a set of instructions; and

at least one processor configured to execute the set of instructions to cause the electronic device to perform the method of any one of claims 1-5.

7. A non-transitory computer readable storage medium storing a set of instructions of a computer for, when executed, causing the computer to perform the method of any of claims 1-5.