Simulation logic system design method, electronic equipment and storage medium

Abstract

The invention provides a method for simulating a logic system design, the logic system design comprises a to-be-tested design and a first C program associated with the to-be-tested design, and the method comprises the following steps: obtaining a plurality of operations of the first C program; reading operation positions of a plurality of operations of the C program in an executable file; determining memory addresses of the plurality of operations in a memory according to the operation positions; a callback function is set in the memory address and used for obtaining function parameters when the multiple operations are executed, and the function parameters comprise at least one of a destination index, a source index, a data register or a handle type of the multiple operations; and generating an operation log of the first C program according to the function parameters of the plurality of operations.

Description

Technical Field

[0001] The present application relates to the field of computer software technology, and in particular to a method, electronic device and storage medium for simulating logic system design. Background Art

[0002] In the field of integrated circuit verification, simulation can refer to compiling a logical system design and then running it using simulation tools to simulate and test various functions of the design. The design can be, for example, an integrated circuit for a specific application (Application SpecifiC Integrated Circuit, referred to as ASIC) or a system-on-chip (System-On-Chip, referred to as SOC). Therefore, the design that is tested or verified in simulation can also be called the design under test (DUT).

[0003] In order to collaborate with the outside world during the verification process, logic system design needs to use interfaces such as VPI (Verilog Procedure Interface, VPI) or DPI (Direct Programming Interface, DPI). These interfaces are usually public interfaces based on syntax standards written in high-level languages ​​such as C. In other words, these interfaces are often directly authorized by EDA tool suppliers to customers for use. Their internal implementations are not completely consistent, but the behavior facing the caller needs to comply with the IEEE syntax specifications.

[0004] This may lead to compatibility issues between interfaces such as VPI or DPI from different suppliers, and it is difficult for users to discover these compatibility issues in advance. Summary of the invention

[0005] A first aspect of the present application provides a method for simulating a logic system design, wherein the logic system design includes a design to be tested and a first C program associated with the design to be tested, and the method includes: obtaining multiple operations of the first C program; reading the operation positions of the multiple operations of the first C program in the executable file of the first C program; determining the memory addresses of the multiple operations in the memory according to the operation positions; setting a callback function at the memory address to obtain function parameters of the multiple operations when they are executed, the function parameters including at least one of the destination index, source index, data register, or handle type of the multiple operations; and generating an operation log of the first C program according to the function parameters of the multiple operations.

[0006] 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 so that the electronic device performs the method as described in the first aspect.

[0007] A third aspect of the present application provides a non-transitory computer-readable storage medium, which stores a set of instructions for a computer, and when the set of instructions is executed, causes the computer to perform the method as described in the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] In order to more clearly illustrate the technical solutions in the present application or related technologies, the drawings required for use in the embodiments or related technical descriptions are briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0009] Figure 1 A schematic structural diagram of an exemplary electronic device according to an embodiment of the present application is shown.

[0010] Figure 2 A schematic diagram of an exemplary simulation system according to an embodiment of the present application is shown.

[0011] Figure 3 A schematic diagram of an exemplary compiler according to an embodiment of the present application is shown.

[0012] Figure 4 A schematic diagram of a C program according to an embodiment of the present application is shown.

[0013] Figure 5 A flowchart of an exemplary method for simulating logic system design according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0014] In order to make the objectives, technical solutions and advantages of the present application more clearly understood, the present application is further described in detail below in combination with specific embodiments and with reference to the accompanying drawings.

[0015] It should be noted that, unless otherwise defined, the technical terms or scientific terms used in this application should be understood by people with ordinary skills in the field to which this application belongs. The words "first", "second" and similar words used in this application do not indicate any order, quantity or importance, but are only used to distinguish different components. "Including" and similar words mean that the elements or objects appearing before the word include the elements or objects listed after the word and their equivalents, without excluding other elements or objects. "Connected" and similar words are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect.

[0016] As mentioned above, for users, two EDA tools from different vendors may provide DPIs and VPIs with similar or even identical functions but different codes. Users need to ensure that these different DPIs or VPIs with corresponding functions are equivalent in behavior during use. DPIs or VPIs are collectively referred to as C programs below.

[0017] During simulation, the simulation behaviors of multiple simulators may be inconsistent. If the inconsistency is caused by the RTL code, it can be traced back through the digital simulation waveform. However, there is no better way to deal with the inconsistency caused by the C program in the existing technology. How to quickly determine whether different C programs are equivalent in behavior is a technical problem that needs to be solved urgently.

