An acquisition method of an intermediate state simulation framework, a storage medium and an electronic device

Abstract

The present application relates to the technical field of electronic design automation, in particular to a method for obtaining an intermediate state simulation framework, a storage medium and an electronic device, which extracts a hardware simulator generated software and hardware interaction running framework, a first host end component and a simulator end hardware design module; respectively obtains a preset simulator end clock controlled behavior level reference model, a preset simulator end hardware interaction interface behavior level reference model specially used for interaction with the first host end; constructs a multiplexing running framework intermediate state simulation framework, including a second host end multiplexing the first host end component and a simulation end multiplexing the hardware design module, the hardware design module communicates with the second host end through the behavior level reference model of the hardware interaction interface, the clock behavior of the hardware design module and the behavior level reference model of the hardware interaction interface is modeled by the clock controlled behavior level reference model, achieving the purpose of improving the debugging capability and reducing the compilation iteration time.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of electronic design automation, and particularly to an intermediate state simulation framework acquisition method, a storage medium and an electronic device. BACKGROUND

[0002] The software and hardware co-simulation is a core function of the current mainstream hardware emulator (Emulator), and its implementation depends on the cross-language interaction standard in the SystemVerilog standard, which is derived from the simulation requirements of the traditional software simulator (Simulator). The existing technology has a consistent processing mode for the cross-language interaction standard: the code of the language interaction standard in the traditional software simulation (simulation) is automatically generated by a hardware emulator dedicated compiler to adapt to the components of the hardware emulator, including a software and hardware interaction running framework, a first host end component, a hardware design module of the simulator end, a software and hardware interaction interface and a clock control component. In the traditional software simulator (simulator) environment, the C++ and SystemVerilog codes are mixed to verify the function of the scheme and then the same code is processed by the hardware emulator, and the same function and verification result as in the software simulator are realized in the hardware emulator, and finally the scheme is deployed and used on the hardware emulator.

[0003] However, the above process has significant defects: in the process of converting to a hardware simulator after verification is completed by a traditional software simulator, although the same cross-language interaction standard code is used, the underlying running logic of the software-hardware communication system is greatly different from the single-process mixed language simulation of the software simulator to the cross-process cross-domain hardware simulation of the hardware simulator. This difference often causes the user's developed scheme to have inconsistent functions in the hardware simulator. The causes of the problem include that the user's software side code does not match the cross-language interaction standard implementation mechanism of the hardware simulator, or the user's hardware side code does not match the cross-language interaction standard implementation mechanism of the hardware simulator. More importantly, since the standard development process is to first verify the function of the scheme in the software simulator and then transplant it to the hardware simulator, the software simulator can no longer reproduce the problems encountered on the hardware simulator, and the user can only debug on the hardware simulator, but the hardware simulator has two major pain points: first, the debugging capability is much weaker than the software simulator, and the problem convergence and positioning of the hardware simulator takes a long time. Second, if the user's hardware side code needs to be modified for iterative debugging, the compilation iteration time of the hardware simulator is much longer than that of the software simulator, usually tens to hundreds of times the time consumption. For example, when the user tries to modify the design code during debugging, the entire design needs to be recompiled and run again on the hardware simulator, and a single compilation iteration may take up to 10 hours; the user may need to go through multiple iterations to finally locate and correct the problem. Therefore, the above problems are common in mainstream hardware simulators, seriously affecting the development efficiency and deployment progress of the software-hardware co-simulation scheme, and there is an urgent need for a software simulator that can improve the debugging capability and reduce the compilation iteration time. SUMMARY

[0004] To solve the above technical problems, the technical scheme adopted by the present application is as follows: An intermediate state simulation framework acquisition method, the method comprising the following steps:

[0005] S100, extracting the running framework of the software-hardware interaction generated by the hardware simulator, the components of the first host end, and the hardware design module of the simulator end.

[0006] S200, respectively acquiring the preset behavior level reference model of the clock control of the simulator end, and the preset behavior level reference model of the software-hardware interaction interface of the simulator end which is specially used for interaction with the first host end.

