An integrated circuit simulation method and a hybrid simulation system

Abstract

The application provides an integrated circuit simulation method and a hybrid simulation system. The method comprises the following steps: simulating a target hardware device through a QEMU simulator to obtain a simulation model to be used; expanding the number of registers of a hardware model in a Model IP, wherein the expanded hardware model comprises original hardware registers and newly added hardware registers; obtaining a system simulation model based on the simulation model to be used and the expanded hardware model; when a simulation request is received, performing circuit simulation through the system simulation model; and if the simulation request comprises a self-defined analysis instruction, the driver further accesses the newly added hardware registers through the newly added simulation device registers to read target monitoring information recorded in the newly added hardware registers. The application can avoid modifying original code to introduce new unpredictable problems, resulting in changes in logical relationships, data type mismatches and the like.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of electronic circuit simulation, and in particular to an integrated circuit simulation method and a hybrid simulation system. BACKGROUND

[0002] The software and hardware joint simulation plays a key role in guaranteeing simulation efficiency, ensuring the quality of solutions, reducing product risks, and saving research and development costs. For example, a technical solution of QEMU (Quick Emulator) and model joint simulation is divided into three parts of an ubuntu Linux system computer, a QEMU environment, and an RTL Model (Register-Transfer Level Model), and the simulation verification stage runs the driver program in the QEMU environment, sends register read / write access / memory data exchange / interrupt processing to the RTL Model, and switches to the entity device to solve the variable problems in the running process when problems occur in the execution process.

[0003] However, the RTL Model has been basically finalized in the simulation verification stage, and if the driver program wants to obtain some state information or performance statistical information that is not originally supported in the RTL Model, the verilog code of the RTL Model needs to be modified, the new state information or performance statistical information is saved to the register of the RTL Model and mapped to the register of the QEMU environment, and then the logic processing of the register of the QEMU environment is modified to enable the software driver to read the state and performance information of the register of the RTL Model through the register of the QEMU environment. However, this method is prone to introduce new unpredictable problems, resulting in changes in logical relationships, data type mismatches, and the like. SUMMARY

[0004] In view of the deficiencies in the prior art, the present application provides an integrated circuit simulation method, which solves the problem that when the driver program wants to obtain some state information or performance statistical information that is not originally supported in the RTL Model, new unpredictable problems are easily introduced, resulting in changes in logical relationships, data type mismatches, and the like.

[0005] According to an embodiment of the present application, a first aspect provides an integrated circuit simulation method applied to a hybrid simulation system, wherein the hybrid simulation system includes an entity computer, a QEMU simulator, and a Model IP, the QEMU simulator and the Model IP run as two processes of the entity computer, the Model IP includes a hardware model based on a target hardware device, and the hardware model has been compiled into an execution file.

[0006] The integrated circuit simulation method comprises:

[0007] The target hardware device is simulated by a QEMU emulator to obtain a to-be-simulated model; the to-be-simulated model comprises a native simulation device register, an added simulation device register and a driver, and the driver is provided with access logic for the added simulation device register;

[0008] The number of registers of the hardware model in the Model IP is expanded, and the expanded hardware model comprises native hardware registers and added hardware registers; wherein the added hardware registers communicate with the added simulation device registers, the native hardware registers communicate with the native simulation device registers, and the communication modes are the same;

[0009] A system simulation model is obtained based on the to-be-simulated model and the expanded hardware model;

[0010] When a simulation request is received, circuit simulation is performed by the system simulation model; wherein if the simulation request comprises a custom analysis instruction, the driver further accesses the added hardware registers through the added simulation device registers to read target monitoring information recorded in the added hardware registers; the target monitoring information is state statistical information and / or performance statistical information that is not supported by a native hardware register pointed to by the custom analysis instruction.

[0011] Optionally, if the simulation request comprises a custom analysis instruction, before the added simulation device registers access the added hardware registers, the method comprises:

[0012] The added hardware registers are defined according to the target simulation request, so that the added hardware registers monitor performance indicators corresponding to state information and / or performance statistical information that is not supported by the native hardware registers.

[0013] Optionally, when the number of added hardware registers is greater than 1 and the performance indicators comprise multiple performance indicators, each added hardware register is defined so that one added hardware register monitors one performance indicator.

[0014] Optionally, the native hardware registers and the added hardware registers are independent of each other, and the native simulation device registers and the added simulation device registers are independent of each other.

