A graphics processor performance simulation method and simulation system

Abstract

The embodiment of the application discloses a kind of graphic processor performance simulation method and simulation system, it is related to integrated circuit technical field, for both can guarantee the accuracy of multiple grain performance simulation of graphic processor to some extent, can also improve performance simulation speed, to shorten the verification period and invent. Graphic processor includes the first type of grain for the hardware model based on hardware description language implementation, the second type of grain is the software model based on software establishment, interconnection grain is the hardware model based on hardware description language implementation or the software model based on software establishment;The method comprises loading the first type of grain to hardware simulation platform, and performance simulation is carried out on hardware simulation platform based on first simulation data;Second type of grain is loaded to software simulation platform, and second type of grain obtains second simulation data from interconnection grain, and performance simulation is carried out on software simulation platform based on second simulation data.The application is applicable to the simulation of multiple grain graphic processor.

Description

Technical Field

[0001] This application relates to the field of integrated circuit technology, and in particular to a method and system for simulating the performance of a graphics processor. Background Technology

[0002] Graphics Processing Units (GPUs), as general-purpose computing chips capable of accelerating computational tasks, face numerous challenges such as manufacturing process limitations and multi-chip interconnection, urgently requiring the application of multi-die technology. Multi-die technology is a semiconductor solution that integrates multiple independent dies into a single package using advanced packaging techniques.

[0003] To confirm whether the performance of a graphics processing unit (GPU) comprising multiple chips meets design requirements, performance simulation is necessary during GPU development. Currently, hardware simulation is primarily used, which involves building a multi-chip co-simulation environment using register-transfer level (RTL) code from real hardware. While hardware simulation can accurately simulate the GPU hardware system, its speed decreases rapidly with increasing hardware scale, and it offers limited flexibility for debugging and modification, thus significantly reducing its speed. Summary of the Invention

[0004] In view of this, the embodiments of this application provide a graphics processor performance simulation method and simulation system, which can not only ensure the accuracy of performance simulation of multiple chips of graphics processor to a certain extent, but also improve the performance simulation speed, thereby shortening the verification cycle.

[0005] In a first aspect, embodiments of this application provide a method for simulating the performance of a graphics processor, wherein the graphics processor includes a first type of die, a second type of die, and interconnect dies, the first type of die being a hardware model implemented based on a hardware description language, the second type of die being a software model built based on software, and the interconnect dies being either a hardware model implemented based on a hardware description language or a software model built based on software; the method includes: loading the first type of die onto a hardware simulation platform, the first type of die obtaining first simulation data from the interconnect dies, and performing performance simulation on the hardware simulation platform based on the first simulation data; loading the second type of die onto a software simulation platform, the second type of die obtaining second simulation data from the interconnect dies, and performing performance simulation on the software simulation platform based on the second simulation data.

[0006] According to a specific implementation of an embodiment of this application, the first type of die obtains first simulation data from the interconnect die, including: the first type of die sending a simulation data acquisition request; a first verification environment obtaining the first simulation data from the interconnect die according to the simulation data acquisition request, and sending the first simulation data to the first type of die; wherein, the first verification environment runs on the hardware simulation platform.

[0007] According to a specific implementation of an embodiment of this application, the interconnect die is a software model built based on software and is loaded onto the software simulation platform; wherein, the first verification environment obtains first simulation data from the interconnect die according to the simulation data acquisition request, including: the first verification environment storing the simulation data acquisition request into shared memory; the second verification environment obtaining the simulation data acquisition request from the shared memory and obtaining the first simulation data corresponding to the simulation data acquisition request from the interconnect die; wherein, the second verification environment runs on the software simulation platform; the second verification environment storing the first simulation data into the shared memory; and the first verification environment obtaining the first simulation data from the shared memory.

[0008] According to a specific implementation of an embodiment of this application, after the first verification environment stores the simulation data acquisition request into shared memory, the first verification environment further acquires the first simulation data from the interconnect die according to the simulation data acquisition request by: the first verification environment sets the value of the first state parameter in the shared memory to a first value; wherein, the first state parameter corresponds to the die hardware model, and the first value indicates that there is a pending request; wherein, the second verification environment acquires the simulation data acquisition request from the shared memory by: when the second verification environment detects that the value of the first state parameter is the first value, it acquires the simulation data acquisition request from the shared memory.

[0009] According to a specific implementation of an embodiment of this application, before the first verification environment obtains the first simulation data from the shared memory, the first verification environment obtaining the first simulation data from the interconnect die according to the simulation data acquisition request further includes: the second verification environment setting the value of the first state parameter in the shared memory to a second value; wherein, the second value indicates that the simulation data has been prepared; wherein, the first verification environment obtaining the first simulation data from the shared memory includes: obtaining the first simulation data from the shared memory when the first verification environment detects that the value of the first state parameter is the second value.

