Simulation method and simulation device for simulating integrated circuit chip

Abstract

The invention relates to a simulation method and a simulation device for simulating an integrated circuit chip. Based on the application, the plurality of software modules can be divided into the plurality of module groups respectively corresponding to the plurality of software threads, and the plurality of module groups can be called in parallel by running the plurality of software threads in parallel. Therefore, the plurality of software modules can realize simulation of the integrated circuit chip based on data interaction matched with the data flow topology among the plurality of hardware modules. Wherein the cross-thread data interaction between the software modules associated and called by different software threads can be realized through data asynchronous transfer in a specified memory space, so that the synchronous coupling for limiting the associated calling of different software threads to be synchronous can be relieved through the asynchronous margin provided by the data asynchronous transfer; therefore, synchronous time delay caused by synchronous coupling can be avoided, and the software simulation time consumption of the integrated circuit chip can be shortened through the scheme that the multiple software modules are concurrently called by the multiple software threads.

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 is implemented by calling multiple software modules, wherein the multiple software modules may correspond to multiple hardware modules in the integrated circuit chip, and the multiple software modules may be serially called by a single software thread.

[0004] However, it takes a long time for a single software thread to serially call multiple software modules, which results in a long software simulation time for the integrated circuit chip. Therefore, how to shorten the software simulation time for the integrated circuit chip has become a technical problem to be solved in the prior art. Summary of the Invention

[0005] 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.

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

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

[0008] By running the multiple software threads in parallel and calling the multiple module groups in parallel, the multiple software modules can realize simulation of the integrated circuit chip based on data interaction matching the data flow topology between the multiple hardware modules;

[0009] The data interaction includes: same-thread data interaction between software modules in the same module group among the multiple module groups, and cross-thread data interaction between software modules in different module groups among the multiple module groups; the software modules in the same module group participating in the same-thread data interaction are serially called by the same software thread, and the software modules in different module groups participating in the cross-thread data interaction are called in parallel by different software threads, and the cross-thread data interaction is implemented by asynchronous transfer of data in a designated memory space to provide an asynchronous margin for releasing the synchronous coupling of the associated calls.

[0010] In some examples, optionally, the asynchronous data transfer includes: different software threads asynchronously executing independent data storage operations and data retrieval operations in the designated memory space for each software module in different module groups participating in the cross-thread data interaction.

[0011] In some examples, optionally, the asynchronous data transfer also includes: performing locking protection on the designated memory space during the execution of any one of the data storage operation and the data acquisition operation on the designated memory space; wherein the locking protection is used to prevent other software threads among the multiple software threads except the software thread currently executing the data storage operation or the data acquisition operation from accessing the designated memory space.

[0012] In some examples, optionally, different software threads asynchronously perform independent data storage operations and data acquisition operations in the designated memory space for each software module in different module groups participating in the cross-thread data interaction, including: 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 a sender, then performing a data storage operation on the designated memory space; 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 a receiver, then performing a data acquisition operation on the designated memory space.

[0013] In some examples, optionally, each of the multiple software modules is allocated a corresponding module memory space; the asynchronous execution of independent data storage operations and data acquisition operations in the designated memory space by different software threads for the software modules in different module groups participating in the cross-thread data interaction also includes: 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 sender, then the module memory space corresponding to other software modules in other module groups that are receivers of the cross-thread data interaction is determined as the designated memory space for the current cross-thread data interaction; 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 receiver, then the data stored by other modules in other module groups that are senders of the cross-thread data interaction are obtained from the module memory space corresponding to the currently called software module.

[0014] In some examples, optionally, each software module includes a corresponding execution function and an interface function, the execution function corresponding to each software module is used to implement the software module being called by the corresponding software thread, and the interface function corresponding to each software module is configured as an access interface of the module memory space corresponding to the software module; performing the data storage operation on the designated memory space includes: using the execution function corresponding to the currently called software module to call the interface function corresponding to other software modules in other module groups that serve as recipients of the cross-thread data interaction, so as to perform the data storage operation on the module memory space corresponding to the other software modules; performing the data acquisition operation on the designated memory space includes: using the execution function corresponding to the currently called software module to perform the data acquisition operation on the module memory space corresponding to the software module.

[0015] In some examples, optionally, data of different data categories in the cross-thread data interaction are respectively transferred through queues corresponding to different data categories in the designated memory space.

[0016] In some examples, optionally, dividing the multiple software modules into multiple module groups corresponding to multiple software threads respectively includes: 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 the grouping strategy of minimizing cross-thread data interaction.

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

[0018] a simulation configuration unit, configured to divide a plurality of software modules into a plurality of module groups corresponding to a plurality of software threads, respectively; wherein the plurality of software modules correspond to a 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;