[0007] S300, construct an intermediate state simulation framework, the intermediate state simulation framework reuses the running framework, the intermediate state simulation framework comprises a second host end reusing components of the first host end and a simulation end reusing the hardware design module, the hardware design module communicates with the second host end through a behavior level reference model of the software and hardware interaction interface, and clock behaviors of the hardware design module and the behavior level reference model of the software and hardware interaction interface are modeled by the clock controlled behavior level reference model.

[0008] Further, the application further provides a non-transitory computer-readable storage medium, wherein at least one instruction or at least one program is stored in the storage medium, and the at least one instruction or the at least one program is loaded and executed by a processor to implement the method.

[0009] Further, the application further provides an electronic device, comprising a processor and the non-transitory computer-readable storage medium.

[0010] The application has at least the following beneficial effects:

[0011] The embodiment of the application provides an acquisition method of an intermediate state simulation framework, which maximally reuses components in a simulation database generated by front-end compilation of a hardware simulator, simulates a running environment on a hardware platform, and constructs an intermediate state simulation framework highly consistent with a running framework of the hardware simulator, so that a real running scene of the hardware simulator is restored and powerful debugging functions of the simulator are utilized. BRIEF DESCRIPTION OF DRAWINGS

[0012] In order to more clearly illustrate the technical solutions in the embodiments of the application, the following will briefly introduce the drawings needed in the embodiment description. Obviously, the drawings in the following description are only some embodiments of the application, and for those skilled in the art, other drawings can also be obtained from these drawings without creative labor.

[0013] Figure 1 A flowchart of an acquisition method of an intermediate state simulation framework is provided for the embodiment of the application.

[0014] Figure 2 A schematic diagram of an intermediate state simulation framework is provided for the embodiment of the application. DETAILED DESCRIPTION

[0015] Clearly, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the protection scope of the present application.

[0016] Unless otherwise defined, all technical and scientific terms used in the embodiments of the present application have the same meanings as commonly understood by those skilled in the art.

[0017] Please refer to Figure 1 The method for acquiring an intermediate state simulation framework comprises the following steps:

[0018] S100, extracting a running framework of software and hardware interaction generated by a hardware simulator, components of a first host end and hardware design modules of a simulator end.

[0019] In an embodiment, before S100, there is further included: inputting the original user hardware side code and user software side code into a compiler dedicated to a hardware emulator to perform front-end compilation to generate an emulation database, wherein the emulation database includes the running framework, the first host end component and the hardware design module of the emulator end. It is to be noted that the complete compilation process of the hardware emulator includes front-end compilation and back-end compilation. The process of the front-end compilation includes: in a first stage, inputting the original user hardware side code and user software side code into the compiler, and the compiler front-end performs single hardware design module analysis to obtain an analyzed database; in a second stage, performing design elaboration on the analyzed database to generate an emulation database, i.e. establishing the connection relationship between the instantiated modules and forming a complete hierarchical design, and during the process, parameterized expansion of the modules and other processes are also included; in a third stage, performing synthesis according to the emulation database to generate a netlist. The process of the back-end compilation includes: main steps of clock conversion, timing analysis, partition, FPGA placement and routing (place&route) and the like based on the netlist. In the traditional compilation process, the emulation database is only an intermediate product in the compilation process and is not saved. However, the purpose of the present application is to build an intermediate state emulation framework, which needs to reuse the running framework, the first host end component and the hardware design module of the emulator end, and therefore the emulation database needs to be saved. The hardware design module is executable code obtained after the user hardware side code is compiled. The user software side code component in the first host end component is executable code obtained after the user software side code is compiled. It is to be noted that, for the front-end compilation, the time consumed from inputting the original user hardware side code and user software side code into the compiler to generating the emulation database is usually within half an hour, which is in the order of minutes; the time consumed from the emulation database to generating the netlist is in the order of minutes to a small number of hours. For the back-end compilation, the time consumed to complete the back-end compilation is as high as several hours to several tens of hours.

[0020] The running framework is a bottom infrastructure supporting the running of the entire hardware emulator, and is used to organize, schedule and execute various functional modules, and manage the software and hardware interaction between the first host end and the emulator end.

