Cooperative evaluation method for processor micro-architecture performance upper limit exploration and related device

Abstract

The embodiment of the application discloses a kind of collaborative evaluation method for exploring the upper limit of processor micro-architecture performance and related device, the method includes that various idealized micro-architecture components are constructed according to the collaborative process of ideal model by real processor model, processor micro-architecture performance is collaboratively evaluated, and collaborative process includes: real processor model sends instruction query and information request to ideal model, and the request carries the memory address of dynamic instruction;Ideal model executes dynamic instruction according to memory address and obtains target value in normal working state, and target value is returned as the response of the request to real processor model;Real processor model executes dynamic instruction and obtains actual value in execution phase;Target value and actual value are verified in submission phase, and verification result is obtained.Using the embodiment of the application, the theoretical performance upper limit of value prediction and other speculative execution techniques can be accurately quantified, and the real performance bottleneck of the entire processor system integrated with the technique can be identified.

Description

Technical Field

[0001] This invention relates to the field of computer performance evaluation technology, and in particular to a collaborative evaluation method and related apparatus for exploring the performance ceiling of processor microarchitecture. Background Technology

[0002] With the ever-increasing demand for high-performance computing, the performance requirements for central processing units (CPUs) are becoming increasingly stringent. High-performance superscalar processors are the mainstream technological path to meet this demand, with their core being the simultaneous improvement of instruction fetch and execution bandwidth. However, although processor front-end technology has matured, the instruction-level parallelism of back-end execution units is still generally severely constrained by true dependencies between instructions, which constitutes a key bottleneck for improving processor performance.

[0003] To address this issue, academia and industry have proposed value prediction technology, which breaks true dependencies by predicting the execution results of instructions, thereby improving the instruction-level parallelism of processors. However, due to inherent flaws, existing value prediction techniques have not yet achieved widespread commercial application in modern processors.

[0004] Existing value prediction techniques generally face the following problems: First, in the long pipelines of modern processors, a single incorrect prediction can trigger huge pipeline flushing overhead, severely offsetting its potential performance gains. Second, value predictors themselves require significant chip area and power consumption, and their performance improvement cost-effectiveness is often lower than using the same resources to expand caches or more mature components such as branch predictors. Finally, the regularity of instruction value changes is far lower than that of memory address accesses or branch jumps, resulting in limited accuracy and coverage of the predictor, significantly reducing its practical benefits. These problems make it difficult to assess the true performance ceiling and feasibility of value prediction techniques in the early stages of design, hindering the development and application of this technology. Summary of the Invention

[0005] In view of the problems existing in the above background technology, although processor back-end speculative technologies such as value prediction have great potential, they suffer from high overhead of misprediction, high hardware cost, difficulty in assessing actual benefits, and existing evaluation methods are time-consuming and cannot accurately determine the performance upper limit and bottleneck in the early stages of design. The embodiments of this application provide a collaborative evaluation method and related apparatus for exploring the performance upper limit of processor microarchitecture, aiming to solve the above technical problems.

[0006] The first aspect of this application provides a collaborative evaluation method for exploring the performance ceiling of processor microarchitectures, the method comprising:

[0007] The real processor model constructs various idealized microarchitecture components based on a collaborative process with the ideal model, and collaboratively evaluates the processor microarchitecture performance. This collaborative process includes:

[0008] The real processor model sends an instruction query and information request to the ideal model. The instruction query and information request is used to query the target value of the dynamic instruction obtained by the real processor model in the instruction fetch stage. The instruction query and information request carries the memory address of the dynamic instruction.

[0009] Under normal operating conditions, the ideal model executes the dynamic instruction based on the memory address to obtain the target value, and returns the target value as the response to the instruction query and information request to the real processor model;

[0010] The actual processor model executes the dynamic instructions during the execution phase to obtain the actual value;

[0011] The real processor model verifies the target value and the actual value during the submission phase, and obtains the verification results.

[0012] In some examples, before the real processor executes the dynamic instructions to obtain the actual value during the execution phase, the method further includes:

[0013] During the renaming phase, the real processor model allocates a physical register for the target value and writes the target value into the physical register.

[0014] The real processor model marks the physical registers as available.

[0015] The real processor model looks up instructions that depend on the physical registers in the scoreboard's dependency table;

[0016] The real processor model marks the dependency counters of instructions that depend on the physical registers as satisfied, so that instructions that depend on the physical registers can be scheduled and issued by the scheduler.

[0017] In some examples, after the ideal model obtains the target value by executing the dynamic instruction based on the memory address under normal operating conditions, the method further includes:

[0018] The ideal model saves a current self-snapshot and records memory trajectories.

[0019] In some examples, after the real processor model executes the dynamic instructions to obtain the actual value during the execution phase, the method further includes:

[0020] If the real processor model determines that the branch prediction is wrong based on the actual value, the real processor model triggers pipeline flushing and sends a recovery signal to the ideal model. The recovery signal carries the sequence number of the dynamic instruction that caused the pipeline to be flushed and the memory address of the correct jump.

[0021] The ideal model determines the preceding dynamic instruction that caused the pipeline to be cleared based on the sequence number of the dynamic instruction that caused the pipeline to be cleared.

[0022] The ideal model restores the register state and memory state based on the self-snapshot saved after the previous dynamic instruction is executed and the recorded memory trajectory.

[0023] In some examples, the method further includes:

