Simulation method and simulation device for simulating integrated circuit chip

Abstract

The present application relates to a simulation method and a simulation device for simulating an integrated circuit chip. Based on the present application, an idle flag sequence can be dynamically maintained for multiple software modules. The idle flag sequence can include idle flag bits corresponding to multiple software modules respectively. When the idle flag bit corresponding to each software module is set to valid, it can indicate that the data to be processed currently waiting for the software module to process is empty. In addition, before a software thread executes a call to any software module, the idle flag bit of the software module can be detected first, and then whether to execute the call to the software module is determined based on the detection result. Therefore, it can be avoided that an invalid call to the software module is still executed when any software module does not have data to be processed involving data interaction, thereby helping to shorten the software simulation time of the integrated circuit chip by reducing invalid calls to the software modules.

Description

Technical Field

[0001] The present application relates to the field of integrated circuit chip design, and in particular to a simulation method for simulating an integrated circuit chip, and a simulation device for simulating an integrated circuit chip. Background Art

[0002] During the design phase of an integrated circuit (IC) chip, simulation is often required to evaluate its performance after tape-out. Unlike post-tapeout testing, which relies on actual IC chip operation, IC chip simulation can also be achieved through software simulation of the IC chip's operational process. This method of simulating the IC chip's operational process using software is referred to as software emulation.

[0003] Typically, software simulation of an integrated circuit chip can be implemented by a software thread calling multiple software modules, where the multiple software modules correspond to multiple hardware modules in the integrated circuit chip, and the software thread can periodically call the multiple software modules in a serial order.

[0004] When a software thread executes a call to any software module and detects that the module currently has no data to process, it terminates the current call to the module and jumps to the next module in the serial order. Therefore, the software thread's call to the module is considered an invalid call. A large number of invalid calls will cause the software simulation of the integrated circuit chip to take a long time.

[0005] Therefore, how to shorten the time consumption of software simulation of integrated circuit chips has become a technical problem to be solved in the prior art. Summary of the Invention

[0006] The embodiments of the present application provide a simulation method for simulating an integrated circuit chip and a simulation device for simulating an integrated circuit chip, which help to shorten the time consumed by software simulation of the integrated circuit chip.

[0007] In one embodiment of the present application, a simulation method for simulating an integrated circuit chip is provided, comprising:

[0008] Before a software thread executes a call to any software module among a plurality of software modules, an idle flag bit corresponding to the software module in an idle flag sequence is detected; wherein the plurality of software modules respectively correspond to a plurality of hardware modules in the integrated circuit chip, the software thread is configured to periodically initiate calls to the plurality of software modules in a serial order, the plurality of software modules being configured to perform data interaction with the plurality of hardware modules by being called by the software thread, and the idle flag bit corresponding to any software module among the plurality of software modules, when set to valid, is configured to indicate that there is no pending data currently waiting to be processed by the software module in the data interaction, and the detection of the idle flag bit corresponding to any software module among the plurality of software modules is decoupled from the calling of the plurality of software modules;

[0009] If, before the software thread executes a call to any software module among the plurality of software modules, it is detected that the idle flag corresponding to the software module is currently invalid, the software thread is caused to execute the call to the software module;

[0010] If, before the software thread calls any software module among the multiple software modules, it is detected that the idle flag corresponding to the software module is currently valid, the software thread is caused to skip calling the software module.

[0011] In some examples, optionally, the to-be-processed data of any software module among the multiple software modules is stored in an interactive memory space, and the access operation to the interactive memory space is coupled with the call to the multiple software modules; the idle flag sequence is stored in an open memory space, the open memory space is independent of the interactive memory space, and the detection operation of the idle flag bit of the open memory space is decoupled from the call to the multiple software modules.

[0012] In some examples, optionally, a setting operation of a free flag corresponding to any software module among the multiple software modules is associated with an access operation to the interactive memory space.

[0013] In some examples, optionally, the call to any software module among the multiple software modules includes: calling an execution function corresponding to the software module; wherein, when the execution function corresponding to any software module among the multiple software modules is called, it is used to: perform a read operation on the interactive memory space to obtain the to-be-processed data provided to the software module by the upstream software module located on the interactive upstream side of the software module in the data interaction; and perform a write operation on the interactive memory space to provide the data processed by the software module as to-be-processed data for the downstream software module located on the interactive downstream side of the software module in the data interaction.

[0014] In some examples, optionally, when called, the execution function corresponding to any software module among the multiple software modules is further used to: perform a setting operation on the open memory space to invalidate the idle flag position corresponding to the downstream software module.

[0015] In some examples, optionally, the call to any software module among the multiple software modules further includes: in response to the completion of the call to the execution function corresponding to the software module, calling an idle function corresponding to the software module; wherein, the idle function corresponding to any software module among the multiple software modules, when called, is used to: detect the interactive memory space; if it is detected that the data to be processed by the software module in the interactive memory space is empty, then performing a setting operation on the open memory space to set the idle flag position corresponding to the software module to be valid.

[0016] In another embodiment of the present application, a simulation device for simulating an integrated circuit chip is provided, comprising:

[0017] an idle detection unit, configured to detect an idle flag bit corresponding to any software module among a plurality of software modules in an idle flag sequence before a software thread executes a call to the software module; wherein the plurality of software modules respectively correspond to a plurality of hardware modules in the integrated circuit chip, the software thread is configured to periodically initiate calls to the plurality of software modules in a serial order, the plurality of software modules being configured to perform data interaction with the plurality of hardware modules by being called by the software thread, the idle flag bit corresponding to any software module among the plurality of software modules, when set to active, indicating that there is no pending data currently waiting to be processed by the software module in the data interaction, and the detection of the idle flag bit corresponding to any software module among the plurality of software modules is decoupled from the calling of the plurality of software modules;

[0018] A calling control unit, configured to control the calling of the software thread according to the detection result of the idle detection unit, wherein:

[0019] If the idle detection unit detects that the idle flag corresponding to any software module among the plurality of software modules is currently invalid before the software thread calls the software module, the idle detection unit causes the software thread to call the software module;

[0020] If the idle detection unit detects that the idle flag corresponding to any software module among the multiple software modules is currently valid before the software thread calls the software module, the software thread is caused to skip calling the software module.

[0021] In another embodiment of the present application, an electronic device is provided, including a processor, wherein the processor is configured to execute the simulation method as described in the above embodiment.

[0022] In another embodiment of the present application, a non-transitory computer-readable storage medium is provided. The non-transitory computer-readable storage medium stores instructions. When the instructions are executed by a processor, the processor implements the simulation method as described in the above embodiment.