[0019] a simulation execution unit, configured to execute the plurality of software threads in parallel and call the plurality of module groups in parallel, so that the plurality of software modules can simulate the integrated circuit chip based on data interaction matching the data flow topology between the plurality of hardware modules;

[0020] The data interaction includes: same-thread data interaction between software modules in the same module group among the multiple module groups, and cross-thread data interaction between software modules in different module groups among the multiple module groups; the software modules in the same module group participating in the same-thread data interaction are serially called by the same software thread, and the software modules in different module groups participating in the cross-thread data interaction are associated and called by different software threads, and the cross-thread data interaction is implemented by asynchronous transfer of data in a designated memory space to provide an asynchronous margin for releasing the synchronous coupling of the associated calls.

[0021] In some examples, optionally, the simulation execution unit is configured to implement the asynchronous data transfer in the following manner: different software threads asynchronously execute independent data storage operations and data retrieval operations in the designated memory space for each software module in different module groups participating in the cross-thread data interaction.

[0022] In some examples, optionally, the simulation execution unit is configured to further perform, when implementing the asynchronous data transfer, the following: performing locking protection on the designated memory space during the execution of any one of the data storage operation and the data acquisition operation on the designated memory space; wherein the locking protection is used to prevent other software threads among the multiple software threads except the software thread currently executing the data storage operation or the data acquisition operation from accessing the designated memory space.

[0023] In some examples, optionally, the simulation execution unit is specifically configured to implement the asynchronous data transfer in the following manner: if any software thread among multiple software threads determines that the software module currently called in the corresponding module group participates in the cross-thread data interaction as a sender, then a data storage operation is performed on the designated memory space; if any software thread among multiple software threads determines that the software module currently called in the corresponding module group participates in the cross-thread data interaction as a receiver, then a data acquisition operation is performed on the designated memory space.

[0024] In some examples, optionally, each of the multiple software modules is allocated a corresponding module memory space; the simulation execution unit is configured to further perform, when implementing the asynchronous data transfer: 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 a sender, then, the module memory space corresponding to other software modules in other module groups that are receivers of the cross-thread data interaction is determined as the designated memory space for the current cross-thread data interaction; 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 a receiver, then, data stored by other modules in other module groups that are senders of the cross-thread data interaction is obtained from the module memory space corresponding to the currently called software module.

[0025] In some examples, optionally, each software module includes a corresponding execution function and an interface function, the execution function corresponding to each software module is used to implement the software module being called by the corresponding software thread, and the interface function corresponding to each software module is configured as an access interface of the module memory space corresponding to the software module; the simulation execution unit is specifically configured to perform a data storage operation on the designated memory space in the following manner: using the execution function corresponding to the currently called software module, calling the interface function corresponding to other software modules in other module groups that are recipients of the cross-thread data interaction, so as to perform the data storage operation on the module memory space corresponding to the other software modules; the simulation execution unit is specifically configured to perform a data acquisition operation on the designated memory space in the following manner: using the execution function corresponding to the currently called software module, performing the data acquisition operation on the module memory space corresponding to the software module.

[0026] In some examples, optionally, data of different data categories in the cross-thread data interaction are respectively transferred through queues corresponding to different data categories in the designated memory space.

[0027] In some examples, optionally, the simulation configuration unit is configured to perform grouping of the multiple software modules in the following manner: evaluating the module interaction frequency between the multiple software modules based on the data flow topology, and implementing grouping of the multiple software modules based on the module interaction frequency with minimizing the cross-thread data interaction as the grouping strategy.

[0028] 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.

[0029] In another embodiment of the present application, a non-transitory computer readable storage medium storing instructions which, when executed by a processor, cause the processor to implement the simulation method as described in the foregoing embodiments is provided.

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

[0031] Based on the embodiments of the present application, a plurality of software modules can be divided into a plurality of module groups respectively corresponding to a plurality of software threads, and the plurality of module groups can be invoked in parallel by running the plurality of software threads in parallel, so that the plurality of software modules can implement simulation (i.e. software simulation) of an integrated circuit chip based on data interaction matching a data flow topology between a plurality of hardware modules. Among them, the cross-thread data interaction between the software modules called by different software threads associated can be implemented by asynchronous data transfer in a specified memory space, thereby the synchronous coupling of restricting the associated calls of different software threads to be synchronous can be released by the asynchronous margin provided by the asynchronous data transfer, so that the synchronization delay caused by the synchronous coupling of the associated calls can be avoided in the parallel invocation of the plurality of module groups by running the plurality of software threads in parallel. Further, compared with the software simulation scheme in which all the plurality of software modules are serially called by a single software thread, the scheme in which the plurality of software modules are concurrently called by the plurality of software threads implemented by decoupling the associated calls in the embodiments of the present application can shorten the software simulation time of the integrated circuit chip. BRIEF DESCRIPTION OF DRAWINGS

[0032] The following drawings only schematically illustrate and explain the present application and do not limit the scope of the present application:

[0033] Figure 1 An exemplary flowchart of the simulation method for simulating an integrated circuit chip in the embodiments of the present application;

[0034] Figure 2 An exemplary diagram of grouping a plurality of software modules for the simulation method for simulating an integrated circuit chip in the embodiments of the present application;

[0035] Figure 3 An exemplary diagram of a data flow topology between a plurality of hardware modules in an integrated circuit chip as a simulation object in the embodiments of the present application;

[0036] Figure 4 An exemplary diagram of data interaction simulated by the simulation method for simulating an integrated circuit chip in the embodiments of the present application by parallel invocation of a plurality of module groups;

[0037] Figure 5This 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;

[0038] Figure 6 Schematic diagram of an example of a simulation timing of a simulation method for simulating an integrated circuit chip in an embodiment of the present application when synchronous coupling is released;

[0039] Figure 7 This is a schematic diagram of an example of a simulation method for simulating an integrated circuit chip in an embodiment of the present application using a designated memory space to implement decoupled cross-thread data interaction. DETAILED DESCRIPTION

[0040] 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.

[0041] Figure 1 Schematic diagram of an exemplary flow chart of a simulation method for simulating an integrated circuit chip in an embodiment of the present application.

[0042] See Figure 1 In an embodiment of the present application, a simulation method for simulating an integrated circuit chip may include:

[0043] S110: Dividing the plurality of software modules into a plurality of module groups corresponding to the plurality of software threads respectively; and

[0044] S130: Calling multiple module groups in parallel by running multiple software threads in parallel.

[0045] Exemplarily, in an embodiment of the present application, the integrated circuit chip serving as the simulation object may be any one of a 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).

[0046] Exemplarily, in an embodiment of the present application, multiple software modules may correspond to multiple hardware modules in an integrated circuit chip, respectively, 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 as an example, 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.

[0047] For example, in an embodiment of the present application, the heterogeneous architecture in which the GPU or GPGPU is located may further include a CPU as a host, and physical memory. In this case, the CP may dispatch tasks of external input (e.g., input from the CPU as a host) to multiple computing cores, and a 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 in the on-chip mapping space of the GPU or GPGPU. The HBM area is used to store task data corresponding to each task, and the bus controller may utilize a page table of external input (e.g., input from the CPU as a 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 through 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.

[0048] For example, in an embodiment of the present application, tasks assigned by the CP may include operation tasks and access tasks. The operation tasks are used to instruct the computing core to use the module cluster to perform computing operations on task data. For example, the computing operations may include reduce operations. The access tasks are used to instruct the computing core to assist the bus controller in transferring task data between the HBM area of ​​the physical memory and the HBM module.

[0049] 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.

[0050] 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.

[0051] 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.

[0052] 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.

[0053] 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.

[0054] Illustratively, in an embodiment of the present application, the multiple module groups obtained by grouping the multiple software modules in S110 may correspond one-to-one to the multiple software threads.

[0055] 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 S110 calling multiple module groups in parallel by running multiple software threads in parallel can be considered as a process of calling multiple module groups in parallel by the virtual machine.

[0056] Figure 2 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 2The 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, where m is a positive integer greater than 1. Furthermore, these software modules may be grouped through S110 to obtain m module groups 0 to m-1 corresponding to the m software threads 1 to m-1. For example, the soft HBM module, the soft CP, and the soft bus controller may be grouped through S110 to be grouped into 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 through S110 to be grouped into 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.

[0057] 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).

[0058] 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 2 The use of the letter n to uniformly represent the number of soft computing modules i_1 to i_n in different intra-core soft module clusters i is only for simplifying visual and textual expressions.

[0059] Illustratively, in an embodiment of the present application, for multiple software threads 0 to m-1 running in parallel in S130, each software thread i is used to call a corresponding module group i among the multiple module groups 0 to m-1 during the running period, and each software thread i adopts a serial calling method for each software module in the module group i. For example, the serial calling 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.

[0060] Exemplarily, in an embodiment of the present application, S130 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.

[0061] Figure 3 This is a schematic diagram of an example of the data flow topology between multiple hardware modules in the integrated circuit chip used as the simulation object in the embodiment of this application. Figure 3 Assuming that the multiple hardware modules of the integrated circuit chip used as the simulation object in the embodiment of the present application include an HBM module, a CP, a module cluster with a computing core as the granularity, and a bus controller, the data flow topology between the multiple hardware modules may include:

[0062] S3 10: CP receives tasks inputted by the CPU as the host, including operation tasks and access tasks received successively; Figure 3 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 3 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.

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

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

[0065] S33 1: CP assigns the operation task to at least one computing core i;

[0066] S341: The CP assigns the operation task to at least one 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;

[0067] S332: 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;

[0068] S342: 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;