[0021] It should be noted that the hardware simulator not only compiles the user hardware-side code, but also builds a unified and efficiently executable environment for the entire hardware-software co-simulation, which includes the hardware design model, the software part interacting with the hardware, and the scheduling system and running framework coordinating the running of the two, so that the close integration and efficient interaction of the software and hardware can be achieved during the simulation running. Therefore, during the compilation process, the simulator-specific compiler analyzes the entire design, including the hardware environment on the simulator side and the software environment on the first host side interacting with the hardware, as well as the connection therebetween, such as the cross-language interaction interface, and then generates a database including all necessary components, such as the hardware design module, the components on the first host side, and the running framework. When the simulator loads the database, it can run a complete hardware-software co-simulation.

[0022] The components on the first host side and the hardware design module on the simulator side are both components for adapting the software and hardware interaction automatically generated in the front-end compilation stage.

[0023] It should be noted that when the simulation database is generated in the front-end compilation stage of the hardware simulator, the simulation database is directly extracted without waiting for the completion of the entire compilation process.

[0024] In an embodiment, the components on the first host side include the user software-side code components, the scheduling system, and the first host communication module. The first host communication module is configured to transmit the software and hardware interaction logic information from the outlet of the software and hardware interaction interface on the emulator to the inlet of the first host communication module, and the scheduling system is configured to associate the software and hardware interaction logic information with the user software-side code components.

[0025] In an embodiment, the hardware design module on the simulator side includes the transformed cross-language interaction interface module, wherein the cross-language interaction interface module refers to the user hardware-side code including the cross-language interaction interface being recognized and transformed into a module for adapting the software and hardware interaction by the compiler. As an example, a complete hardware simulation design can include 100 RTL modules, of which 10 RTL modules include the cross-language interaction interface. After the 10 RTL modules including the cross-language interaction interface are recognized by the compiler, the 10 RTL modules are transformed to adapt the software and hardware interaction. It should be noted that the emulator components further include the emulator communication module and the clock control module. The emulator communication module is directly connected to the transformed cross-language interaction interface module and is configured to transmit the software and hardware interaction information to the data upload IP via the system bus IP of the emulator outlet, and finally transmit the software and hardware interaction information to the host side by the data upload IP. The clock control module is configured to generate and manage one or more clock signals.

[0026] In an embodiment, the cross-language interaction interface module complies with a cross-language interaction interface standard, which is a DPI-C (Direct Programming Interface-C) interface specification or a Standard Co-Emulation Modeling Interface (SCE-MI). Other types of cross-language interaction standards for connecting models written in hardware description languages and models written in high-level languages also fall within the protection scope of the present application.

[0027] S200, respectively, acquire a preset clock-controlled behavior level reference model of the simulator end, and a preset behavior level reference model of a software and hardware interaction interface of the simulator end dedicated for interaction with the first host end.

[0028] It should be noted that, in order to achieve the purposes of high debugging capability and reduced compilation iteration time, the present application provides an intermediate-state simulator, which includes a second host end and a simulation end in an intermediate-state simulation framework, and in order to achieve component consistency with a hardware simulator, the intermediate-state simulation framework maximally reuses a running framework of the hardware simulator, but the simulator end communication module and the clock control module which cannot be directly reused need to be redesigned. As for the simulation end in the intermediate-state simulation framework, it only needs to be functionally consistent with a behavior level reference model in the hardware simulator, and therefore the clock-controlled behavior level reference model simulates the function of the simulator end clock control module, and the functions of the two are completely consistent, that is, the clock-controlled behavior level reference model is equivalent modeling of the simulator end clock control module. Similarly, the behavior level reference model of the software and hardware interaction interface is equivalent modeling of the simulator end communication module. Through the equivalent modeling, it is ensured that the interaction logic is completely consistent with that on the hardware simulator.

[0029] S300, construct an intermediate-state simulation framework, which reuses the running framework, and includes a second host end reusing components of the first host end and a simulation end reusing the hardware design module, the hardware design module communicates with the second host end through the behavior level reference model of the software and hardware interaction interface, and the clock behavior of the hardware design module and the behavior level reference model of the software and hardware interaction interface is modeled by the clock-controlled behavior level reference model. Figure 2 which shows a schematic diagram of the intermediate-state simulation framework.