[0023] In another embodiment of the present application, a computer program product is provided, comprising computer-executable instructions, which, when executed by a processor, implement the simulation method as described in the foregoing embodiment.

[0024] Based on the embodiments of the present application, an idle flag sequence can be dynamically maintained for multiple software modules. The idle flag sequence can include idle flag bits corresponding to the multiple software modules respectively. When the idle flag bit corresponding to each software module is set to valid, it can indicate that the data to be processed by the software module is empty. Moreover, before a software thread executes a call to any software module, the idle flag bit of the software module can be first detected, and then whether to execute the call to the software module is determined based on the detection result. Since the detection operation of the idle flag bit corresponding to any software module can be decoupled from the call to multiple software modules, it is possible to avoid executing an invalid call to the software module when any software module does not have data to be processed involving data interaction. This helps to shorten the software simulation time of the integrated circuit chip by reducing invalid calls to software modules. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The following drawings are only provided for schematic illustration and explanation of the present application and do not limit the scope of the present application:

[0026] Figure 1 This is a schematic diagram of an example of a data flow topology between multiple hardware modules in an integrated circuit chip serving as a simulation object in an embodiment of the present application;

[0027] Figure 2 This is a schematic diagram of an example of data interaction performed by calling multiple software modules in a simulation method for simulating an integrated circuit chip in an embodiment of the present application;

[0028] Figure 3 1 is a schematic diagram of an exemplary flow chart of a simulation method for simulating an integrated circuit chip in an embodiment of the present application;

[0029] Figure 4 Schematic diagram of an example of operating an idle flag bit in a simulation method for simulating an integrated circuit chip in an embodiment of the present application;

[0030] Figure 5 Schematic diagram of an exemplary extended flow chart of a simulation method for simulating an integrated circuit chip in an embodiment of the present application;

[0031] Figure 6 This is a schematic diagram of an example of grouping multiple software modules in a simulation method for simulating an integrated circuit chip in an embodiment of the present application;

[0032] Figure 7 This is a schematic diagram of an example of data interaction of a simulation method for simulating an integrated circuit chip in an embodiment of the present application by calling multiple module groups for simulation in parallel;

[0033] Figure 8 This is a schematic diagram of an example of simulation timing in a case where there is synchronous coupling between different software threads in a simulation method for simulating an integrated circuit chip according to an embodiment of the present application;

[0034] Figure 9 This is a schematic diagram of an example of a simulation sequence of a simulation method for simulating an integrated circuit chip in an embodiment of the present application when synchronous coupling is released. DETAILED DESCRIPTION

[0035] In order to make the objectives, technical solutions and advantages of this application more clear, the application is further described in detail below with reference to the accompanying drawings and examples.

[0036] In an embodiment of the present application, multiple software modules can exchange data by being called by software threads. Moreover, since the multiple software modules correspond to multiple hardware modules in the integrated circuit chip, the data interaction between the multiple software modules by being called by software threads can match the data flow topology between the multiple hardware modules in the integrated circuit chip.

[0037] For example, in an embodiment of the present application, the integrated circuit chip serving as the simulation object may be any processor chip such as a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), a TPU (Tensor Processing Unit), an NPU (Neural Network Processing Unit), a DPU (Deep Learning Processing Unit), an APU (Accelerated Processing Unit), and a GPGPU (General-Purpose computing on Graphics Processing Units).

[0038] For example, in an embodiment of the present application, multiple software modules may correspond to multiple hardware modules in an integrated circuit chip, and each software module may be used to simulate the module functions of the corresponding hardware module during the simulation process. For example, taking the integrated circuit chip as a GPU or GPGPU suitable for a heterogeneous architecture, the multiple hardware modules in the integrated circuit chip may include at least one of an HBM (High Bandwidth Memory) module, a CP (Command Processor), a module cluster with a computing core as the granularity, and a bus controller. In this case, the multiple software modules may include at least one of the following: a soft HBM module corresponding to the HBM module, a soft CP corresponding to the CP, an intra-core soft module cluster corresponding to the module cluster of each computing core, and a soft bus controller corresponding to the bus controller.

[0039] For example, in an embodiment of the present application, the heterogeneous architecture in which the GPU or GPGPU is located may also include a CPU as a host and physical memory. In this case, the CP may dispatch tasks input from the external input (e.g., input from the CPU as the host) to multiple computing cores. The module cluster of multiple computing cores may be used to execute the dispatched tasks. The HBM module may be an HBM area configured by the CPU in the physical memory, mapped to the on-chip space of the GPU or GPGPU. The HBM area is used to store task data corresponding to each task. In addition, the bus controller may use a page table input from the external input (e.g., input from the CPU as the host) to determine the HBM area in the physical memory and perform access operations (e.g., at least one of a read operation and a write operation) on the HBM area via an off-chip bus. Accordingly, multiple software modules may be used to simulate the module functions of the above-mentioned hardware modules during the simulation process.

[0040] For example, in an embodiment of the present application, tasks assigned by the CP may include operation tasks and access tasks. Operation tasks instruct the compute core to utilize the module cluster to perform computational operations on task data. For example, computational operations may include reduce operations. Access tasks instruct the compute core to assist the bus controller in transferring task data between the HBM area of ​​physical memory and the HBM module.

[0041] For example, in an embodiment of the present application, the module cluster of each computing core may include a read / write module and multiple computing modules. The read / write module in each computing core's module cluster may be used to receive tasks assigned to the computing core by the CP, and the computing module in each computing core's module cluster is used to perform at least one computing operation. Accordingly, the soft module cluster within each core corresponding to the computing core in the multiple software modules may include a soft read / write module and multiple soft computing modules.

[0042] For example, in an embodiment of the present application, if the task received by the read-write module in the module cluster of any computing core from the CP is an operation task, then the read-write module in the module cluster of the computing core can be used to: obtain task data corresponding to the operation task from the HBM module based on the operation task (for example, task data of the computing operation to be performed read by the bus controller from the HBM area of ​​the physical memory), send the task data obtained from the HBM module to at least one computing module in the module cluster of the computing core to perform the computing operation, and write back the task data after the computing module performs the computing operation to the HBM module.

[0043] For example, in an embodiment of the present application, if the task received by the read-write module in the module cluster of any computing core from the CP is an access task, then the read-write module in the module cluster of the computing core can be used to: provide the task data in the HBM module (for example, task data for which the computing operation has been completed) to the bus controller, so that the bus controller writes it to the HBM area of ​​the physical memory through the off-chip bus, that is, the bus controller's write operation on the HBM area of ​​the physical memory through the off-chip bus is controlled by the access task.

