Instruction-level simulation and performance modeling system for parallel computing architecture

Abstract

The invention provides an instruction-level simulation and performance modeling system for a parallel computing architecture, and belongs to the technical field of computer architecture and simulation verification, and the system comprises an instruction modeling layer which is used for analyzing and executing an intermediate instruction set defined by the architecture; the scheduling execution layer is used for simulating a multi-thread and multi-core parallel execution process; the storage access layer is used for constructing a hierarchical storage access and bandwidth and delay model; and the performance analysis layer is used for collecting and counting key indexes such as an execution period, an instruction utilization rate and memory access delay, and realizing accurate performance modeling of the parallel architecture. According to the method, the performance bottleneck of the design scheme can be rapidly evaluated in the early stage of architecture design, the simulation speed is high, the module configurability is high, the modeling precision is adjustable, and the method is suitable for functional verification, micro-architecture exploration and compiler performance analysis of parallel computing architectures, accelerator chips, heterogeneous multi-core processors and the like.

Description

Technical Field

[0001] This invention relates to the field of computer architecture and simulation verification technology, and in particular to an instruction-level simulation and performance modeling system for parallel computing architectures. Background Technology

[0002] With the widespread application of parallel computing and heterogeneous acceleration technologies, the complexity of computing architectures continues to increase. Modern processor and accelerator systems often include multi-level cache hierarchies, complex instruction scheduling mechanisms, and multi-core or even multi-cluster heterogeneous unit collaborative execution mechanisms, which significantly increases the difficulty of verifying architecture-level design and optimization.

[0003] In the current chip architecture development process, the following common verification and performance evaluation methods are mainly used:

[0004] 1. RTL-level simulation (Register Transfer Level Simulation)

[0005] RTL simulation, based on register-transfer level description, can accurately reflect the timing behavior of hardware logic and is an important means of hardware functional verification. Its advantages are high modeling accuracy and coverage of signal-level verification; however, because it requires performing a large number of logic calculations at the signal level, the simulation speed is usually only one ten-thousandth to one millionth of that of actual hardware, making it difficult to support system-level and large-scale application performance evaluation and algorithm optimization.

[0006] 2. FPGA Prototyping

[0007] FPGA verification can be performed in an environment close to real hardware, with a much faster execution speed than RTL simulation. However, this approach requires synthesizing the complete RTL design onto the programmable logic device, resulting in a long development cycle, high resource consumption, and poor flexibility in modification. When the architecture changes frequently or multiple versions are explored, the cost of repeated builds is extremely high.

[0008] 3. Pure Software Functional Model (CModel)

[0009] CModel, based on the C / C++ language, describes the functional logic of a system and boasts high runtime efficiency, enabling rapid verification of algorithm correctness or system functionality. However, traditional CModels typically lack cycle-accurate precision and timing characteristics, failing to accurately reflect real performance bottlenecks such as instruction scheduling, memory access latency, and on-chip interconnect conflicts. Therefore, they have limitations in areas such as architectural performance evaluation, compiler optimization verification, and scheduling strategy research.

[0010] In summary, existing simulation and modeling solutions struggle to achieve a balance between simulation accuracy and execution efficiency.

[0011] 1. High-precision simulations (such as RTL and FPGA) are too slow and not suitable for rapid system-level evaluation;

[0012] 2. High-efficiency modeling (such as CModel) lacks fine-grained performance characteristics, making it difficult to guide microarchitecture optimization.

[0013] Therefore, how to establish an instruction-level performance modeling system that combines high efficiency, scalability, and timing accuracy at the architecture level has become a key technical issue in the current design and performance optimization of parallel computing architectures. Summary of the Invention

[0014] To address the above technical issues, this invention provides an instruction-level simulation and performance modeling system for parallel computing architectures. This system can quickly assess the performance bottlenecks of design schemes in the early stages of architecture design. It features high simulation speed, strong module configurability, and adjustable modeling accuracy. It is suitable for functional verification, microarchitecture exploration, and compiler performance analysis of parallel computing architectures, accelerator chips, heterogeneous multi-core processors, etc.

[0015] The technical solution of this invention is:

[0016] An instruction-level simulation and performance modeling system for parallel computing architectures, including

[0017] The instruction modeling layer is used to parse and execute the intermediate instruction set defined by the architecture;

[0018] The scheduling and execution layer is used to simulate multi-threaded, multi-core parallel execution processes;

[0019] The storage access layer is used to build a hierarchical storage access and bandwidth / latency model;

[0020] The performance analysis layer is used to collect various statistical information generated during the execution process, so as to achieve quantitative evaluation of system performance.

[0021] Furthermore,

[0022] The instruction modeling layer is supported by forwarding API interfaces, parsing and converting intermediate representations.