[0069] S333: The read / write module i in the module cluster of 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 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.

[0070] S334: At least one computing module i_p in the module cluster of the computing core i performs a computing operation on the task data. If there is more than one computing module i_p participating in the computing operation, each computing module i_p can perform the computing operation on the task data independently of each other, or can perform the computing operation on the task data cooperatively through interaction with each other.

[0071] S335: At least one computing module i_p in the module cluster of the computing core i returns the task data after performing the computing operation to the read-write module i.

[0072] S336: The read-write module i in the module cluster of the computing core i writes back the task data after performing the computing operation to the HBM module.

[0073] S343-S346 are similar to S333-S336.

[0074] S351: The CP assigns an access task to the computing core k, 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.

[0075] S352: The read-write module k in the module cluster of the computing core k obtains the task data (e.g., the task data after performing the computing operation) written back by the read-write module i in the module cluster of the computing core i and the read-write module j in the module cluster of the computing core j from the HBM module.

[0076] S353: The read-write module k in the module cluster of the computing core k provides the task data (e.g., the task data after performing the computing operation) obtained from the HBM module to the bus controller.

[0077] S322: The bus controller writes the task data (e.g., the task data after performing the computing operation) provided by the read-write module j in the module cluster of the computing core j to the HBM region of the physical memory through the off-chip bus.

[0078] In the embodiments of the present application, the data flow topology shown in Figure 3 is an exemplary expression of one-time handling of task data and data operation, and the data flow topology shown in Figure 3 may occur repeatedly in actual application for different task data provided continuously.

[0079] Figure 4 The simulation method for simulating an integrated circuit chip in the embodiments of the present application is illustrated by an instance of data interaction of simulation of a plurality of module groups in parallel. As shown in Figure 4 , the soft HBM module, the soft CP, the m-1 intra-core soft module clusters 1-m-1, and the soft bus controller in the plurality of software modules can be concurrently called by m software threads of the m module groups running in parallel, to realize the data interaction with the Figure 3 The data flow topology matches the data interaction shown. Wherein, if the m software threads are assigned to the software threads of the virtual machine of the electronic device running the simulation method, the virtual machine can assume the identity of the GPU or GPGPU in the heterogeneous architecture, and other software programs (such as the software driver of the GPU or GPGPU) in the electronic device other than the virtual machine can assume the identity of the CPU as the host in the heterogeneous architecture.

[0080] As can be seen from Figure 4 , the S333-S336 implemented by the software thread i through the serial call to the intra-core soft module cluster of the computing core i can occur in parallel with the S343-S346 implemented by the software thread j through the serial call to the intra-core soft module cluster of the computing core j, and the call of the software thread k to the soft read-write module k in the intra-core soft module cluster of the computing core k can also occur during this period, so that compared with the mode that all software modules are serially called by one software thread, dividing the multiple software modules into multiple module groups and concurrently calling by multiple software threads can help shorten the simulation time consumption.

[0081] In the embodiments of the present application, the multiple software modules based on the data interaction matching the data flow topology between the multiple hardware modules can include in-thread data interaction between the software modules of the same module group in the multiple module groups, and cross-thread data interaction between the software modules of different module groups in the multiple module groups. For example, in the example shown as Figure 4 , the in-thread data interaction includes S321, S333, S334 (involving cooperation between multiple soft computing modules in the same intra-core soft module cluster) and S335, and the cross-thread data interaction includes S331, S322, S336, S352 and S353. Wherein, the software modules participating in the in-thread data interaction in the same module group are serially called by the same software thread, and the software modules participating in the cross-thread data interaction in different module groups are associatedly called by different software threads.

[0082] It can be understood that the embodiments of the present application utilize Figure 3 and Figure 4 the examples shown, only for the purpose of facilitating understanding of the data flow topology between the multiple hardware modules, the data interaction between the multiple software modules, and the association therebetween, and not intended to make unnecessary limitations on the data flow topology between the multiple hardware modules or the data interaction between the multiple software modules.

[0083] Whether interacting with data within the same thread or across threads, synchronization is theoretically required between the sender and receiver of the data interaction. That is, the sender and receiver of the data interaction should theoretically complete the send and receive operations simultaneously. It should be understood that the synchronization mentioned herein is not necessarily limited to absolute synchronization in time, but can also include situations where the send and receive operations overlap in time.

[0084] For data interaction within the same thread, the same software thread only needs to call the software modules used as sender and receiver in the module group in a serial call process to achieve synchronization of the sender and receiver of data interaction within the same thread.

[0085] For cross-thread data interaction, if the sender and receiver are to be synchronized, 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 synchronization. Moreover, the associated calls that produce waiting delays will cause the serial calls to stagnate, thereby weakening the effect of shortening the simulation time.