[0044] For example, in an embodiment of the present application, the off-chip bus may include a PCIE (Peripheral Component Interconnect Express) bus. In this case, the bus controller may be referred to as a PCIE controller.

[0045] For example, in an embodiment of the present application, the bus controller may use a DMA (Direct Memory Access) method to access the physical memory. In this case, the access task may also be referred to as a DMA task.

[0046] Figure 1 This is a schematic diagram of an example of the data flow topology between multiple hardware modules in an integrated circuit chip that is a simulation object in an embodiment of the present application. Figure 2 This is a schematic diagram of an example of data interaction performed by calling multiple software modules in the simulation method for simulating an integrated circuit chip in an embodiment of the present application. Figure 1 , the multiple hardware modules of the integrated circuit chip as the simulation object in the embodiment of the present application include HBM module, CP, module cluster with computing core as granularity, and bus controller as an example for illustration. In this case, Figure 2 As shown, multiple software modules may include a soft HBM module, a soft CP, m-1 intra-core soft module clusters 1~m-1, and a soft bus controller as an example, where m-1 represents the total number of computing cores, m is a positive integer greater than 1, and all mapping modules in each intra-core soft module cluster i may include a soft read-write module i and n soft computing modules i_1~i_n, i is a positive integer greater than or equal to 1 and less than or equal to m-1, and n is a positive integer greater than or equal to 1.

[0047] For example, in the embodiments of the present application, Figure 1 As shown, the data flow topology between multiple hardware modules may include:

[0048] S110: The CP receives tasks inputted by the CPU as the host, including operation tasks and access tasks received successively; Figure 1 The example in which the CPU directly inputs the operation tasks and access tasks to the CP is used. However, it is understandable that the operation tasks and access tasks provided by the CPU to the CP can also be first transferred by the CPU to the HBM through the bus controller and then obtained by the CP from the HBM. That is, Figure 1 The above is merely an illustrative example and is not intended to impose unnecessary limitations on the data flow topology in the integrated circuit chip to which the embodiments of the present application are applicable.

[0049] S120: The bus controller reads the task data corresponding to the operation task in the HBM area of ​​the physical memory;

[0050] S121: The bus controller writes the task data read from the HBM area of ​​the physical memory into the HBM module;

[0051] S131: CP assigns the operation task to computing core i;

[0052] S141: The CP assigns the operation task to computing core j, where j represents a positive integer greater than or equal to 1, less than or equal to m-1, and different from i;

[0053] S132: The read / write module i in the module cluster of the computing core i obtains the task data corresponding to the operation task (task data of the computing operation to be performed) from the HBM module according to the operation task;

[0054] S142: The read / write module j in the module cluster of the computing core i obtains the task data corresponding to the operation task (task data of the computing operation to be performed) from the HBM module according to the operation task;

[0055] S133: The read / write module i in the module cluster of the computing core i sends the task data obtained from the HBM module to at least one computing module i_p in the module cluster of the computing core i, where p represents at least one positive integer in the range of greater than or equal to 1 and less than or equal to n;

[0056] S134: At least one computing module i_p in the module cluster of computing core i performs a computing operation on the task data. If there is more than one computing module i_p involved in the computing operation, each computing module i_p may perform the computing operation on the task data independently, or may collaboratively perform the computing operation on the task data through interaction with each other.

[0057] S135: At least one computing module i_p in the module cluster of computing core i returns the task data after executing the computing operation to the read-write module i;

[0058] S136: The read / write module i in the module cluster of the computing core i writes back the task data after executing the computing operation to the HBM module;

[0059] S143–S146 are similar to S133–S136;

[0060] S151: The CP assigns the access task to computing core k, where k is a positive integer greater than or equal to 1 and less than or equal to m-1 and different from i and j.

[0061] S152: The read / write module k in the module cluster of computing core k obtains from the HBM module the task data (e.g., task data on which computing operations have been completed) written back by the read / write module i in the module cluster of computing core i and the read / write module j in the module cluster of computing core j.

[0062] S153: The read / write module k in the module cluster of the computing core k provides the task data (eg, task data on which the computing operation has been completed) obtained from the HBM module to the bus controller;

[0063] S122: The bus controller writes the task data (eg, task data that has completed the computing operation) provided by the read / write module j in the module cluster of the computing core j into the HBM area of ​​the physical memory through the off-chip bus.

[0064] In the embodiments of the present application, Figure 1 The data flow topology shown is an exemplary expression of a single transport and data operation for task data, and as Figure 1 The data flow topology shown may occur repeatedly in actual applications for continuously provided different task data.

[0065] Please see again Figure 2 , corresponding to Figure 1 The data flow topology between the multiple hardware modules shown in FIG1 , the soft HBM module, the soft CP, the m-1 in-core soft module clusters 1 to m-1, and the soft bus controller in the multiple software modules can be called by the software threads in a serial order to achieve the same as shown in FIG1 . Figure 1 The data flow topology shown in the figure matches the data interaction. Interaction steps such as S121, S131, and S141 are split into sending steps (e.g., S121t, S131t, S141t, etc.) performed by the upstream software module located relatively upstream in the data interaction, and receiving steps (e.g., S121r, S131r, S141r, etc.) performed by the downstream software module located relatively downstream in the data interaction.

[0066] It is understandable that in the embodiments of the present application, Figure 1 and Figure 2 The examples shown are merely for facilitating understanding of the data flow topology between multiple hardware modules, the data interaction between multiple software modules, and the relationship between the two, and are not intended to impose unnecessary restrictions on the data flow topology between multiple hardware modules or the data interaction between multiple software modules.

[0067] For example, in an embodiment of the present application, the software thread used to call the software module may include a software thread of a virtual machine, that is, the software module can be considered to be called by the virtual machine. In this case, if the software thread is a software thread assigned to the virtual machine by an electronic device running the simulation method, the virtual machine can assume the identity of a GPU or GPGPU in a heterogeneous architecture, and other software programs in the electronic device independent of the virtual machine (such as a software driver for the GPU or GPGPU) can assume the identity of a CPU serving as a host in the heterogeneous architecture.

[0068] For example, in the embodiment of the present application, due to the deviation between the interaction timing of data interaction between multiple software modules and the serial calling order of the software thread to the multiple software modules, therefore, in any cycle of the software thread calling the multiple software modules in the serial order, some software modules may be in an idle state that does not need to be called, for example Figure 2 If a call is executed to a software module in an idle state and the call to the software module is terminated because there is no pending data waiting to be processed by the software module in the data interaction, the simulation time will be increased due to such an invalid call.