[0024] If the ideal model detects an anomaly when executing the dynamic instruction based on the memory address under normal working conditions, the ideal model changes the state machine state from the normal working state to the abnormal pause state and stops working until the real processor model starts processing the anomaly detected by the ideal model and then resumes normal working.

[0025] If the dynamic instruction is a system instruction or a privileged instruction, the ideal model will change the state of the state machine from the normal working state to the system or privileged instruction pause state and stop working until the system instruction or privileged instruction is submitted on the real processor model and then resume normal working.

[0026] If the dynamic instruction is an instruction that the ideal model cannot execute, the ideal model changes the state of its state machine from the normal working state to the non-speculation instruction pause state and stops working until the real processor model finishes executing the non-executable instruction and synchronizes the execution result of the non-executable instruction to the ideal model, at which point it resumes normal operation.

[0027] In some examples, the method further includes:

[0028] The ideal model checks whether the real processor model is working on the wrong path before resuming normal operation;

[0029] If the real processor model is operating on an incorrect path, the ideal model will change the state of the state machine to an iterative recovery pause state until it receives a normal operation recovery signal from the real processor model and then resumes normal operation.

[0030] In some examples, the ideal model checks whether the real processor model is working on the faulty path before resuming normal operation, including:

[0031] The ideal model traverses all in-transit dynamic instructions before resuming normal operation to obtain branch instructions that have not yet been executed by the real processor.

[0032] The ideal model calculates the actual jump destination address of the branch instruction that has not yet been executed by the real processor;

[0033] If the actual jump destination address is inconsistent with the predicted jump destination address of the real processor, then it is confirmed that the real processor model is working on the wrong path.

[0034] A second aspect of this application provides a collaborative evaluation apparatus for exploring the performance ceiling of a processor microarchitecture, the apparatus comprising:

[0035] The performance evaluation unit controls the real processor model to construct various idealized microarchitecture components according to a collaborative process with the ideal model, and collaboratively evaluates the processor microarchitecture performance. The collaborative process includes:

[0036] The real processor model sends an instruction query and information request to the ideal model. The instruction query and information request is used to query the target value of the dynamic instruction obtained by the real processor model in the instruction fetch stage. The instruction query and information request carries the memory address of the dynamic instruction.

[0037] Under normal operating conditions, the ideal model executes the dynamic instruction based on the memory address to obtain the target value, and returns the target value as the response to the instruction query and information request to the real processor model;

[0038] The actual processor model executes the dynamic instructions during the execution phase to obtain the actual value;

[0039] The real processor model verifies the target value and the actual value during the submission phase, and obtains the verification results.

[0040] A third aspect of this application provides an electronic device, including: a processor and a memory;

[0041] The processor is connected to a memory, wherein the memory is used to store computer programs and the processor is used to invoke the computer programs to execute the methods as described in the first aspect of the embodiments of this application.

[0042] A fourth aspect of this application provides a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a processor, perform the method as described in the first aspect of this application.

[0043] This application constructs a realistic processor model. Before the real processor model executes the dynamic instruction to obtain the actual value during the execution phase, it executes the dynamic instruction based on the memory address to obtain the target value. Then, during the submission phase, the target value and the actual value are verified to obtain the verification result. Under normal operating conditions, the target value and the actual value are the same, thus constructing an ideal value predictor with 100% accuracy and configurable coverage, perfectly breaking the true data dependency between instructions in simulation. Analyzing the performance of the real processor model under this idealized speculative execution condition can determine the performance upper limit of this speculative technique and identify system-level bottlenecks that limit further performance improvement. Therefore, the embodiments of this application can accurately quantify the theoretical performance upper limit of speculative execution techniques such as value prediction in the initial stage of microarchitecture design, and even before any specific predictor hardware design, and identify the real performance bottleneck of the entire processor system after integrating this technique. This greatly shortens the R&D cycle, reduces trial and error costs, and provides a clear and reliable direction for subsequent microarchitecture design. Attached Figure Description

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

[0045] Figure 1 This illustration shows a schematic diagram of a collaborative evaluation system for exploring the performance ceiling of processor microarchitectures according to an embodiment of this application;

[0046] Figure 2 This illustration shows a flowchart of the collaborative operation between a real processor model and an ideal model provided in one embodiment of this application;

[0047] Figure 3 A flowchart illustrating a collaborative evaluation method for exploring the performance ceiling of processor microarchitectures according to an embodiment of this application is shown.

[0048] Figure 4 This illustration shows a schematic diagram of the structure of a collaborative evaluation device for exploring the performance ceiling of processor microarchitecture according to an embodiment of this application;

[0049] Figure 5 A schematic diagram of the structure of a computer device provided in one embodiment of this application is shown. Detailed Implementation

[0050] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0051] Please refer to Figure 1 This illustration shows a schematic diagram of a collaborative evaluation system for exploring the performance ceiling of a processor microarchitecture according to an embodiment of this application. The collaborative evaluation system may include: a real processor model 10, an ideal model 20, and a lightweight interactive interface 30.