[0010] According to one specific implementation of the embodiments of this application, the number of the first type of grains is less than the number of the second type of grains; or, the number of the first type of grains is greater than or equal to the number of the second type of grains.

[0011] According to a specific implementation of an embodiment of this application, the method further includes: the hardware simulation platform collecting first performance simulation information and second performance simulation information of the first die; wherein, the first performance simulation information is information corresponding to the first type of die; the second performance simulation information is information corresponding to the first die belonging to the second type of die; and based on the first performance simulation information and the second performance simulation information, determining whether the functions and performance of the hardware model and the software model of the first die are consistent.

[0012] According to a specific implementation of an embodiment of this application, the first simulation data is a first test case; the interconnect die is a software model built based on software; before the first type of die obtains the first simulation data from the interconnect die, the method further includes: the hardware simulation platform writes the preset test cases into the interconnect die through a backdoor function.

[0013] According to a specific implementation of an embodiment of this application, after the first type of die is loaded onto the hardware simulation platform and before the first type of die obtains the first simulation data from the interconnect die, the method further includes: starting the hardware simulation platform; configuring the initialization information of the first type of die; and starting the first type of die on the hardware simulation platform according to the initialization information of the first type of die.

[0014] Secondly, embodiments of this application provide a graphics processor performance simulation system, comprising: a hardware simulation platform, a software simulation platform, and a graphics processor; wherein the graphics processor comprises: a first type of die, a second type of die, and interconnect dies; the first type of die is a hardware model implemented based on a hardware description language, the second type of die is a software model built based on software, and the interconnect dies are either a hardware model implemented based on a hardware description language or a software model built based on software; wherein the hardware simulation platform is used to load the first type of die; the first type of die is used to obtain first simulation data from the interconnect dies and perform performance simulation on the hardware simulation platform based on the first simulation data; the software simulation platform is used to load the second type of die; the second type of die is used to obtain second simulation data from the interconnect dies and perform performance simulation on the software simulation platform based on the second simulation data.

[0015] According to a specific implementation of an embodiment of this application, the first type of die is specifically used for: sending a simulation data acquisition request; a first verification environment is running on a hardware simulation platform, and the first verification environment acquires first simulation data from the interconnect die according to the simulation data acquisition request, and sends the first simulation data to the first type of die.

[0016] According to a specific implementation of an embodiment of this application, the interconnect die is a software model built based on software and can be loaded onto the software simulation platform; wherein, the first verification environment is used to: store the simulation data acquisition request into shared memory; the software simulation platform runs a second verification environment, the second verification environment being used to obtain the simulation data acquisition request from the shared memory, and obtain first simulation data corresponding to the simulation data acquisition request from the interconnect die; store the first simulation data into the shared memory; the first verification environment is also used to obtain the first simulation data from the shared memory.

[0017] According to a specific implementation of an embodiment of this application, the first verification environment is further configured to: after storing the simulation data acquisition request into shared memory, set the value of the first state parameter in the shared memory to a first value; wherein, the first state parameter corresponds to the die hardware model, and the first value indicates that there is a request to be processed; wherein, the second verification environment is further configured to: when the value of the first state parameter is detected to be the first value, retrieve the simulation data acquisition request from the shared memory.

[0018] According to a specific implementation of an embodiment of this application, the second verification environment is further configured to set the value of the first state parameter in the shared memory to a second value before the first verification environment obtains the first simulation data from the shared memory; wherein the second value indicates that the simulation data has been prepared; wherein the first verification environment is further configured to: obtain the first simulation data from the shared memory when the value of the first state parameter is detected to be the second value.

[0019] According to one specific implementation of the embodiments of this application, the number of the first type of grains is less than the number of the second type of grains; or, the number of the first type of grains is greater than or equal to the number of the second type of grains.

[0020] According to a specific implementation of an embodiment of this application, the hardware simulation platform is further configured to collect first performance simulation information and second performance simulation information of the first die; wherein, the first performance simulation information is information corresponding to the first type of die; the second performance simulation information is information corresponding to the first die belonging to the second type of die; and based on the first performance simulation information and the second performance simulation information, it is determined whether the functions and performance of the hardware model and the software model of the first die are consistent.

[0021] According to a specific implementation of an embodiment of this application, the first simulation data is a first test case; the interconnect die is a software model built based on software; the hardware simulation platform is further used to write preset test cases into the interconnect die through a backdoor function before the first type of die obtains the first simulation data from the interconnect die.