[0018] Figure 1 FIG. 1 is a schematic diagram showing the structure of an electronic device 100 according to an embodiment of the present application. The electronic device 100 may be an electronic device for running a simulation system. Figure 1 As shown, the electronic device 100 may include: a processor 102, a memory 104, a network interface 106, a peripheral interface 108 and a bus 110. The processor 102, the memory 104, the network interface 106 and the peripheral interface 108 are connected to each other through the bus 110 in the electronic device.

[0019] Processor 102 may be a 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 (ASIC), or one or more integrated circuits. Processor 102 may be used to perform functions related to the technology described in this application. In some embodiments, processor 102 may also include multiple processors integrated into a single logical component. Figure 1As shown, the processor 102 may include a plurality of processors 102a, 102b, and 102c.

[0020] The memory 104 may be configured to store data (eg, instruction sets, computer codes, intermediate data, etc.). In some embodiments, the simulation test system for simulation test design may be a computer program stored in the memory 104. Figure 1 As shown, the data stored in the memory may include program instructions (e.g., program instructions for implementing the method of emulation logic system design of the present application) and data to be processed (e.g., the memory may store temporary codes generated during the compilation process). The processor 102 may also access the program instructions and data stored in the memory, and execute the program instructions to operate on the data to be processed. The memory 104 may include a volatile storage device or a non-volatile storage device. In some embodiments, the memory 104 may include a random access memory (RAM), a read-only memory (ROM), an optical disk, a magnetic disk, a hard disk, a solid-state drive (SSD), a flash memory, a memory stick, etc.

[0021] The network interface 106 can be configured to provide the electronic device 100 with communication with other external devices via a network. The network can be any wired or wireless network capable of transmitting and receiving data. For example, the network can 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 thereof. It is understood that the type of network is not limited to the above specific examples. In some embodiments, the network interface 106 can include any number of network interface controllers (NICs), radio frequency modules, transceivers, modems, routers, gateways, adapters, cellular network chips, etc., in any combination.

[0022] The peripheral interface 108 can be configured to connect the electronic device 100 to one or more peripheral devices to achieve information input and output. For example, the peripheral devices can include input devices such as a keyboard, a mouse, a touch pad, a touch screen, a microphone, and various sensors, and output devices such as a display, a speaker, a vibrator, and an indicator light.

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

[0024] 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 the specific implementation process, the electronic device architecture may also include other components necessary for normal operation. In addition, it can be understood by those skilled in the art that the above electronic device architecture may also only include the components necessary for implementing the embodiment of the present application, and does not necessarily include all the components shown in the figure.

[0025] Figure 2 FIG. 2 is a schematic diagram of an exemplary simulation tool 200 according to an embodiment of the present disclosure. The simulation tool 200 may be a computer program running on the electronic device 100 .

[0026] In the field of chip design, a design can usually be simulated using a simulation tool, such as the GalaxSim simulation tool produced by Xinhuazhang Technology Co., Ltd. Figure 2 The exemplary simulation tool 200 shown may include a compiler 210 and a simulator 220. The compiler 210 may receive source code 204 (e.g., a hardware description language such as VHDL, Verilog, SystemVerilog, etc.) and compile it into an executable code 206 (e.g., machine code, assembly code, software code, etc.). It is understood that the description of the logic system design may be described in a hardware description language (HDL), a register transfer level (RTL) language, binary code, assembly code, or machine code, etc. The simulator 220 may perform simulation according to the executable code 206 and output the simulation result 208. For example, the simulation tool 200 may output the simulation result 208 via Figure 1 The peripheral interface 108 outputs the data to an output device (eg, displayed on a display).

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

[0028] The front end 212 may be used to analyze the lexical, grammatical, and semantic aspects of the source code according to a specific source language.

[0029] After the lexical, grammatical and semantic analysis of the source code is completed, the middle end 214 can convert the source code into an intermediate representation (or intermediate code) and can optimize the intermediate representation. The intermediate language (intermediate code) is a syntax-oriented, equivalent internal representation code of the source code that is easy to translate into the target program. Its comprehensibility and the degree of easy generation of execution code are between the source code and the execution code. Commonly used intermediate codes include reverse Polish notation, quadruple, ternary and tree representation. For example, the middle end 214 can remove useless code, remove inaccessible code, clear unused variables, etc. Optimization can include machine-related optimization and machine-independent optimization. Among them, machine-related optimization, for example, can be the optimization of the test platform (Testbench, TB), and some test platform characteristics can be used to help optimize. Machine-independent optimization, for example, can be the optimization of the design under test (Design Under Test, DUT). The optimized intermediate representation can be passed to the back end 126 for further processing.