[0052] The realistic processor model 10, in this embodiment, is a highly sophisticated microarchitecture simulator, such as the XS-GEM5 microarchitecture simulator customized for the Xiangshan processor (e.g., the Kunming Lake architecture). Of course, it could also be other microarchitecture simulators, which are not limited here. Its "realism" lies in its faithful modeling of modern superscalar processor cores, including not only L1 and L2 caches and translation lookaside buffers (TLBs), but also deeper microarchitecture components, such as: a large-capacity reorder buffer (ROB) with hundreds of entries, separate integer / floating-point physical register files, multiple reservation stations, and parallel arithmetic and logic units (ALUs), floating-point units (FPUs), and address generation units (AGUs). Every detail of this realistic processor model is designed to accurately reproduce the behavior of the hardware at each clock cycle, providing a solid foundation for performance evaluation.

[0053] Ideal Model 20, in this embodiment of the application, is a functionally correct reference model based on a full-system simulator. For example, it can be the lightweight full-system simulator NEMU (NJU Emulator) developed by Nanjing University, which supports multiple architectures such as x86, MIPS32, and RISC-V32 / 64. Its design is simple and highly scalable, making it naturally suitable as a functionally correct reference model.

[0054] The real processor model 10 and the ideal model 20 form a decoupled collaborative evaluation system. This decoupling of the ideal model from the real processor model offers significant advantages. It means that the implementation of the ideal model can be iterated and optimized independently of the real processor model. For example, the same validated ideal model can be used to evaluate multiple real processor models with different configurations, allowing for a cross-sectional comparison of the impact of different microarchitectural decisions on realizing speculative technology potential under a unified benchmark. This modular design greatly improves the efficiency and scalability of the research.

[0055] The lightweight interactive interface 30 serves as a bridge connecting the real processor model 10 and the ideal model 20, primarily functioning to efficiently coordinate, adapt data, and decouple functions. For example, it performs data conversion and format adaptation, converting the physical signals (such as voltage and timing signals) or hardware-level data (such as register values ​​and memory addresses) of the real processor model into logical data (such as algorithm input parameters and state variables) recognizable by the ideal model; conversely, it converts the output of the ideal model (such as optimized instruction sequences and theoretical performance indicators) into hardware operations (such as control signals and configuration parameters) executable by the real processor model. This eliminates data incompatibility issues caused by different levels of model abstraction, ensuring accurate information transmission between heterogeneous models. Furthermore, it achieves functional decoupling and abstraction isolation. Through standardized interface definitions (such as input / output ports, communication protocols, and data frame formats), the lightweight interactive interface allows the real processor model and the ideal model to operate without needing to understand each other's internal implementation details.

[0056] The following section provides a detailed explanation of the collaborative operation between the real processor model 10 and the ideal model 20. Please refer to [link / reference needed]. Figure 2 This illustration shows a flowchart illustrating the collaborative operation of a real processor model and an ideal model according to an embodiment of this application. The method can be applied to computer devices, which refer to electronic devices with data computing and processing capabilities. The method may include the following steps:

[0057] Step 201: The real processor model sends an instruction query and information request to the ideal model. The instruction query and information request is used to query the target value of the dynamic instruction obtained by the real processor model in the instruction fetch stage. The instruction query and information request carries the memory address of the dynamic instruction.

[0058] The dynamic instruction can include at least one of the following: data transfer instructions, arithmetic logic instructions, control transfer instructions, input / output instructions, and processor control instructions. For example, when the dynamic instruction is an arithmetic logic instruction `addi rd, r1, 2`, this instruction calculates the sum of the value in register `r1` and the immediate value `2`, and writes the result to register `rd`. As another example, when the dynamic instruction is a data transfer instruction `ld rd, (rs)`, this instruction reads data from the memory address pointed to by register `rs` and writes it to register `rd`. In both of these different instructions, the instruction query and the information request query retrieve the value in register `rd`, which is the target value.

[0059] The memory address of this dynamic instruction can be obtained through the Program Counter (PC). The Program Counter is a special-purpose register in the computer processor used to store the address in memory of the next instruction to be executed. Before instruction execution, the PC value is the memory address of the instruction to be executed. After instruction execution is completed, the PC is automatically updated to the address of the next instruction based on the length of the current instruction or control logic (such as jumps or branches), ensuring that the program executes sequentially or according to the expected flow.

[0060] Furthermore, this dynamic instruction can be one of multiple instructions constituting a program. When the real processor model sends an instruction query and information request to the ideal model, the query and request not only transmit the program counter but also a dynamic instruction sequence number generated by the real processor model during the instruction fetch phase. This dynamic instruction sequence number serves as a unique identifier for the instruction, preventing confusion between multiple instructions; establishing end-to-end tracing of the instruction lifecycle; ensuring accurate matching of information requests and responses; and supporting instruction-level state management and verification of the ideal model. For example, when the instruction fetch unit fetches an `add x3, x1, x2` instruction at address 0x80001004, it assigns a unique sequence number to this dynamic instruction, such as ID=150. Subsequently, an instruction query and information request containing (PC=0x80001004, ID=150) is sent to the ideal model through a lightweight interactive interface.

[0061] Step 202: Under normal operating conditions, the ideal model executes the dynamic instruction based on the memory address to obtain the target value, and returns the target value as a response to the instruction query and information request to the real processor model.

[0062] For example, after the ideal model receives the instruction query and information request, its internal NEMU engine will execute the dynamic instruction located at the memory address, such as the add instruction at memory address 0x80001004. It can directly calculate the correct result of the x3 register and package the correct result as the target value and the received sequence number ID=150 together and return it to the real model.

[0063] Furthermore, after the ideal model obtains the target value by executing the dynamic instruction based on the memory address under normal working conditions, the method further includes:

[0064] The ideal model saves a current self-snapshot and records memory trajectories.

[0065] A current self-snapshot refers to capturing complete state information of a system, program, or entity at a specific point in time. Snapshot content typically includes memory data, runtime status, configuration information, etc. For example, a current self-snapshot may include the current state of all architecture registers and the program counter; these architecture registers may include general-purpose registers, floating-point registers, control status registers, etc.

[0066] Memory traces refer to all memory access behaviors of a program or system recorded in chronological order. They can include the access address, operation type, specific data read or written, timestamp of the access, address of the instruction that triggered the access, and the process / thread to which it belongs. For example, when the instruction is a write operation, its target address and the data written will be appended to a memory write log (trace).

[0067] Step 203: The real processor model executes the dynamic instructions during the execution phase to obtain the actual value.

[0068] Similarly, a real processor model can fetch the dynamic instruction through the program counter, then read the source operands and / or immediate values ​​according to the instruction, and allocate the corresponding functional unit according to the instruction type. The corresponding functional unit performs the calculation through combinational logic circuits or sequential logic circuits to generate the calculation result as the actual value. It should be noted that if there are multiple dynamic instructions, the real processor model can execute them out of order. The calculated actual value is first stored in the reorder buffer (ROB) and then committed in the order of instruction fetching.

[0069] Furthermore, before the actual processor executes the dynamic instructions to obtain the actual value during the execution phase, the method further includes:

[0070] During the renaming phase, the real processor model allocates a physical register for the target value and writes the target value into the physical register.

[0071] The real processor model marks the physical registers as available.

[0072] The real processor model looks up instructions that depend on the physical registers in the scoreboard's dependency table;

[0073] The real processor model marks the dependency counters of instructions that depend on the physical registers as satisfied, so that instructions that depend on the physical registers can be scheduled and issued by the scheduler.

[0074] The registers defined in the processor's instruction set are called logical registers, but the actual number of registers in the physical hardware is far greater than the number of logical registers (e.g., 64 logical registers correspond to 256 physical registers). When an instruction enters the renaming stage, the instruction contains the target logical register (e.g., x3 in add x3, x1, x2). The renaming unit allocates an unused physical register (e.g., P8) from the free physical register pool and records the mapping relationship through the renaming table (logical → physical mapping table): x3 → P8. This physical register P8 is used to write the target value.

[0075] Physical registers have three core states: idle, allocated but not ready, and available. Idle means it has not been allocated and can be used for renaming in a new instruction; allocated but not ready means it has been renamed and allocated to an instruction, but the result has not been written; available means the result has been written and it can be used as a source operand for other instructions. For example, after a write operation is completed, the state of physical register P8 is updated from "not ready" to "available," and this change is broadcast through the state table (which records the states of all physical registers).

[0076] The scoreboard records the dependencies of all unexecuted instructions: after the source operands (logical registers) of each instruction are renamed and mapped to physical registers, they are recorded in the dependency table as "the current instruction depends on physical register Pn". For example, when physical register P8 is marked as "available", the processor searches the dependency table for all instructions whose source operands depend on P8 (e.g., the instruction or x6, x5, x7, where x5 has been renamed to P8, then this instruction depends on P8).

[0077] Each unexecuted instruction maintains a dependency counter, recording the number of unmet source operand dependencies. For example, if an instruction has two source operands, the initial counter is 2, and it is decremented by 1 for each dependency satisfied. When the dependency counter of an instruction reaches 0, it means that all its source operands are ready (the physical register status is "available"). At this time, the scheduler will remove the instruction from the waiting queue and issue it to the corresponding functional unit for execution.

[0078] As can be seen from the embodiments of this application, the subsequent instructions of the dynamic instruction can be immediately woken up and sent to the reserved station, waiting for the execution unit to become available, thereby greatly shortening the length of the critical dependency chain and improving the instruction-level parallelism.

[0079] Furthermore, after the real processor model executes the dynamic instructions to obtain the actual value during the execution phase, the method further includes:

[0080] If the real processor model determines that the branch prediction is wrong based on the actual value, the real processor model triggers pipeline flushing and sends a recovery signal to the ideal model. The recovery signal carries the sequence number of the dynamic instruction that caused the pipeline to be flushed and the memory address of the correct jump.

[0081] The ideal model determines the preceding dynamic instruction that caused the pipeline to be cleared based on the sequence number of the dynamic instruction that caused the pipeline to be cleared.

[0082] The ideal model restores the register state and memory state based on the self-snapshot saved after the previous dynamic instruction is executed and the recorded memory trajectory.

[0083] The actual value can be, for example, whether to jump or the correct target address. For instance, if the actual value is no jump, the branch predictor predicts a jump; or, if the actual value is the target address PC_B, and the branch predictor predicts the target address PC_C, then the branch prediction is incorrect.

[0084] Triggering pipeline flushing can include marking and clearing all instructions belonging to the error path in the fetch buffer (IF Buffer), decode queue, reservation station, and reorder buffer (ROB); resetting the physical registers that have been allocated for erroneous instructions but have not yet been written to to "free" to avoid resource occupation; marking write memory instructions for the error path in the StoreBuffer as invalid to prevent erroneous data from being written to the cache / memory; and updating the program counter to the correct target address of the branch instruction, etc.