[0022] The graphics processor performance simulation method and system of this embodiment obtain first simulation data from interconnect dies based on a first type of die implemented using a hardware description language, and perform performance simulation on a hardware simulation platform based on the first simulation data. Conversely, a second type of die implemented using software obtains second simulation data from interconnect dies, and performs performance simulation on a software simulation platform based on the second simulation data. The interconnect dies are either hardware models implemented using a hardware description language or software models built using software. Thus, when simulating the performance of a graphics processor, performance simulation is performed on a portion of the graphics processor's dies on a hardware simulation platform and on another portion of the graphics processor's dies on a software simulation platform. This process combines the realism of hardware simulation with the speed of software simulation. In other words, it can ensure the accuracy of performance simulation for multiple dies of the graphics processor to a certain extent while improving the performance simulation speed, thereby shortening the verification cycle. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 A flowchart illustrating a graphics processor performance simulation method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a graphics processor provided in a specific embodiment of this application; Figure 3A schematic diagram of the structure of a graphics processor during simulation provided in a specific embodiment of this application; Figure 4 A schematic diagram of the structure of a graphics processor during simulation, provided for yet another specific embodiment of this application; Figure 5 This is a schematic diagram of the structure of a graphics processor performance simulation system provided in an embodiment of this application. Detailed Implementation

[0025] The embodiments of this application will now be described in detail with reference to the accompanying drawings. It should be understood that the described embodiments are merely some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0026] To enable those skilled in the art to better understand the technical concept, implementation scheme and beneficial effects of the embodiments of this application, detailed descriptions are provided below through specific embodiments.

[0027] This application aims to provide a graphics processor performance simulation method and simulation system. The graphics processor in this embodiment includes multiple chips. By performing performance simulation on some chips of the graphics processor through a hardware simulation platform and on some chips through a software simulation platform, the accuracy of hardware simulation can be preserved to a certain extent, while improving the performance simulation speed of multiple chips of the graphics processor and shortening the verification cycle.

[0028] The graphics processor can be a general-purpose graphics processor (GPGPU). A general-purpose graphics processor is a chip that uses a graphics processor to handle graphics tasks to perform general-purpose computing tasks that would otherwise be handled by a central processing unit.

[0029] The following provides a detailed description of the graphics processor performance simulation method and simulation system according to embodiments of the present invention.

[0030] Figure 1 This is a flowchart illustrating a graphics processor performance simulation method according to an embodiment of this application. The graphics processor (graphics processor during simulation) in this embodiment may include a first type of die, a second type of die, and interconnect dies. The first type of die is a hardware model implemented based on a hardware description language, the second type of die is a software model built based on software, and the interconnect dies are either a hardware model implemented based on a hardware description language or a software model built based on software.

[0031] like Figure 1As shown, the graphics processor performance simulation method of this embodiment may include: S101. Load the first type of die onto the hardware simulation platform. The first type of die obtains the first simulation data from the interconnect die and performs performance simulation on the hardware simulation platform based on the first simulation data.

[0032] like Figure 2 The general-purpose graphics processor shown in the embodiment includes multiple dies, specifically several core dies responsible for processing computing tasks and one interconnect die (SoC die) with interconnect and storage subsystems. The core die is mainly divided into a task distribution subsystem, a computing subsystem, and a cache subsystem. The core dies are interconnected through the SoC die.

[0033] In this embodiment, the first type of die simulates at least one core die among a plurality of core dies, the second type of die simulates the other core dies among a plurality of core dies besides the core die corresponding to the first type of die, and the interconnect die simulates the SOC die.

[0034] The first type of die can be implemented based on a register transfer level (RTL) model of a hardware description language; that is, the first type of die is an RTL model. Performance simulation of the first type of die on a hardware simulation platform can accurately simulate the die's hardware system. In this embodiment, the hardware simulation platform can be a Verilog Compiler Simulator (VCS).

[0035] Interconnect dies can be either RTL models or software models.

[0036] It is understandable that when the interconnect chip is an RTL model, the interconnect chip runs on a hardware simulation platform; when the interconnect chip is a software model, the interconnect chip runs on a software simulation platform.

[0037] In a real graphics processor, the interconnect die, in addition to interconnecting with other dies, also has a storage system. Data required by other dies is read from the interconnect die. In this embodiment, the interconnect die stores simulation data. The first type of die can obtain the simulation data, i.e., the first simulation data, from it. After obtaining the first simulation data, the first die can perform performance simulation on a hardware simulation platform.

[0038] Loading the first type of die into the hardware simulation platform can be done by loading one die into the hardware simulation platform, or by loading multiple dies into the hardware simulation platform.

[0039] S102. Load the second type of die into the software simulation platform. The second type of die obtains the second simulation data from the interconnect die and performs performance simulation on the software simulation platform based on the second simulation data.

