Simulation method, device, computer equipment and medium of GPU architecture
By monitoring the operating metrics of GPU architecture modules and dynamically switching simulation modes, the problem of low simulation efficiency in existing GPU architectures has been solved, achieving high-precision and high-speed simulation results.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- MOXIN ARTIFICIAL INTELLIGENCE TECH (SHENZHEN) CO LTD
- Filing Date
- 2026-03-25
- Publication Date
- 2026-07-14
AI Technical Summary
Existing GPU architecture simulation systems are inefficient in full-module, full-cycle fine simulation mode, which causes a large number of computing units to still consume a lot of simulation resources when idle, resulting in extremely low simulation efficiency.
By monitoring the operational metrics of each functional module of the GPU architecture, hotspot scores are dynamically calculated, and adaptive switching is performed between fine-grained simulation mode and fast-forward simulation mode. For high-activity modules, the internal state machine is updated cycle by cycle, while low-activity modules adopt fast-forward mode, directly deriving the equivalent delay and spanning the simulation time step, skipping meaningless cycle by cycle state updates.
It effectively avoids the waste of computing power caused by idle modules in traditional full-cycle simulation, significantly reduces simulation overhead while maintaining high simulation accuracy, and greatly improves the overall simulation speed.
Smart Images
Figure CN121936381B_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of hardware simulation technology, and in particular to a simulation method for GPU architecture, a simulation device for GPU architecture, a computer device, a computer-readable storage medium, and a computer program product. Background Technology
[0002] With the rapid development of artificial intelligence and high-performance computing, the architecture of graphics processing units (GPUs) is becoming increasingly large and complex. Before GPU chips are tape-out, it is essential to rely on architecture-level simulation systems for performance evaluation and design space exploration. Architecture-level simulation is a crucial step in verifying microarchitecture designs, optimizing hardware-software collaboration, and analyzing performance bottlenecks. Because modern GPUs contain massive numbers of computing units, complex multi-level cache hierarchies, and high-concurrency on-chip interconnect networks, their simulation process involves enormous computational scale and complex state tracking.
[0003] Therefore, there is an urgent need in this field for an efficient GPU architecture simulation solution to meet the increasingly complex GPU design verification requirements. Summary of the Invention
[0004] This disclosure provides a GPU architecture simulation method, a GPU architecture simulation device, a computer device, a computer-readable storage medium, and a computer program product.
[0005] According to one aspect of this disclosure, a simulation method for a GPU architecture is provided, the GPU architecture including multiple functional modules. The simulation method includes: monitoring the operating metrics of each of the multiple functional modules within a preset time window; calculating a hotspot score for each functional module based on its operating metrics, wherein the hotspot score represents the activity level of the functional module within the preset time window; comparing the hotspot score of each functional module with a preset threshold for each functional module, and determining a simulation mode to be used for the functional module based on the comparison result, wherein the simulation mode is one of a fine simulation mode and a fast-forward simulation mode; updating the internal state machine of the functional module cycle by cycle in response to determining that the fine simulation mode is used to simulate the functional module; and deriving the equivalent delay of the functional module based on historical data of the functional module, and skipping the cycle-by-cycle update of the internal state machine of the functional module within the simulation time step based on the equivalent delay across the corresponding simulation time step.
[0006] In some embodiments, the plurality of functional modules include compute-intensive modules and memory-intensive modules, wherein the operational metrics monitored for the compute-intensive modules include at least one of instruction issue rate, number of active thread bundles, and pipeline blocking ratio, and wherein the operational metrics monitored for the memory-intensive modules include at least one of load / store wait request count, missing state holding register utilization, and on-chip network bandwidth utilization.
[0007] In some embodiments, calculating the hotspot score of a functional module based on its operational metrics includes: for the first of the plurality of functional modules... i The first functional module is calculated using the following formula. i HotScore (M) of each functional module i ): ,in, K i Indicates the first i The total number of operational metrics monitored by each functional module, and i and K i All are positive integers. k Not greater than K i positive integers, w i,k For the first i The first functional module k The preset weight coefficients for each operating indicator For the normalized first i The first functional module k Several operational indicators, among which... ,in, x i,k For the first i The first functional module k The original values of each operating indicator x i,k_max For the first k The maximum theoretical threshold corresponding to each operating indicator.
[0008] In some embodiments, the preset threshold includes a first threshold and a second threshold less than the first threshold. The simulation method further includes: at the start of the simulation, setting the initial simulation mode of each functional module to the fine simulation mode, wherein comparing the hotspot score of each functional module with the preset threshold and determining the simulation mode to be used for the functional module based on the comparison result includes: for each functional module, in response to determining that the functional module is currently in the fast-forward simulation mode and that the hotspot score of the functional module is greater than the first threshold for N consecutive preset time windows, switching the simulation mode of the functional module to the fine simulation mode, where N is a positive integer; and in response to determining that the functional module is currently in the fine simulation mode and that the hotspot score of the functional module is less than the second threshold for N consecutive preset time windows, switching the simulation mode of the functional module to the fast-forward simulation mode.
[0009] In some embodiments, responding to determining to simulate the functional module using the fast-forward simulation mode, deriving the equivalent delay of the functional module based on its historical data, and traversing the corresponding simulation time step based on the equivalent delay includes: obtaining the historical operating indicators of the functional module within the previous preset time window; calculating the equivalent delay of the functional module based on the historical operating indicators; using the time span included in the preset time window as the simulation time step corresponding to the functional module to advance the global simulation time; and updating the state variables of the functional module after traversing the simulation time step based on the equivalent delay.
[0010] In some embodiments, the compute-intensive module includes at least one of a scheduler, a launch unit, and a tensor core, and the memory-intensive module includes at least one of a load / store unit, a cache module, an on-chip network, and a dynamic random access memory.
[0011] In some embodiments, calculating the equivalent latency of the functional module based on the historical operating metrics includes: in response to determining that the functional module is the compute-intensive module, extracting pipeline utilization and blocking rate from the historical operating metrics, and calculating the equivalent latency based on the pipeline utilization and the blocking rate; in response to determining that the functional module is a cache module in the memory-intensive module, extracting cache hit rate and cache miss rate from the historical operating metrics, and calculating the equivalent latency using the following formula. AvgLatency : AvgLatency = HitRate L hit + MissRate L miss ,in, HitRate The cache hit rate is... MissRate The cache miss rate is... L hit This is due to the inherent hit latency of this caching module. L miss The cache module inherently has a miss latency; in response to determining that the functional module is an on-chip network or dynamic random access memory in the memory-intensive module, the request arrival rate and request service rate are extracted from the historical operating metrics, and the equivalent latency is calculated using the following formula. Latency : Latency = 1 / (μ-λ), in, λ The request arrival rate is used to represent the number of requests entering this functional module per unit period. μ The request service rate is used to represent the number of requests that this functional module can complete per unit period.
[0012] According to one aspect of this disclosure, a simulation device for a GPU architecture is provided, wherein the GPU architecture includes multiple functional modules. The simulation device includes: a monitoring module configured to monitor the operating metrics of each of the multiple functional modules within a preset time window; a calculation module configured to calculate a hotspot score for each functional module based on its operating metrics, wherein the hotspot score represents the activity level of the functional module within the preset time window; and a determination module configured to compare the hotspot score of each functional module with a preset threshold, and based on the... The comparison results determine the simulation mode to be used for the functional module, wherein the simulation mode is one of a fine simulation mode and a fast-forward simulation mode; an update module is configured to update the internal state machine of the functional module cycle by cycle in response to determining that the fine simulation mode is used to simulate the functional module; and a derivation module is configured to derive the equivalent delay of the functional module based on the historical data of the functional module in response to determining that the fast-forward simulation mode is used to simulate the functional module, and skip the cycle-by-cycle update of the internal state machine of the functional module within the simulation time step by crossing the corresponding simulation time step based on the equivalent delay.
[0013] According to another aspect of this disclosure, a computer device is provided, comprising: at least one processor; and a memory having a computer program stored thereon, wherein the computer program, when executed by the at least one processor, causes the at least one processor to perform the methods provided above in this disclosure.
[0014] According to another aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, causes the processor to perform the methods provided above in this disclosure.
[0015] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, causes the processor to perform the methods provided above in this disclosure.
[0016] According to one or more embodiments of this disclosure, a simulation method for a GPU architecture is provided. This method monitors the operational metrics of each functional module of the GPU architecture, dynamically calculates hotspot scores reflecting their activity levels, and adaptively switches between a fine-grained simulation mode and a fast-forward simulation mode. For highly active modules, the internal state machine is updated cycle-by-cycle to ensure simulation accuracy; for low-activity modules, a fast-forward mode is used, directly deriving the equivalent delay and skipping the corresponding simulation time step, thus avoiding meaningless cycle-by-cycle state updates. By performing fine-grained simulation only on hotspot modules during operation, and using fast-forward modeling for the remaining modules, the wasted computing power caused by idle modules in traditional full-cycle simulation can be effectively avoided. This significantly reduces simulation overhead while maintaining high simulation accuracy, greatly improving the overall simulation speed.
[0017] These and other aspects of this disclosure will be apparent from the embodiments described below, and will be elucidated with reference to the embodiments described below. Attached Figure Description
[0018] The accompanying drawings exemplify embodiments and form part of the specification, serving together with the textual description to explain exemplary implementations of the embodiments. The illustrated embodiments are for illustrative purposes only and do not limit the scope of this disclosure. Throughout the drawings, the same reference numerals refer to similar but not necessarily identical elements.
[0019] Figure 1 This is a flowchart illustrating a simulation method for a GPU architecture according to an exemplary embodiment.
[0020] Figure 2 This is a flowchart illustrating a portion of the process of a simulation method for a GPU architecture according to an exemplary embodiment.
[0021] Figure 3 This is a schematic block diagram illustrating a simulation apparatus for a GPU architecture according to an exemplary embodiment.
[0022] Figure 4 This is a block diagram illustrating an exemplary computer device that can be applied to an exemplary embodiment. Detailed Implementation
[0023] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.
[0024] In this disclosure, unless otherwise stated, the use of terms such as "first," "second," etc., to describe various elements is not intended to limit the positional, temporal, or importance relationships of these elements; such terms are merely used to distinguish one element from another. In some examples, the first element and the second element may refer to the same instance of that element, while in other cases, based on the context, they may refer to different instances.
[0025] The terminology used in the description of the various examples described in this disclosure is for the purpose of describing particular examples only and is not intended to be limiting. Unless the context explicitly indicates otherwise, an element may be one or more unless the number of elements is specifically limited. As used herein, the term "multiple" means two or more, and the term "based on" should be interpreted as "at least partially based on". Furthermore, the terms "and / or" and "at least one of..." cover any one of the listed items and all possible combinations thereof.
[0026] Existing GPU architecture simulation systems typically employ a detailed simulation approach covering all modules and the entire lifecycle. Even if a large number of computing units, caches, or interconnect structures are idle for most cycles, a significant amount of simulation resources are still required to advance the simulation cycle by cycle, resulting in extremely low simulation efficiency.
[0027] To address the aforementioned issues, this paper proposes a simulation method for GPU architecture. By monitoring the operational metrics of each functional module of the GPU architecture, a hotspot score reflecting its activity level is dynamically calculated, and adaptive switching is performed between a fine-grained simulation mode and a fast-forward simulation mode. For highly active modules, the internal state machine is updated cycle-by-cycle to ensure simulation accuracy; for low-activity modules, a fast-forward mode is used, directly deriving the equivalent delay and skipping the corresponding simulation time step, thus avoiding meaningless cycle-by-cycle state updates. By performing fine-grained simulation only on hotspot modules during operation, and using fast-forward modeling for the remaining modules, the computational waste caused by idle modules in traditional full-cycle simulation can be effectively avoided. This significantly reduces simulation overhead while maintaining high simulation accuracy, greatly improving the overall simulation speed.
[0028] Exemplary embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.
[0029] Figure 1This is a flowchart illustrating a simulation method for a GPU architecture according to an exemplary embodiment, the GPU architecture including multiple functional modules.
[0030] like Figure 1 As shown, the simulation method 100 for GPU architecture includes:
[0031] Step S101: Within a preset time window, monitor the operating indicators of each of the multiple functional modules.
[0032] Step S102: Calculate the hotspot score of each functional module based on its operating metrics, wherein the hotspot score represents the activity level of the functional module within the preset time window;
[0033] Step S103: For each of the multiple functional modules, compare the hot spot score of the functional module with the size of the preset threshold, and determine the simulation mode to be used for the functional module based on the comparison result, wherein the simulation mode is one of fine simulation mode and fast forward simulation mode.
[0034] Step S104: In response to determining that the fine simulation mode is used to simulate the functional module, update the internal state machine of the functional module cycle by cycle; and
[0035] Step S105: In response to determining that the fast-forward simulation mode is used to simulate the functional module, the equivalent delay of the functional module is derived based on the historical data of the functional module, and the equivalent delay is used to skip the cycle-by-cycle update of the internal state machine of the functional module within the simulation time step.
[0036] Step S101 involves real-time acquisition of operational metrics for various functional modules within the GPU architecture within a specific preset time window, i.e., a set of a certain number of clock cycles. It is understood that the specific metrics monitored can be determined based on the module attributes. Monitoring within the time window enables the simulation system to capture the transient behavior changes of various hardware components in the GPU under real workloads, providing accurate and objective real-time data support for subsequent dynamic adjustments to simulation accuracy.
[0037] For each collected operational metric, step S102 uses the corresponding operational metric to derive a hotspot score for that functional module. This score directly quantifies the actual busy status of the functional module within the recently passed preset time window. This step maps multi-dimensional, physically different underlying hardware metrics into a unified hotspot score, achieving a standardized measurement of the activity of heterogeneous functional modules. This allows for a unified assessment of the system impact of different modules within the entire GPU architecture.
[0038] In step S103, the hotspot score calculated in real time is compared with a preset threshold to determine whether the current functional module is a critical hotspot affecting system performance. Finally, the system adaptively switches between fine simulation mode and fast-forward simulation mode. This endows the simulation method with dynamic adaptive adjustment capability.
[0039] When the mode decision result indicates that the functional module is currently in a highly active state, i.e., when the fine simulation mode is determined, step S104 retains the full-cycle simulation characteristic for that functional module, strictly proceeding according to the step size of each clock cycle, and updating the state machine of the internal registers and control logic of that functional module. Thus, for hotspot modules that truly affect system behavior during operation and are on the critical path, a high degree of fidelity is maintained, completely consistent with their microarchitecture hardware design, ensuring the absolute accuracy of the results of architecture exploration, bottleneck analysis, and performance evaluation.
[0040] Accordingly, when the decision result indicates that a functional module is in an idle or low-activity state, i.e., when switching to fast-forward simulation mode, step S104 no longer advances the simulation cycle by cycle for that functional module. Instead, it directly derives its equivalent delay based on the module's historical operating metrics. Subsequently, the simulation global clock directly skips the corresponding simulation time step using this equivalent delay, completely omitting all cycle-by-cycle state update actions of the low-activity module during this period. This successfully eliminates a large number of meaningless cycle-by-cycle state polls for idle or low-activity modules, fundamentally overcoming the core problem of severe computational waste in existing full-cycle fine simulations. While ensuring statistical accuracy, it achieves an order-of-magnitude improvement in simulation speed.
[0041] As can be seen, Method 100 provides a closed-loop control mechanism for GPU architecture simulation acceleration based on dynamic hotspot tracking. This method overcomes the technical bottleneck of traditional simulation systems, which struggle to balance high precision and high speed. Through a dynamic adaptive process of monitoring operational metrics, quantitatively evaluating hotspots, making threshold-based decisions, and determining simulation modes, it achieves intelligent allocation of simulation computing resources. This prioritizes core computing power for hotspot modules in precise simulations, while allowing for larger jumps in idle or low-load modules. Thus, it can effectively adapt to dynamically changing runtime workloads while significantly avoiding wasted computing power, and substantially improving overall simulation speed while maintaining high simulation accuracy.
[0042] To achieve the aforementioned balance between high precision and high speed, and to accurately capture transient changes in the GPU microarchitecture during runtime, the time granularity design of monitoring and thermal evaluation is particularly crucial. In actual simulations, excessively high sampling frequencies introduce unnecessary control overhead and may even negate the speedup gains from mode switching; conversely, excessively low sampling frequencies lead to sluggish responses to load changes, resulting in a loss of simulation accuracy. Therefore, embodiments of this disclosure provide a scientific time window division and periodic update mechanism.
[0043] According to some embodiments, the preset time window includes a preset number of clock cycles, and the hotspot score is updated every E clock cycles. Here, the periodic monitoring of metrics and the periodic calculation of scores give the simulation system a discrete yet continuous observation capability. On the one hand, setting the monitoring granularity to a window containing multiple cycles directly avoids the huge computational redundancy caused by calculating scores for each single clock cycle, ensuring that the hotspot tracking mechanism itself is extremely lightweight; on the other hand, the fixed update cycle ensures timely response to sudden or phased changes in workload, enabling the adaptive switching of simulation modes to keep pace with the actual execution rhythm of the GPU instruction or data flow.
[0044] Furthermore, the specific value of parameter E can be flexibly configured according to the scale and focus of the actual simulation task. For example, for architecture exploration scenarios, since extremely fine-grained micro-architectural behavior analysis is typically required (e.g., testing new pipeline scheduling strategies or cache replacement algorithms), the preferred value range for E is 512 to 2048 clock cycles. Within this smaller time window, minute state changes such as cache jitter and partial pipeline congestion can be captured more sensitively, thus providing high-resolution performance verification data for architecture design. For ultra-large-scale GPU simulation scenarios (e.g., running a complete large neural network model or graphics rendering pipeline), since the global simulation cycle is extremely long and the focus is on macroscopic throughput, the preferred value range for E is set to 2048 to 8192 clock cycles. By appropriately increasing the monitoring window and update cycle, the intervention frequency of the state evaluation module can be further reduced, thereby maximizing the acceleration potential of the simulation system without affecting statistical accuracy.
[0045] To make the hotspot assessment in Method 100 more accurate and targeted, the extremely complex heterogeneous characteristics within the GPU microarchitecture must be taken into account. It is understood that a GPU is not a single computing engine, but rather composed of numerous hardware units with vastly different functions; using a single metric to measure the activity of all modules is clearly unscientific. Therefore, embodiments of this disclosure further propose a technical solution for classifying and monitoring functional modules.
[0046] According to some embodiments, the plurality of functional modules include a compute-intensive module and a memory-intensive module, wherein the operational metrics monitored for the compute-intensive module include at least one of instruction issue rate, number of active thread bundles, and pipeline blocking ratio, and wherein the operational metrics monitored for the memory-intensive module include at least one of load / store wait request count, missing state holding register occupancy rate, and on-chip network bandwidth utilization.
[0047] The core task of compute-intensive modules is to handle mathematical operations and logical control. Therefore, the instruction issue rate or the number of active warp threads can most directly reflect the actual degree of computational power utilization, while the pipeline blocking ratio can accurately reveal whether it is stalled due to waiting for operands. Correspondingly, the responsibility of memory-intensive modules is data movement and buffering, and their performance bottlenecks are often bandwidth and concurrent request processing capabilities. Therefore, using the number of load / store wait requests, the missing state holding register occupancy rate (reflecting concurrent missing state processing capability), and on-chip network bandwidth utilization to measure their activity is more accurate. Through independent monitoring of the above-mentioned subdivided indicators, Method 100 can more realistically and comprehensively depict the actual operating characteristics of different types of modules within a specific preset time window, thus laying a high-quality data foundation for accurately determining whether a module belongs to a hotspot.
[0048] Based on the above-described classification and monitoring architecture, in order to closely integrate this abstract module classification with the actual GPU microarchitecture design, the embodiments of this disclosure further clarify the specific physical / logical units covered by each type of module.
[0049] According to some embodiments, the computationally intensive module includes at least one of a scheduler, a launch unit, and a tensor core, and the memory-intensive module includes at least one of a load / store unit, a cache module, a network-on-chip (NoC), and a dynamic random access memory.
[0050] For example, the tensor core, as the main force of AI computing, exhibits extremely high activity when running specific workloads such as matrix multiplication. Tracking and simulating it as an independent computationally intensive hotspot ensures the absolute accuracy of microarchitecture computing power assessment. In contrast, the activity of modules like cache and dynamic random access memory (DRAM) is often constrained by spatial or temporal locality, easily falling into long periods of idleness or low-frequency access during specific computational phases. Clearly defining these specific modules allows Method 100 to target these specific areas prone to wasted computing power with fast-forward simulation modes. Matching highly heterogeneous underlying microarchitecture units to their corresponding modules ensures both detailed simulation of critical data paths and maximizes fast-forward acceleration of non-critical paths.
[0051] Having clearly defined the aforementioned highly heterogeneous underlying microarchitectural units, a unified quantitative evaluation model must be established to accurately and objectively assess the actual activity level of these functionally diverse modules during runtime. Since the operational metrics monitored by different modules (such as instruction issue rate and cache miss rate) differ significantly in physical meaning, data volume, and dimensions, they cannot be directly compared or accumulated. Therefore, embodiments of this disclosure further provide a specific calculation scheme for step S102 to achieve standardized fusion processing of multi-dimensional monitoring data.
[0052] According to some embodiments, step S102 includes: targeting the first of the plurality of functional modules i The first functional module is calculated using the following formula. i HotScore (M) of each functional module i ): ,in, K i Indicates the first i The total number of operational metrics monitored by each functional module, and i and K i All are positive integers. k Not greater than K i positive integers, w i,k For the first i The first functional module k The preset weight coefficients for each operating indicator For the normalized first i The first functional module k Several operational indicators, among which... ,in, x i,k For the first i The first functional module k The original values of each operating indicator x i,k_max For the first k The maximum theoretical threshold corresponding to each operating indicator.
[0053] The computational model, including the above formula, mainly incorporates two core mechanisms: normalization truncation and weighted summation. First, in the normalization truncation stage, the formula... The collected absolute physical quantities (i.e., original values) x i,k Divide by the module's theoretical peak value in the architectural design (i.e., the maximum theoretical threshold). x i,k_maxThis transforms indicators of arbitrary dimensions into relative utilization rates or percentages between 0 and 1. Simultaneously, the min(1,...) function is introduced as a truncation protection mechanism to ensure that even in certain extreme transient conditions, such as when instantaneous indicators slightly exceed theoretical peak values due to measurement artifacts or special bus contention, the normalized values will not exceed the limits, guaranteeing the convergence of subsequent calculations.
[0054] Secondly, in the weighted summation stage, the formula introduces preset weight coefficients. w i,k Because the same functional module may monitor multiple metrics simultaneously (i.e. K i There are several metrics, and these metrics contribute differently to measuring the overall activity of the module. For example, for the compute module, the instruction issue rate may have a higher weight than the pipeline blockage rate. By assigning differentiated weights to different metrics and multiplying them by normalized values and summing them, a single scalar value is finally obtained, namely the HotScore (M). i ).
[0055] The aforementioned computational model effectively eliminates the dimensional barriers of heterogeneous data. Specifically, it maps the complex, multidimensional, and physically diverse underlying hardware operating states of the GPU into a standardized scalar value, enabling the entire simulation method to macroscopically measure and compare the system impact of each heterogeneous module on a uniform scale. Furthermore, it endows the method with extremely high configurability and adaptability. (Weighting coefficients) w i,k The introduction of this method provides a flexible control approach for the simulation verification process. Under different test cases, the weight matrix can be fine-tuned to guide the method to focus more on certain specific performance bottlenecks, such as increasing the weight of bandwidth utilization when analyzing memory access bottlenecks. This allows the above calculation model to perfectly adapt to the verification needs of various microarchitecture designs. Furthermore, the above calculation method also improves the robustness of simulation decisions. The truncation protection mechanism effectively prevents abnormal spikes in a single indicator from interfering with the overall score, avoids misjudgments of simulation modes due to data overflow, and ensures the stable operation of the closed-loop control mechanism.
[0056] After calculating the standardized hotspot score, the next crucial step is to utilize this score to make reasonable simulation mode switching decisions. In scenarios relying solely on a single threshold for hard segmentation, when the workload of a functional module experiences small, transient fluctuations at the threshold edge, the simulation system will frequently switch between fine-grained and fast-forward simulation modes. This frequent mode switching can introduce additional control overhead. Therefore, embodiments of this disclosure introduce a hysteresis mechanism based on dual thresholds to avoid frequent switching.
[0057] According to some embodiments, the preset threshold includes a first threshold and a second threshold that is less than the first threshold, and wherein the simulation method further includes: at the start of the simulation, setting the initial simulation mode of each functional module to the fine simulation mode, wherein step S103 includes: for each of the plurality of functional modules, in response to determining that the functional module is currently in the fast-forward simulation mode and that the hotspot score of the functional module is greater than the first threshold for N consecutive preset time windows, switching the simulation mode of the functional module to the fine simulation mode, wherein N is a positive integer; and in response to determining that the functional module is currently in the fine simulation mode and that the hotspot score of the functional module is less than the second threshold for N consecutive preset time windows, switching the simulation mode of the functional module to the fast-forward simulation mode.
[0058] The above embodiments describe in detail the finite state machine logic for switching functional modules between two simulation modes. First, in the initial stage of starting (or resetting) the simulation, the initial state of all functional modules is forcibly anchored to the fine simulation mode by default. A first threshold is preset as a high wake-up threshold for confirming entry into fine mode, and a second threshold is preset as a low sleep threshold for confirming entry into fast-forward mode. These two thresholds, one high and one low, determine how and whether to switch the simulation mode of the functional module.
[0059] In actual operation, mode switching is not immediate once a threshold is exceeded. Instead, it must simultaneously meet conditions in two dimensions: magnitude (exceeding or falling below the threshold) and time (maintaining for several cycles). Specifically, when an idle functional module in fast-forward simulation mode suddenly receives a task, its hotspot score must break through the higher first threshold N times consecutively before it is awakened to fine-grained simulation mode. Conversely, when a busy functional module in fine-grained simulation mode gradually becomes idle, its hotspot score must fall below the lower second threshold N times consecutively before it is allowed to hibernate to fast-forward simulation mode.
[0060] By adopting the aforementioned dual-threshold hysteresis mechanism, the "ping-pong effect" can be effectively eliminated, reducing control overhead. Specifically, by introducing hysteresis intervals with high and low thresholds, minor fluctuations in runtime workload are effectively filtered out. Mode switching is only triggered when the activity of a module undergoes a real and significant trend change, avoiding meaningless frequent switching near the critical point and ensuring the smooth operation of the simulation architecture. Furthermore, the dual-threshold hysteresis mechanism acts as a low-pass filter, enhancing fault tolerance. The time constraint of N consecutive preset time windows is equivalent to introducing a low-pass filter mechanism in the time dimension. It can shield extremely short-term abnormal bursts of traffic or statistical noise, ensuring that simulation mode switching is based on the steady-state behavior of the module rather than transient spikes. The dual-threshold hysteresis mechanism also guarantees absolute accuracy during the cold start phase. By default using a fine simulation mode at the start of the simulation, it ensures that no critical microarchitectural behavioral details are missed during the most complex cold start phase, when the workload has just been received, various caches have not yet warmed up, and the state is most complex, thus upholding the bottom line of high-precision simulation.
[0061] Once a functional module has exited its high-activity state and entered fast-forward simulation mode through the aforementioned hysteresis mechanism and dual-threshold judgment logic, another core technical challenge this disclosure aims to address is how to maintain the macroscopic accuracy of the simulation results without advancing the internal state machine cycle by cycle. Simply skipping clock cycles without compensating for the module's state would result in severe timing and state disconnects in the entire GPU system. To solve this problem, embodiments of this disclosure detail the specific execution mechanism of the fast-forward simulation mode.
[0062] Figure 2 This is a flowchart illustrating a portion of the process of a simulation method for a GPU architecture according to an exemplary embodiment.
[0063] like Figure 2 As shown, step S105 includes:
[0064] Step S201: Obtain the historical operating indicators of this functional module within the previous preset time window;
[0065] Step S202: Based on the historical operating indicators, calculate the equivalent delay of the functional module;
[0066] Step S203: Use the time span included in the preset time window as the simulation time step corresponding to the functional module, in order to advance the global simulation time; and
[0067] Step S204: Based on the equivalent delay, update the state variables of the functional module after crossing the simulation time step.
[0068] Steps S201-S204 establish the standard operating procedure for the fast-forward simulation mode. Utilizing the principle of temporal locality during hardware program execution, that is, a functional module in a low-activity or steady state is likely to maintain similar statistical characteristics to the previous time window in the future. Therefore, step S201 first extracts the historical running data of the module's last preset time window. Subsequently, step S202 does not perform micro-level state machine deduction, but directly converts this historical data into a macro-level equivalent delay. After obtaining the equivalent delay, step S203 causes the simulation system's global clock to directly span the entire preset time window, i.e., advance by E clock cycles as mentioned above, and superimposes the equivalent delay onto the module's state variables or pending transactions.
[0069] This completely avoids cycle-by-cycle polling and updating of the complex register transfer level (RTL) or microarchitectural state within inactive modules, enabling simulation time to be skipped. This not only frees up massive computing resources but also ensures, through an equivalent delay compensation mechanism, that the throughput and latency response of the modules during the skipped time period still conform to physical laws, achieving acceleration without distortion.
[0070] According to some embodiments, step S202 includes: in response to determining that the functional module is the compute-intensive module, extracting pipeline utilization and blocking rate from the historical operating metrics, and calculating the equivalent latency based on the pipeline utilization and the blocking rate; in response to determining that the functional module is the cache module in the memory-intensive module, extracting cache hit rate and cache miss rate from the historical operating metrics, and calculating the equivalent latency using the following formula. AvgLatency :
[0071] AvgLatency = HitRate L hit + MissRate L miss， ,in, HitRate The cache hit rate is... MissRate The cache miss rate is... L hit This is due to the inherent hit latency of this caching module. L miss The cache module inherently has a miss latency; in response to determining that the functional module is an on-chip network or dynamic random access memory in the memory-intensive module, the request arrival rate and request service rate are extracted from the historical operating metrics, and the equivalent latency is calculated using the following formula. Latency : Latency = 1 / (μ-λ), in, λThe request arrival rate is used to represent the number of requests entering this functional module per unit period. μ The request service rate is used to represent the number of requests that this functional module can complete per unit period.
[0072] It can be seen that step S202 includes three parallel statistical derivation logics. The first is for computationally intensive modules. In this scenario, since the computing unit itself is under low load (e.g., only a few tail instructions are in the pipeline), the average number of cycles required to clear these tail instructions can be directly evaluated through historical utilization and blocking rates, and used as the equivalent latency.
[0073] The second approach targets the caching module. In this model, the micro-level cache lookup process is macroscopically transformed into a probabilistic expected value. Since the module is in a low-activity state, its access patterns typically exhibit stable statistical regularities. By directly applying the expected value formula driven by historical hit / miss rate, the average memory access overhead during that period can be simulated with remarkable accuracy.
[0074] The third approach targets the network and memory controller modules. The formula employed is an innovative application of classical queuing theory (such as the M / M / 1 model) in GPU hardware simulation. Routing congestion in the on-chip network (NoC) and queuing waiting in the dynamic random access memory (DRAM) controller are essentially queuing service processes. When traffic is low or in a steady state, the average response time of the queue is directly calculated using the arrival rate and service rate, perfectly replacing traditional Flit-level route tracing or DDR timing command-level simulation.
[0075] For the three core areas of GPUs—computation, caching, and networking / memory—the above embodiments provide rigorous solutions for deriving equivalent latency. This statistical dimensionality reduction approach, based on queuing theory and probabilistic expectation, transforms fast-forward mode from a crude direct sleep or fixed latency approach into a prediction based on statistical models. While maximizing the simulation computing power of idle modules, it firmly maintains the latency and bandwidth accuracy requirements for system-level performance evaluation, achieving a perfect blend of high precision and high speed.
[0076] Embodiments of this disclosure also provide a simulation apparatus for a GPU architecture, wherein the GPU architecture includes multiple functional modules.
[0077] like Figure 3As shown, the GPU architecture simulation device 300 includes: a monitoring module 301 configured to monitor the operating metrics of each of the plurality of functional modules within a preset time window; a calculation module 302 configured to calculate a hotspot score for each functional module based on its operating metrics, wherein the hotspot score represents the activity level of the functional module within the preset time window; and a determination module 303 configured to compare the hotspot score of each functional module with a preset threshold, and determine the appropriate application for that functional module based on the comparison result. The simulation mode is one of a fine simulation mode and a fast-forward simulation mode; the update module 304 is configured to update the internal state machine of the functional module cycle by cycle in response to determining that the fine simulation mode is used to simulate the functional module; and the derivation module 305 is configured to derive the equivalent delay of the functional module based on the historical data of the functional module in response to determining that the fast-forward simulation mode is used to simulate the functional module, and skip the cycle-by-cycle update of the internal state machine of the functional module within the simulation time step based on the equivalent delay.
[0078] The monitoring module 301 collects real-time operational metrics of various functional modules within the GPU architecture within a specific preset time window, which includes a certain number of clock cycles. Understandably, the specific metrics monitored can be determined based on the module's attributes. Monitoring within the time window enables the simulation system to capture the transient behavior changes of various hardware components in the GPU under real workloads, providing accurate and objective real-time data support for subsequent dynamic adjustments to simulation accuracy.
[0079] For each collected operational metric, the calculation module 302 uses the corresponding operational metric to derive a hotspot score for that functional module. This score directly quantifies the actual busy status of the functional module within the recently passed preset time window. This step maps multi-dimensional, physically different underlying hardware metrics into a unified hotspot score, achieving a standardized measurement of the activity of heterogeneous functional modules. This allows for a unified assessment of the system impact of different modules within the entire GPU architecture.
[0080] The determination module 303 compares the hotspot score calculated in real time with a preset threshold to determine whether the current functional module belongs to a critical hotspot affecting system performance, and finally adaptively makes a switching decision between fine simulation mode and fast-forward simulation mode. This endows the simulation device with dynamic adaptive adjustment capabilities.
[0081] When the mode decision indicates that a functional module is currently in a highly active state, i.e., when a fine-grained simulation mode is determined, the update module 304 retains the full-cycle simulation characteristics for that functional module, strictly advancing according to the step size of each clock cycle, and updating the state machine of the internal registers and control logic of that functional module. Thus, for hotspot modules that truly affect system behavior during operation and are on the critical path, a high degree of fidelity is maintained, completely consistent with their microarchitecture hardware design, ensuring the absolute accuracy of architecture exploration, bottleneck analysis, and performance evaluation results.
[0082] Accordingly, when the decision result indicates that a functional module is in an idle or low-activity state, i.e., when fast-forward simulation mode is entered, the simulation no longer proceeds cycle by cycle for that functional module. Instead, the derivation module 305 directly derives its equivalent delay based on the module's historical operating metrics. Subsequently, the simulation global clock directly skips the corresponding simulation time step using this equivalent delay, completely bypassing all cycle-by-cycle state update actions of the low-activity module during this period. This successfully eliminates a large number of meaningless cycle-by-cycle state polls for idle or low-activity modules, fundamentally overcoming the core problem of severe computational waste in existing full-cycle fine simulations, and achieving an order-of-magnitude improvement in simulation speed while ensuring statistical accuracy.
[0083] As can be seen, the GPU-based simulation device 300 provides a closed-loop control mechanism for GPU architecture simulation acceleration based on dynamic hotspot tracking, breaking through the technical bottleneck of traditional simulation systems that struggle to balance high precision and high speed. Through a dynamic adaptive process of monitoring operational metrics, quantitatively evaluating hotspots, making threshold-based decisions, and determining simulation modes, it achieves intelligent allocation of simulation computing resources. This prioritizes core computing power for hotspot modules in precise simulations, while allowing for larger jumps in idle or low-load modules. Thus, it can fully adapt to dynamically changing runtime workloads while significantly avoiding wasted computing power, and substantially improving overall simulation speed while maintaining high simulation accuracy.
[0084] It is understood that the various modules of the GPU architecture simulation device 300 can be configured to execute the various method steps defined in method 100 to achieve the simulation of the GPU architecture, which the applicant will not elaborate on here.
[0085] According to one aspect of this disclosure, a computer device is also provided, including a memory, a processor, and a computer program stored in the memory. The processor is configured to execute the computer program to implement the steps of any of the method embodiments described above.
[0086] According to one aspect of this disclosure, a non-transitory computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the steps of any of the method embodiments described above.
[0087] According to one aspect of this disclosure, a computer program product is also provided, which includes a computer program that, when executed by a processor, implements the steps of any of the method embodiments described above.
[0088] In the following text, combined with Figure 4 Illustrative examples describing such computer devices, non-transitory computer-readable storage media, and computer program products.
[0089] Figure 4 An example computer device 400 is shown in which any of the embodiments described herein may be implemented. Computer device 400 may be used to implement one or more components of the systems and methods described above. Computer device 400 may include a bus 402 or other communication mechanism for communicating information, and one or more processors 404 coupled to the bus 402 for processing information. Processor 404 may be, for example, one or more general-purpose microprocessors.
[0090] Computer device 400 may also include main memory 406, such as random access memory (RAM), cache, and / or other dynamic storage devices, coupled to bus 402, for storing information and instructions to be executed by processor 404. Main memory 406 may also be used to store temporary variables or other intermediate information during the execution of instructions to be executed by processor 404. Such instructions, when stored in a storage medium accessible to processor 404, can make computer device 400 a special-purpose machine customized to perform the operations specified in the instructions. Main memory 406 may include non-volatile media and / or volatile media. Non-volatile media may include, for example, optical discs or magnetic disks. Volatile media may include dynamic memory. Common media formats may include, for example, floppy disks, collapsible disks, hard disks, solid-state drives, magnetic tapes or any other magnetic data storage media, CD-ROMs (read-only optical disc drives), any other optical data storage media, any physical media with a perforated arrangement, RAM (random access memory), DRAM (dynamic random access memory), PROM (programmable read-only memory) and EPROM (erasable programmable read-only memory), FLASH-EPROM (fast erase programmable read-only memory), NVRAM (non-volatile random access memory), any other memory chips or tape cartridges, or network versions of the above.
[0091] Computer device 400 may implement the techniques described herein using custom hardwired logic, one or more ASICs (Application-Specific Integrated Circuits) or FPGAs (Field-Programmable Gate Arrays), firmware, and / or program logic, which, when combined with computer device 400, enable computer device 400 to become a special-purpose machine or to be programmed therein. According to one embodiment, the techniques described herein are executed by computer device 400 in response to processor 404 executing one or more sequences of one or more instructions contained in main memory 406. Such instructions may be read into main memory 406 from another storage medium, such as storage device 408. Executing the sequence of instructions contained in main memory 406 causes processor 404 to perform the processing steps described herein. For example, the processes / methods disclosed herein may be implemented by computer program instructions stored in main memory 406. When these instructions are executed by processor 404, they may perform the steps shown in the corresponding figures and as described above. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions.
[0092] Computer device 400 also includes a network interface 410 coupled to bus 402. Network interface 410 can provide bidirectional data communication coupled to one or more network links connected to one or more networks. As another example, network interface 410 can be a local area network (LAN) card to provide data communication connectivity with a compatible LAN (or a WAN component communicating with a WAN (wide area network)). Wireless links can also be implemented.
[0093] The performance of certain operations can be distributed across processors, not just residing within a single machine, but deployed across many machines. In some exemplary embodiments, the processor or the processor-implemented engine may reside in a single geographic location (e.g., in a home environment, office environment, or server farm). In other exemplary embodiments, the processor or the processor-implemented engine may be distributed across many geographic locations.
[0094] Each process, method, and algorithm described in the preceding sections can be embodied in a code module executed by one or more computer systems or computer processors including computer hardware, and can be fully or partially automated by them. These processes and algorithms can be implemented, in part or in whole, in a specific application circuit.
[0095] When the functions disclosed herein are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Specific technical solutions (all or part) disclosed herein, or aspects contributing to the prior art, can be embodied in the form of a software product. This software product can be stored in a storage medium and includes instructions to cause a computer device (which may be a personal computer, server, network device, etc.) to perform all or part of the steps of the methods described in the embodiments of this application. The storage medium may include a flash drive, a portable hard drive, ROM, RAM, a magnetic disk, an optical disk, another medium suitable for storing program code, or any combination thereof.
[0096] The embodiments disclosed herein can be implemented via a cloud platform, server, or group of servers that interact with a client. The client can be a terminal device or a client registered by a user on the platform, wherein the terminal device can be a mobile terminal, a personal computer (PC), or any device that can install platform applications.
[0097] The various features and processes described above can be used independently or combined in various ways. All possible combinations and sub-combinations are intended to fall within the scope of this disclosure. Furthermore, certain method or process blocks may be omitted in some embodiments. The methods and processes described herein are not limited to any particular order, and associated blocks or states may be executed in other suitable orders. For example, described blocks or states may be executed in a non-specifically disclosed order, or multiple blocks or states may be combined in a single block or state. Exemplary blocks or states may be executed serially, in parallel, or otherwise. Blocks or states may be added to or removed from the disclosed exemplary embodiments. The exemplary systems and components described herein may be configured differently from those described. For example, elements may be added, removed, or rearranged compared to the disclosed exemplary embodiments.
[0098] The various operations of the exemplary methods described herein can be performed at least in part by an algorithm. An algorithm may consist of program code or instructions stored in memory (such as the non-transitory computer-readable storage medium described above). Such an algorithm may include a machine learning algorithm. In some embodiments, the machine learning algorithm may not be explicitly programmed into the computer to perform the function, but may learn from training data to obtain a predictive model for performing that function.
[0099] The various operations of the exemplary methods described herein can be performed at least in part by one or more processors, which are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors can constitute the engine of a processor implementation whose operation is to perform one or more of the operations or functions described herein.
[0100] Similarly, the methods described herein can be implemented at least partially by a processor, where a specific processor or one or more processors are examples of hardware. For example, at least some operations of the methods can be performed by one or more processors or an engine implemented by a processor. Furthermore, one or more processors can also run in a “cloud computing” environment or as “Software as a Service” (SaaS) to support the execution of the relevant operations. For example, at least some operations can be performed by a group of computers (as an example of a machine including processors), which can be accessed via a network (e.g., the Internet) and through one or more appropriate interfaces (e.g., application programming interfaces (APIs)).
[0101] The performance of certain operations can be distributed across processors, not just residing within a single machine, but deployed across many machines. In some exemplary embodiments, the processor or the processor-implemented engine may reside in a single geographic location (e.g., in a home environment, office environment, or server farm). In other exemplary embodiments, the processor or the processor-implemented engine may be distributed across many geographic locations.
[0102] In this specification, multiple instances may implement components, operations, or structures described as a single instance. Although individual operations of one or more methods are described and illustrated as independent operations, one or more individual operations may be performed concurrently, and these operations are not required to be performed in the order shown. Structures and functionalities presented as independent components in the example configuration may be implemented as combined structures or components. Similarly, structures and functionalities presented as individual components may be implemented as independent components. These and other variations, modifications, additions, and improvements are all within the scope of this document.
[0103] As used herein, “or” is inclusive rather than exclusive unless explicitly stated or indicated by context. Furthermore, “and” is both common and individual unless explicitly stated or indicated by context. Moreover, multiple instances may be provided for the resources, operations, or structures described herein as a single example. Furthermore, the boundaries between various resources, operations, engines, and data stores are somewhat arbitrary, and specific operations are illustrated within the context of a particular illustrative configuration. The allocation of other functionalities is conceivable and may fall within the scope of various embodiments of this disclosure. Generally, structures and functionalities presented as independent resources in example configurations may be implemented as combined structures or resources. Similarly, structures and functionalities presented as individual resources may be implemented as independent resources. These and other variations, modifications, additions, and improvements are all within the scope of embodiments of this disclosure. Therefore, this specification and accompanying drawings should be viewed in an illustrative rather than restrictive sense.
[0104] The terms “comprising” or “including” are used to indicate the presence of a subsequently stated feature, but do not preclude the addition of other features. Conditional language, in particular, such as “may,” “can,” or “may,” unless specifically stated or otherwise understood in the context of use, is generally intended to express that certain embodiments include certain features, elements, and / or steps, while other embodiments do not. Therefore, such conditional language generally does not imply that a feature, element, and / or step is necessary in any way for one or more embodiments, or that one or more embodiments must include logic that, with or without user input or prompting, determines whether such features, elements, and / or steps are included in any particular embodiment, or whether they are to be performed in any particular embodiment.
Claims
1. A simulation method for a GPU architecture, wherein, The GPU architecture includes multiple functional modules, characterized in that the simulation method includes: Within a preset time window, the operating metrics of each of the plurality of functional modules are monitored. The plurality of functional modules include compute-intensive modules and memory-intensive modules. The operating metrics monitored for the compute-intensive modules include at least one of instruction issue rate, number of active thread bundles, and pipeline blocking ratio. The operating metrics monitored for the memory-intensive modules include at least one of load / store wait request count, missing state holding register utilization, and on-chip network bandwidth utilization. Based on the operational metrics of each functional module, a hotspot score is calculated for that functional module, where the hotspot score represents the activity level of the functional module within the preset time window, and the calculation of the hotspot score based on the operational metrics of each functional module includes: For the first of the multiple functional modules The first functional module is calculated using the following formula. Hotspot scores for each functional module : ， in, Indicates the first The total number of operational metrics monitored by each functional module, and and All are positive integers. Not greater than positive integers, For the first The first functional module The preset weight coefficients for each operating indicator For the normalized first The first functional module Several operational indicators, among which... ， in, For the first The first functional module The original values of each operating indicator For the first The maximum theoretical threshold corresponding to each operating indicator; For each of the multiple functional modules, the hotspot score of the functional module is compared with the size of a preset threshold, and the simulation mode to be adopted for the functional module is determined based on the comparison result. The simulation mode is one of fine simulation mode and fast-forward simulation mode. In response to determining that the fine simulation mode is used to simulate the functional module, the internal state machine of the functional module is updated periodically. In response to determining that the fast-forward simulation mode should be used to simulate the functional module, the equivalent delay of the functional module is derived based on the historical data of the functional module, wherein the equivalent delay is used to characterize the delay of the functional module within the corresponding simulation time step, and wherein the process of deriving the equivalent delay of the functional module based on the historical data of the functional module in response to determining that the fast-forward simulation mode should be used to simulate the functional module includes: Retrieve the historical operating metrics of this functional module within the previous preset time window; Based on the historical operating metrics, the equivalent delay of this functional module is calculated, including: In response to determining that the functional module is the compute-intensive module, the pipeline utilization and congestion rate are extracted from the historical operating metrics, and the equivalent delay is calculated based on the pipeline utilization and the congestion rate. In response to the determination that the functional module is the cache module in the memory-intensive module, the cache hit rate and cache miss rate are extracted from the historical operating metrics, and the equivalent latency is calculated using the following formula. AvgLatency : ， in, HitRate The cache hit rate is... MissRate The cache miss rate is... L hit This is due to the inherent hit latency of this caching module. L miss This is the inherent miss latency of this cache module; In response to determining that the functional module is an on-chip network or dynamic random access memory in the memory-intensive module, the request arrival rate and request service rate are extracted from the historical operating indicators, and the equivalent latency is calculated using the following formula. Latency : Latency = 1 / (μ-λ), in, λ The request arrival rate is used to represent the number of requests entering this functional module per unit period. μ The request service rate is used to represent the number of requests that this functional module can complete per unit period; and Based on the equivalent delay spanning the corresponding simulation time step, the cycle-by-cycle update of the internal state machine of the functional module within the simulation time step is skipped.
2. The simulation method according to claim 1, characterized in that, in, The preset threshold includes a first threshold and a second threshold that is less than the first threshold, and the simulation method further includes: At the start of the simulation, the initial simulation mode for each functional module is set to the fine simulation mode, wherein, The step of comparing the hotspot score of each of the plurality of functional modules with a preset threshold, and determining the simulation mode to be used for the functional module based on the comparison result, includes: For each of the plurality of functional modules, in response to determining that the functional module is currently in the fast-forward simulation mode and that the hotspot score of the functional module is greater than the first threshold for N consecutive preset time windows, the simulation mode of the functional module is switched to the fine simulation mode, where N is a positive integer; and In response to determining that the functional module is currently in the fine simulation mode, and that the hotspot score of the functional module is less than the second threshold for N consecutive preset time windows, the simulation mode of the functional module is switched to the fast-forward simulation mode.
3. The simulation method according to claim 1, characterized in that, in, The simulation time step corresponding to the equivalent delay span includes: The time span encompassed by the preset time window is used as the simulation time step corresponding to this functional module, in order to advance the global simulation time; and Based on the equivalent delay, update the state variables of the functional module after crossing the simulation time step.
4. The simulation method according to claim 1, characterized in that, in, The computationally intensive module includes at least one of a scheduler, a launch unit, and a tensor core, and the memory-intensive module includes at least one of a load / store unit, a cache module, an on-chip network, and a dynamic random access memory.
5. A simulation device for a GPU architecture, wherein, The GPU architecture includes multiple functional modules, characterized in that the simulation device includes: The monitoring module is configured to monitor the operating metrics of each of the plurality of functional modules within a preset time window. The plurality of functional modules include compute-intensive modules and memory-intensive modules. The operating metrics monitored for the compute-intensive modules include at least one of instruction issue rate, number of active thread bundles, and pipeline blocking ratio. The operating metrics monitored for the memory-intensive modules include at least one of load / store wait request count, missing state holding register utilization, and on-chip network bandwidth utilization. A calculation module is configured to calculate a hotspot score for each functional module based on its operational metrics, wherein the hotspot score represents the activity level of the functional module within a preset time window, and wherein the calculation module is further configured to: For the first of the multiple functional modules The first functional module is calculated using the following formula. Hotspot scores for each functional module : ， in, Indicates the first The total number of operational metrics monitored by each functional module, and and All are positive integers. Not greater than positive integers, For the first The first functional module The preset weight coefficients for each operating indicator For the normalized first i The first functional module Several operational indicators, among which... ， in, For the first The first functional module The original values of each operating indicator For the first The maximum theoretical threshold corresponding to each operating indicator; The determination module is configured to compare the hotspot score of each of the plurality of functional modules with a preset threshold, and determine the simulation mode to be used for the functional module based on the comparison result, wherein the simulation mode is one of fine simulation mode and fast-forward simulation mode. The update module is configured to update the internal state machine of the functional module periodically in response to determining that the fine simulation mode is used to simulate the functional module. A derivation module is configured to, in response to determining that the fast-forward simulation mode is used to simulate the functional module, derive the equivalent delay of the functional module based on historical data of the functional module, wherein the equivalent delay is used to characterize the delay of the functional module within the corresponding simulation time step, and wherein the derivation module is further configured to: Retrieve the historical operating metrics of this functional module within the previous preset time window; Based on the historical operating metrics, the equivalent delay of this functional module is calculated, including: In response to determining that the functional module is the compute-intensive module, the pipeline utilization and congestion rate are extracted from the historical operating metrics, and the equivalent delay is calculated based on the pipeline utilization and the congestion rate. In response to the determination that the functional module is the cache module in the memory-intensive module, the cache hit rate and cache miss rate are extracted from the historical operating metrics, and the equivalent latency is calculated using the following formula. AvgLatency : ， in, HitRate The cache hit rate is... MissRate The cache miss rate is... L hit This is due to the inherent hit latency of this caching module. L miss This is the inherent miss latency of this cache module; In response to determining that the functional module is an on-chip network or dynamic random access memory in the memory-intensive module, the request arrival rate and request service rate are extracted from the historical operating metrics, and the equivalent latency is calculated using the following formula. Latency : Latency = 1 / (μ-λ), in, λ The request arrival rate is used to represent the number of requests entering this functional module per unit period. μ The request service rate is used to represent the number of requests that this functional module can complete per unit period; and A module configured to skip cycle-by-cycle updates of its internal state machine within the simulation time step based on the equivalent delay.
6. A computer device, characterized in that, The computer device includes: At least one processor; A memory having a computer program stored thereon, wherein, when executed by the at least one processor, the computer program causes the at least one processor to perform the method of any one of claims 1-4.
7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, causes the processor to perform the method of any one of claims 1-4.
8. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, causes the processor to perform the method of any one of claims 1-4.