[0069] In order to reduce invalid calls during the simulation process for simulating an integrated circuit chip, an embodiment of the present application can dynamically maintain an idle flag sequence for multiple software modules. The idle flag sequence can include idle flag bits corresponding to the multiple software modules respectively. When the idle flag bit corresponding to each software module is set to valid, it can indicate that the data to be processed by the software module is empty. In addition, before a software thread executes a call to any software module, the idle flag bit of the software module can be detected first, and then whether to execute the call to the software module is determined based on the detection result. The detection operation of the idle flag bit corresponding to any software module can be decoupled from the call to multiple software modules. Therefore, it can avoid executing invalid calls to any software module when there is no data to be processed involving data interaction. Therefore, it helps to shorten the software simulation time of the integrated circuit chip by reducing invalid calls to software modules.

[0070] Figure 3 This is a schematic diagram of an exemplary flow chart of a simulation method for simulating an integrated circuit chip in an embodiment of the present application. Figure 3 In an embodiment of the present application, a simulation method for simulating an integrated circuit chip may include:

[0071] S310: Before the software thread executes a call to any software module among the multiple software modules, detect an idle flag bit corresponding to the software module in the idle flag sequence;

[0072] As described above, the multiple software modules involved in S310 may respectively correspond to multiple hardware modules in an integrated circuit chip. The software thread involved in S310 may periodically initiate calls to the multiple software modules in a serial order. The multiple software modules involved in S310 may perform data interaction with the multiple hardware modules by being called by the software thread. The idle flag corresponding to any software module among the multiple software modules involved in S310 may be used to indicate, when set to valid, that the pending data currently waiting to be processed by the software module in the data interaction is empty. Furthermore, the detection operation of the idle flag corresponding to any software module among the multiple software modules in S310 may be decoupled from the call to the multiple software modules (for example, decoupled from the call to any software module among the multiple software modules).

[0073] If S310 detects that the idle flag corresponding to any software module among the multiple software modules is currently invalid before the software thread executes a call to the software module, the process may jump to S330 to enable the software thread to execute the call to the software module. After the software thread completes the call to the software module, the process prepares to call the next software module among the multiple software modules in a serial order, that is, executes S310 for the next software module.

[0074] If S310 detects that the idle flag corresponding to any software module among the multiple software modules is currently valid before the software thread executes a call to the software module, it indicates that the call to be executed on the software module is an invalid call, and the software thread skips the call to the software module and prepares to call the next software module among the multiple software modules in a serial order, that is, executes S310 for the next software module.

[0075] As Figure 2 As an example, if the above process of the simulation method in the embodiment of the present application is adopted, then Figure 2 Invalid calls can be avoided at the positions marked as "idle", thereby helping to shorten the software simulation time of the integrated circuit chip by reducing invalid calls to the software modules.

[0076] Exemplarily, in an embodiment of the present application, the data to be processed of any software module among a plurality of software modules is stored in a pre-designated interactive memory space, and the access operation to the interactive memory space is coupled with the call to the plurality of software modules (for example, coupled with the call to any software module among the plurality of software modules). For example, the interactive memory space may be a memory space allocated to a software thread and shared by a plurality of software modules called by the software thread, and the executor of the access operation to the memory space is limited to any software module currently being executed and called. Alternatively, the interactive memory space may also include module memory spaces allocated separately for a plurality of software modules, and the executor of the access operation to the module memory space of any software module may be limited to the software module currently being executed and called, or an upstream software module located on the interactive upstream side of the software module in data interaction.

[0077] Illustratively, in an embodiment of the present application, an idle flag sequence can be stored in an open memory space, which can be independent of the interactive memory space described above, and the access operation of the idle flag sequence of the open memory space can be decoupled from the call to multiple software modules (for example, decoupled from the call to any software module among the multiple software modules), thereby, the detection operation of the idle flag bit of the open memory space can be decoupled from the call to multiple software modules.

[0078] For example, in an embodiment of the present application, each of the plurality of software modules may include a corresponding module instance and an execution function, and calling any software module may include calling the execution function corresponding to the software module. The execution function corresponding to any of the plurality of software modules, when called, may be used to:

[0079] Performing a read operation on the interactive memory space to obtain data to be processed provided by an upstream software module located at an interactive upstream side of the software module in data interaction for the software module;

[0080] Calling a module instance of the software module to process data waiting to be processed by the software module in data interaction; and

[0081] A write operation is performed on the interactive memory space to provide the data processed by the software module as to-be-processed data of a downstream software module located at an interactive downstream side of the software module in the data interaction.

[0082] For example, in an embodiment of the present application, if the interactive memory space includes module memory spaces allocated to multiple software modules, then the execution function corresponding to any software module can perform a read operation on the module memory space corresponding to that software module, and can also perform a write operation on the module memory space corresponding to a downstream software module. In this case, each of the multiple software modules may further include an interface function, where the interface function corresponding to any software module serves as an access interface for other software modules (e.g., an upstream software module) to perform write operations on the module memory space corresponding to that software module. Thus, the execution function corresponding to any software module can perform a write operation on the module memory space corresponding to the downstream software module by calling the interface function corresponding to the downstream software module.

[0083] Illustratively, in an embodiment of the present application, a software thread's detection operation on an idle flag corresponding to any software module among multiple software modules may include: the software thread performs a read operation on the idle flag corresponding to the software module in the detection idle flag sequence by directly accessing the open memory space without calling the execution function of the software module.

[0084] Illustratively, in an embodiment of the present application, a software thread's setting operation on an idle flag corresponding to any software module among a plurality of software modules may be associated with an access operation to the interactive memory space.

[0085] For example, in an embodiment of the present application, the execution function corresponding to any software module among the multiple software modules can also be used, when called, to: execute an invalid setting operation on the idle flag position corresponding to the downstream software module on the open memory space. In particular, since the upstream and downstream relationship of the multiple software modules in data interaction is not a serial relationship in which two are sequentially connected in series, when the execution function of any software module performs an invalid setting operation on the idle flag position corresponding to the downstream software module, the idle flag may have been in an invalid state due to the setting operation performed by other software modules. However, even so, when the execution function of any software module completes the write operation of providing the data to be processed to the downstream software module, it is still necessary to perform an invalid setting operation on the idle flag position corresponding to the downstream software module. Thus, the setting operation of the idle flag position corresponding to any software module among the multiple software modules by the software thread can occur following the execution of the write operation on the interactive memory space for the downstream software module.

[0086] For example, in an embodiment of the present application, calling any software module from among the multiple software modules may further include: in response to the completion of the call to the execution function corresponding to the software module, calling an idle function corresponding to the software module. The idle function corresponding to any software module from among the multiple software modules, when called, may be used to:

[0087] Detecting the interactive memory space, that is, detecting whether there is still data to be processed by the software module in the interactive memory space;