[0040] The second type of die can be a software model built based on software such as SystemC, C / C++, or GEM5.

[0041] The software simulation platform can be GEM5 (GEM5 is a merger of GEMS and M5; GEMS is the simulation framework from Wisconsin, and M5 is the simulation framework from Michigan; 5 is the version number of the merged framework). GEM5 is widely used as a full-system simulator for computer system research and development. It can simulate the behavior of various computer systems, including processors, memory, and networks, and provides rich configuration options and extension interfaces.

[0042] Performance simulation of the second type of die on a software simulation platform is faster, more flexible, and easier to debug than simulation on a hardware platform. It can simulate the functions and performance of real hardware from a macroscopic perspective.

[0043] Loading the second type of die into the software simulation platform can be done by loading one die from the second type of die into the software simulation platform, or by loading multiple dies from the second type of die into the software simulation platform.

[0044] In this embodiment, a first type of die implemented using a hardware description language obtains first simulation data from interconnect dies and performs performance simulation on a hardware simulation platform based on the first simulation data. Conversely, a second type of die built using software obtains second simulation data from interconnect dies and performs performance simulation on a software simulation platform based on the second simulation data. The interconnect dies are either hardware models implemented using a hardware description language or software models built using software. Thus, when performing performance simulation on multiple dies of the graphics processor, performance simulation is performed on a portion of the graphics processor's dies on a hardware simulation platform and on another portion of the graphics processor's dies on a software simulation platform. This process combines the realism of hardware simulation with the speed of software simulation. In other words, it can ensure the accuracy of performance simulation on multiple dies of the graphics processor to a certain extent while improving the performance simulation speed, thereby shortening the verification cycle.

[0045] The first type of die can directly obtain simulation data from the interconnect die. To reduce the operating pressure on the first type of die, simulation data can be obtained from the interconnect die through other modules, and then the simulation data can be sent to the first type of die. In some examples, the process of the first type of die obtaining the first simulation data from the interconnect die in step S101 may include: S101a, The first type of die sends a simulation data acquisition request.

[0046] S101b: The first verification environment obtains first simulation data from the interconnect die according to the simulation data acquisition request, and sends the first simulation data to the first type of die; wherein, the first verification environment runs on the hardware simulation platform.

[0047] The first verification environment monitors the simulation data acquisition request of the first type of die. When the simulation data acquisition request is detected by the first type of die, the first simulation data is obtained from the interconnect die according to the acquisition request, and the first simulation data is sent to the first type of die, so that the first type of die can acquire the first simulation data.

[0048] The interconnect chip providing simulation data can be a hardware model implemented using a hardware description language or a software model built using software. To improve the simulation speed of the interconnect chip, in some examples, the interconnect chip is a software model built using software and loaded onto a software simulation platform. In this case, the first type of chip needs to acquire simulation data across simulation platforms, and during the simulation of the first type of chip, it may need to frequently interact with the interconnect chip to exchange data. To establish a stable interaction path, in some examples, the first verification environment in step S101b, based on the simulation data acquisition request, acquires the first simulation data from the interconnect chip, which may include: A1. The first verification environment stores the simulation data acquisition request in shared memory.

[0049] Shared memory can be created in either way; in some cases, it can be created using a hardware emulation platform or a software emulation platform.

[0050] A2. The second verification environment obtains a simulation data acquisition request from shared memory and obtains the first simulation data corresponding to the simulation data acquisition request from the interconnect die; wherein, the second verification environment runs on the software simulation platform.

[0051] A3. The second verification environment stores the first simulation data into shared memory.

[0052] A4. The first verification environment obtains the first simulation data from shared memory.

[0053] In this embodiment, the first verification environment on the hardware simulation platform and the second verification environment on the software simulation platform can interact with the shared memory and ultimately send the simulation data to the first type of die. The first type of die only needs to perform performance simulation based on the first simulation data, which reduces the operating pressure on the first type of die.

[0054] If the second verification environment fails to process the simulation data acquisition request in a timely manner after the first verification environment writes it into shared memory, it will lead to simulation delay. To ensure the continuity of simulation between the software simulation platform and the hardware simulation platform, in some examples, after the first verification environment stores the simulation data acquisition request into shared memory in step A1, the first verification environment in step S101b may further include acquiring the first simulation data from the interconnect die according to the simulation data acquisition request. A5. The first verification environment sets the value of the first state parameter in the shared memory to the first value.

[0055] The first state parameter corresponds to the die hardware model, and the first value indicates that there is a request to be processed.

[0056] The first state parameter can also be called a semaphore. The first state parameter can be created by a software simulation platform or a hardware simulation platform.