[0015] The native hardware registers are arranged based on the address space of the native simulation device registers, and the arrangement of the added hardware registers based on the address space of the added simulation device registers is the same as or different from the arrangement of the native hardware registers.

[0016] Optionally, if the target simulation request is received, the address space type of the new simulation device register and the native simulation device register is also reset.

[0017] Optionally, if the target hardware device is a PCIE device, the communication mode of the native hardware register and the native simulation device register and the communication mode of the new hardware register and the new simulation device register are both implemented based on the RP protocol.

[0018] Optionally, if the target hardware device is an I2C interface device, the communication mode of the native hardware register and the native simulation device register and the communication mode of the new hardware register and the new simulation device register are both implemented based on the I2C protocol.

[0019] Optionally, if the target hardware device is an SPI interface device, the communication mode of the native hardware register and the native simulation device register and the communication mode of the new hardware register and the new simulation device register are both implemented based on the SPI protocol.

[0020] Optionally, if the target hardware device is a UART interface device, the communication mode of the native hardware register and the native simulation device register and the communication mode of the new hardware register and the new simulation device register are both implemented based on the UART protocol.

[0021] The second aspect provides a hybrid simulation system, comprising a physical computer, a QEMU emulator and a Model IP, wherein the QEMU emulator and the Model IP run as two processes of the physical computer; the Model IP comprises a hardware model based on a target hardware device, and the hardware model has been compiled into an execution file;

[0022] The QEMU emulator is configured to simulate the target hardware device and obtain a simulation model to be used; the simulation model to be used comprises a native simulation device register, a new simulation device register and a driver, and the driver is configured with access logic for the new simulation device register;

[0023] The Model IP is configured to expand the number of registers of the hardware model, and the expanded hardware model comprises a native hardware register and a new hardware register; the new hardware register communicates with the new simulation device register, the native hardware register communicates with the native simulation device register, and the communication modes are the same.

[0024] The to-be-used simulation model and the extended hardware model are used as a system simulation model, and when a simulation request is received, circuit simulation is performed through the system simulation model; if the simulation request includes a custom analysis instruction, the driver further accesses the new hardware register through the new simulation device register to read the target monitoring information recorded in the new hardware register; the target monitoring information is state statistical information and / or performance statistical information that is not supported by the native hardware register pointed to by the custom analysis instruction.

[0025] The beneficial effects of the present application are that the new state detection and performance statistics functions are realized through the new simulation register and the new hardware register, new unpredictable problems are avoided by modifying the verilog code of the RTL Model, and the occurrence of logical relationship changes, data type mismatches, and the like is avoided. BRIEF DESCRIPTION OF DRAWINGS

[0026] Figure 1 The integrated circuit simulation method of the embodiment of the present application is shown in the implementation flow diagram.

[0027] Figure 2 The structure diagram of the hybrid simulation system of another embodiment of the present application is shown. DETAILED DESCRIPTION

[0028] The technical solutions in the present application will be further described below with reference to the accompanying drawings and embodiments.

[0029] As shown in Figure 1 , the embodiment of the present application proposes an integrated circuit simulation method applied to a hybrid simulation system, the hybrid simulation system including a physical computer, a QEMU emulator, and a Model IP, the QEMU emulator and the Model IP being run as two processes of the physical computer; the Model IP includes a hardware model based on a target hardware device, and the hardware model has been compiled into an execution file.

[0030] It should be noted that the Model IP is a circuit design module or functional block that can be reused, and the hardware model included in the Model IP in the embodiment of the present application is provided by a third party producing or selling the target hardware device.

[0031] Referring to Figure 1 , the integrated circuit simulation method includes but is not limited to the following steps:

[0032] S1, simulate the target hardware device through the QEMU emulator to obtain a to-be-used simulation model; the to-be-used simulation model includes a native simulation device register, a new simulation device register, and a driver, and the driver is provided with access logic to the new simulation device register;

[0033] S2, expand the number of registers of the hardware model in the Model IP, the expanded hardware model comprising native hardware registers and new hardware registers; wherein the new hardware registers communicate with the new simulation device registers, the native hardware registers communicate with the native simulation device registers, and the communication modes are the same;

[0034] S3, obtaining a system simulation model based on the to-be-used simulation model and the expanded hardware model;

