Cross-process simulation method and device, computer equipment and readable storage medium
By creating shared memory and establishing cross-process communication in a multi-GPU chip system, the problem of parallel read and write operations on the same storage space by multiple GPUs is solved, achieving efficient utilization of simulation resources and reducing data overhead.
Patent Information
- Application Number
- CN202511485591.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-16
- Publication Date
- 2026-02-10
AI Technical Summary
In multi-GPU chip systems, traditional simulation methods cannot effectively achieve parallel read and write operations on the same memory space by multiple GPUs, resulting in wasted simulation resources and increased data overhead.
By creating shared memory in multiple functional modules and establishing cross-process communication based on remote procedure calls, parallel simulation between multiple simulation processes can be achieved, sharing the same memory.
It improves simulation efficiency, reduces data overhead, and saves simulation resources.
Smart Images
Figure CN121503372A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of chip simulation technology, and in particular to a cross-process simulation method, apparatus, computer device, and readable storage medium. Background Technology
[0002] With the development of artificial intelligence technology, the demand for computing power is increasing. However, GPUs (Graphics Processing Units), as the core of computing power, are finding it increasingly difficult to improve computing power within a limited area. The introduction of chiplet technology has effectively alleviated this computing power pressure. Chiplet technology breaks down a large chip into multiple smaller, independent functional modules, each containing different functions. These modules can be connected to one or more base chips through high-speed interfaces, thus forming a complete chip system.
[0003] As an IP (Intellectual Property, referring to a pre-designed functional module that can be ported to other chips) subsystem, the GPU can be packaged with single or multiple GPUs or CPUs (Central Processing Units) and various subsystems to form a new chip system, thereby improving the computing power of the GPU per unit area.
[0004] However, this context places higher demands on chip front-end design and simulation environments. For example, multiple GPUs in a chip system may need to make read and write requests to the same memory space simultaneously, which requires the simulation to also allow multiple GPUs to make read and write requests to the same memory space. Summary of the Invention
[0005] Based on this, this application provides a cross-process simulation method, apparatus, computer device, computer-readable storage medium, and computer program product based on shared memory.
[0006] In a first aspect, this application provides a cross-process simulation method, which is applied to chip simulation, wherein the chip includes multiple functional modules, and each functional module has a corresponding simulation process; the method includes:
[0007] Create shared memory in one of the multiple functional modules based on memory configuration information;
[0008] Based on remote procedure call, cross-process communication is established between multiple simulation processes of multiple functional modules;
[0009] Multiple simulation processes are run to perform parallel simulations of multiple functional modules, and the multiple simulation processes share the shared memory based on the inter-process communication.
[0010] In one embodiment, the memory configuration information includes the target functional module carrying the shared memory and the memory configuration of the shared memory; the step of creating shared memory in one of the multiple functional modules based on the memory configuration information includes:
[0011] In response to a memory creation request from any functional module, if it is determined that the shared memory has not been created, the shared memory is created in the target functional module based on the memory configuration of the shared memory, and the shared memory has a memory identifier;
[0012] If it is determined that any of the functional modules is not the target functional module, the memory identifier of the shared memory is returned to any of the functional modules.
[0013] In one embodiment, after responding to a memory creation request from any functional module, the method further includes:
[0014] If it is determined that the shared memory has been created, the memory identifier of the shared memory is returned to any of the functional modules.
[0015] In one embodiment, the method further includes:
[0016] Obtain the number of memory accesses for each of the aforementioned functional modules during the chip simulation process;
[0017] The functional module with the highest number of visits is identified as the target functional module.
[0018] In one embodiment, the establishment of cross-process communication between multiple simulation processes of the multiple functional modules based on remote procedure calls includes:
[0019] Obtain process configuration information for multiple simulation processes, and exchange the process configuration information among multiple simulation processes;
[0020] Based on the process configuration information, cross-process communication between multiple simulation processes is established based on remote procedure calls.
[0021] In one embodiment, the plurality of functional modules include a first functional module and a second functional module, and the plurality of simulation processes include a first simulation process created by the first functional module and a second simulation process created by the second functional module; if the first functional module carries shared memory, the process configuration information of the first simulation process of the first functional module includes a remote procedure call address; the process configuration information of the second simulation process of the second functional module includes the configuration of the second simulation process;
[0022] The step of obtaining process configuration information for multiple simulation processes and exchanging the process configuration information among the multiple simulation processes includes:
[0023] The remote procedure call address of the first simulation process is obtained by calling local storage, and the configuration of the second simulation process is obtained.
[0024] The second simulation process of the second functional module obtains the remote procedure call address of the first simulation process through the local storage;
[0025] The first simulation process of the first functional module obtains the configuration of the second simulation process through the local storage.
[0026] In one embodiment, establishing cross-process communication between multiple simulation processes based on remote procedure calls includes:
[0027] Configure the first simulation process as a parallel simulation server and configure a remote procedure call interface;
[0028] Configure the second simulation process as a client for parallel simulation, and connect the client and the server by calling the remote procedure call interface based on the remote procedure call address, thereby establishing cross-process communication between the second simulation process and the first simulation process.
[0029] In one embodiment, after establishing cross-process communication between the second simulation process and the first simulation process, the method further includes:
[0030] The second simulation process is invoked to monitor the inter-process communication. If the inter-process communication link is detected to be broken, the remote procedure call interface is invoked based on the remote procedure call address to connect the client and the server, thereby establishing inter-process communication between the second simulation process and the first simulation process.
[0031] In one embodiment, running multiple simulation processes to perform parallel simulations of multiple functional modules, wherein the multiple simulation processes share the shared memory based on the inter-process communication, includes:
[0032] Run the first simulation process, and in response to the first read / write request of the first functional module to the shared memory, send the first read / write request to the shared memory;
[0033] The second simulation process is run, and in response to the second read / write request of the second functional module to the shared memory, the second read / write request is transmitted to the first simulation process based on the inter-process communication.
[0034] In one embodiment, after transmitting the second read / write request to the first emulation process based on the inter-process communication, the method further includes:
[0035] If the second read / write request has a return value, the first simulation process is invoked to return the return value of the second read / write request to the second simulation process based on the inter-process communication.
[0036] In one embodiment, the method further includes:
[0037] The codec is invoked to encode and decode the communication data of the cross-process communication.
[0038] In one embodiment, the second functional module includes multiple modules.
[0039] In one embodiment, the method further includes:
[0040] In response to a command to close or open inter-process communication of the simulation process of the specified functional module, the inter-process communication of the simulation process of the specified functional module is closed or opened.
[0041] In one embodiment, the method further includes:
[0042] The debugging module is invoked to record the communication log of the cross-process communication, which includes the communication time, communication data, and communication objects.
[0043] Secondly, this application provides a cross-process simulation device, which is applied to chip simulation. The chip includes multiple functional modules, each of which has a corresponding simulation process. The device includes:
[0044] The memory creation module is configured to perform the creation of shared memory in one of the multiple functional modules based on memory configuration information;
[0045] The communication establishment module is configured to perform cross-process communication between multiple simulation processes of the multiple functional modules based on remote procedure calls;
[0046] The simulation module is configured to run multiple simulation processes to perform parallel simulations of multiple functional modules, with the multiple simulation processes sharing the shared memory based on the inter-process communication.
[0047] Thirdly, this application provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described method.
[0048] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.
[0049] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method.
[0050] The aforementioned cross-process simulation method, apparatus, computer equipment, computer-readable storage medium, and computer program product create shared memory in one of multiple functional modules based on memory configuration information, and establish cross-process communication between multiple simulation processes of multiple functional modules based on remote procedure calls, thereby running multiple simulation processes to perform parallel simulation of multiple functional modules. Since each functional module has a corresponding simulation process, running multiple simulation processes enables parallel simulation of multiple functional modules, improving simulation efficiency. Furthermore, during the simulation process, multiple simulation processes can share shared memory based on cross-process communication, thereby reducing data overhead and saving simulation resources. Attached Figure Description
[0051] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0052] Figure 1 This is a flowchart illustrating a cross-process simulation method in one embodiment;
[0053] Figure 2 This is a flowchart illustrating the steps for creating shared memory in one embodiment;
[0054] Figure 3 This is a diagram illustrating the application environment of a process simulation method in one embodiment.
[0055] Figure 4This is a flowchart illustrating the steps for determining the target functional module in one embodiment;
[0056] Figure 5 This is a flowchart illustrating the steps for establishing cross-process communication in one embodiment;
[0057] Figure 6 A flowchart illustrating the steps of exchanging process configuration information in one embodiment;
[0058] Figure 7 This is a flowchart illustrating the steps for establishing cross-process communication in another embodiment;
[0059] Figure 8 This is a schematic diagram of the cross-process communication establishment process in one embodiment;
[0060] Figure 9 This is a flowchart illustrating the cross-process communication steps in one embodiment;
[0061] Figure 10 This is a schematic diagram of cross-process communication in one embodiment;
[0062] Figure 11 This is a block diagram of a cross-process simulation device in one embodiment;
[0063] Figure 12 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation
[0064] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0065] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.
[0066] Since multiple GPUs in a chip system may need to read and write to the same memory space simultaneously, the simulation must also allow multiple GPUs to read and write to the same memory space. Traditional GPU IP-level simulations typically consist of only one GCD (Graphics Core Die, the core computing unit in a GPU), a peripheral model, and an stimulus environment, where the peripheral model includes a memory model. In a GPU IP environment where multiple GCDs are combined in chiplets, the simulation environment is usually built by configuring each GCD in a different simulator (i.e., one GCD corresponds to one simulator), and each simulator instantiates the memory model of the corresponding GCD.
[0067] However, the memory models instantiated in each simulator cannot be accessed by the GCDs in other simulators. If a computational task is divided into multiple parts and distributed to the GCDs in multiple simulators, each simulator will initialize its own memory space and initialize multiple sets of raw data, providing each simulator with the necessary data to begin the next step of computation. However, multiple instantiations consume more simulation resources, and the multiple sets of raw data result in resource waste. Furthermore, the results data need to be retrieved from each simulator for comparison. This increases the data overhead of the simulation and makes the simulation process more complex.
[0068] Based on this, this application provides a cross-process simulation method based on shared memory. This method is applied to chip simulation, where a chip includes multiple functional modules, each with a corresponding simulation process. Figure 1 As shown, the method includes:
[0069] Step 102: Create shared memory in one of the multiple functional modules based on memory configuration information.
[0070] In this context, a functional module can be a core module of a sub-chip packaged within a die. Functional modules are typically used to perform specific tasks. For example, a functional module can be a CPU core, the core chip of the CPU, made of monocrystalline silicon, used to perform all calculations, receive / store commands, process data, etc., and is the core of digital processing. A functional module can also be the Graphics Card Display (GCD), one of the core components of a GPU, the core computing unit of the GPU responsible for performing graphics processing tasks. It contains a large number of processing cores and related logic circuits, capable of performing complex graphics rendering and computation tasks. In this embodiment, multiple functional modules can be the same or different. Each functional module is configured in a different simulator; therefore, each functional module can create its own simulation process to simulate the corresponding functional module.
[0071] Memory configuration information can be predefined configuration information used to create shared memory. This may include, but is not limited to, memory type (such as SRAM, DRAM, etc.), memory read / write ports, and read / write logic. Shared memory is a mapped segment of memory that can be shared between processes. This memory space is created by one process and can be shared and accessed by multiple processes.
[0072] In this embodiment, shared memory can be created in one of the multiple functional modules based on predefined memory configuration information, so that multiple simulation processes of multiple functional modules can share the shared memory during the simulation process.
[0073] Step 104: Based on remote procedure calls, establish cross-process communication between multiple simulation processes of multiple functional modules.
[0074] Remote Procedure Call (RPC) is a technology that allows a program running on one computer to call a subroutine on another computer. This technology shields the underlying network communication details, making remote communication between programs as simple as local calls.
[0075] Inter-process communication (IPC) refers to the mechanism by which programs running in different processes exchange data or information. Because the operating system allocates an independent virtual address space (memory space) for each process, one process typically cannot directly access the memory of another process. Based on this, this implementation establishes IPC between multiple simulation processes of multiple functional modules, allowing these simulation processes to share the shared memory configured within one of the functional modules.
[0076] Step 106: Run multiple simulation processes to perform parallel simulations on multiple functional modules. The multiple simulation processes share shared memory based on cross-process communication.
[0077] Since each functional module has its own simulation process, running multiple simulation processes allows for parallel simulation of multiple functional modules, thus improving simulation efficiency. Furthermore, because shared memory has been configured for multiple functional modules through the above steps, and cross-process communication has been established between the multiple simulation processes of these modules, multiple simulation processes can share shared memory during simulation based on cross-process communication, thereby saving simulation resources.
[0078] In the aforementioned cross-process simulation method, shared memory is created within one of the multiple functional modules based on memory configuration information. Cross-process communication is established between multiple simulation processes of these functional modules based on remote procedure calls, thereby running multiple simulation processes to perform parallel simulation of the multiple functional modules. Since each functional module has a corresponding simulation process, running multiple simulation processes enables parallel simulation of multiple functional modules, improving simulation efficiency. Furthermore, during the simulation process, multiple simulation processes can share shared memory based on cross-process communication, thus reducing data overhead and saving simulation resources.
[0079] In an exemplary embodiment, the memory configuration information described above may include the target functional module carrying the shared memory and the memory configuration of the shared memory. The target functional module refers to the specific functional module carrying the shared memory. The target functional module can be randomly specified from multiple functional modules, or it can be selected based on a certain strategy; this embodiment does not limit this. The memory configuration of the shared memory may include, but is not limited to, memory type, memory read / write ports, and read / write logic. For example... Figure 2 As shown, in step 102, shared memory is created in one of the multiple functional modules based on memory configuration information. Specifically, this may include:
[0080] Step 202: In response to a memory creation request from any functional module, create shared memory if it is determined that shared memory has not been created.
[0081] Since each functional module is configured in a different simulator, traditional simulation instantiates the memory model of the corresponding functional module in each simulator, which requires initializing multiple copies of raw data and distributing them to each simulator, resulting in a waste of data resources.
[0082] Specifically, in this embodiment, when the simulator instantiation of each functional module requests memory creation, that is, when any functional module initiates a memory creation request, it can first determine whether the shared memory has already been created. If the shared memory has not been created, it can be created in the target functional module based on the shared memory's memory configuration. The shared memory has a corresponding memory identifier, which is used to uniquely identify the shared memory, and the corresponding shared memory can be accessed based on the memory identifier. The "any functional module" can be the functional module currently requesting memory creation among multiple functional modules.
[0083] Step 204: If it is determined that any functional module is not the target functional module, return the memory identifier of the shared memory to any functional module.
[0084] Specifically, if any functional module (i.e., the functional module currently requesting memory creation) is determined not to be the target functional module, the memory identifier of the shared memory is returned to that functional module. Since the target functional module is a predefined functional module that hosts the shared memory, if the functional module currently requesting memory creation is not the target functional module, it means that the already created shared memory is not within the functional module currently requesting memory creation. Therefore, the memory identifier of the shared memory can be returned to the functional module currently requesting memory creation, allowing that functional module to access the corresponding shared memory based on the memory identifier. Subsequent memory read and write operations can be performed within this shared memory, enabling multiple functional modules to share the same shared memory. This saves data resources and reduces data overhead.
[0085] In an exemplary embodiment, in step 202, after responding to a memory creation request from any functional module, the method may further include: if it is determined that shared memory has been created, returning the memory identifier of the shared memory to any functional module.
[0086] Specifically, when the simulator instantiation of each functional module requests the creation of memory, that is, when any functional module initiates a memory creation request, it can first determine whether the shared memory has already been created. If the shared memory has been created, it means that the shared memory already exists. Therefore, the memory identifier of the shared memory can be returned to any functional module, so that any functional module can access the corresponding shared memory based on the memory identifier, thereby realizing the sharing of the same shared memory.
[0087] In one exemplary embodiment, the above-described cross-process simulation method can be applied to, for example... Figure 3 The simulation environment shown is illustrated below. Taking a chiplet comprising two functional modules (e.g., a first functional module and a second functional module, representing different design modules) as an example, each functional module has its own simulator. Therefore, a simulation process for simulating that functional module is run separately. For example, a corresponding first simulation process can be created for the first functional module, and a corresponding second simulation process can be created for the second functional module. Specifically, the first and second simulation processes can run on different servers or on the same server; this embodiment does not limit this. Each simulation process may also include a signal transmission module and a data transmission module. The signal transmission module controls signal transmission, and the data transmission module controls data transmission.
[0088] In this embodiment, cross-server and cross-process memory operations (including memory creation and memory read / write) are achieved by creating cross-domain memory access models (such as memio_wrapper) in each functional module. This cross-domain memory access model can be a C++ model, which may include RPC and completely overrides the original memio (i.e., memory I / O), providing adapted API interfaces (for calling relevant functions in the original memio). Then, inter-process communication is performed via RPC to create simulation processes for the corresponding functional modules.
[0089] For example, the cross-domain memory access model (memio_wrapper) may include a corresponding server (memio_wrapper_server) and client (memio_wrapper_client). The functional module that configures memio_wrapper_server is used to host shared memory, while the functional module that configures memio_wrapper_client can access shared memory through inter-process communication by calling RPC.
[0090] For example, if the first functional module is configured with `memio_wrapper_server`, the simulator of the second functional module can remotely call the constructor in the first functional module through `memio_wrapper_client` when creating memory. If the first functional module has already completed the creation of shared memory, the second functional module can obtain the corresponding memory identifier. Subsequent memory read and write operations are implemented on the shared memory of the first functional module, thereby achieving parallel simulation of the two functional modules in two processes, sharing the same shared memory, to save simulation resources and simplify the simulation process. It is understandable that the clocks of each functional module can also be synchronously set for parallel simulation.
[0091] In one exemplary embodiment, such as Figure 4 As shown, the above method may further include:
[0092] Step 402: Obtain the number of memory accesses for each functional module during the chip simulation process.
[0093] Chip simulation is a core verification step in the integrated circuit design process, referring to the use of software tools to simulate the actual behavior and performance of chips on a computer. Its core purpose is to discover and fix design errors before fabrication, ensuring that the chip functions correctly, meets performance standards, has controllable power consumption, and satisfies reliability requirements.
[0094] Memory access refers to the memory access behavior of functional modules during simulation. In this embodiment, multiple functional modules share the same shared memory based on inter-process communication. Therefore, to reduce inter-process requests and improve simulation efficiency, the number of memory accesses by each functional module during the core-level simulation can be obtained before creating the shared memory, and the target functional module carrying the shared memory can be determined based on subsequent steps. The number of memory accesses by each functional module can be obtained based on core-level simulation scenario prediction or testing.
[0095] Step 404: Determine the functional module with the highest number of visits as the target functional module.
[0096] Specifically, after obtaining the number of memory accesses for each functional module in the core during core simulation based on the above steps, the magnitude of the access counts for each functional module can be compared to determine the functional module with the highest access count. This functional module with the highest access count is then identified as the target functional module to carry the shared memory, thereby reducing cross-process requests between functional modules during core simulation.
[0097] In this embodiment, by obtaining the number of times each functional module accesses memory during the core simulation process, and determining the functional module with the highest number of accesses as the target functional module carrying shared memory, the cross-process requests of each functional module during the core simulation process are reduced, thereby improving simulation efficiency.
[0098] In one exemplary embodiment, such as Figure 5 As shown, in step 104, cross-process communication between multiple simulation processes of multiple functional modules is established based on remote procedure calls, which may specifically include:
[0099] Step 502: Obtain process configuration information for multiple simulation processes and exchange process configuration information among multiple simulation processes.
[0100] Process configuration information may include, but is not limited to, process identifiers (used to distinguish different processes), memory addresses (such as the address of shared memory), connection parameters (parameters required to establish inter-process communication connections, such as authentication information and encryption methods), communication protocols (the protocols used for inter-process communication), and data formats (such as the data formats used when transferring data between processes). Process configuration information is the foundation for establishing stable communication links and conducting effective data exchange between processes. In actual simulations, process configuration information can be configured according to the specific system environment and requirements.
[0101] Specifically, in the process of establishing cross-process communication, the process configuration information of multiple simulation processes can be obtained first, and the process configuration information can be exchanged between multiple simulation processes to lay the foundation for establishing cross-process communication between multiple simulation processes.
[0102] Step 504: Based on the process configuration information, establish cross-process communication between multiple simulation processes based on remote procedure calls.
[0103] Because the process configuration information of each simulation process is exchanged among them, each simulation process obtains the process configuration information of the other simulation processes. Based on this, each simulation process can establish cross-process communication with other simulation processes by calling RPC, thereby enabling cross-process communication between the simulation processes.
[0104] In an exemplary embodiment, multiple functional modules include a first functional module and a second functional module, and multiple simulation processes include a first simulation process created by the first functional module and a second simulation process created by the second functional module. If the first functional module carries shared memory, the process configuration information of the first simulation process of the first functional module includes a remote procedure call address; the process configuration information of the second simulation process of the second functional module includes the configuration of the second simulation process. For example... Figure 6 As shown, in step 502, process configuration information for multiple simulation processes is obtained, and this process configuration information is exchanged among the multiple simulation processes. Specifically, this may include:
[0105] Step 602: Obtain the remote procedure call address of the first simulation process and the configuration of the second simulation process by calling local storage.
[0106] Local storage can be a pre-configured file path used for exchanging process configuration information between multiple simulation processes. Since the first functional module carries shared memory, the address of the first simulation process within that module can be used as an RPC address, allowing other simulation processes to establish links with this RPC address and access shared memory via cross-process communication. The configuration of the second simulation process refers to its process identifier, connection parameters, communication protocol, and data format.
[0107] Step 604: The second simulation process of the second functional module obtains the remote procedure call address of the first simulation process through local storage.
[0108] Specifically, the second simulation process of the second functional module can obtain the remote procedure call address of the first simulation process through local storage.
[0109] Step 606: The first simulation process of the first functional module obtains the configuration of the second simulation process through local storage.
[0110] Specifically, the first simulation process of the first functional module can obtain the configuration of the second simulation process through local storage. This enables the exchange of process configuration information between multiple simulation processes, facilitating cross-process communication.
[0111] In one exemplary embodiment, such as Figure 7 As shown, in step 504, establishing cross-process communication between multiple simulation processes based on remote procedure calls can specifically include:
[0112] Step 702: Configure the first simulation process as the server for parallel simulation and configure the remote procedure call interface.
[0113] Since the first functional module carries shared memory, the first simulation process of the first functional module can be configured as the server side of parallel simulation (i.e., the server side), and an interface (API, Application Programming Interface) that can be remotely called via RPC can be configured.
[0114] Step 704: Configure the second simulation process as a client for parallel simulation, and call the remote procedure call interface to connect the client and the server to establish cross-process communication.
[0115] Specifically, the second simulation process can be configured as a client for parallel simulation, and the RPC interface can be called based on the remote procedure call address to connect the client and the server, thereby establishing cross-process communication between the second simulation process and the first simulation process, so that the second simulation process can access the shared memory in the first functional module based on the cross-process communication.
[0116] In one scenario, multiple second functional modules can be included. Each of these multiple second simulation processes is configured as a client for parallel simulation and establishes a connection with the server, i.e., establishing cross-process communication between each second simulation process and the first simulation process. This allows each second simulation process to access shared memory within the first functional module via this cross-process communication, enabling multiple functional modules to share shared memory without significantly increasing simulation overhead, thus more closely resembling the operating mode of a multi-functional module in a chiplet structure in an actual chip.
[0117] In an exemplary embodiment, after establishing inter-process communication between the second simulation process and the first simulation process, the method may further include: invoking the second simulation process to monitor the inter-process communication link; and, if the inter-process communication link is detected to be broken, invoking a remote procedure call interface based on the remote procedure call address to connect the client and the server, thereby re-establishing the inter-process communication between the second simulation process and the first simulation process. This method monitors the stability of the inter-process communication link through the second simulation process; when a link break is detected before the task has finished, a re-establishment request is initiated to ensure the stability of the inter-process communication link.
[0118] In an exemplary embodiment, the above-described cross-process communication establishment process is further described below, such as... Figure 8 As shown, the example includes simulation process 0 and simulation process 1, where simulation process 0 is the server for parallel simulation and simulation process 1 is the client for parallel simulation. After the simulation program starts running, a simulation database can be created to store various configuration and status information during the simulation process.
[0119] For simulation process 0, start the simulation for process 0, configure the RPC address for process 0, and send it to local storage (local file) for subsequent remote procedure calls. Process 0 polls the local storage to obtain the configuration information of process 1 and records it in process 0. Then, process 0 configures RPC functions (such as creating a server and configuring APIs that can be called remotely), allowing other processes to remotely call the relevant APIs via RPC. Perform testing and checks to ensure that the configuration of process 0 is correct.
[0120] For simulation process 1, the simulation of process 1 is started; then, local storage is polled to obtain the RPC address of process 0 and recorded in process 1, returning the configuration information of process 1. Afterwards, the client of process 1 connects to process 0 (process 1 creates a client and remotely calls the API to connect to process 0 based on the recorded configuration of process 0). Testing and checks are performed to ensure that the configuration of process 1 is correct. This completes the establishment of cross-process communication.
[0121] During subsequent simulations, thanks to the established inter-process communication, any operation on shared memory by process 1 can be performed by remotely calling the relevant APIs in process 0 via RPC, thereby manipulating the shared memory in process 0. Until the simulation ends, subsequent simulation results can be compared with the ideal results using data from the same shared memory, thus reducing simulation data overhead and simplifying the simulation process for parallel simulations of multiple processes.
[0122] In one exemplary embodiment, such as Figure 9As shown, in step 106, multiple simulation processes are run to perform parallel simulations of multiple functional modules. These multiple simulation processes share shared memory based on inter-process communication, and may specifically include:
[0123] Step 902: Run the first simulation process and, in response to the first read / write request from the first functional module to the shared memory, send the first read / write request to the shared memory.
[0124] In this embodiment, the first simulation process is created by the first functional module, and the first functional module carries shared memory. Therefore, the first read / write request from the first functional module to the shared memory can be processed by the shared memory within the first functional module.
[0125] Step 904: Run the second simulation process and, in response to the second read / write request for shared memory from the second functional module, transmit the second read / write request to the first simulation process based on inter-process communication.
[0126] Since the shared memory is configured in the first functional module, for the second read / write request of the second functional module to the shared memory, it is necessary to transmit the second read / write request to the first simulation process of the first functional module through inter-process communication so that the shared memory in the first functional module can be processed.
[0127] Step 906: If the second read / write request has a return value, call the first simulation process to return the return value of the second read / write request to the second simulation process based on cross-process communication.
[0128] In one scenario, if the second read / write request returns a value, the first simulation process of the first functional module can be invoked to return the return value of the second read / write request to the second simulation process via inter-process communication. This enables multiple simulation processes to perform memory read / write operations across processes, reducing data overhead and improving resource utilization.
[0129] In one scenario, during inter-process communication, a codec can be invoked to encode and decode the communication data, thereby improving the security of inter-process communication. The codec can be configured within the cross-domain memory access model (memio_wrapper).
[0130] In an exemplary embodiment, the above-described inter-process communication process is further described below, such as... Figure 10As shown, this embodiment uses a first functional module and a second functional module as an example for explanation. The first functional module creates a first simulation process, and the second functional module creates a second simulation process. The first simulation process is the server for parallel simulation, and the second simulation process is the client for parallel simulation. During simulation, when the first functional module or the test platform performs read / write operations on shared memory, the first simulation process first sends the request to the cross-domain memory access model-server (memio_wrapper_server, hereinafter referred to as server) and determines the destination of the request. Then, it sends the request from the first functional module to the shared memory within the first functional module. When the second functional module or the test platform performs read / write operations on shared memory, the second simulation process first sends the request to the cross-domain memory access model-client (memio_wrapper_client, hereinafter referred to as client) and determines the destination of the request. It then calls the codec to package the data into an RPC transmission format and sends it to the codec in the server of the first functional module via the RPC-based cross-process communication link. After unpacking the data, it sends it to the shared memory. If the request from the client returns a value, the return value is repackaged using the codec in the server and sent back to the client. After unpacking, subsequent operations are performed. This completes a cross-process shared memory read / write operation.
[0131] In an exemplary embodiment, the cross-domain memory access model (memio_wrapper) can also be configured with an enable or disable switch for inter-process communication. The method may further include: disabling the inter-process communication function of the simulation process of the specified functional module in response to a disable command for inter-process communication of the specified functional module's simulation process; and enabling the inter-process communication function of the simulation process of the specified functional module in response to an enable command for inter-process communication of the specified functional module's simulation process. This satisfies simulation requirements in different simulation scenarios.
[0132] In an exemplary embodiment, to meet debugging requirements, a debugging module can also be configured in the cross-domain memory access model (memio_wrapper). The above method can then further include: calling the debugging module to record communication logs for cross-process communication, wherein the communication logs may include communication time, communication data, and communication objects, etc.
[0133] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.
[0134] Based on the same inventive concept, this application also provides a cross-process simulation apparatus for implementing the cross-process simulation method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more cross-process simulation apparatus embodiments provided below can be found in the limitations of the cross-process simulation method described above, and will not be repeated here.
[0135] In one exemplary embodiment, such as Figure 11 As shown, a cross-process simulation device is provided. The device is applied to chip simulation, where each chip includes multiple functional modules, and each functional module has a corresponding simulation process. The device includes:
[0136] The memory creation module 1102 is configured to perform the creation of shared memory in one of the multiple functional modules based on memory configuration information;
[0137] The communication establishment module 1104 is configured to perform cross-process communication between multiple simulation processes of the multiple functional modules based on remote procedure calls;
[0138] Simulation module 1106 is configured to run multiple simulation processes to perform parallel simulations of multiple functional modules, wherein the multiple simulation processes share the shared memory based on the inter-process communication.
[0139] In an exemplary embodiment, the memory configuration information includes a target functional module carrying the shared memory and the memory configuration of the shared memory; the memory creation module is configured to perform the following: in response to a memory creation request from any functional module, if it is determined that the shared memory has not been created, create the shared memory in the target functional module based on the memory configuration of the shared memory, wherein the shared memory has a memory identifier; if it is determined that the target functional module is not the target functional module, return the memory identifier of the shared memory to the target functional module.
[0140] In an exemplary embodiment, the memory creation module is configured to perform the following: in response to a memory creation request from any functional module, if it is determined that the shared memory has been created, return the memory identifier of the shared memory to the functional module.
[0141] In an exemplary embodiment, the memory creation module is configured to perform: obtaining the number of times each of the functional modules accesses memory during the chip simulation process; and determining the functional module with the highest number of accesses as the target functional module.
[0142] In an exemplary embodiment, the communication establishment module is configured to perform: obtaining process configuration information of multiple simulation processes and exchanging the process configuration information among the multiple simulation processes; and establishing cross-process communication between the multiple simulation processes based on remote procedure calls according to the process configuration information.
[0143] In an exemplary embodiment, the plurality of functional modules include a first functional module and a second functional module, and the plurality of simulation processes include a first simulation process created by the first functional module and a second simulation process created by the second functional module; if the first functional module carries shared memory, the process configuration information of the first simulation process of the first functional module includes a remote procedure call address; the process configuration information of the second simulation process of the second functional module includes the configuration of the second simulation process; the communication establishment module is configured to perform: calling local storage to obtain the remote procedure call address of the first simulation process, and obtaining the configuration of the second simulation process; the second simulation process of the second functional module obtains the remote procedure call address of the first simulation process through the local storage; the first simulation process of the first functional module obtains the configuration of the second simulation process through the local storage.
[0144] In an exemplary embodiment, the communication establishment module is configured to perform: configuring the first simulation process as a server for parallel simulation and configuring a remote procedure call interface; configuring the second simulation process as a client for parallel simulation, and calling the remote procedure call interface based on the remote procedure call address to connect the client and the server, thereby establishing cross-process communication between the second simulation process and the first simulation process.
[0145] In an exemplary embodiment, the communication establishment module is configured to: call the second simulation process to monitor the inter-process communication; and, if the inter-process communication link is detected to be disconnected, call the remote procedure call interface based on the remote procedure call address to connect the client and the server, thereby establishing inter-process communication between the second simulation process and the first simulation process.
[0146] In an exemplary embodiment, the simulation module is configured to: run the first simulation process, and in response to the first functional module's first read / write request to the shared memory, send the first read / write request to the shared memory; run the second simulation process, and in response to the second functional module's second read / write request to the shared memory, transmit the second read / write request to the first simulation process based on the inter-process communication.
[0147] In an exemplary embodiment, the simulation module is configured to: after transmitting the second read / write request to the first simulation process based on the inter-process communication, if the second read / write request has a return value, call the first simulation process to return the return value of the second read / write request to the second simulation process based on the inter-process communication.
[0148] In one exemplary embodiment, the apparatus further includes a calling module configured to perform: calling a codec to encode and decode the communication data of the inter-process communication.
[0149] In one exemplary embodiment, the second functional module includes multiple modules.
[0150] In an exemplary embodiment, the apparatus further includes a response module configured to perform: in response to a shutdown or startup instruction for inter-process communication of the simulation process of the specified functional module, shutting down or starting inter-process communication of the simulation process of the specified functional module.
[0151] In an exemplary embodiment, the calling module is configured to execute: calling the debugging module to record the communication log of the inter-process communication, the communication log including communication time, communication data, and communication objects.
[0152] Each module in the aforementioned cross-process simulation device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.
[0153] In one exemplary embodiment, a computer device is provided, the internal structure of which can be as shown in the figure. Figure 12 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores simulation data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a cross-process simulation method.
[0154] Those skilled in the art will understand that Figure 12 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0155] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.
[0156] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.
[0157] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.
[0158] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.
[0159] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.
[0160] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.
Claims
1. A cross-process simulation method, characterized in that, The method is applied to chip simulation, wherein the chip includes multiple functional modules, and each functional module has a corresponding simulation process; the method includes: Create shared memory in one of the multiple functional modules based on memory configuration information; Based on remote procedure call, cross-process communication is established between multiple simulation processes of multiple functional modules; Multiple simulation processes are run to perform parallel simulations of multiple functional modules, and the multiple simulation processes share the shared memory based on the inter-process communication.
2. The method according to claim 1, characterized in that, The memory configuration information includes the target functional module that carries the shared memory and the memory configuration of the shared memory; the step of creating shared memory in one of the multiple functional modules based on the memory configuration information includes: In response to a memory creation request from any functional module, if it is determined that the shared memory has not been created, the shared memory is created in the target functional module based on the memory configuration of the shared memory, and the shared memory has a memory identifier; If it is determined that any of the functional modules is not the target functional module, the memory identifier of the shared memory is returned to any of the functional modules.
3. The method according to claim 2, characterized in that, Following the response to a memory creation request from any functional module, the method further includes: If it is determined that the shared memory has been created, the memory identifier of the shared memory is returned to any of the functional modules.
4. The method according to claim 2, characterized in that, The method further includes: Obtain the number of memory accesses for each of the aforementioned functional modules during the chip simulation process; The functional module with the highest number of visits is identified as the target functional module.
5. The method according to any one of claims 1 to 4, characterized in that, The cross-process communication between multiple simulation processes of the multiple functional modules established based on remote procedure calls includes: Obtain process configuration information for multiple simulation processes, and exchange the process configuration information among multiple simulation processes; Based on the process configuration information, cross-process communication between multiple simulation processes is established based on remote procedure calls.
6. The method according to claim 5, characterized in that, The plurality of functional modules include a first functional module and a second functional module, and the plurality of simulation processes include a first simulation process created by the first functional module and a second simulation process created by the second functional module; if the first functional module carries shared memory, the process configuration information of the first simulation process of the first functional module includes a remote procedure call address; the process configuration information of the second simulation process of the second functional module includes the configuration of the second simulation process; The step of obtaining process configuration information for multiple simulation processes and exchanging the process configuration information among the multiple simulation processes includes: The remote procedure call address of the first simulation process is obtained by calling local storage, and the configuration of the second simulation process is obtained. The second simulation process of the second functional module obtains the remote procedure call address of the first simulation process through the local storage; The first simulation process of the first functional module obtains the configuration of the second simulation process through the local storage.
7. The method according to claim 6, characterized in that, The method for establishing cross-process communication between multiple simulation processes based on remote procedure calls includes: Configure the first simulation process as a parallel simulation server and configure a remote procedure call interface; Configure the second simulation process as a client for parallel simulation, and connect the client and the server by calling the remote procedure call interface based on the remote procedure call address, thereby establishing cross-process communication between the second simulation process and the first simulation process.
8. The method according to claim 7, characterized in that, After establishing cross-process communication between the second simulation process and the first simulation process, the method further includes: The second simulation process is invoked to monitor the inter-process communication. If the inter-process communication link is detected to be broken, the remote procedure call interface is invoked based on the remote procedure call address to connect the client and the server, thereby establishing inter-process communication between the second simulation process and the first simulation process.
9. The method according to claim 7, characterized in that, The operation of multiple simulation processes to perform parallel simulation of multiple functional modules, wherein the multiple simulation processes share the shared memory based on the inter-process communication, includes: Run the first simulation process, and in response to the first read / write request of the first functional module to the shared memory, send the first read / write request to the shared memory; The second simulation process is run, and in response to the second read / write request of the second functional module to the shared memory, the second read / write request is transmitted to the first simulation process based on the inter-process communication.
10. The method according to claim 9, characterized in that, After transmitting the second read / write request to the first simulation process based on the cross-process communication, the method further includes: If the second read / write request has a return value, the first simulation process is invoked to return the return value of the second read / write request to the second simulation process based on the inter-process communication.
11. The method according to claim 9 or 10, characterized in that, The method further includes: The codec is invoked to encode and decode the communication data of the cross-process communication.
12. The method according to claim 6, characterized in that, The second functional module includes multiple components.
13. The method according to claim 1, characterized in that, The method further includes: In response to a command to close or open inter-process communication of the simulation process of the specified functional module, the inter-process communication of the simulation process of the specified functional module is closed or opened.
14. The method according to claim 1, characterized in that, The method further includes: The debugging module is invoked to record the communication log of the cross-process communication, which includes the communication time, communication data, and communication objects.
15. A cross-process simulation device, characterized in that, The device is used for chip simulation, wherein the chip includes multiple functional modules, each of which has a corresponding simulation process; the device includes: The memory creation module is configured to perform the creation of shared memory in one of the multiple functional modules based on memory configuration information; The communication establishment module is configured to perform cross-process communication between multiple simulation processes of the multiple functional modules based on remote procedure calls; The simulation module is configured to run multiple simulation processes to perform parallel simulations of multiple functional modules, with the multiple simulation processes sharing the shared memory based on the inter-process communication.
16. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 14.
17. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 14.
18. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 14.