[0085] Among them, the dynamic instruction sequence number that causes the clear is the globally unique sequence number generated by the branch instruction during the instruction fetch phase, which is used by the ideal model to accurately locate the instruction where the error occurred; the memory address to which the correct jump is the actual target address of the branch instruction, which is used by the ideal model to synchronize the subsequent instruction fetch address.

[0086] For example, the real processor model encounters a branch at PC_A, incorrectly predicting a jump to PC_C when the correct target is actually PC_B. The real processor model begins fetching instructions from PC_C and sends instruction queries and information requests to the ideal model. The ideal model serves the instructions at PC_C and on the subsequent incorrect path, creating a state snapshot and memory write log for each step.

[0087] After several cycles, the execution unit of the real model finally resolved the branch at PC_A and found a prediction error. It immediately triggered a pipeline flush and sent a recovery signal to the ideal model, which contained the instruction sequence number that caused the flush and the correct jump target PC_B.

[0088] The ideal model uses the sequence number in the signal to pinpoint the correct snapshot in its stored snapshot history before the execution of the PC_A instruction. It first fully restores the internal register state to that snapshot, then iterates through all memory write logs generated on the error path (starting from PC_C) and performs undo operations on each one in simulated memory, thereby restoring the memory state to the correct state as well.

[0089] Once the recovery is complete, the ideal model and the real model are synchronized again in the correct state at PC_A. The real model begins fetching instructions from PC_B, and the entire collaborative workflow continues seamlessly.

[0090] Step 204: The real processor model verifies the target value and the actual value during the submission phase to obtain the verification result.

[0091] This step is a built-in "assertion" within the entire co-simulation framework. When the `add` instruction with sequence number ID=150 has been actually computed in the execution unit of the real processor model and finally reaches the submission stage, its result computed in the real processor model is rigorously compared with the target value initially provided by the ideal model and read from the ROB entry. The two must be completely consistent. This mechanism not only verifies the simulation process of value prediction, but more importantly, it continuously checks the consistency of instruction semantic implementation between the real processor model and the ideal model, making it a powerful tool for discovering and debugging potential differences between the two models.

[0092] To effectively manage the behavior of the ideal model in complex working scenarios and enable it to stably adapt to the dynamic changes of real processors, this application designs it as a five-stage state machine. The state machine model makes the behavioral stages and state transition logic of the ideal model clear, greatly facilitating debugging and state rollback. The state machine includes one working state and four pause states:

[0093] WORK: Normal operating state. In this state, the ideal model continuously provides accurate instruction execution information to the real model.

[0094] NONSPECSTOP: Non-speculative instruction pause state. For example, when the ideal model receives a load instruction that accesses the UART (Universal Asynchronous Receiver / Transmitter) status register, it enters this state. This is because the value of the UART status register depends on external, real-time physical signals, which are beyond the modeling scope of the ISA simulator. The ideal model pauses here, waiting for the real model to interact with the simulated peripheral through its bus interface, complete the load instruction, and obtain the real return value. Afterward, the real model synchronizes this value and the updated register state back to the ideal model, restoring it to the WORK state.

[0095] EXCEPTIONSTOP: An abnormal pause state. When the ideal model executes an instruction, an exception is triggered, and it enters EXCEPTIONSTOP. However, the real processor model may still have dozens of earlier instructions in its ROB that have not yet been committed. According to the requirements of a precise exception, it must wait until all these instructions have safely retired before switching control flow to the exception handler. Only when the real processor model finally begins to jump to the exception handling vector will it notify the ideal model. At this point, the two are synchronized in control flow, and the ideal model exits the pause and resumes normal operation.

[0096] SYSOPSTOP: System or privileged instruction pause state. In a real processor model, this is a heavyweight serialization instruction that pauses instruction dispatch, waits for the pipeline to empty, performs a refresh operation, and then resumes. When the ideal model encounters a query for this instruction, it enters SYSOPSTOP, pausing its own execution and waiting for the real model to complete the entire complex microarchitecture serialization and refresh process before being woken up by a signal from the real processor model. This ensures that the memory views and system states of the two models are strictly consistent after the serialization point.

[0097] ITERSTOP: Iterative recovery from a pause. This is a brief but crucial intermediate state. When the ideal model recovers from a pause, the real processor model's pipeline may already contain a large number of instructions. At this point, the ideal model needs to iteratively execute these instructions and attempt to synchronize with the real processor model. If no unexpected issues arise, the ideal model will directly return to normal operation. However, if the ideal model detects that the processor is on an incorrect path, it stops working and enters ITERSTOP. It continues until the real model explicitly signals its return, at which point it returns to the WORK state. This intermediate state supports synchronization between the ideal and real models.

[0098] The following describes the state transitions of the ideal model's state machine. The method also includes:

[0099] If the ideal model detects an anomaly when executing the dynamic instruction based on the memory address under normal working conditions, the ideal model changes the state machine state from the normal working state to the abnormal pause state and stops working until the real processor model starts processing the anomaly detected by the ideal model and then resumes normal working.

[0100] If the dynamic instruction is a system instruction or a privileged instruction, the ideal model will change the state of the state machine from the normal working state to the system or privileged instruction pause state and stop working until the system instruction or privileged instruction is submitted on the real processor model and then resume normal working.

[0101] If the dynamic instruction is an instruction that the ideal model cannot execute, the ideal model changes the state of its state machine from the normal working state to the non-speculation instruction pause state and stops working until the real processor model finishes executing the non-executable instruction and synchronizes the execution result of the non-executable instruction to the ideal model, at which point it resumes normal operation.