[0035] S4, when receiving a simulation request, performing circuit simulation through the system simulation model; wherein, if the simulation request comprises a custom analysis instruction, the driver further accesses the new hardware registers through the new simulation device registers to read target monitoring information recorded in the new hardware registers; the target monitoring information is state statistical information and / or performance statistical information that is not supported by the native hardware registers pointed to by the custom analysis instruction.

[0036] For the above step S1, the new simulation device register is mainly used in step S3 to read the target monitoring information recorded in the new hardware registers, i.e. state information and / or performance statistical information that is not supported by the native hardware registers. This is because the native simulation register is used for register access, and the logic in the to-be-used simulation model has been fixed, so that the spatial arrangement of the native simulation register has been determined, and the register function corresponding to each address has been determined. Therefore, when a new access object, i.e. a new hardware register, appears, the present embodiment reads through the new simulation device register, which is separated from the function of the native simulation device register, to avoid a large amount of logic modification in the to-be-used simulation model.

[0037] For example: the address space of 0x0000~0x1000 is the native simulation register for register access, and 0x00 register is the control register and 0x04 register is the interrupt register. On this basis, if a new register access is added to the native simulation register, the new register access is arranged after 0x1000, such as 0x1000~0x2000. This way of obtaining new simulation registers by overall rearrangement will cause a large amount of logic modification.

[0038] For the above step S2, similarly, the hardware model is expanded to obtain new hardware registers, which also avoids a large amount of logic modification of the hardware model to implement the custom analysis instruction.

[0039] For the above step S2, the user-defined analysis instruction is an instruction formulated by the user according to specific analysis requirements, and the target monitoring information is state statistical information and / or performance statistical information that is not supported by the original hardware register pointed to by the user-defined analysis instruction. Therefore, after the user formulates the user-defined analysis instruction according to specific requirements, the embodiment of the present application defines a new hardware register and a new simulation device register according to the user-defined analysis instruction, so that the user can obtain the target monitoring information, such as running state (start / stop / exception), cache hit rate, instruction execution speed, and the like, to meet the specific analysis requirements of the user, and thus intuitively and accurately understand the model running performance, helping to debug and optimize the model.

[0040] In addition, in the embodiment of the present application, the original hardware register and the new hardware register in the above steps S1 and S2 are independent of each other, and the original simulation device register and the new simulation device register are independent of each other; the original hardware register is arranged based on the address space of the original simulation device register, and the new hardware register is arranged based on the address space of the new simulation device register, which can be the same or different. For example, BAR2 is completely independent of BAR0 space, and the address spaces do not affect each other. The address space of the new register can be arranged arbitrarily, for example, the address space of the new register is arranged as 0x0000-0x1000 space of BAR2, which does not affect 0x0000-0x1000 space of BAR0.

[0041] To realize the access of the driver to the new simulation device register in the to-be-used simulation model, the above step S1 customizes the access logic of the driver to the new simulation device register; to realize the communication of the new simulation device register to the new hardware register in the extended hardware model, in the above step S2, the communication of the new hardware register is defined, that is, the communication of the original hardware register and the original simulation device register. The function definition of the new simulation device register and the function definition of the new hardware register are realized before the system simulation model performs circuit simulation when the simulation request of step S4 includes the user-defined analysis instruction, including:

[0042] According to the user-defined analysis instruction, the new hardware register and the new simulation device register are defined to monitor and record the target monitoring information.

[0043] In a better implementation, when the number of new hardware registers is greater than 1 and the performance indicators include multiple indicators, each new hardware register is defined to monitor one performance indicator. By designing multiple new registers for different performance indicator monitoring, data confusion or inaccuracy is avoided, which helps to accurately analyze the performance of the CPU under different loads.

[0044] For the above step S4, in a specific application, the native simulation device register usually includes at least two, and the native hardware register usually includes at least two, one for register access and one for memory exchange. When the new hardware register and the new simulation device register are obtained through the above steps S1 and S2, the native simulation device register and the native hardware register can maintain the original function, or the function of one of the registers can be modified according to the actual situation before the new hardware register and the new simulation device register are needed. Based on this, before the above step S4, it includes:

[0045] If the simulation request includes a custom analysis instruction, the address space type of the new simulation device register and the native simulation device register is reset.

[0046] It can be understood that when the simulation request does not include a custom analysis instruction, the driver reads the simulation information and statistical information recorded by the native hardware register through the native simulation device register, combines the simulation information and statistical information recorded by the native simulation device register, and outputs the simulation result.