[0086] Figure 5 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 5 ,by Figure 4 The software thread 0, software thread i and software thread k in the example are taken as examples, and the Figure 4 The software thread j in the process of cross-thread data interaction S331, S322, S336, S352 and S353 calls any software thread of the software module used as the sender, and generates a synchronization delay due to waiting for the software modules used as the receiver in other module groups to be synchronized by the calls of other software threads. Among them, the cross-thread data interaction S331, S322, S336, S352 and S353 implemented by associated calls can be respectively split into data storage operations and data acquisition operations, that is, cross-thread data interaction S331 is split into data storage operation S331t and data acquisition operation S331r, cross-thread data interaction S332 is split into data storage operation S332t and data acquisition operation S332r, cross-thread data interaction S336 is split into data storage operation S336t and data acquisition operation S336r, cross-thread data interaction S352 is split into data storage operation S352t and data acquisition operation S352r, and cross-thread data interaction S353 is split into data storage operation S353t and data acquisition operation S353r, Figure 5The shaded blocks in represent time slots occupied by 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.

[0087] 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.

[0088] 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.

[0089] For example, in an embodiment of the present application, asynchronous data transfer may specifically include: different software threads asynchronously executing independent data storage operations and data retrieval operations in a designated memory space for each software module participating in cross-thread data interaction in different module groups. That is, in an embodiment of the present application, the data sending and data receiving respectively performed by the sender and receiver of the cross-thread data interaction may be separated, the separated data sending is used to transfer data to the designated memory space through a data storage operation on the designated memory space, and the separated data receiving is used to obtain data from the designated memory space through a data retrieval operation on the designated memory space, and the data storage operation and data retrieval operation for the cross-thread data interaction for the same pair of sender and receiver may be for the same designated memory space.

[0090] 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).

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

[0092] If any of the software threads in the plurality of software threads determines that the currently invoked software module in the corresponding module group participates in the cross-thread data interaction as a sender, a data storing operation is performed on the specified memory space;

[0093] If any of the software threads in the plurality of software threads determines that the currently invoked software module in the corresponding module group participates in the cross-thread data interaction as a receiver, a data obtaining operation is performed on the specified memory space.

[0094] Figure 6 For an example of the simulation method for simulating the integrated circuit chip in the embodiments of the present application, the simulation timing in the case of decoupling synchronization is shown in the schematic diagram. Please refer to Figure 6 , still taking the software thread 0, the software thread i and the software thread k in Figure 4 as an example, and omitting the software thread j in Figure 4 , the cross-thread data interaction S331, S322, S336, S352 and S353 implemented by the associated invocation can be respectively split into a data storing operation and a data obtaining operation as Figure 5 . By comparing Figure 6 with Figure 5 , it can be seen that Figure 6 each pair of data storing operation and data obtaining operation can have an asynchronous margin due to the data transfer of the specified memory space, and such an asynchronous margin can decouple the synchronization of the associated invocation, thereby eliminating the synchronization delay existing in Figure 5 .

[0095] As can be seen above, in the embodiments of the present application, the data of the cross-thread data interaction can be implemented by the data transfer of the specified memory space, instead of being necessarily invoked at the same time (i.e. synchronous invocation) by the software modules of different module groups, so that the different software threads can not need to generate an interrupt waiting in order to facilitate the synchronous invocation of the software modules of different module groups, thereby decoupling the synchronization. That is, the cross-thread data interaction implemented by the data transfer of the specified memory space in the embodiments of the present application can be called decoupled data interaction. Further, by decoupled data interaction, the synchronization delay caused by the synchronization coupling of the associated invocation can be avoided in the parallel invocation of the plurality of module groups by the parallel running of the plurality of software threads. Compared with the software simulation scheme in which all the software modules are serially invoked by a single software thread, the scheme in which the plurality of software modules are concurrently invoked by the plurality of software threads by decoupling the associated invocation in the embodiments of the present application can shorten the software simulation time of the integrated circuit chip.

[0096] Further, in the embodiments of the present application, the decoupling mode of association call can be implemented simultaneously with the mode of grouping strategy optimization module group, so that the data transfer using the specified memory space can be reduced on the basis of decoupling synchronization, and reducing or even eliminating the synchronization delay.

[0097] Exemplarily, in the embodiments of the present application, the decoupling mode of cross-thread data interaction implemented by the data transfer using the specified memory space can be considered as providing an asynchronous margin for data reception of the receiving party. In this case, in the embodiments of the present application, the data storage operation and the data acquisition operation of the cross-thread data interaction of the same receiving party can be directed to the same specified memory space, i.e.

[0098] As described above, the data storage operation and the data acquisition operation of the cross-thread data interaction of the same pair of sending party and receiving party can be directed to the same specified memory space, i.e. each software module in the plurality of software modules can be allocated with a corresponding module memory space. In this case, the process of asynchronously executing the mutually independent data storage operation and data acquisition operation of each software module in the different module groups participating in the cross-thread data interaction in the specified memory space by different software threads can further include the following process of determining the specified memory space:

[0099] If any software thread in 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 a sending party, the module memory space corresponding to the other software module in the other module group as a receiving party of the cross-thread data interaction is determined as the specified memory space for the current cross-thread data interaction.

[0100] If any software thread in 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 a receiving party, the data stored by the other module in the other module group as a sending party of the cross-thread data interaction is acquired from the module memory space corresponding to the currently called software module.

[0101] Exemplarily, in the embodiments of the present application, each software module can include a corresponding software instance, an execution function and an interface function. Wherein, the software instance of each software module is used to implement the module function of the hardware module corresponding to the software module, the execution function of each software module is used to implement the calling of the software module by the software thread and the running of the software instance when called by the software thread, the interface function of each software module is configured as the access interface of the module memory space corresponding to the software module, and the interface function of each software module is used to be called by the other software module in the other module group as the other sending party (such as the execution function of the other software module) when the software module is the receiving party of the cross-thread data interaction.

[0102] 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 a sender, then the software thread performing a data storage 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 other software modules in other module groups that are recipients of cross-thread data interaction, so as to perform a data storage operation on the module memory space corresponding to the other software modules by calling the interface function corresponding to the other software modules.

[0103] Exemplarily, 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 receiver, then the software thread performs a data acquisition operation on the specified memory space, which may include: using the execution function corresponding to the currently called software module to perform a data acquisition operation on the module memory space corresponding to the software module.

[0104] Figure 7 This is a schematic diagram of an example of a simulation method for simulating an integrated circuit chip in an embodiment of the present application using a designated memory space to implement decoupled cross-thread data interaction. Figure 7 ,by Figure 4 Take the cross-thread data interaction S33 1 with the soft CP as the sender and the soft read / write module i as the receiver as an example:

[0105] If software thread 0 determines (for example, at the first moment) that the soft CP currently called in the corresponding module group 0 participates in the cross-thread data interaction S33 1 as the sender, then the software thread 0 can use the execution function corresponding to the currently called CP to call the interface function corresponding to the soft read-write module i in other module group i as the receiver of the cross-thread data interaction S33 1, so as to perform a data storage operation on the module memory space corresponding to the soft read-write module i by calling the interface function corresponding to the soft read-write module i.

[0106] If software thread i determines (for example, at a second moment later than the first moment) that the currently called soft read-write module i in the corresponding module group i participates in cross-thread data interaction as a receiver, then the software thread i can use the execution function corresponding to the currently called soft read-write module i to perform a data acquisition operation on the module memory space corresponding to the soft read-write module i.

[0107] For example, in the embodiments of the present application, the 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 affect the data storage operation or the data acquisition operation and cause data errors. For example, if the same receiver participates in multiple cross-thread data interactions with different senders, such as Figure 4 In the cross-thread data interaction S336 and S346 shown in FIG, with the soft HBM module as the receiver and the soft read / write module i and the soft read / write module j as the sender, there may be cross-accesses in which the module memory space corresponding to the same software module as the receiver is accessed simultaneously by the software module and at least two of the multiple other modules as the sender. To this end, in an embodiment of the present application, asynchronous data transfer may also include: during the period when any thread among the multiple software threads performs any one of a data storage operation and a data retrieval operation on the specified memory space (e.g., the module memory space corresponding to the software module as the receiver), performing locking protection on the specified memory space; wherein the locking protection operation can be used to prevent other software threads among the multiple software threads except the software thread currently performing the data storage operation or the data retrieval operation from accessing the specified memory space, and the software thread implementing the locking protection can release the locking protection in response to the completion of the currently implemented data storage operation or the data retrieval operation.

[0108] 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 software module serving as the recipient).

[0109] For example, in an embodiment of the present application, data interacting with thread data may also be stored in the module memory space corresponding to each software module, or may be stored in the thread memory allocated for the corresponding software thread. The embodiment of the present application does not limit the storage method of data interacting with thread data.

[0110] 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:

[0111] 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;

[0112] The simulation execution unit is used to simulate the integrated circuit chip (i.e., software simulation) 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.

[0113] Based on the above-mentioned simulation device of the embodiment of the present application, multiple software modules can be divided into multiple module groups corresponding to multiple software threads respectively, and multiple module groups can be called in parallel by running multiple software threads in parallel, so that multiple software modules can realize the simulation of integrated circuit chips based on data interaction matching the data flow topology between multiple hardware modules (i.e., software simulation). Among them, the cross-thread data interaction between software modules associated with different software threads can be realized by asynchronous data transfer in a designated memory space. Thus, the asynchronous margin provided by the asynchronous data transfer can be used to release the synchronous coupling that limits the associated calls of different software threads to synchronous, thereby avoiding the synchronization delay caused by the synchronous coupling of the associated calls in the parallel calls of multiple module groups running multiple software threads in parallel. Furthermore, compared to the software simulation scheme in which multiple software modules are all serially called by a single software thread, the embodiment of the present application can shorten the software simulation time of the integrated circuit chip by decoupling the associated calls to realize the scheme in which multiple software modules are concurrently called by multiple software threads.