[0030] It should be noted that the intermediate state simulation framework simulates the final hardware running environment to the greatest extent, that is, the software running on the second host end and the hardware design module running on the emulator end maintain the consistency of the running framework structure and the running code through the behavior level reference model of the software and hardware interaction interface. That is, the intermediate state simulation framework reuses the underlying infrastructure of the running framework for organizing, scheduling, and executing various functional modules and managing the software and hardware interaction between the second host end and the simulation end.

[0031] The second host end is equal to the first host end because the second host end reuses the components of the first host end. The use of the first host end and the second host end is only for the convenience of describing the host end before and after reuse, and does not mean that the two are different host ends.

[0032] In an implementation, when the simulation end of the intermediate state simulation framework reuses the hardware design module including the converted cross-language interaction interface module, the converted cross-language interaction interface module is directly connected with the behavior level reference model of the software and hardware interaction interface.

[0033] When a cross-language interaction interface related software and hardware co-simulation problem is found in the hardware simulator, the problem scenario, such as the corresponding code, configuration parameters, running instructions, etc., is migrated to the intermediate state simulation framework. Since the intermediate state framework restores the running logic and component interaction of the hardware simulator, the problem on the hardware simulator can be reproduced; at the same time, the powerful debugging function of the software simulator is used to quickly locate the problem cause.

[0034] In an embodiment, the updating step of the intermediate state simulation framework comprises: when the user modifies the original user hardware side code and / or the user software side code, re-compiling the modified user hardware side code and / or the user software side code by the hardware simulator, extracting a new simulation database generated by the re-compiling, and importing the new simulation database into the intermediate state simulation framework. The effect of modifying the corresponding code is verified according to the updated intermediate state simulation framework. In this process, the complete compiling process of the hardware simulator does not need to be performed, and only the simulation database needs to be generated, and the iteration time is minute-level iteration, which greatly improves the debugging efficiency. At the same time, the simulator (simulator) is used in the intermediate state simulation framework, rather than the emulator (emulator), and the debugging capability of the simulator is much higher than that of the emulator, so the debugging capability is also improved. For example, the simulator can visualize waveform data, but the emulator cannot achieve this function. It should be noted that when the new simulation database is imported into the intermediate state simulation framework, only the running framework, the host end component and the hardware design module of the simulator end of the intermediate state simulation framework are updated by the simulation database, and the clock-controlled behavior level reference model and the behavior level reference model of the software and hardware interaction interface already existing in the intermediate state simulation framework maintain the original state and are not changed.

[0035] In an embodiment, when the original user hardware side code comprises user hardware side code comprising a cross-language interaction interface, if the user modifies the user hardware side code comprising the cross-language interaction interface, the modified user hardware side code also needs to be re-compiled by the hardware simulator, a new simulation database generated by the re-compiling is extracted, and the new simulation database is imported into the intermediate state simulation framework to verify the modification effect.

[0036] In an embodiment, when the user does not modify the user hardware side code of the cross-language interaction interface, the intermediate state simulation framework is used for debugging. In the case of not modifying the code, the intermediate state simulation framework provided by the present application greatly improves the debugging capability compared with the hardware simulator.

[0037] In an embodiment, the simulation end uses a software simulator (simulator). The software simulator is any software simulator (simulator) supporting standard SystemVerilog and DPI-C. Other types of software simulators also fall within the protection scope of the present application.

[0038] In summary, the embodiment of the present application provides an intermediate state simulation framework acquisition method, which maximizes the reuse of components in the simulation database generated by the front-end compilation of the hardware simulator, simulates the running environment on the hardware platform, and constructs an intermediate state simulation framework highly consistent with the running framework of the hardware simulator, which restores the real running scene of the hardware simulator and utilizes the powerful debugging function of the simulator; meanwhile, only the simulation database generated by the front-end compilation is needed when the code is modified and iteratively compiled each time, and the entire compilation process is not needed, thereby avoiding the long waiting time of the complete hardware simulator compilation.