[0088] If it is detected that the data to be processed by the software module in the interactive memory space is empty, a setting operation is performed on the open memory space to set the idle flag corresponding to the software module to be valid;

[0089] If it is detected that the data to be processed by the software module in the interactive memory space is not empty, then optionally, a setting operation is performed on the open memory space to set the idle flag corresponding to the software module to invalid, even if the idle flag is in an invalid set state before calling the software module.

[0090] For example, in an embodiment of the present application, a software module may retain data to be processed after being called. For example, a job pool may be provided in the CP in an integrated circuit chip, which may include task status information of assigned tasks. The CP will dynamically maintain work based on the completion of the tasks, and if there are currently unfinished tasks, the task status information will not be empty. In this case, the data to be processed of the soft CP in multiple software modules may include the task status information in the job pool, and as long as there are currently unfinished tasks, that is, there is currently at least one other software module with data to be processed, the task status information in the data to be processed of the soft CP will not be empty. The soft CP is used as an example here for illustration only to facilitate understanding that it is possible for a software module to retain data to be processed after being called, and it is not intended to make unnecessary limitations on this.

[0091] Figure 4 This is a schematic diagram of an example of operating the idle flag bit in the simulation method for simulating an integrated circuit chip in an embodiment of the present application. Figure 4 In the embodiment of the present application, three software modules, q-1, q, and q+1, are serially arranged among multiple software modules. Assume that software modules q-1 and q+1 are in a upstream-downstream relationship in data exchange, and that software module q, located between them, does not have a upstream-downstream relationship in data exchange and has no data to be processed in the current cycle. Where q represents any positive integer less than or equal to the total number of software modules.

[0092] When the software thread prepares to call the software module q-1 in a serial order, it can be determined in S310 that the corresponding idle flag is invalid "F", and thus the call to the software module q-1 is executed, that is:

[0093] First, the execution function of the software module q-1 is called to process the data, and based on the processed data, the data to be processed is provided to the software module q+1 on the downstream side of the interaction;

[0094] Then, the idle flag of the software module q+1 on the downstream side of the interaction is set to invalid "F";

[0095] Then, based on the detection result of whether there is still data to be processed of the software module q-1 in the interactive memory space, the idle function that calls the software module q-1 performs a set operation on the idle function of the software module q-1 to invalid "F" or valid "T".

[0096] When the software thread is ready to call the software module q in a serial order, it can be determined in S310 that the corresponding idle flag is valid “T”, thereby skipping the call to the software module q.

[0097] When the software thread is ready to call the software module q+1 in a serial order, it can be determined in S310 that the corresponding idle flag is invalid "F", and thus the call to the software module q+1 is executed, that is:

[0098] First, the execution function of the software module q+1 is called to process the data (for example, the data provided by the software module q-1 on the upstream side of the interaction), and the software module on the downstream side of the interaction (not in the Figure 4 ) providing data to be processed;

[0099] Then, the idle flag of the software module on the downstream side of the interaction is set to invalid "F";

[0100] Then, based on the detection result of whether there is still data to be processed of the software module q+1 in the interactive memory space, the idle function that calls the software module q+1 performs a setting operation on the idle function of the software module q+1 to invalid "F" or valid "T".

[0101] For example, in the embodiments of this application, the preceding descriptions all use the example of multiple software modules being periodically called in a serial order by a single software thread. Furthermore, in the following descriptions, to further shorten the time required for software simulation of an integrated circuit chip, an optimization approach can be employed in which the multiple software modules are divided into multiple module groups, and multiple software threads running in parallel call the multiple module groups in parallel.

[0102] Figure 5 This is a schematic diagram of an exemplary extended flow chart of a simulation method for simulating an integrated circuit chip in an embodiment of the present application. Figure 5 In an embodiment of the present application, the simulation method for simulating an integrated circuit chip may further include:

[0103] S510: Divide the plurality of software modules into a plurality of module groups corresponding to the plurality of software threads respectively; and

[0104] S530: Call multiple module groups in parallel by running multiple software threads in parallel.

[0105] For example, in an embodiment of the present application, the multiple module groups obtained by grouping the multiple software modules in S510 may correspond one-to-one to the multiple software threads.

[0106] Exemplarily, in an embodiment of the present application, the multiple software threads may include multiple software threads of a virtual machine. In this case, the process of S510 calling multiple module groups in parallel by running multiple software threads in parallel can be considered as a process in which multiple module groups are called in parallel by the virtual machine.

[0107] Figure 6 This is a schematic diagram of an example of grouping multiple software modules in the simulation method for simulating an integrated circuit chip in an embodiment of the present application. Figure 6 The multiple software modules may include a soft HBM module, a soft CP, m-1 intra-core soft module clusters 1 to m-1, and a soft bus controller. These software modules may be grouped in S110 to obtain m module groups 0 to m-1 corresponding to the m software threads 0 to m-1. For example, the soft HBM module, soft CP, and soft bus controller may be grouped in S510 to be grouped in module group 0 corresponding to software thread 0. Furthermore, all mapping modules (including soft read / write module i and n soft computing modules i_1 to i_n) in each intra-core soft module cluster i may be grouped in S510 to be grouped in module group i corresponding to software thread i, where i is a positive integer greater than or equal to 1 and less than or equal to m-1, and n is a positive integer greater than or equal to 1.

[0108] Exemplarily, in an embodiment of the present application, the group number m of module groups 0 to m-1 can be the same as the thread number m of software threads, and the thread number m of software threads can be determined by the thread resources that can be provided by the electronic device that executes the simulation method, that is, the group number m of module groups 0 to m-1 and the thread number m of software threads can be less than or equal to the maximum number of threads that can be provided by the electronic device that runs the simulation method (for example, the maximum number of threads that the electronic device can allocate to the virtual machine).

[0109] For example, in the embodiment of the present application, the hardware configuration of the intra-core cluster of each computing core of the integrated circuit chip may not be completely the same. Therefore, the module number n of the soft computing modules i_1 to i_n in all the intra-core soft modules in each intra-core soft module cluster i may have different values. Figure 6 The letter n is used to uniformly represent the number of soft computing modules i_1~i_n in different core soft module clusters i only to simplify the visual expression and textual expression.

[0110] Illustratively, in an embodiment of the present application, for multiple software threads 0~m-1 running in parallel in S530, each software thread i is used to call a corresponding module group i among the multiple module groups 0~m-1, and each software thread i is used to periodically call each software module in the corresponding module group i in a serial order. For example, the serial call of each software thread i to each software module in the module group i can be a periodic serial traversal of all software modules in the module group i.