[0114] Exemplarily, in an embodiment of the present application, the simulation configuration unit can be configured to perform grouping of multiple software modules in the following manner: evaluating the module interaction frequency between multiple software modules based on the data flow topology, and implementing grouping of multiple software modules based on the module interaction frequency with the grouping strategy of minimizing cross-thread data interaction.

[0115] For example, in an embodiment of the present application, the data interaction implemented by the simulation execution unit by running multiple software threads in parallel and calling multiple module groups in parallel may include: same-thread data interaction between software modules in the same module group in the multiple module groups, and cross-thread data interaction between software modules in different module groups in the multiple module groups. In this case, the software modules in the same module group that participate in the same-thread data interaction are serially called by the same software thread, and the software modules in different module groups that participate in the cross-thread data interaction are associated and called by different software threads, and the cross-thread data interaction is implemented by asynchronously transferring data in a designated memory space to provide an asynchronous margin for releasing the synchronous coupling of the associated calls.

[0116] Exemplarily, in an embodiment of the present application, the simulation execution unit can be configured to implement asynchronous data transfer in the following manner: different software threads asynchronously execute independent data storage operations and data acquisition operations in a designated memory space for each software module participating in cross-thread data interaction in different module groups.

[0117] Exemplarily, in an embodiment of the present application, the simulation execution unit can be configured to further be used when implementing asynchronous data transfer: during the period of performing any one of the data storage operation and data acquisition operation on the designated memory space, perform locking protection on the designated memory space; wherein, the locking protection is used to prevent other software threads among multiple software threads except the software thread currently executing the data storage operation or data acquisition operation from accessing the designated memory space.

[0118] For example, in an embodiment of the present application, the simulation execution unit is specifically configured to implement asynchronous data transfer in the following manner:

[0119] 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 sender, then performing a data storage operation on the designated memory space;

[0120] 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 receiver, a data acquisition operation is performed on the designated memory space.

[0121] For example, in an embodiment of the present application, each of the multiple software modules may be allocated a corresponding module memory space. In this case, the simulation execution unit may be configured to further perform the following when implementing asynchronous data transfer:

[0122] 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 a sender, then the module memory space corresponding to other software modules in other module groups that are receivers of the cross-thread data interaction is determined as the designated memory space for the current cross-thread data interaction;

[0123] 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 receiver, then the data stored by other modules in other module groups that serve as senders of cross-thread data interaction are obtained from the module memory space corresponding to the currently called software module.

[0124] Exemplarily, in the embodiments of the present application, each software module includes a corresponding execution function and an interface function, the execution function of each software module is configured to be called by the corresponding software thread, and the interface function of each software module is configured as an access interface of the module memory space corresponding to the software module. In this case, the simulation execution unit can be specifically configured to perform the data storage operation on the specified memory space by calling the interface function of the other software module in the other module group as the receiver of the cross-thread data interaction by using the execution function of the currently called software module, so as to perform the data storage operation on the module memory space corresponding to the other software module. Moreover, the simulation execution unit can also be specifically configured to perform the data acquisition operation on the specified memory space by using the execution function of the currently called software module to perform the data acquisition operation on the software module.

[0125] Exemplarily, in the embodiments of the present application, the data of different data categories in the cross-thread data interaction can be respectively transferred through the queues corresponding to the different data categories in the specified memory space.

[0126] Another embodiment of the present application also provides an electronic device, for example, a server, which can include a processor (for example, a CPU) that can be used to execute the simulation method in the foregoing embodiments.

[0127] Another embodiment of the present application also provides a non-transitory computer readable storage medium storing instructions, which can cause a processor (for example, a CPU) to implement the simulation method in the foregoing embodiments when the instructions are executed by the processor.

[0128] Another embodiment of the present application also provides a computer program product including computer executable instructions, which implement the simulation method in the foregoing embodiments when executed by a processor (for example, a CPU).

[0129] It can be understood that in the embodiments of the present application, there can be an "and / or" relationship between parts of the exemplary description. In this paper, the meaning of "and / or" is that there can be a common definition relationship of "and" or a choice definition relationship of "or" between the context connected by it. Therefore, the parts with "and / or" relationship can be understood as including different case combinations of "and / or" representing the common definition relationship of "and" or the choice definition relationship of "or" between each two parts, and this different case combination can be considered as substantially equivalent to the definition range of "at least one of the parts".

[0130] The above only is the preferred embodiment of the present application, and is not used to limit the present application, any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the protection scope of the present application.