[0023] Parallel computing architecture applications are divided into host-side programs and device-side programs.

[0024] In actual execution by the simulator, the host-side program uses C language to implement the relevant application programming interface. During actual compilation, the compiler forwards the upper-level calls to the programming interface to the corresponding simulator's runtime library interface, thereby supporting the runtime of the parallel computing program.

[0025] For the device-side program, during actual program execution, the intermediate representation in the binary file is parsed and loaded into the simulator. After instruction parsing, the obtained intermediate representation is converted into a custom intermediate representation inside the simulator. Each instruction in these intermediate representations has its corresponding implementation opcode. Then, a traditional compiler is called to compile the code and output the final binary file, which can then support running in the implemented simulator.

[0026] Furthermore,

[0027] The scheduling execution layer functions include:

[0028] 1) Establish a thread context model, including register states, program counter, execution flags, and synchronization events.

[0029] 2) Simulate the allocation and occupation of execution units.

[0030] 3) Supports multi-core parallel execution strategies, inter-thread synchronization, resource contention, and execution order modeling.

[0031] 4) Implement an event-driven scheduling mechanism that can dynamically adjust the execution order and priority of tasks.

[0032] The scheduling and execution layer abstracts the stages of instruction fetching, decoding, execution, memory access, and write-back in the software, and schedules and advances them at the granularity of cycles, reflecting the parallel execution, structural conflicts, and latency hiding behaviors of each functional unit of the parallel computing architecture.

[0033] The address fetching process first retrieves the instruction from the instruction cache based on the address of the instruction currently being executed by the thread bundle, and then uses SIMT-Stack to handle branch divergence, saving the program counter and active mask for different execution paths.

[0034] During the decoding stage, binary instructions are parsed into an internal format, a predicate register is used for conditional execution, and a scoreboard is used to detect dependencies on registers.

[0035] The issuing unit sends the decoded instructions to the execution unit and collects the ready instructions of multiple thread bundles through the collection unit. An arbitrator is used to select the thread bundles ready by the collection unit and issue instructions. Finally, the operands are collected with the help of the operand collector.

[0036] The execution phase involves executing instructions sent from the upper layer, including memory access instructions and arithmetic and logical operations.

[0037] Furthermore,

[0038] The storage access layer uses software to abstract the multi-level storage architecture of the GPU, including registers, shared memory, cache layer, global memory, and constant / texture memory. The storage access layer uses periodic modeling to reproduce the storage access characteristics of the GPU, and supports the configuration of cache capacity, number of channels, and bandwidth by providing a flexible and configurable parameter interface. The periodic modeling of the flexible parameter configuration set can be used to study the impact of different specifications on GPU performance.

[0039] To more effectively simulate the behavior that occurs during memory access, several memory access requests generated during the issuance phase of the relevant memory access instructions are mapped to each bank, and the latency of memory access is simulated through the bank queue. At the same time, in order to simulate the hierarchical structure of GPU storage, when accessing global memory, the cache layer interface is automatically called first in the software implementation link, and then the global memory interface is called.

[0040] Furthermore,

[0041] The performance analysis layer includes the following functions:

[0042] 1) Collect information on execution trajectory, instruction statistics, memory access hit rate, and thread utilization rate;

[0043] 2) Supports bottleneck location and performance hotspot analysis;

[0044] 3) Provide a visual analysis interface or export report files for performance comparison and optimization guidance;

[0045] 4) Supports integration with external performance tools.

[0046] The beneficial effects of this invention are

[0047] By designing multiple layers—instruction modeling, scheduling and execution, memory access, and performance analysis—accurate performance modeling of parallel architectures can be achieved. This invention enables rapid evaluation of performance bottlenecks in the early stages of architecture design, offering high simulation speed, strong module configurability, and adjustable modeling accuracy. It is suitable for functional verification, microarchitecture exploration, and compiler performance analysis of parallel computing architectures, accelerator chips, and heterogeneous multi-core processors. Attached Figure Description

[0048] Figure 1 This is the overall architecture diagram of the simulation system;

[0049] Figure 2 This is the flowchart of the instruction modeling layer;

[0050] Figure 3 This is the flowchart of the scheduling and execution layer. Detailed Implementation

[0051] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are some embodiments of the present invention, but not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0052] This invention provides an instruction-level simulation and performance modeling system for parallel computing architectures, which can achieve adjustable precision timing modeling and performance prediction while ensuring functional correctness verification. This system enables rapid verification of performance differences among different hardware configurations, scheduling strategies, and memory access mechanisms during the architecture design phase, thus providing a unified simulation platform for architecture optimization, compiler design, and research on parallel task scheduling strategies.