[0057] In step A2, the second verification environment obtains a simulation data acquisition request from shared memory, which may include: A21. If the second verification environment detects that the value of the first state parameter is the first value, obtain the simulation data acquisition request from the shared memory.

[0058] The second verification environment can monitor the value of the first state parameter according to preset monitoring measurements. For example, it can monitor the value of the first state parameter continuously or at certain intervals.

[0059] When the second verification environment detects that the value of the first state parameter is the first value, it indicates that the shared memory contains the simulation data acquisition request written by the first verification environment. In this way, the second verification environment can obtain the simulation data acquisition request from the shared memory according to the simulation data acquisition request.

[0060] In this embodiment, by monitoring the value of the first state parameter, the second verification environment can process simulation data acquisition requests in a timely manner, which facilitates the timely synchronization of the first simulation data to the first type of die and improves the continuity of the simulation.

[0061] If the second verification environment can process the simulation data acquisition request in a timely manner and write the first simulation data into the shared memory, in order to improve the continuity of the simulation of the first type of die, it is also necessary to send the first simulation data from the shared memory to the first type of die in a timely manner. Based on this, in some examples, before the first verification environment in step A4 acquires the first simulation data from the shared memory, the first verification environment in step S101b may acquire the first simulation data from the interconnect die according to the simulation data acquisition request, and may further include: A6. The second verification environment sets the value of the first state parameter in the shared memory to the second value.

[0062] The second value indicates that the simulation data is ready.

[0063] The first verification environment obtains the first simulation data (A4) from shared memory, which may include: A41. If the value of the first state parameter is detected as the second value in the first verification environment, the first simulation data is obtained from the shared memory.

[0064] The first verification environment can monitor the value of the first state parameter according to a preset monitoring strategy. For example, it can monitor the value of the first state parameter continuously or at certain intervals.

[0065] When the first verification environment detects that the value of the first state parameter is the second value, it indicates that the shared memory contains the first simulation data corresponding to the simulation data acquisition request. In this way, the first verification environment can retrieve the first simulation data from the shared memory and send it to the first type of die.

[0066] In this embodiment, by monitoring the value of the first state parameter, the first verification environment can promptly send the first simulation data to the first type of die, thereby improving the continuity of the simulation.

[0067] Depending on the progress of the project, the graphics processor chips can be flexibly arranged in the hardware simulation platform and the software simulation platform. In some cases, the number of first-type chips is less than the number of second-type chips; or, the number of first-type chips is greater than or equal to the number of second-type chips.

[0068] like Figure 3 In the embodiment shown, the graphics processor has four core dies and one soc die. In the initial simulation process, one core die can be simulated using an RTL model (core RTL) based on the real RTL, i.e., the first type of die. The other three core dies and the soc die are simulated using software models. The core die corresponds to the core model, i.e. the second type of die, and the soc die corresponds to the soc model, i.e. the interconnect die.

[0069] After the simulation environment stabilizes, and provided that simulation machine resources and runtime allow, the number of RTL models derived from the real RTL can be adjusted, such as... Figure 4In the embodiment shown, three core dies are simulated using RTL models (i.e., type 1 dies) obtained from real RTL, while the other core die and soc die are simulated using software models. The core die corresponds to the core model (i.e., type 2 dies), and the soc die corresponds to the soc model (i.e., interconnect dies). This facilitates a more realistic reflection of the performance of the real chip.

[0070] This embodiment proposes a multi-die graphics processor co-simulation technique. Some core dies are simulated using real RTL, while others are replaced by a core model based on the GEM5 platform. This approach preserves the implementation details of the real chip to the greatest extent possible while simultaneously considering simulation speed and scalability. Since both core RTL and core model are used simultaneously in the environment, inconsistencies between the functionality and performance of a core model and the core RTL of the same core die can be easily identified through analysis of the simulation results, facilitating iterative development of the core model.

[0071] To maximize the balance between the realism of hardware simulation and the speed of software simulation, in some embodiments, hardware models of 50% of the total number of GPU chips are run on the hardware simulation platform, while software models of the remaining 50% of the chips are run on the software simulation platform. In other embodiments, hardware models of 40% of the total number of GPU chips are run on the hardware simulation platform, while software models of the remaining 60% of the chips are run on the software simulation platform.

[0072] Because software models built on software do not consider the implementation of the internal microarchitecture of the die during the modeling process, the simulation of micro-functions and performance is not very accurate, and there are limitations in accurately reflecting all the details and behaviors of the hardware circuit. In order to calibrate the accuracy of the function and performance of the second type of die, in some examples, the method may also include: S103, the hardware simulation platform collects first performance simulation information and second performance simulation information of the first die; wherein, the first performance simulation information is the information corresponding to the first type of die; the second performance simulation information is the information corresponding to the first die belonging to the second type of die.