[0102] In the ideal model, an anomaly is detected when executing dynamic instructions based on memory addresses under normal operating conditions. This anomaly can be either a hardware or software exception. Hardware anomalies can include, for example, memory access out of bounds (e.g., accessing an unmapped address), permission violations (e.g., user-mode access to kernel addresses), data verification errors (e.g., ECC verification failure), and undefined instructions (invalid instruction encoding). Software anomalies can include program-triggered exceptions (e.g., system call `ecall`, breakpoint instruction `ebreak`), and arithmetic exceptions (e.g., division by zero, overflow). This anomaly can be monitored through a built-in exception checking module. For example, when executing a memory write instruction, it checks whether the target address is within the legal physical memory range; when parsing instructions, it compares the opcode with the legal instruction set defined by the ISA to identify undefined instructions; and when performing arithmetic operations, it checks whether the result overflows or is divided by zero.

[0103] System instructions are used to implement operating system kernel functions (such as process management, memory allocation, and interrupt handling). They are directly related to system calls, kernel services, or hardware resource management, and serve as a "bridge" for interaction between user-mode programs and kernel-mode functions. Privileged instructions can only be executed at high privilege levels (such as kernel mode and machine mode). They directly manipulate critical hardware resources (such as control registers, MMU, and I / O devices). Executing them at low privilege levels (such as user mode) will trigger exceptions.

[0104] Furthermore, the method also includes:

[0105] The ideal model checks whether the real processor model is working on the wrong path before resuming normal operation;

[0106] If the real processor model is operating on an incorrect path, the ideal model will change the state of the state machine to an iterative recovery pause state until it receives a normal operation recovery signal from the real processor model and then resumes normal operation.

[0107] Specifically, before resuming normal operation, the ideal model checks whether the real processor model is operating on the error path, including:

[0108] The ideal model traverses all in-transit dynamic instructions before resuming normal operation to obtain branch instructions that have not yet been executed by the real processor.

[0109] The ideal model calculates the actual jump destination address of the branch instruction that has not yet been executed by the real processor;

[0110] If the actual jump destination address is inconsistent with the predicted jump destination address of the real processor, then it is confirmed that the real processor model is working on the wrong path.

[0111] In-transit dynamic instructions refer to all instructions that have flowed into the instruction pipeline before the ideal model pauses, but have not yet been completed (committed) by the real processor. These include: branch instructions that the ideal model is processing at the time of the pause; and subsequent branch instructions that have been decoded but not executed before the pause (such as branch instructions that have been temporarily suspended due to out-of-order execution).

[0112] Specifically, the ideal model calculates the actual jump destination address of the branch instruction that has not yet been executed by the real processor, including: if it is a conditional branch, the ideal model can determine the actual jump destination address based on the current register value and the branch condition. For example, for the instruction beq t0, t1, label, if t0 == t1, then jump to label; otherwise, execute sequentially. If it is an unconditional jump, directly calculate the target address based on the immediate offset in the instruction. For example, for the instruction jal x0, 0x10, then jump to the current PC+0x10. If it is an indirect jump, calculate and determine the actual jump destination address based on the base address register value and the offset. For example, for the instruction jr ra, jump to the address stored in the ra register.

[0113] Furthermore, if the dynamic instruction is a system instruction or a privileged instruction, the real processor model sends a specific type of exception signal to the ideal model. The specific type of exception signal carries additional metadata, and the ideal model can determine the exception type based on the additional metadata.

[0114] For example, regarding potential misalignment issues caused by sfence.vma, when the real model executes sfence.vma, the hardware detects uncommitted page table modification instructions (such as write operations to the SATA register or page table entries) in the Store Buffer. In this case, the TLB invalidate operation of sfence.vma cannot be completed immediately and must wait for the Store Buffer to be flushed before taking effect. The real model sends a signal to the ideal model containing the following metadata: Exception type: SFENCE_VMA_STORE_BUFFER_DELAY (sfence.vma delayed activation exception due to Store Buffer delay); Associated information: the address of the page table modification instruction that triggered the delay (e.g., the sd instruction at 0x80001234), and the address of the unflushed page table entry in the Store Buffer (e.g., 0xffff0000).

[0115] It can be seen that the misalignment caused by implementation details differences between the real processor model and the ideal model can improve the semantic level of communication, so that what is sent is no longer a general exception signal, but a specific type of exception signal with additional metadata. This explicit and more information-rich communication avoids the ideal model from falling into an uncertain state due to mismatches in underlying logic.

[0116] Please refer to Figure 3 This illustration shows a flowchart of a collaborative evaluation method for exploring the performance ceiling of processor microarchitectures according to an embodiment of this application. The method can be applied to computer devices, which refer to electronic devices with data computing and processing capabilities. The method may include the following steps:

[0117] Step 301: The real processor model constructs various idealized microarchitecture components according to a collaborative process with the ideal model, and collaboratively evaluates the processor microarchitecture performance. The collaborative process includes:

[0118] The real processor model sends an instruction query and information request to the ideal model. The instruction query and information request is used to query the target value of the dynamic instruction obtained by the real processor model during the instruction fetch phase. The instruction query and information request carries the memory address of the dynamic instruction. Under normal operating conditions, the ideal model executes the dynamic instruction according to the memory address to obtain the target value, and returns the target value as the response to the instruction query and information request to the real processor model. During the execution phase, the real processor model executes the dynamic instruction to obtain the actual value. During the submission phase, the real processor model verifies the target value and the actual value to obtain the verification result.