[0047] According to the above steps S1 to S4, the embodiment of the application realizes the functions of new state detection and performance statistics through the new simulation register and the new hardware register, avoids modifying the verilog code of the RTL Model to introduce new unpredictable problems, and causes the occurrence of logical relationship changes, data type mismatches and the like. And this way has the advantages of real-time state performance monitoring, non-intrusiveness, customizability and the like. In actual application, by adding additional registers specially used for state and performance detection, there are many benefits for the driver software, such as avoiding modifying the native supporting driver logic, only adding operation logic for BAR2, decoupling from the original code, clear logic, and only needing to check the new logic in the simulation model and the extended hardware model when a problem occurs.

[0048] It should be noted that the integrated circuit simulation method provided by the embodiment of the present application does not limit the type of target hardware device, and several types of target hardware devices are exemplarily proposed and described herein. In an embodiment, if the target hardware device is a PCIE device, the communication mode of the native hardware register and the native simulation device register and the communication mode of the new hardware register and the new simulation device register are both realized based on the RP protocol. In another embodiment, if the target hardware device is an I2C interface device, the communication mode of the native hardware register and the native simulation device register and the communication mode of the new hardware register and the new simulation device register are both realized based on the I2C protocol. In an embodiment, if the target hardware device is an SPI interface device, the communication mode of the native hardware register and the native simulation device register and the communication mode of the new hardware register and the new simulation device register are both realized based on the SPI protocol. In yet another embodiment, if the target hardware device is a UART interface device, the communication mode of the native hardware register and the native simulation device register and the communication mode of the new hardware register and the new simulation device register are both realized based on the UART protocol.

[0049] As shown in Figure 2 Another embodiment of the present application provides a hybrid simulation system, which comprises an entity computer 21, a QEMU simulator 22 and a Model IP 23, the QEMU simulator 22 and the Model IP 23 are run as two processes of the entity computer 21; the Model IP 23 comprises a hardware model based on a target hardware device, and the hardware model has been compiled into an execution file; the QEMU simulator 22 is used for simulating the target hardware device to obtain a simulation model to be used; and the Model IP 23 is used for expanding the number of registers of the hardware model to obtain an expanded hardware model. The simulation model to be used and the expanded hardware model are used as a system simulation model to perform integrated circuit simulation.

[0050] In the embodiment of the present application, the target hardware device is a PCIE device, the entity computer 21 is an ubuntu PC, and the QEMU simulator 22 is used for simulating the target hardware device to obtain a simulation model to be used. Figure 2To be simulated model includes native simulation device registers BAR0 and BAR1, newly added simulation device register BAR2 and driver, the extended hardware model includes native hardware registers reg_old0 and reg_old1, newly added hardware registers reg_new1 and reg_new2; wherein, BAR0 is used to access reg_old0 and reg_old1, and communication is established based on RP communication protocol. The newly added hardware registers reg_new1 and reg_new2 are used to realize some state information or performance statistical information that the native hardware registers reg_old0 and reg_old1 do not support, therefore, the newly added simulation device register BAR2 is used to access the newly added hardware registers reg_new1 and reg_new2, and communication is established based on RP communication protocol. Wherein, the RP protocol uses socket and shared memory to communicate, which can convert the request / access to PCIE into socket for data transmission and reception; there is a specific implementation in the code library libsystemctlm-soc. When receiving the simulation request, circuit simulation is performed based on the system simulation model composed of the to-be-simulated model and the extended hardware model; wherein, if the simulation request includes a custom analysis instruction, the driver also accesses the newly added hardware registers through the newly added simulation device register to read the target monitoring information recorded in the newly added hardware registers; the target monitoring information is state statistical information and / or performance statistical information that the native hardware registers pointed to by the custom analysis instruction do not support.

[0051] Finally, it should be pointed out that the above embodiments are only used to illustrate the technical solutions of the present application and not to limit it, although the present application has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present application can be modified or replaced equivalently without departing from the purpose and scope of the technical solutions of the present application, which should be covered in the scope of the claims of the present application.

Claims