[0073] Performance simulation information can include information from the entire simulation process, such as the total number of simulation clock cycles, the total number of instructions, the number of pipeline pause cycles and the reasons for pauses, etc.

[0074] The first performance simulation information of the first die in this embodiment is the simulation data obtained in one simulation where the first die is a hardware model implemented based on a hardware description language; the second performance simulation information is the simulation data obtained in another simulation where the first die is a software model built based on software.

[0075] S104. Based on the first performance simulation information and the second performance simulation information, determine whether the functions and performance of the hardware model and the software model of the first die are consistent.

[0076] After collecting the first performance simulation information and the second performance simulation information of the first chip, it can be determined whether the functions and performance of the hardware model and the software model of the first chip are consistent. If they are inconsistent, the software model of the first chip is calibrated.

[0077] For example, comparing and analyzing the first and second performance simulation information can calibrate the accuracy of the function and performance of the second type of grain, and further guide the project's preliminary research on the development and iteration of the second type of grain.

[0078] During the simulation process, test cases are required for simulation. To quickly and concisely write the test cases into the interconnect die, in some examples, the first simulation data is the first test case. Before the first type of die obtains the first simulation data from the interconnect die in step S101, the method may further include: S105 The hardware simulation platform writes preset test cases into the interconnect chip through a backdoor function.

[0079] The interconnect die is a software model built on software. When both the hardware simulation platform and the software simulation platform are started, and the interconnect die is also started on the software simulation platform, the hardware simulation platform writes the preset test cases into the interconnect die through a backdoor function.

[0080] In some examples, after loading the first type of die onto the hardware simulation platform in step S101 and before the first type of die obtains the first simulation data from the interconnect die, the method of this embodiment may further include: S106. Start the hardware simulation platform.

[0081] S107. Configure the initialization information for the first type of grain.

[0082] S108. Based on the initialization information of the first type of die, start the first type of die on the hardware simulation platform.

[0083] It is understandable that the startup process of the software simulation platform and the second type of die is similar to steps S106-S108 above, and will not be repeated here.

[0084] In some examples, the VCS simulation platform is first started; the VCS simulation platform generates the clock and reset signals required for the platform to operate, and reads the test cases and writes them into the soc model of the GEM5 simulation platform through a backdoor function.

[0085] Start the GEM5 simulation platform, which includes a soc model and a core model.

[0086] After completing the initial configuration of core rtl, core model, and soc model, and starting core rtl, core model, and soc model simultaneously, the startup process of the computing task is complete.

[0087] Figure 5 This is a schematic diagram of the structure of a graphics processor performance simulation system provided in an embodiment of this application, as shown below. Figure 5 As shown, the graphics processor performance simulation system of this embodiment may include: a hardware simulation platform 1, a software simulation platform 2, and a graphics processor 3; wherein, the graphics processor 3 includes: a first type of die 31, a second type of die 32, and an interconnect die 33; the first type of die is a hardware model implemented based on a hardware description language, the second type of die is a software model built based on software, and the interconnect die is a hardware model implemented based on a hardware description language or a software model built based on software; wherein, the hardware simulation platform is used to load the first type of die; the first type of die is used to obtain first simulation data from the interconnect die and perform performance simulation on the hardware simulation platform based on the first simulation data; the software simulation platform is used to load the second type of die; the second type of die is used to obtain second simulation data from the interconnect die and perform performance simulation on the software simulation platform based on the second simulation data.

[0088] The simulation system in this embodiment can be used to execute... Figure 1 The technical solutions of the method embodiments shown are similar in principle and in effect, and will not be described again here.

[0089] In this embodiment, the simulation system uses a first type of die 31, implemented using a hardware description language, to obtain first simulation data from interconnect dies 33 and perform performance simulation on a hardware simulation platform 1 based on the first simulation data. Conversely, a second type of die 32, built using software, obtains second simulation data from interconnect dies 33 and performs performance simulation on a software simulation platform 2 based on the second simulation data. The interconnect dies 33 can be either a hardware model implemented using a hardware description language or a software model built using software. Thus, when performing performance simulation on the graphics processor 3, performance simulation is performed on some dies of the graphics processor 3 on the hardware simulation platform 1, and on another part of the dies of the graphics processor 3 on the software simulation platform 2. This process combines the realism of hardware simulation with the speed of software simulation, ensuring the accuracy of performance simulation on multiple dies of the graphics processor to a certain extent while improving the performance simulation speed, thereby shortening the verification cycle.

[0090] The simulation system in this embodiment can provide rapid iterative support for the performance verification of graphics processors.