[0119] For a detailed explanation of the collaborative process, please refer to [link to relevant documentation]. Figure 2 The example shown.

[0120] In this process, the real processor model constructs various idealized microarchitecture components through a collaborative process with the ideal model, and then collaboratively evaluates the processor microarchitecture performance. This can involve the real processor model constructing various idealized microarchitecture components through a collaborative process with the ideal model, and then calculating performance metrics to collaboratively evaluate the processor microarchitecture performance. Performance metrics may include, for example, coverage, speedup, and instructions per cycle.

[0121] Coverage is a metric that measures the effective scope of microarchitectural optimization mechanisms (such as predictors, caching, and branching). It represents the percentage of instructions successfully identified, processed, or predicted by the optimization mechanism in a dynamic instruction flow. Its core function is to evaluate the "coverage capability of the optimization mechanism for the target scenario." High coverage indicates that the mechanism can effectively work on most instructions, which is a prerequisite for performance improvement; low coverage indicates that the mechanism has limited effect on the current program or scenario.

[0122] Speedup ratio is a core metric for measuring the performance improvement after microarchitecture optimization, representing the ratio of the optimized system performance to the baseline performance before optimization. Its core function is to quantify the actual performance gains brought about by the optimization mechanism. Speedup ratio is the "ultimate indicator" for evaluating the quality of microarchitecture design, directly answering whether the optimization mechanism effectively improves performance (e.g., speedup ratio > 1 indicates performance improvement, = 1 indicates no improvement, < 1 indicates performance degradation).

[0123] Instructions Per Cycle (IPC) is a metric that measures the average number of instructions a processor can execute and submit in a single clock cycle, directly reflecting the processor's parallel execution efficiency and pipeline utilization.

[0124] As can be seen, this application constructs a realistic processor model. Before the real processor model executes the dynamic instruction to obtain the actual value during the execution phase, it has already executed the dynamic instruction based on the memory address to obtain the target value. Then, during the submission phase, the target value and the actual value are verified to obtain the verification result. Under normal operating conditions, the target value and the actual value are the same, thus constructing an ideal value predictor with 100% accuracy and configurable coverage, perfectly breaking the true data dependency between instructions in the simulation. Analyzing the performance of the real processor model under this idealized speculative execution condition can determine the performance upper limit of this speculative technique and identify system-level bottlenecks that limit further performance improvement. Therefore, the embodiments of this application can accurately quantify the theoretical performance upper limit of speculative execution techniques such as value prediction in the initial stage of microarchitecture design, and even before any specific predictor hardware design, and identify the real performance bottleneck of the entire processor system after integrating this technique, thereby greatly shortening the R&D cycle, reducing trial and error costs, and providing a clear and reliable direction for subsequent microarchitecture design.

[0125] Figure 4 A schematic diagram of a collaborative evaluation apparatus for exploring the performance ceiling of a processor microarchitecture, according to an embodiment of this application, is shown. The apparatus includes:

[0126] Performance evaluation unit 401 is used to control the real processor model to construct various idealized microarchitecture components according to a collaborative process with the ideal model, and to collaboratively evaluate the processor microarchitecture performance, wherein the collaborative process includes:

[0127] The real processor model sends an instruction query and information request to the ideal model. The instruction query and information request is used to query the target value of the dynamic instruction obtained by the real processor model in the instruction fetch stage. The instruction query and information request carries the memory address of the dynamic instruction.

[0128] Under normal operating conditions, the ideal model executes the dynamic instruction based on the memory address to obtain the target value, and returns the target value as the response to the instruction query and information request to the real processor model;

[0129] The actual processor model executes the dynamic instructions during the execution phase to obtain the actual value;

[0130] The real processor model verifies the target value and the actual value during the submission phase, and obtains the verification results.

[0131] Figure 5A schematic diagram of the structure of a computer device provided in one embodiment of this application is shown, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the functions of a computer system for the collaborative evaluation method of exploring the upper limit of processor microarchitecture performance in any of the above embodiments.

[0132] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a computer, causes the computer to perform the functions of a computer system of the collaborative evaluation method for exploring the upper limit of processor microarchitecture performance in any of the above embodiments.

[0133] This application also provides a computer program product containing instructions that, when executed by a computer, cause the computer to perform the functions of a computer system of the collaborative evaluation method for exploring the upper limit of processor microarchitecture performance in any of the above embodiments.

[0134] It is understood that the specific examples in this application are only intended to help those skilled in the art better understand the implementation methods of this application, and are not intended to limit the scope of the invention.

[0135] It is understood that in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not limit the implementation process of the embodiments of this application in any way.

[0136] It is understood that the various implementation methods described in this application can be implemented individually or in combination, and the implementation methods in this application are not limited in this respect.

[0137] Unless otherwise stated, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The term "and / or" as used in this application includes any and all combinations of one or more of the associated listed items. The singular forms "a," "the," and "the" as used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0138] It is understood that the processor in the embodiments of this application can be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method embodiments can be completed by the integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0139] It is understood that the memory in the embodiments of this application may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Specifically, non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may be random access memory (RAM). It should be noted that the memory in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0140] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0141] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the aforementioned method implementations, and will not be repeated here.