Claims

1. A simulation method for simulating an integrated circuit chip, characterized in that: include: dividing a plurality of software modules into a plurality of module groups corresponding to a plurality of software threads, respectively; wherein the plurality of software modules correspond to a plurality of hardware modules in the integrated circuit chip, respectively; and each software thread in the plurality of software threads is configured to call a corresponding one of the plurality of module groups during execution; By running the multiple software threads in parallel and calling the multiple module groups in parallel, the multiple software modules can realize simulation of the integrated circuit chip based on data interaction matching the data flow topology between the multiple hardware modules; The data interaction includes: same-thread data interaction between software modules in the same module group among the multiple module groups, and cross-thread data interaction between software modules in different module groups among the multiple module groups; the software modules in the same module group participating in the same-thread data interaction are serially called by the same software thread, and the software modules in different module groups participating in the cross-thread data interaction are called in parallel by different software threads, and the cross-thread data interaction is realized by asynchronous transfer of data in a designated memory space to provide an asynchronous margin for releasing the synchronous coupling of the cross-thread calls.

2. The simulation method according to claim 1, wherein: The data asynchronous transfer includes: different software threads respectively execute mutually independent data storage operations and data acquisition operations in the designated memory space for each software module in different module groups participating in the cross-thread data interaction.

3. The simulation method according to claim 2, wherein: The data asynchronous transfer further includes: performing locking protection on the designated memory space during the period of performing any one of the data storing operation and the data obtaining operation on the designated memory space; The locking protection is used to prevent other software threads in the multiple software modules except the software thread currently executing the data storing operation or the data acquiring operation from accessing the designated memory space.

4. The simulation method according to claim 2, wherein: The different software threads are software modules in different module groups that participate in the cross-thread data interaction, and asynchronously execute independent data storage operations and data acquisition operations in the designated memory space, including: 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 a sender, performing a data storage operation on the designated memory space; 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 receiver, a data acquisition operation is performed on the designated memory space.

5. The simulation method according to claim 4, characterized in that: Each software module in the plurality of software modules is allocated a corresponding module memory space; The step of asynchronously executing independent data storage operations and data acquisition operations in the designated memory space by different software threads representing software modules in different module groups that participate in the cross-thread data interaction further includes: If any software thread among the multiple software threads determines that a software module currently called in a corresponding module group participates in the cross-thread data interaction as a sender, then determining the module memory space corresponding to other software modules in other module groups that are receivers of the cross-thread data interaction as the designated memory space for the current cross-thread data interaction; 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 receiver, then, data stored by other modules in other module groups that serve as senders of the cross-thread data interaction are obtained from the module memory space corresponding to the currently called software module.

6. The simulation method according to claim 4, characterized in that: Each software module includes a corresponding execution function and an interface function. The execution function corresponding to each software module is used to enable the software module to be called by the corresponding software thread, and the interface function corresponding to each software module is configured as an access interface to the module memory space corresponding to the software module; The performing the data storage operation on the designated memory space includes: using the execution function corresponding to the currently called software module to call the interface function corresponding to other software modules in other module groups that are recipients of the cross-thread data interaction, so as to perform the data storage operation on the module memory space corresponding to the other software modules; The performing of the data acquisition operation on the designated memory space includes: utilizing the execution function corresponding to the currently called software module to perform the data acquisition operation on the module memory space corresponding to the software module.

7. The simulation method according to claim 1, wherein: Data of different data categories in the cross-thread data interaction are transferred through queues corresponding to different data categories in the designated memory space respectively; and / or, The dividing of the plurality of software modules into a plurality of module groups corresponding to the plurality of software threads respectively includes: evaluating the module interaction frequency between the plurality of software modules according to the data flow topology; and grouping the plurality of software modules based on the module interaction frequency using the grouping strategy of minimizing cross-thread data interaction.

8. A simulation device for simulating an integrated circuit chip, characterized in that: include: a simulation configuration unit, configured to divide a plurality of software modules into a plurality of module groups corresponding to a plurality of software threads, respectively; wherein the plurality of software modules correspond to a 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; a simulation execution unit, configured to execute the plurality of software threads in parallel and call the plurality of module groups in parallel, so that the plurality of software modules can simulate the integrated circuit chip based on data interaction matching the data flow topology between the plurality of hardware modules; The data interaction includes: same-thread data interaction between software modules in the same module group among the multiple module groups, and cross-thread data interaction between software modules in different module groups among the multiple module groups; the software modules in the same module group participating in the same-thread data interaction are serially called by the same software thread, and the software modules in different module groups participating in the cross-thread data interaction are associated and called by different software threads, and the cross-thread data interaction is implemented by asynchronous transfer of data in a designated memory space to provide an asynchronous margin for releasing the synchronous coupling of the associated calls.

9. 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 7.

10. 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 7.

Images