[0091] As an optional implementation, the first type of die 31 is specifically used to: send a simulation data acquisition request; the hardware simulation platform 1 runs a first verification environment, which is used to acquire first simulation data from the interconnect die 33 according to the simulation data acquisition request, and send the first simulation data to the first type of die 31.

[0092] As an optional implementation, the interconnect die 33 is a software model built based on software and can be loaded onto the software simulation platform 2; wherein, the first verification environment is used to: store the simulation data acquisition request into shared memory; the software simulation platform 2 runs a second verification environment, the second verification environment being used to obtain the simulation data acquisition request from the shared memory, and obtain first simulation data corresponding to the simulation data acquisition request from the interconnect die 33; store the first simulation data into the shared memory; the first verification environment is also used to obtain the first simulation data from the shared memory.

[0093] As an optional implementation, the first verification environment is further configured to: after storing the simulation data acquisition request into shared memory in the first verification environment running on the hardware simulation platform 1, set the value of the first state parameter in the shared memory to a first value; wherein, the first state parameter corresponds to the die hardware model, and the first value indicates that there is a request to be processed; wherein, the second verification environment is further configured to: when the value of the first state parameter is detected to be the first value, retrieve the simulation data acquisition request from the shared memory.

[0094] As an optional implementation, the second verification environment is further configured to set the value of the first state parameter in the shared memory to a second value before the first verification environment obtains the first simulation data from the shared memory; wherein the second value indicates that the simulation data has been prepared; wherein the first verification environment is further configured to: obtain the first simulation data from the shared memory when the value of the first state parameter is detected to be the second value.

[0095] As an optional implementation, the number of the first type of grains 31 is less than the number of the second type of grains 32; or, the number of the first type of grains 31 is greater than or equal to the number of the second type of grains 32.

[0096] As an optional implementation, the hardware simulation platform 1 is further configured to collect first performance simulation information and second performance simulation information of the first die; wherein, the first performance simulation information is the information corresponding to the first type of die 31; the second performance simulation information is the information corresponding to the first die belonging to the second type of die 32; and based on the first performance simulation information and the second performance simulation information, it is determined whether the functions and performance of the hardware model and the software model of the first die are consistent.

[0097] As an optional implementation, the first simulation data is a first test case; the interconnect die 33 is a software model based on software; the hardware simulation platform 1 is also used to write the preset test cases into the interconnect die 33 through a backdoor function before the first type of die 31 obtains the first simulation data from the interconnect die 33.

[0098] The simulation system described in the above embodiments can be used to execute the technical solutions of the above method embodiments. Its implementation principle and technical effects are similar, and will not be repeated here.

[0099] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0100] The various embodiments in this specification are described in a related manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0101] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0102] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for simulating the performance of a graphics processing unit, characterized in that, The graphics processor includes a first type of die, a second type of die, and interconnect dies. The first type of die is a hardware model implemented using a hardware description language, the second type of die is a software model built using software, and the interconnect dies are either a hardware model implemented using a hardware description language or a software model built using software. The method includes: The first type of die is loaded onto the hardware simulation platform. The first type of die obtains first simulation data from the interconnect die and performs performance simulation on the hardware simulation platform based on the first simulation data. The second type of die is loaded into the software simulation platform. The second type of die obtains second simulation data from the interconnect die and performs performance simulation on the software simulation platform based on the second simulation data.

2. The method of claim 1, wherein, The first type of die obtains first simulation data from the interconnect die, including: The first type of die sends a simulation data acquisition request; The first verification environment obtains first simulation data from the interconnect die according to the simulation data acquisition request, and sends the first simulation data to the first type of die; wherein, the first verification environment runs on the hardware simulation platform.

3. The method of claim 2, wherein, The interconnect die is a software model built based on software and is loaded onto the software simulation platform; The first verification environment acquires first simulation data from the interconnect die according to the simulation data acquisition request, including: The first verification environment stores the simulation data acquisition request in shared memory; The second verification environment obtains the simulation data acquisition request from the shared memory and obtains the first simulation data corresponding to the simulation data acquisition request from the interconnect die; wherein, the second verification environment runs on the software simulation platform; The second verification environment stores the first simulation data into the shared memory; The first verification environment obtains the first simulation data from the shared memory.

4. The method of claim 3, wherein, After the first verification environment stores the simulation data acquisition request in shared memory, the first verification environment further includes acquiring the first simulation data from the interconnect die according to the simulation data acquisition request: The first verification environment sets the value of the first state parameter in the shared memory to a first value; wherein, the first state parameter corresponds to the die hardware model, and the first value indicates that there is a request to be processed; The second verification environment retrieves the simulation data acquisition request from the shared memory, including: If the second verification environment detects that the value of the first state parameter is the first value, the simulation data acquisition request is obtained from the shared memory.