[0142] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0143] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0144] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0145] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

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

Claims

1. A method for collaborative evaluation of processor microarchitecture performance ceiling exploration, the method comprising: The method comprises: The real processor model constructs various idealized micro-architecture components according to a collaborative process with the ideal model, and collaboratively evaluates processor micro-architecture performance, the collaborative process comprising: The real processor model sends an instruction query and information request to the ideal model, the instruction query and information request being used to query a target value of a dynamic instruction currently acquired by the real processor model in a fetch stage, the instruction query and information request carrying a memory address of the dynamic instruction; The ideal model executes the dynamic instruction according to the memory address in a normal working state to obtain the target value, and returns the target value as a response to the instruction query and information request to the real processor model; The real processor model allocates a physical register for the target value in a renaming stage, and writes the target value into the physical register; The real processor model marks a state of the physical register as available; The real processor model looks up an instruction dependent on the physical register in a dependency table of a scoreboard; The real processor model marks a dependency counter of the instruction dependent on the physical register as dependent satisfied, so that the instruction dependent on the physical register can be dispatched and transmitted by a dispatcher; The real processor model executes the dynamic instruction to obtain an actual value in an execution stage; The real processor model verifies the target value and the actual value to obtain a verification result in a commit stage.

2. The method of claim 1, wherein, After the ideal model executes the dynamic instruction according to the memory address in the normal working state to obtain the target value, the method further comprises: The ideal model saves a current self snapshot and records a memory track.

3. The method of claim 2, wherein, After the real processor model executes the dynamic instruction to obtain the actual value in the execution stage, the method further comprises: If the real processor model determines a branch prediction error according to the actual value, the real processor model triggers pipeline flushing, sends a recovery signal to the ideal model, the recovery signal carrying a sequence number of a dynamic instruction causing the pipeline to be flushed and a correct jump memory address; The ideal model determines a previous dynamic instruction of the dynamic instruction causing the pipeline to be flushed according to the sequence number of the dynamic instruction causing the pipeline to be flushed; The ideal model recovers a register state and a memory state according to the self snapshot and the recorded memory track saved after the previous dynamic instruction is executed.

4. The method of claim 1, wherein, The method further comprises: If the ideal model detects an exception while executing the dynamic instruction according to the memory address in the normal working state, the ideal model changes a state of a state machine from the normal working state to an exception pause state and stops working until the real processor model starts processing the exception detected by the ideal model and recovers the normal working state; If the dynamic instruction is a system instruction or a privileged instruction, the ideal model changes the state of the state machine from the normal working state to a system or privileged instruction pause state and stops working until the system instruction or the privileged instruction is committed on the real processor model and recovers the normal working state. If the dynamic instruction is an instruction that cannot be executed by the ideal model, the ideal model changes the state of the state machine from the normal working state to a non-speculative instruction stall state and stops working until the real processor model finishes executing the unexecutable instruction and synchronizes the execution result of the unexecutable instruction to the ideal model.

5. The method of claim 4, wherein, The method further comprises: The ideal model checks whether the real processor model is working on an error path before resuming normal working; If the real processor model is working on an error path, the ideal model changes the state of the state machine to an iterative recovery stall state and resumes normal working after receiving a signal for resuming normal working sent by the real processor model.

6. The method of claim 5, wherein, The ideal model checks whether the real processor model is working on an error path before resuming normal working, comprising: The ideal model traverses all in-transit dynamic instructions to obtain branch instructions that have not been executed by the real processor before resuming normal working; The ideal model calculates actual jump destination addresses of the branch instructions that have not been executed by the real processor; If the actual jump destination addresses are inconsistent with predicted jump destination addresses of the real processor, it is confirmed that the real processor model is working on an error path.

7. A collaborative evaluation device for exploring the performance ceiling of processor microarchitecture, characterized in that, The apparatus comprises: A performance evaluation unit configured to control the real processor model to construct various idealized micro-architecture components according to a cooperative process with the ideal model, and cooperatively evaluate the performance of the processor micro-architecture, wherein the cooperative process comprises: The real processor model sends an instruction query and information request to the ideal model, wherein the instruction query and information request is used to query a target value of a dynamic instruction obtained by the real processor model in a fetch stage, and the instruction query and information request carries a memory address of the dynamic instruction; The ideal model executes the dynamic instruction according to the memory address to obtain the target value in a normal working state, and returns the target value as a response to the instruction query and information request to the real processor model; The real processor model allocates a physical register for the target value in a renaming stage, and writes the target value into the physical register; The real processor model marks a state of the physical register as available; The real processor model looks up an instruction dependent on the physical register in a dependency table of a scoreboard; The real processor model marks a dependency counter of the instruction dependent on the physical register as dependent satisfied, so that the instruction dependent on the physical register can be dispatched by a dispatcher; The real processor model executes the dynamic instruction to obtain an actual value in an execution stage; The real processor model verifies the target value and the actual value to obtain a verification result in a commit stage.

8. An electronic device, comprising: The apparatus comprises: A processor and a memory; The processor and the memory are connected, wherein the memory is configured to store a computer program, and the processor is configured to invoke the computer program to execute the method according to any one of claims 1-6.

9. A computer readable storage medium characterized by, The computer readable storage medium stores a computer program, the computer program comprising program instructions which, when executed by a processor, perform the method of any one of claims 1-6.

Images