[0111] Exemplarily, in an embodiment of the present application, S530 can enable multiple software modules to simulate an integrated circuit chip (i.e., software simulation) based on data interaction that matches the data flow topology between multiple hardware modules by running multiple software threads in parallel and calling multiple module groups in parallel.

[0112] Figure 7 This is a schematic diagram of an example of data interaction of the simulation method for simulating an integrated circuit chip in an embodiment of the present application by calling multiple module groups for simulation in parallel. Figure 7 As shown, the soft HBM module, soft CP, m-1 in-core soft module clusters 1 to m-1, and soft bus controller in multiple software modules can be concurrently called by m software threads running in parallel through m module groups to achieve the same as shown in FIG. Figure 1 The data flow topology shown matches the data interaction.

[0113] from Figure 7 It can be seen that S133~S136 implemented by software thread i through serial calls to the soft module cluster within the core of computing core i and S143~S146 implemented by software thread j through serial calls to the soft module cluster within the core of computing core j can occur in parallel, and the call of software thread k to the soft read-write module k in the soft module cluster within the core of computing core k can also occur during this period. Therefore, compared with the method of serially calling all software modules by one software thread, dividing multiple software modules into multiple module groups and concurrently calling them by multiple software threads can help shorten the software simulation time.

[0114] For example, in an embodiment of the present application, if the software thread includes multiple software threads running in parallel, the multiple software modules are divided into multiple module groups, and each software thread in the multiple software threads is used to periodically initiate calls to each software module in a corresponding module group in the multiple module groups in a serial order, then, Figure 3The illustrated process can be executed by each software thread for the corresponding module group, rather than by a single software thread for all of the multiple software modules. In this case, the idle flag sequence can include multiple idle flag sequences corresponding to the multiple module groups, and each of the multiple idle flag sequences can include an idle flag bit corresponding to each software module of the corresponding module group in the multiple module groups, for the corresponding software thread to perform a detection operation.

[0115] In an embodiment of the present application, if a software thread includes multiple software threads running in parallel, multiple software modules are divided into multiple module groups, and each software thread in the multiple software threads is used to periodically initiate calls to each software module of a corresponding module group in the multiple module groups in a serial order, then the data interaction of the multiple software modules based on the data flow topology matching between the multiple hardware modules may include: same-thread data interaction between each software module of the same module group in the multiple module groups, and cross-thread data interaction between each software module of different module groups in the multiple module groups. For example, in Figure 7 In the example shown, intra-thread data interaction includes S121, S133, S134 (involving collaboration between multiple soft computing modules in the same in-core soft module cluster), and S135, and cross-thread data interaction includes S131, S122, S136, S152, and S153. Software modules in the same module group that participate in intra-thread data interaction are serially called by the same software thread, while software modules in different module groups that participate in cross-thread data interaction are associated and called by different software threads.

[0116] Cross-thread data exchange typically requires synchronization between upstream and downstream software modules. Specifically, it's best for upstream and downstream software modules to complete send and receive operations synchronously. It's understood that synchronization, as discussed herein, isn't necessarily limited to absolute synchronization in time, but can include situations where send and receive operations overlap in time.

[0117] For data interaction within the same thread, the same software thread only needs to call the upstream software module and the downstream software module in the module group successively during the serial call process of the same module group, so as to achieve synchronization of the upstream side and the downstream side of the interaction of the same thread data interaction.

[0118] For cross-thread data interaction, if synchronization of upstream and downstream software modules is to be achieved, the associated calls of different software threads will be synchronously coupled, that is, different software threads that independently execute serial calls on different module groups may cause waiting delays in the associated calls for the sake of synchronization. Moreover, the associated calls that generate waiting delays will cause the serial calls to stagnate, thereby weakening the effect of shortening the software simulation time.

[0119] Figure 8 This is a schematic diagram of an example of simulation timing in the case where there is synchronous coupling between different software threads in the simulation method for simulating an integrated circuit chip in an embodiment of the present application. Figure 8 ,by Figure 7 The software thread 0, software thread i and software thread k in the example are taken as examples, and the Figure 7 In the case of software thread j, when performing cross-thread data interaction S131, S122, S136, S152, and S153, the call to the upstream software module may cause synchronization delay due to waiting for the downstream software modules in other module groups to be synchronized by the calls of other software threads. Figure 8 The shaded blocks in represent the time slots occupied by the software threads due to calling other software modules in the corresponding module group, and synchronization delays may be caused by the existence of such time slots. Figure 8 In the embodiment, the cross-thread data interactions S131, S122, S136, S152 and S153 implemented by associated calls can be respectively split into write operations and read operations, that is, the cross-thread data interaction S131 is split into a write operation S131t and a read operation S131r, the cross-thread data interaction S132 is split into a write operation S132t and a read operation S132r, the cross-thread data interaction S136 is split into a write operation S136t and a read operation S136r, the cross-thread data interaction S152 is split into a write operation S152t and a read operation S152r, and the cross-thread data interaction S153 is split into a write operation S153t and a read operation S153r.

[0120] For example, in an embodiment of the present application, the process of grouping the multiple software modules into multiple module groups corresponding to the multiple software threads in S110 may include: evaluating the module interaction frequency between the multiple software modules based on the data flow topology; and grouping the multiple software modules based on the module interaction frequency using a grouping strategy that minimizes cross-thread data interaction. Thus, the grouping strategy can be used to optimize the module groups to reduce associated calls between different software threads, thereby reducing synchronization delays caused by synchronous coupling of the associated calls.

[0121] For example, in an embodiment of the present application, cross-thread data interaction can be implemented by different software threads through a decoupling approach. This decoupling approach can mean that cross-thread data interaction can be implemented through asynchronous data transfer in a designated memory space, thereby providing asynchronous margin for decoupling the synchronous coupling of associated calls. Compared to optimizing module groups through grouping strategies, decoupling associated calls can fundamentally decouple synchronous coupling and reduce or even eliminate synchronization delays.

[0122] For example, in an embodiment of the present application, asynchronous data transfer may specifically include: different software threads asynchronously executing independent write and read operations in a designated memory space for each software module in different module groups participating in cross-thread data interaction. That is, in an embodiment of the present application, the data transmission (e.g., write operation) and data reception (e.g., read operation) respectively performed by the upstream software module and the downstream software module in the cross-thread data interaction may be separated. The separated data transmission is used to transfer data to the designated memory space through a write operation on the designated memory space, and the separated data reception is used to obtain data from the designated memory space through a read operation on the designated memory space. Moreover, the write operation and the read operation for the cross-thread data interaction for the same pair of upstream software modules and downstream software modules may be for the same designated memory space.