5. The method of claim 4, wherein, Before the first verification environment retrieves the first simulation data from the shared memory, the first verification environment further retrieves the first simulation data from the interconnect die according to the simulation data retrieval request, including: The second verification environment sets the value of the first state parameter in the shared memory to a second value; wherein the second value indicates that the simulation data has been prepared. The first verification environment obtains the first simulation data from the shared memory, including: If the first verification environment detects that the value of the first state parameter is the second value, the first simulation data is retrieved from the shared memory.

6. The method of claim 1, wherein, The number of the first type of grains is less than the number of the second type of grains; or, the number of the first type of grains is greater than or equal to the number of the second type of grains.

7. The method of claim 1, wherein, The method further includes: The hardware simulation platform collects first performance simulation information and second performance simulation information of the first die; wherein, the first performance simulation information is the information corresponding to the first type of die; and the second performance simulation information is the information corresponding to the first type of die. Based on the first performance simulation information and the second performance simulation information, determine whether the functions and performance of the hardware model and the software model of the first die are consistent.

8. The method of claim 1, wherein, The first simulation data is the first test case; the interconnect die is a software model built based on software. Before the first type of die obtains the first simulation data from the interconnect die, the method further includes: The hardware simulation platform writes preset test cases into the interconnect die through a backdoor function.

9. The method of claim 1, wherein, After loading the first type of die onto the hardware simulation platform, and before the first type of die obtains the first simulation data from the interconnect die, the method further includes: Start the hardware simulation platform; Configure the initialization information for the first type of grain; Based on the initialization information of the first type of die, the first type of die is started on the hardware simulation platform.

10. A graphics processor performance emulation system, comprising: include: The system includes a hardware simulation platform, a software simulation platform, and a graphics processor; wherein the graphics processor comprises: a first type of die, a second type of die, and interconnect dies; the first type of die is a hardware model implemented based on a hardware description language, the second type of die is a software model built based on software, and the interconnect dies are either a hardware model implemented based on a hardware description language or a software model built based on software. The hardware simulation platform is used to load the first type of die; The first type of die is used to obtain first simulation data from the interconnect die and perform performance simulation on the hardware simulation platform based on the first simulation data; The software simulation platform is used to load the second type of grain; The second type of die is used to obtain second simulation data from the interconnect die and to perform performance simulation on the software simulation platform based on the second simulation data.

11. The simulation system of claim 10, wherein, The first type of grain is specifically used for: sending simulation data acquisition requests; The hardware simulation platform runs a first verification environment, which is used to obtain first simulation data from the interconnect die according to the simulation data acquisition request, and send the first simulation data to the first type of die.

12. The simulation system of claim 11, wherein, The interconnect die is a software model built based on software and can be loaded onto the software simulation platform; The first verification environment is used to: store the simulation data acquisition request into shared memory; The software simulation platform runs a second verification environment, which is used to obtain the simulation data acquisition request from the shared memory, and obtain the first simulation data corresponding to the simulation data acquisition request from the interconnect die; and store the first simulation data into the shared memory. The first verification environment is also used to obtain the first simulation data from the shared memory.

13. The simulation system according to claim 12, characterized in that, The first verification environment is also used for: After storing the simulation data acquisition request into shared memory, the value of the first state parameter in the shared memory is set to a first value; wherein, the first state parameter corresponds to the die hardware model, and the first value indicates that there is a request to be processed; The second verification environment is further configured to: obtain the simulation data acquisition request from the shared memory when the value of the first state parameter is detected to be a first value.

14. The simulation system of claim 13, wherein, The second verification environment is further configured to set the value of the first state parameter in the shared memory to a second value before the first verification environment retrieves the first simulation data from the shared memory; wherein the second value indicates that the simulation data has been prepared. The first verification environment is further configured to: obtain the first simulation data from the shared memory when the value of the first state parameter is detected to be a second value.

15. The simulation system according to claim 10, characterized in that, The hardware simulation platform is further configured to collect first performance simulation information and second performance simulation information of the first die; wherein, the first performance simulation information is the information corresponding to the first type of die; the second performance simulation information is the information corresponding to the first die belonging to the second type of die; and based on the first performance simulation information and the second performance simulation information, it is determined whether the functions and performance of the hardware model and the software model of the first die are consistent.

16. The simulation system according to claim 10, characterized in that, The first simulation data is the first test case; the interconnect die is a software model built based on software. The hardware simulation platform is also used to write preset test cases into the interconnect die through a backdoor function before the first type of die obtains the first simulation data from the interconnect die.

Images