[0039] The embodiment of the present application also provides a non-transitory computer readable storage medium, which can be arranged in an electronic device to save at least one instruction or at least one program related to a method in the method embodiment, and the at least one instruction or the at least one program is loaded and executed by the processor to implement the method provided by the above embodiment.

[0040] The embodiment of the present application also provides an electronic device, which comprises a processor and the aforementioned non-transitory computer readable storage medium.

[0041] The embodiment of the present application also provides a computer program product, which comprises program code, and when the program product is run on an electronic device, the program code is used to make the electronic device execute the steps in the method according to various exemplary embodiments of the present application described in the specification.

[0042] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the above-mentioned division of each functional unit and module is exemplified, and in actual application, the above-mentioned functions can be completed by different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the above-described functions.

[0043] Although some specific embodiments of the present application have been described in detail by examples, those skilled in the art should understand that the above examples are only for illustration, but not for limiting the scope of the present application. Those skilled in the art should also understand that various modifications can be made to the embodiments without departing from the scope and spirit of the present application. The scope of the present application is defined by the appended claims.

Claims

1. A method for obtaining an intermediate-state simulation framework, characterized in that, The method includes the following steps: S100: Extract the hardware-software interaction runtime framework, first host-side components, and simulator-side hardware design module generated by the hardware simulator from the simulation database compiled from the front end of the hardware simulator; the simulator-side hardware design module includes a converted cross-language interaction interface module, which conforms to the cross-language interaction interface standard, namely DPI-C or SCE-MI. S200, respectively acquire the preset behavioral reference model of the clock control of the simulator and the preset behavioral reference model of the software and hardware interaction interface of the simulator for interacting with the first host. The behavioral reference model for clock control is used to simulate the function of the clock control module on the simulator side, and the behavioral reference model for the hardware and software interaction interface is an equivalent model of the communication module on the simulator side. S300, Construct an intermediate simulation framework. The intermediate simulation framework reuses the runtime framework. The intermediate simulation framework includes a second host that reuses the components of the first host and a simulation end that reuses the hardware design module. The hardware design module communicates with the second host through the behavioral reference model of the software and hardware interaction interface. The clock behavior of the hardware design module and the behavioral reference model of the software and hardware interaction interface is modeled by the clock-controlled behavioral reference model. The update steps of the intermediate simulation framework include: when the user modifies the original user hardware-side code and / or user software-side code, the hardware emulator's compiler recompiles the modified user hardware-side code and / or user software-side code, extracts the new simulation database generated by the front-end compilation, and imports the new simulation database into the intermediate simulation framework for running and debugging; in this process, it is not necessary to execute the complete compilation process of the hardware emulator, only the simulation database needs to be generated, and its iteration time is on the order of minutes; When the user does not modify the user hardware-side code of the cross-language interaction interface, it can be directly run and debugged through the intermediate simulation framework.

2. The method according to claim 1, characterized in that, The converted cross-language interaction interface module is directly connected to the behavioral reference model of the software and hardware interaction interface.

3. The method according to claim 1, characterized in that, Before S100, the process also includes: inputting the original user hardware-side code and user software-side code into a compiler dedicated to the hardware emulator for front-end compilation to generate a simulation database, wherein the simulation database includes the runtime framework, components of the first host side, and hardware design modules of the emulator side.

4. The method according to claim 1, characterized in that, The components of the first host include user software-side code components, a scheduling system, and a first host communication module.

5. The method according to claim 1, characterized in that, A cross-language interaction interface module refers to a module that contains user hardware-side code with cross-language interaction interfaces, which is then recognized by the compiler and converted into a module adapted for software and hardware interaction.

6. A non-transitory computer-readable storage medium, wherein the storage medium stores at least one instruction or at least one program segment, characterized in that, The at least one instruction or the at least one program segment is loaded and executed by the processor to implement the method as described in any one of claims 1-5.

7. An electronic device, characterized in that, Includes a processor and the non-transitory computer-readable storage medium as described in claim 6.

Images