[0053] Compared with the prior art, the present invention achieves the following:

[0054] 1. Balancing functional correctness and performance analysis at the architecture level;

[0055] 2. Supports multi-level adjustable precision from the functional level to the cycle level;

[0056] 3. It can be extended to multi-core, multi-threaded, and heterogeneous execution environments;

[0057] 4. Significantly improves simulation efficiency and flexibility, and shortens the architecture verification cycle.

[0058] This system mainly includes the following:

[0059] 1. Instruction Modeling Layer

[0060] The instruction set simulation module primarily utilizes API interface forwarding, intermediate representation parsing, and conversion for support. Parallel computing architecture applications can generally be divided into host-side programs and device-side programs. For this instruction set simulation module, unlike the conventional compilation process, considering subsequent parsing and conversion, the compiler cannot directly convert the program into the final hardware instruction set; it can only compile it into a hardware-independent intermediate representation. In actual simulator execution, for the host-side program, the relevant application programming interfaces (APIs) are implemented in C language. During compilation, the compiler forwards calls to the programming interfaces from the upper layer to the corresponding simulator's runtime library interface, thus supporting the runtime of the parallel computing program. For the device-side program, during actual runtime, the intermediate representation in the binary file is parsed and loaded into the simulator. After instruction parsing, the acquired intermediate representation is converted into a custom intermediate representation internal to the simulator. Each instruction in these intermediate representations has its corresponding opcode. Then, a traditional compiler is called to compile the code and output the final binary file, which can then run on the implemented simulator.

[0061] Based on this instruction set simulation module, behavioral models of different types of instructions such as arithmetic, logic, memory access, and control can be constructed; instruction dependencies and scheduling constraints can be established; and instruction flow execution sequences can be generated for simulation, providing input data for subsequent execution layers.

[0062] 2. Scheduling Execution Layer

[0063] This layer is used to simulate the running and scheduling behavior of parallel threads and execution units. Its main functions include:

[0064] 1) Establish a thread context model, including register states, program counter, execution flags, and synchronization events;

[0065] 2) The allocation and occupancy of simulated execution units (such as arithmetic units, memory access units, control units, etc.);

[0066] 3) Supports multi-core parallel execution strategies, inter-thread synchronization, resource contention, and execution order modeling;

[0067] 4) Implement an event-driven scheduling mechanism that can dynamically adjust the execution order and priority of tasks.

[0068] Through the above mechanism, the system can accurately reflect the impact of different scheduling strategies on overall performance and realize the reproduction of the periodic instruction execution process.

[0069] The execution module abstracts stages such as instruction fetching, decoding, execution, memory access, and write-back in the software, and schedules and advances them at the granularity of cycles, accurately reflecting the parallel execution, structural conflicts, latency hiding, and other behaviors of each functional unit of the parallel computing architecture.

[0070] The address fetching process first retrieves the instruction from the instruction cache based on the address of the instruction currently being executed by the thread bundle, and handles branch divergence through SIMT-Stack, saving the program counter and active mask for different execution paths. In the decoding phase, binary instructions are parsed into their internal format, using a predicate register for conditional execution and a scoreboard to detect register dependencies and avoid conflicts such as write-after-read. The issue unit primarily issues the decoded instructions to the execution unit and collects ready instructions from multiple thread bundles through the collection unit. An arbitrator selects the ready thread bundles from the collection unit and issues instructions accordingly. Finally, the operand collector collects the operands. The execution phase mainly executes instructions sent from the upper layer, including related memory access instructions and arithmetic and logical operations.

[0071] 3. Storage Access Layer

[0072] The storage access layer is mainly used to simulate the complex storage architecture in GPUs, as well as behaviors such as access latency, bandwidth, and contention. It mainly supports multi-level memory access modeling of registers, local memory, shared memory, and global memory, and enables numerical configuration of storage capacity, number of channels, number of banks, and bandwidth through a flexible and configurable parameter interface.

[0073] The storage layer module abstracts the GPU's multi-level storage architecture in software, including registers, shared memory, cache layers (L1 / L2), global memory, and constant / texture memory. The module employs periodic modeling to reproduce the GPU's memory access characteristics and provides a flexible, configurable parameter interface to support configuration of cache capacity, channel count, bandwidth, etc. This flexible parameter configuration set and periodic-level modeling can be used to study the impact of different configuration specifications on GPU performance. To more effectively simulate the behavior occurring during memory access, several memory access requests generated during the issuance phase of related memory access instructions are mapped to each bank, and the bank queue simulates memory access latency. Simultaneously, to simulate the GPU's hierarchical storage structure, when accessing global memory, the software-implemented link automatically calls the cache layer (L1 / L2) interface first, and then the global memory interface.

[0074] 4. Performance Analysis Layer