[0123] For example, in an embodiment of the present application, the data transferred to the designated memory space may be cached in a queue manner such as FIFO (First Input First Output).

[0124] For example, in an embodiment of the present application, a process in which different software threads asynchronously execute independent write and read operations in a designated memory space for respective software modules in different module groups that participate in cross-thread data interaction may specifically include:

[0125] If any software thread among the plurality of software threads determines that the currently called software module in the corresponding module group participates in the cross-thread data interaction as an upstream software module, then performing a write operation on the designated memory space;

[0126] If any software thread among the multiple software threads determines that the currently called software module in the corresponding module group participates in the cross-thread data interaction as a downstream software module, a read operation is performed on the designated memory space.

[0127] Figure 9 This is a schematic diagram of an example of the simulation timing of the simulation method for simulating an integrated circuit chip in an embodiment of the present application when the synchronous coupling is released. Figure 9 , still Figure 7 The software thread 0, software thread i and software thread k in the example are taken as examples, and the Figure 7 The software thread j in the Figure 9 and Figure 8 Comparison shows that Figure 6 Each pair of write and read operations in the specified memory space can have asynchronous margins due to the data transfer, and such asynchronous margins can decouple the synchronous coupling of the associated calls, thereby eliminating Figure 8 The synchronization delay exists in .

[0128] As can be seen above, in the embodiments of the present application, since cross-thread data interaction can be implemented by data transfer in a designated memory space, rather than having to be implemented by calling each software module of different module groups at the same time (i.e., synchronous call), different software threads do not need to generate interrupt waits in order to promote the synchronous call of each software module of different module groups, thereby decoupling the synchronous coupling. In other words, the cross-thread data interaction implemented by data transfer in a designated memory space in the embodiments of the present application can be called decoupled data interaction. Furthermore, by decoupling data interaction, synchronization delays caused by the synchronous coupling of associated calls can be avoided in the parallel calls of multiple module groups by running multiple software threads in parallel. Compared to the software simulation solution in which multiple software modules are all serially called by a single software thread, the solution in which multiple software modules are concurrently called by multiple software threads in the embodiments of the present application by decoupling the associated calls can shorten the software simulation time of the integrated circuit chip.

[0129] Moreover, the decoupled association call can be implemented simultaneously with the method of optimizing the module group through the grouping strategy, thereby reducing the data transfer using the specified memory space on the basis of releasing the synchronous coupling and reducing or even eliminating the synchronization delay.

[0130] Exemplarily, in an embodiment of the present application, the decoupled cross-thread data interaction achieved by data transfer in a designated memory space can be considered to provide asynchronous margin for data reception by downstream software modules. In this case, in an embodiment of the present application, the write and read operations for cross-thread data interaction of the same downstream software module can be directed to the same designated memory space corresponding to the downstream software module. That is, as described above, the write and read operations for cross-thread data interaction of the same pair of upstream software modules and downstream software modules can be directed to the same designated memory space, that is, each software module in a plurality of software modules can be allocated a corresponding module memory space. In this case, the process of asynchronously executing independent write and read operations in a designated memory space for each software module participating in cross-thread data interaction in different module groups by different software threads can also include the following process of determining the designated memory space:

[0131] If any software thread among the multiple software threads determines that the software module currently called in the corresponding module group participates in the cross-thread data interaction as an upstream software module, then the module memory space corresponding to the downstream software module in the other module group is determined as the designated memory space for the current cross-thread data interaction;

[0132] If any software thread among the multiple software threads determines that the currently called software module in the corresponding module group participates in cross-thread data interaction as a downstream software module, then the data stored by the upstream software modules in other module groups is obtained from the module memory space corresponding to the currently called software module.

[0133] Illustratively, in an embodiment of the present application, if any software thread among multiple software threads determines that the software module currently called in the corresponding module group participates in cross-thread data interaction as an upstream software module, then the software thread performing a write operation on the specified memory space may include: using the execution function corresponding to the currently called software module to call the interface function corresponding to the downstream software module in other module groups, so as to perform a write operation on the module memory space corresponding to the other software module by calling the interface function corresponding to the other software module.

[0134] Illustratively, in an embodiment of the present application, if any software thread among multiple software threads determines that the currently called software module in the corresponding module group participates in cross-thread data interaction as a downstream software module, then the software thread performing a read operation on the specified memory space may include: using the execution function corresponding to the currently called software module to perform a read operation on the module memory space corresponding to the software module.

[0135] For example, in an embodiment of the present application, a designated memory space used to implement data transfer in cross-thread data interaction may be cross-accessed by multiple software modules at the same time, and the cross-access may cause data errors in write or read operations. For example, if the same downstream software module participates in multiple cross-thread data interactions with different upstream software modules, Figure 7In the cross-thread data interaction S136 and S146 shown in FIG, with the soft HBM module as the downstream software module and the soft read / write module i and the soft read / write module j as the upstream software modules, there may be cross-access to the module memory space corresponding to the downstream software module, which is accessed simultaneously by the software module and at least two upstream modules. To this end, in an embodiment of the present application, asynchronous data transfer may also include: any thread among multiple software threads performs a lock protection on the specified memory space (e.g., the module memory space corresponding to the downstream software module) during the period of performing any one of a write operation and a read operation on the specified memory space; wherein the lock protection operation can be used to prevent other software threads in the multiple software modules except the software thread currently performing the write operation or the read operation from accessing the specified memory space, and the software thread implementing the lock protection can release the lock protection in response to the completion of the currently implemented write operation or read operation.

[0136] Exemplarily, in an embodiment of the present application, data of different data categories (such as different data categories with different hardware operation types such as read requests, read responses, write requests, and write responses) in cross-thread data interaction can be transferred separately through queues corresponding to different data categories in a designated memory space (such as the module memory space corresponding to the downstream software module).

[0137] Another embodiment of the present application further provides a simulation device for simulating an integrated circuit chip. The simulation device may be implemented by a computer program, and the simulation device may include:

[0138] an idle detection unit configured to detect an idle flag corresponding to any software module among a plurality of software modules in an idle flag sequence before a software thread executes a call to the software module; wherein the plurality of software modules correspond to a plurality of hardware modules in an integrated circuit chip, respectively; the software thread is configured to periodically initiate calls to the plurality of software modules in a serial order; the plurality of software modules are configured to perform data interaction with the plurality of hardware modules by being called by the software thread, such that data flow topology matches that between the plurality of hardware modules; the idle flag corresponding to any software module among the plurality of software modules, when set to active, indicates that there is no pending data currently waiting to be processed by the software module in the data interaction; and the detection of the idle flag corresponding to any software module among the plurality of software modules is decoupled from the call to the plurality of software modules (e.g., decoupled from the call to any software module among the plurality of software modules);