[0030] The back end 216 can be configured based on the target processor (e.g., Figure 1 The intermediate representation is further optimized according to the architecture of the processor 102, and an execution code is generated. Usually, the execution code is a machine code.

[0031] It is understood that the structure of the compiler is not limited to Figure 3 For example, front end 212 and middle end 214 may be collectively referred to as a front end of a compiler.

[0032] The compiler 210 can generate an execution code based on the computer code to be compiled. The computer code to be compiled can also be called source code, such as a written logic system design. Usually, the source language for writing the source code is a high-level programming language. The high-level programming language can be the above-mentioned software programming language or hardware programming language. The execution code can be, for example, assembly code, machine code, etc. Usually, the compiler 210 can be stored in Figure 1 The compiler 210 is stored in the memory 104 shown in the figure and is executed by the processor 102 to compile the logic system design into execution code. The compiler 210 can convert the description of the logic system design from a high-level language description (e.g., HDL language) into a lower-level description (e.g., RTL language or binary code) so that the underlying hardware can run the logic system design.

[0033] As mentioned above, how to quickly determine whether different C programs are equivalent in behavior is a technical problem that needs to be solved. In view of the above problem, the present application proposes a method for designing a simulation logic system.

[0034] Figure 4 A schematic diagram of a C program according to an embodiment of the present application is shown.

[0035] Although referred to as a C program in this application, the C program may be described by various high-level languages ​​such as C, C++, etc., and is used to interact with a design under test (DUT) to implement debugging of the DUT.

[0036] like Figure 4 As shown, in configuration 400, DUT 402 is connected to first C program 406 via first interface 404. First interface 404 may be an interface such as Direct Programming Interface (DPI) or Verilog Procedure Interface (VPI) for connecting C program and design under test. In some embodiments, an interface (e.g., first interface 404) may be considered as part of the C program and described separately in this application for clarity.

[0037] To determine whether the first C program 406 is behaviorally equivalent to the second C program 416 , in configuration 410 , the second C program 416 may be similarly connected to the same DUT 402 via interface 414 .

[0038] The simulation tool 200 of the embodiment of the present application can obtain multiple operations of the first C program 406 through a hook program. For example, when the simulation tool 200 simulates the DUT 402 and the first C program 406, the simulation tool 200 can detect the operation of the first C program 406 through, for example, a hook. Multiple operations of the first C program 406 are usually for the design under test 402 (for example, a vpi_put_value operation, which is used by the C program to set the value of a target signal on the DUT side).

[0039] The simulation tool 200 can, for example, use a tracing function to read the operation positions of multiple operations of the first C program 406 in an executable file (ELF). The executable file is an executable file that is loaded into the memory of the electronic device 100 after the first C program 406 is compiled. The executable file occupies a certain space in the memory, and uses the first address of this memory space as the address of the ELF file. Each operation in the executable file has its own operation position (i.e., a memory address) in this memory space. The simulation tool 200 can monitor the process corresponding to the first C program 406 (e.g., the process of the simulation tool 200) and determine the operation position of the operation (e.g., the vpi_put_value operation) via a specific tracing function. The operation position can be an offset of the operation compared to the executable file.

[0040] Therefore, the memory addresses of multiple operations in the memory can be determined according to the above offset and the address of the ELF file.

[0041] The simulation tool 200 can set a hardware breakpoint and a callback function at the memory address of an operation, thereby recording various function parameters when the operation is executed. Function parameters may include at least one of the destination index, source index, data register, or handle type of the operation. The destination index may indicate the destination of the operation of the first C program 406 (e.g., the DPI / VPI handle pointer address of the target signal to be assigned); the source index may indicate the storage address of the data to be operated (e.g., the pointer address of the numerical storage handle); the data register may be used to store some temporary data; the handle type may include an object handle, an interface handle, an event handle, etc.

[0042] These function parameters may be stored and form an operation log 408 of the first C program 406 .

[0043] Similarly, the simulation tool 200 may obtain the operation log 418 of the second C program 416 .

[0044] The simulation tool 200 may then compare the operation log 418 of the second C program 416 with the operation log 408 of the first C program 406 to determine whether the first C program 406 and the second C program 416 are substantially the same.

[0045] Substantially identical means that the operation of a C program is identical. It is understood that two substantially identical C programs may be different at the source code level.

[0046] In some embodiments, simulation tool 200 may use some diff functions to compare operation logs 408 and 418 .

[0047] In this way, the user can use the simulation tool 200 of the present application to quickly determine whether two or more C programs are substantially the same in behavior.

[0048] In addition to the above functions, the embodiments of the present application may also have other uses.

[0049] In some embodiments, the simulation tool 200 may perform drive / load analysis on the target signal using the acquired operation log.

[0050] Since some C programs of DPI / VPI can get or set the value of a target signal (eg, vpi_put_value operation), the simulation tool 200 can use the operation log to determine the driver / load of the target signal.

[0051] For example, simulation tool 200 may determine whether first C program 406 includes reading and writing of a target signal according to operation log 408 of first C program 406. In response to first C program 406 including reading and writing of the target signal, simulation tool 200 may determine that first C program 406 has a dependency on the target signal.

[0052] In some embodiments, the simulation tool 200 can utilize the acquired operation log to directly extract the operation from the operation log and apply it to the design under test without simulating the C program during playback, thereby reducing the time generated by simulating the C program during playback and improving the efficiency of debugging and playback. Playback is usually used to rerun the simulation to a specific time point, which is a common and frequently occurring operation in chip design debugging.

[0053] As described above, the first C program 406 may include an interface 404 connected to the design under test 402. The simulation tool 200 may read the plurality of operations in the operation log 408 and apply the plurality of operations to the design under test 402 via the interface 404.

[0054] It is understandable that for some C programs (e.g., DPI svGetArrayPtr), the C program can return to the user the internal pointer of the actual simulation tool, and the user can perform memory operations on the pointer to change the value of the target signal. For such C programs, the simulation tool 200 needs to record additional pointer operation information to prevent the user's storage copy (memcpy) operation from failing during playback.

[0055] By obtaining the operations of the C program during the simulation and saving them as operation logs, the time spent on resimulating the C program can be reduced in subsequent playback, thereby improving simulation efficiency.

[0056] In some application scenarios, users need to simulate the design to be tested on different computing platforms (for example, X86 platform, ARM platform, RISC-V platform). This is usually caused by large chip design companies having a variety of different servers. Different platforms may have different compilation and execution of C programs, which is usually caused by differences in compilation parameters, compilers, compilation parameters, etc. In the prior art, the C program needs to be ported and adapted before simulation. However, this introduces a lot of work, making cross-platform simulation require more manpower and time.

[0057] In view of this, in some embodiments, the user can complete the simulation of the C program and record the operation on one simulation platform, and then directly apply the recorded operation on another simulation platform, thereby avoiding the transplantation and adaptation of the C program and reducing the workload of cross-platform simulation. Specifically, the simulation tool 200 can complete the generation of the operation log 408 of the first C program 406 according to the function parameters of multiple operations in the first simulation environment, and then complete the reading of multiple operations in the operation log 408 and the application of multiple operations to the design to be tested 402 via the interface 404 in the second simulation environment. The first simulation environment and the second simulation environment are different simulation platforms, usually with different compilation parameters, compilers, or compilation parameters, etc.

[0058] Figure 5 A flowchart of a method 500 for simulating a logic system design according to an exemplary embodiment of the present application is shown. The logic system design includes a design to be tested (eg, Figure 4 A design under test 402) and a first C program associated with the design under test (eg, Figure 4 The method 500 may be performed by Figure 1 The method 500 is implemented by the electronic device 100 shown, and more specifically, is implemented by a simulation tool 200 running on the electronic device 100. The method 500 may include the following steps.

[0059] In step 502, the simulation tool 200 may obtain a plurality of operations of the first C program.

[0060] In step 504, the simulation tool 200 may read the operation locations of the plurality of operations of the first C program in the executable file of the first C program.

[0061] In step 506 , the simulation tool 200 may determine the memory addresses of the multiple operations in the memory according to the operation positions.

[0062] In step 508, the simulation tool 200 may set a callback function at the memory address to obtain function parameters of the multiple operations when they are executed. The function parameters include at least one of the destination index, source index, data register, or handle type of the multiple operations.

[0063] In step 510, the simulation tool 200 may generate an operation log of the first C program according to the function parameters of the multiple operations (eg, Figure 3 Operation log 408).

[0064] In some embodiments, the logic system design includes a second C program associated with the design under test. Similar to the above-mentioned acquisition of the operation log of the first C program, method 500 may also include: acquiring the operation log of the second C program; and comparing the operation log of the second C program with the operation log of the first C program to determine whether the first C program and the second C program are substantially the same.

[0065] In some embodiments, method 500 further includes: determining whether the first C program includes reading and writing a target signal according to an operation log of the first C program; and determining that the first C program is dependent on the target signal in response to the first C program including reading and writing the target signal.

[0066] In some embodiments, the first C program includes an interface connected to the design under test (e.g., Figure 3 The first C program further comprises: reading the plurality of operations in the operation log; and applying the plurality of operations to the design under test via the interface.

[0067] In some embodiments, generating the operation log of the first C program according to the function parameters of the multiple operations is completed in a first simulation environment; reading the multiple operations in the operation log and applying the multiple operations to the design under test via the interface are completed in a second simulation environment, and the first simulation environment is different from the second simulation environment.

[0068] In some embodiments, the interface comprises a DPI or a VPI.

[0069] The present application also provides an electronic device. The electronic device may be Figure 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 so that the electronic device performs the method 500.

[0070] The embodiment of the present application further provides a non-transitory computer-readable storage medium. The non-transitory computer-readable storage medium stores a set of instructions for a computer, and the set of instructions is used to make the computer perform the method 500 when executed.

[0071] Through the method, electronic device and storage medium provided in the embodiments of the present application, the user can store the operations in the C program in the operation log, and further use the operation log to achieve technical effects such as comparison of different C programs, drive / load analysis of target signals, saving playback time and accelerating cross-platform transplantation.

[0072] Some embodiments of the present application are described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0073] A person skilled in the art should understand that the discussion of any of the above embodiments is merely illustrative and is not intended to imply that the scope of the present application (including the claims) is limited to these examples. In line with the concept of the present application, the technical features in the above embodiments or different embodiments may be combined, the steps may be implemented in any order, and there are many other variations of the different aspects of the present application as described above, which are not provided in detail for the sake of simplicity.

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

[0075] This application is intended to cover all such substitutions, modifications and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this application should be included in the scope of protection of this application.

Claims

1. A method for designing a simulation logic system, wherein: The logic system design includes a design to be tested and a first C program associated with the design to be tested, and the method includes: Obtaining multiple operations of the first C program; Reading operation locations of a plurality of operations of the first C program in an executable file of the first C program; Determine memory addresses of the plurality of operations in the memory according to the operation positions; Setting a callback function at the memory address to obtain function parameters of the multiple operations when they are executed, the function parameters including at least one of a destination index, a source index, a data register, or a handle type of the multiple operations; and An operation log of the first C program is generated according to the function parameters of the multiple operations.

2. The method of claim 1, wherein the logic system design comprises a second C program associated with the design under test, the method further comprising: Get the operation log of the second C program; as well as An operation log of the second C program is compared with an operation log of the first C program to determine whether the first C program and the second C program are substantially identical.

3. The method of claim 1, further comprising: determining whether the first C program includes reading and writing a target signal according to the operation log of the first C program; as well as In response to the first C program including reading and writing the target signal, it is determined that the first C program has a dependency on the target signal.

4. The method of claim 1, wherein: The first C program includes an interface connected to the design under test, and the first C program further includes: reading the plurality of operations in the operation log; and The plurality of operations are applied to the design under test via the interface.

5. The method of claim 4, wherein: Generating the operation log of the first C program according to the function parameters of the multiple operations is completed in a first simulation environment; The reading of the multiple operations in the operation log and the applying of the multiple operations to the design under test via the interface are performed in a second simulation environment, The first simulation environment is different from the second simulation environment.

6. The method of claim 4, wherein: The interface includes DPI or VPI.

7. An electronic device comprising: a memory for storing a set of instructions; as well as At least one processor is configured to execute the set of instructions so that the electronic device performs the method according to any one of claims 1 to 6.

8. A non-transitory computer-readable storage medium storing a set of instructions for a computer, the set of instructions being used to cause the computer to perform the method according to any one of claims 1 to 6 when executed.

Images