1. An integrated circuit simulation method, characterized by, The application is applied to a hybrid simulation system, the hybrid simulation system comprises a physical computer, a QEMU simulator and a Model IP, the QEMU simulator and the Model IP run as two processes of the physical computer; the Model IP comprises a hardware model based on a target hardware device, and the hardware model has been compiled into an execution file; The integrated circuit simulation method comprises: A target hardware device is simulated by a QEMU simulator to obtain a simulation model to be used; the simulation model to be used comprises native simulation device registers, newly-added simulation device registers and a driver, and the driver is provided with access logic for the newly-added simulation device registers; The number of registers of the hardware model in the Model IP is expanded, and the expanded hardware model comprises native hardware registers and newly-added hardware registers; wherein the newly-added hardware registers communicate with the newly-added simulation device registers, the native hardware registers communicate with the native simulation device registers, and the communication modes are the same; A system simulation model is obtained based on the simulation model to be used and the expanded hardware model; When a simulation request is received, circuit simulation is performed by the system simulation model; wherein if the simulation request comprises a custom analysis instruction, the driver further accesses the newly-added hardware registers through the newly-added simulation device registers to read target monitoring information recorded in the newly-added hardware registers; the target monitoring information is state statistical information and / or performance statistical information that is not supported by a native hardware register pointed to by the custom analysis instruction.

2. The integrated circuit emulation method of claim 1, wherein, If the simulation request comprises a custom analysis instruction, before the newly-added hardware registers are accessed through the newly-added simulation device registers, the following steps are further included: The newly-added hardware registers are defined according to the target simulation request, so that the newly-added hardware registers monitor performance indicators corresponding to state information and / or performance statistical information that is not supported by the native hardware registers.

3. The integrated circuit emulation method of claim 2, wherein, If the number of the newly-added hardware registers is greater than 1 and the performance indicators comprise multiple performance indicators, each of the newly-added hardware registers is defined, so that one newly-added hardware register monitors one performance indicator.

4. The integrated circuit emulation method of claim 1, wherein, The native hardware registers and the newly-added hardware registers are independent of each other, and the native simulation device registers and the newly-added simulation device registers are independent of each other; The native hardware registers are arranged based on the address space of the native simulation device registers, and the newly-added hardware registers are arranged based on the address space of the newly-added simulation device registers, which are the same or different.

5. The integrated circuit emulation method of claim 1, wherein, If a target simulation request is received, the address space types of the newly-added simulation device registers and the native simulation device registers are further reset.

6. The integrated circuit simulation method according to any one of claims 1 to 5, characterized by, If the target hardware device is a PCIE device, the communication modes of the native hardware registers and the native simulation device registers and the communication modes of the newly-added hardware registers and the newly-added simulation device registers are all implemented based on an RP protocol.

7. The integrated circuit simulation method according to any one of claims 1 to 5, characterized by, If the target hardware device is an I2C interface device, the communication mode of the native hardware register and the native analog device register and the communication mode of the new hardware register and the new analog device register are implemented based on the I2C protocol.

8. The integrated circuit simulation method according to any one of claims 1 to 5, characterized by, If the target hardware device is an SPI interface device, the communication mode of the native hardware register and the native analog device register and the communication mode of the new hardware register and the new analog device register are implemented based on the SPI protocol.

9. The integrated circuit simulation method of any one of claims 1 to 5, wherein, If the target hardware device is a UART interface device, the communication mode of the native hardware register and the native analog device register and the communication mode of the new hardware register and the new analog device register are implemented based on the UART protocol.

10. A hybrid simulation system, characterized by The system comprises an entity computer, a QEMU emulator and a Model IP, wherein the QEMU emulator and the Model IP are run as two processes of the entity computer; the Model IP comprises a hardware model based on a target hardware device, and the hardware model has been compiled into an execution file; The QEMU emulator is configured to simulate the target hardware device to obtain a simulation model to be used; the simulation model to be used comprises a native analog device register, a new analog device register and a driver, and the driver is provided with access logic for the new analog device register; The Model IP is configured to extend the number of registers of the hardware model, and the extended hardware model comprises a native hardware register and a new hardware register; wherein the new hardware register communicates with the new analog device register, the native hardware register communicates with the native analog device register, and the communication modes are the same; The simulation model to be used and the extended hardware model are used as a system simulation model, and when a simulation request is received, circuit simulation is performed through the system simulation model; wherein, if the simulation request comprises a custom analysis instruction, the driver further accesses the new hardware register through the new analog device register to read target monitoring information recorded in the new hardware register; the target monitoring information is state statistical information and / or performance statistical information that is not supported by a native hardware register pointed to by the custom analysis instruction.

Images