[0075] This layer is used to collect various statistical information generated during execution, enabling quantitative evaluation of system performance. Its functions include:

[0076] 1) Collect metrics such as execution trajectory, instruction statistics, memory access hit rate, and thread utilization rate;

[0077] 2) Supports bottleneck location and performance hotspot analysis;

[0078] 3) Provide a visual analysis interface or export report files for performance comparison and optimization guidance;

[0079] 4) Supports integration with external performance tools (such as trace analyzers and scheduling visualization tools).

[0080] The design of this layer enables the simulation system not only to verify functional correctness, but also to provide architectural-level performance feedback, providing data support for subsequent hardware optimization.

[0081] The above description is merely a preferred embodiment of the present invention and is used only to illustrate the technical solution of the present invention, and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention are included within the scope of protection of the present invention.

Claims

1. An instruction-level simulation and performance modeling system for parallel computing architectures, characterized in that, include The instruction modeling layer is used to parse and execute the intermediate instruction set defined by the architecture; The scheduling and execution layer is used to simulate multi-threaded, multi-core parallel execution processes; The storage access layer is used to build a hierarchical storage access and bandwidth / latency model; The performance analysis layer is used to collect various statistical information generated during the execution process, so as to achieve quantitative evaluation of system performance.

2. The system according to claim 1, characterized in that, The instruction modeling layer is supported by forwarding API interfaces, parsing and converting intermediate representations.

3. The system according to claim 2, characterized in that, Parallel computing architecture applications are divided into host-side programs and device-side programs; In actual execution by the simulator, the host-side program uses C language to implement the relevant application programming interface. During actual compilation, the compiler forwards the upper-level calls to the programming interface to the corresponding simulator's runtime library interface, thereby supporting the runtime of the parallel computing program. For the device-side program, during actual program execution, the intermediate representation in the binary file is parsed and loaded into the simulator. After instruction parsing, the obtained intermediate representation is converted into a custom intermediate representation inside the simulator. Each instruction in these intermediate representations has its corresponding implementation opcode. Then, the compiler is called to compile the code and output the final binary file, which can then support running in the implemented simulator.

4. The system according to claim 1, characterized in that, The scheduling execution layer functions include: 1) Establish a thread context model, including register states, program counter, execution flags, and synchronization events; 2) Simulate the allocation and occupation of execution units; 3) Supports multi-core parallel execution strategies, inter-thread synchronization, resource contention, and execution order modeling; 4) Implement an event-driven scheduling mechanism that can dynamically adjust the execution order and priority of tasks.

5. The system according to claim 4, characterized in that, The scheduling and execution layer abstracts the stages of instruction fetching, decoding, execution, memory access, and write-back in the software, and schedules and advances them at the granularity of cycles, reflecting the parallel execution, structural conflicts, and latency hiding behaviors of each functional unit of the parallel computing architecture.

6. The system according to claim 5, characterized in that, The address fetching process first retrieves the instruction from the instruction cache based on the address of the instruction currently being executed by the thread bundle, and then uses SIMT-Stack to handle branch divergence, saving the program counter and active mask for different execution paths; During the decoding stage, binary instructions are parsed into an internal format, a predicate register is used for conditional execution, and a scoreboard is used to detect dependencies on registers. The issuing unit sends the decoded instructions to the execution unit and collects the ready instructions of multiple thread bundles through the collection unit. An arbitrator is used to select the thread bundles ready by the collection unit and issue instructions. Finally, the operands are collected with the help of the operand collector. The execution phase involves executing instructions sent from the upper layer, including memory access instructions and arithmetic and logical operations.

7. The system according to claim 1, characterized in that, The storage access layer uses software to abstract the multi-level storage architecture of the GPU, including registers, shared memory, cache layer, global memory, and constant / texture memory. The storage access layer uses periodic modeling to reproduce the storage access characteristics of the GPU, and supports the configuration of cache capacity, number of channels, and bandwidth by providing a flexible and configurable parameter interface. The periodic modeling of the flexible parameter configuration set can be used to study the impact of different specifications on GPU performance.

8. The system according to claim 7, characterized in that, The related memory access instructions generate several memory access requests during the launch phase, which are mapped to each bank. The bank queue simulates the memory access latency. When accessing global memory, the cache layer interface is automatically called first in the software-implemented link, and then the global memory interface is called.

9. The system according to claim 1, characterized in that, The performance analysis layer includes the following functions: 1) Collect information on execution trajectory, instruction statistics, memory access hit rate, and thread utilization rate; 2) Supports bottleneck location and performance hotspot analysis; 3) Provide a visual analysis interface or export report files for performance comparison and optimization guidance; 4) Supports integration with external performance tools.

Images