[0139] The calling control unit is used to control the calling of the software thread according to the detection result of the idle detection unit, wherein:

[0140] If the idle detection unit detects that the idle flag corresponding to any software module among the multiple software modules is currently invalid before the software thread executes a call to the software module, the software thread is caused to execute the call to the software module;

[0141] If the idle detection unit detects that the idle flag corresponding to any software module among the multiple software modules is currently valid before the software thread calls the software module, the software thread is caused to skip calling the software module.

[0142] For example, the calling method of any software module and the detection and setting operations of the idle flag bit involved in the above-mentioned simulation device can be found in the above description of the simulation method, which will not be repeated here.

[0143] Illustratively, in an embodiment of the present application, the simulation device for simulating an integrated circuit chip may further include:

[0144] a simulation configuration unit configured to divide the plurality of software modules into a plurality of module groups corresponding to the plurality of software threads, respectively; wherein the plurality of software modules correspond to the plurality of hardware modules in the integrated circuit chip, respectively; and each of the plurality of software threads is configured to call a corresponding one of the plurality of module groups during execution;

[0145] The simulation execution unit is used to simulate the integrated circuit chip by running multiple software threads in parallel and calling multiple module groups in parallel, so that multiple software modules can realize data interaction based on data flow topology matching between multiple hardware modules.

[0146] For example, in the embodiments of the present application, the simulation configuration unit and the simulation execution unit can refer to the relevant description of the simulation method in the foregoing text, which will not be repeated here.

[0147] Another embodiment of the present application further provides an electronic device, such as a server, which may include a processor (such as a CPU) that can be used to execute the simulation method in the aforementioned embodiment.

[0148] Another embodiment of the present application further provides a non-transitory computer-readable storage medium, which stores instructions. When these instructions are executed by a processor (eg, a CPU), the processor can implement the simulation method in the aforementioned embodiment.

[0149] Another embodiment of the present application further provides a computer program product, including computer-executable instructions, which implement the simulation method in the aforementioned embodiment when executed by a processor (such as a CPU).

[0150] It can be understood that, in the embodiments of the present application, the various parts of the content exemplified can be in an "and / or" relationship. In this article, the meaning of "and / or" refers to the context in which it is connected, which can be a common limiting relationship of "and", or can also be an alternative limiting relationship of "or". Therefore, the various parts of the content with an "and / or" relationship can be understood as including different combinations of situations in which "and / or" between each two parts of the content respectively represents a common limiting relationship of "and" or an alternative limiting relationship of "or", and this combination of different situations can be considered to be basically equivalent to the limiting scope of "at least one of the parts".

[0151] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A simulation method for simulating an integrated circuit chip, characterized in that: include: Before a software thread executes a call to any software module among a plurality of software modules, an idle flag bit corresponding to the software module in an idle flag sequence is detected; wherein the plurality of software modules respectively correspond to a plurality of hardware modules in the integrated circuit chip, the software thread is configured to periodically initiate calls to the plurality of software modules in a serial order, the plurality of software modules are configured to exchange data by being called by the software thread, the idle flag bit corresponding to any software module, when set to valid, is configured to indicate that there is no pending data currently waiting to be processed by the software module, and the detection of the idle flag bit corresponding to any software module is decoupled from the calling of the plurality of software modules; If, before the software thread executes a call to any software module, it is detected that the idle flag corresponding to the software module is currently invalid, the software thread is caused to execute the call to the software module; If, before the software thread executes a call to any software module, it is detected that the idle flag corresponding to the software module is currently valid, the software thread is caused to skip the call to the software module.

2. The simulation method according to claim 1, wherein: Data to be processed of any software module is stored in the interactive memory space, and access operations to the interactive memory space are coupled with calls to the plurality of software modules; The idle flag sequence is stored in an open memory space, which is independent of the interactive memory space. Furthermore, the detection operation of the idle flag bits of the open memory space is decoupled from the calling of the multiple software modules.

3. The simulation method according to claim 2, wherein: The setting operation of the idle flag corresponding to any software module is associated with the access operation to the interactive memory space.

4. The simulation method according to claim 3, wherein: The call to any software module includes: calling the execution function corresponding to the software module; The execution function corresponding to any software module is used, when called, to: Performing a read operation on the interactive memory space to obtain data to be processed provided by an upstream software module located at an interactive upstream side of the software module for the software module; and A write operation is performed on the interactive memory space to provide the data processed by the software module as to-be-processed data of a downstream software module on an interactive downstream side of the software module.

5. The simulation method according to claim 4, characterized in that: The execution function corresponding to any software module is also used when called to: A setting operation is performed on the open memory space to invalidate the idle flag corresponding to the downstream software module.

6. The simulation method according to claim 4, characterized in that: The calling of any software module further includes: in response to completion of the calling of the execution function corresponding to the software module, calling an idle function corresponding to the software module; Wherein, the idle function corresponding to any software module is used, when called: detecting the interactive memory space; If it is detected that the data to be processed of the software module in the interactive memory space is empty, a setting operation is performed on the open memory space to set the idle flag position corresponding to the software module to be valid.

7. A simulation device for simulating an integrated circuit chip, characterized in that: include: an idle detection unit, configured to detect an idle flag corresponding to any software module among a plurality of software modules in an idle flag sequence before a software thread executes a call to the software module; wherein the plurality of software modules respectively correspond to a plurality of hardware modules in the integrated circuit chip, the software thread is configured to periodically initiate calls to the plurality of software modules in a serial order, the plurality of software modules are configured to exchange data by being called by the software thread, the idle flag corresponding to any software module, when set to active, is configured to indicate that there is no pending data waiting to be processed by the software module, and the detection of the idle flag corresponding to any software module is decoupled from the calling of the plurality of software modules; A calling control unit, configured to control the calling of the software thread according to the detection result of the idle detection unit, wherein: If the idle detection unit detects that the idle flag corresponding to any software module is currently invalid before the software thread executes a call to the software module, the software thread is caused to execute the call to the software module; If the idle detection unit detects that the idle flag corresponding to any software module is currently valid before the software thread calls the software module, the software thread is caused to skip calling the software module.

8. An electronic device, characterized in that: The method comprises a processor configured to execute the simulation method according to any one of claims 1 to 6.

9. A non-transitory computer-readable storage medium, characterized in that The non-transitory computer-readable storage medium stores instructions, which, when executed by a processor, cause the processor to implement the simulation method according to any one of claims 1 to 6.

10. A computer program product, characterized in that The method comprises computer executable instructions, which implement the simulation method according to any one of claims 1 to 6 when executed by a processor.

Images