Risc-v branch predictor closed loop verification method and system

Abstract

The application relates to the technical field of processor verification, and provides a RISC-V branch predictor closed-loop verification method and system, which comprises the following steps: providing a plurality of test modes facing a branch predictor micro-architecture, each test mode corresponds to a branch behavior feature and has a parameterized configuration; receiving a random seed, selecting a target test mode from the plurality of test modes based on the random seed, and determining parameters for the target test mode; generating a corresponding RISC-V assembly test program according to the target test mode and the parameters, so as to perform closed-loop verification on the RISC-V branch predictor. Through the parameterized test mode facing the micro-architecture and the random seed driving mechanism, efficient closed-loop verification is realized, the problem that test excitation randomness is too high or simulation time is too long in the prior art is solved, and the verification efficiency is effectively improved.

Description

Technical Field

[0001] This application relates to the field of chip technology, and more specifically, to a method and system for closed-loop verification of a RISC-V branch predictor. Background Technology

[0002] Currently, in the field of processor chip design, the performance of branch predictors directly affects the processor's execution efficiency. Existing processor branch predictor verification technologies mainly include performance evaluation methods based on benchmark programs, manually written directed assembly tests, and random instruction generators. Among these, methods based on standard benchmark programs such as SPECint2017, while reflecting real-world workloads, involve billions to tens of billions of instructions. Running these in RTL simulations takes weeks to months, forcing performance evaluation to be postponed until after FPGA prototyping or tape-out. This is not only time-consuming but also extremely costly to fix performance defects discovered late in development. General-purpose random instruction generators generate branch patterns that are too random, lacking bias characteristics and historical correlations from real-world workloads. They cannot effectively distinguish the performance differences between predictors of different complexities and cannot systematically cover microarchitectural boundary conditions such as branch target buffer capacity overflow and return address stack depth overflow. Furthermore, existing verification processes separate stimulus generation from the prediction rate baseline, lacking an "expected prediction rate" reference. This prevents engineers from distinguishing between predictor design flaws and the difficulty of the test stimuli themselves, making it difficult to "shift" the verification process to the left. Therefore, there is an urgent need for a method and system that can quickly and effectively evaluate the performance of branch predictors and achieve closed-loop verification in the early stages of chip development. Summary of the Invention

[0003] The purpose of this application is to provide a method and system for closed-loop verification of a RISC-V branch predictor, in order to solve the above-mentioned technical problems.

[0004] In a first aspect, this application provides a method for closed-loop verification of a RISC-V branch predictor, the method comprising:

[0005] It provides multiple test modes for branch predictor microarchitectures, each test mode corresponding to a branch behavior feature and having parameterized configuration;

[0006] Receive a random seed, select a target test mode from multiple test modes based on the random seed, and determine parameters for the target test mode;

[0007] Based on the target test mode and its parameters, a corresponding RISC-V assembly test program is generated to perform closed-loop verification of the RISC-V branch predictor.

[0008] In optional implementations, the plurality of test modes include:

[0009] The first type of test mode is a stress test mode designed for the branch predictor microarchitecture sub-module;

[0010] The second type of test mode is the prediction rate benchmark mode, which is used to reproduce the typical branch behavior characteristics in standard benchmark test programs.

[0011] In an optional implementation, the microarchitectural submodules targeted by the stress test mode include at least one of the following: Branch Target Buffer (BTB), Branch History Table (BHT), Return Address Stack (RAS), Indirect Branch Target Buffer (iBTB), and Pipeline; each stress test mode corresponds to a specific microarchitectural behavior, which includes at least one of the following: BTB capacity overflow, BHT saturation counter hysteresis, RAS deep overflow, and iBTB polymorphic jump.

[0012] The typical branching behavior characteristics reproduced by the prediction rate benchmark pattern are derived from Dhrystone, CoreMark, or SPEC CPU standard benchmark programs.

[0013] The prediction rate benchmark mode includes at least one of the following modes: a re-loop mode for simulating high-biased loop branches; a biased if-else mode for simulating data-dependent conditional branches; a nested loop mode for simulating multi-level loop structures in matrix operations; a correlated branch pair mode for constructing a branch sequence with global historical correlation; a call return mode for testing the return address stack; a periodic mode for testing historical pattern matching; and a phase change branch mode for testing the predictor's adaptation speed to changes in branch behavior.

[0014] In an optional implementation, generating the corresponding RISC-V assembly test program based on the target test mode and its parameters includes:

[0015] Based on the random seed, while generating the RISC-V assembly test program, a branch execution trajectory consistent with the logic of the RISC-V assembly test program is generated simultaneously.

[0016] The branch execution trajectory is input into multiple preset branch predictor software models for simulation analysis, and the theoretical prediction rate data corresponding to each model is output to form an ideal prediction rate report associated with the assembly test program.

[0017] In an optional implementation, the multiple preset branch predictor software models include multiple models with a stepped distribution of complexity, wherein the branch predictor software models include: Bimodal predictor model, Gshare predictor model, Tournament predictor model, TAGE predictor model, or TAGE-lite predictor model.

[0018] In an optional implementation, it further includes:

[0019] The RISC-V assembly test program was run in an RTL simulation environment to obtain the actual branch misprediction rate.

[0020] The actual branch misprediction rate is compared with the theoretical prediction rate data in the ideal prediction rate report, and the branch predictor design is determined to meet the performance requirements based on the comparison results.

[0021] In an optional implementation, selecting the target test mode from the plurality of test modes based on the random seed further includes:

[0022] Based on the received operating mode parameters, select a test mode from the corresponding test mode set;

[0023] The operating modes include:

[0024] The stress mode is selected only from the first type of test modes;

[0025] The predict mode is selected only from the second type of test modes;

[0026] The mixed mode is selected from the combined set of the first type of test mode and the second type of test mode.

[0027] In an optional implementation, the mixed mode includes randomly inserting stress test modes between prediction rate benchmark modes to generate a mixed test sequence for testing the branch predictor's ability to recover after being subjected to extreme microarchitectural stress.

[0028] In an optional implementation, during the process of selecting a target test mode from multiple test modes based on the random seed, the generated test mode sequence and parameter configuration are completely consistent under the same random seed input, thereby ensuring the repeatability of the verification results.

[0029] Secondly, this application provides a RISC-V branch predictor closed-loop verification system, the system comprising:

[0030] The pattern library provides multiple test patterns for branch predictor microarchitectures, each corresponding to a branch behavior feature and having parameterized configuration.

[0031] A receiving module is configured to receive a random seed, select a target test mode from a plurality of test modes based on the random seed, and determine parameters for the target test mode;

[0032] The generation module is used to generate a corresponding RISC-V assembly test program based on the target test mode and its parameters, so as to perform closed-loop verification of the RISC-V branch predictor.

[0033] In optional implementations, the plurality of test modes include:

[0034] The first type of test mode is a stress test mode designed for the microarchitecture sub-modules of the branch predictor; wherein, the microarchitecture sub-modules targeted by the stress test mode include at least one of the following: branch target buffer (BTB), branch history table (BHT), return address stack (RAS), indirect branch target buffer (iBTB), and pipeline; each stress test mode corresponds to a specific microarchitecture behavior, which includes at least one of the following: BTB capacity overflow, BHT saturation counter hysteresis, RAS depth overflow, and iBTB polymorphic jump;

[0035] The second type of test mode is a prediction rate benchmark mode used to reproduce typical branch behavior characteristics in standard benchmark programs. The typical branch behavior characteristics reproduced by the prediction rate benchmark mode are derived from Dhrystone, CoreMark, or SPEC CPU standard benchmark programs. The prediction rate benchmark mode includes at least one of the following modes: a recursive loop mode for simulating high-biased loop branches; a biased if-else mode for simulating data-dependent conditional branches; a nested loop mode for simulating multi-level loop structures in matrix operations; a correlated branch pair mode for constructing branch sequences with global historical correlation; a call return mode for testing the return address stack; a periodic mode for testing historical pattern matching; and a phase change branch mode for testing the predictor's adaptation speed to changes in branch behavior.

[0036] In an optional implementation, the generation module is specifically used for:

[0037] Based on the random seed, while generating the RISC-V assembly test program, a branch execution trajectory consistent with the logic of the RISC-V assembly test program is generated simultaneously.

[0038] The branch execution trajectory is input into multiple preset branch predictor software models for simulation analysis, and the theoretical prediction rate data corresponding to each model is output to form an ideal prediction rate report associated with the assembly test program.

[0039] In an optional implementation, the module further includes a running module for:

[0040] The RISC-V assembly test program was run in an RTL simulation environment to obtain the actual branch misprediction rate.

[0041] The actual branch misprediction rate is compared with the theoretical prediction rate data in the ideal prediction rate report, and the branch predictor design is determined to meet the performance requirements based on the comparison results.

[0042] In an optional implementation, the receiving module is specifically used for:

[0043] Based on the received operating mode parameters, select a test mode from the corresponding test mode set;

[0044] The operating modes include:

[0045] The stress mode is selected only from the first type of test modes;

[0046] The predict mode is selected only from the second type of test modes;

[0047] The mixed mode is selected from the combined set of the first type of test mode and the second type of test mode.

[0048] In an optional implementation, the mixed mode includes randomly inserting stress test modes between prediction rate benchmark modes to generate a mixed test sequence for testing the branch predictor's ability to recover after being subjected to extreme microarchitectural stress.

[0049] In an optional implementation, during the process of selecting a target test mode from multiple test modes based on the random seed, the generated test mode sequence and parameter configuration are completely consistent under the same random seed input, thereby ensuring the repeatability of the verification results.

[0050] This application provides a closed-loop verification method and system for RISC-V branch predictors. By designing a dedicated test mode for the microarchitecture of the branch predictor, the branch behavior characteristics in the real workload are extracted. While ensuring the effectiveness of the test, the simulation time is greatly reduced, enabling performance verification to be performed in the early stage of RTL simulation, thus realizing the "left shift" of the verification process.

[0051] In addition, by using a random seed-driven dual-channel parallel generation mechanism, assembly test programs and branch execution trajectories are generated synchronously. The theoretical prediction rate is calculated using multiple software models as the expected baseline, which solves the problem of stimulus and baseline separation in existing technologies. This enables engineers to quickly locate predictor design defects and performance bottlenecks.

[0052] Furthermore, the flexible configuration of three operating modes—stress, predict, and mixed—unifies the tool process for functional stress testing and performance evaluation testing, improves verification efficiency, and reduces the risk and cost of discovering performance problems and fixing them in the later stages of chip development. Attached Figure Description

[0053] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0054] Figure 1 This is a schematic flowchart of a RISC-V branch predictor closed-loop verification method according to an embodiment of this application;

[0055] Figure 2 This is a schematic diagram of another RISC-V branch predictor closed-loop verification method according to an embodiment of this application;

[0056] Figure 3 This is a schematic diagram of another RISC-V branch predictor closed-loop verification method according to an embodiment of this application;

[0057] Figure 4 This is a schematic diagram of a RISC-V branch predictor closed-loop verification system according to an embodiment of this application;

[0058] Figure 5 This is a schematic diagram of an electronic device structure according to an embodiment of this application. Detailed Implementation

[0059] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0060] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in 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, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0061] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

[0062] Example 1:

[0063] This embodiment provides a closed-loop verification method for RISC-V branch predictors. This method aims to address the problems in existing technologies where excessively high randomness of test stimuli leads to invalid verification, or excessively long simulation times in benchmark programs cause verification delays. It achieves efficient closed-loop verification by constructing a parameterized test pattern library oriented towards microarchitecture and utilizing random seeds to drive the generation of deterministic test programs.

[0064] like Figure 1 As shown, the method specifically includes the following steps:

[0065] Step S100 provides multiple test modes for branch predictor microarchitecture, each test mode corresponding to a branch behavior feature and having parameterized configuration.

[0066] Specifically, the test mode is a pre-designed instruction sequence template used to elicit specific behaviors of the branch predictor. Unlike the random instruction generators commonly used in the prior art, the test modes in this embodiment are designed "microarchitecture-oriented," meaning that each mode specifically simulates or triggers the behavior of specific sub-modules within the branch predictor (such as the branch target buffer (BTB), branch history table (BHT), etc.). For example, one test mode might be specifically designed to generate a large number of branch instructions with different jump targets to test the capacity limitations of the BTB; another test mode might be designed to generate a specific pattern of jump direction sequences to test the prediction accuracy of the saturation counter in the BHT.

[0067] More importantly, each test pattern has parameterized configuration. This means that certain key variables within a test pattern are not fixed constants, but rather variables that can be adjusted through parameters. Parameterized configuration includes, but is not limited to: the number of loop iterations, the branch jump bias ratio, the density of branch instructions, the address range of the jump target, and the nesting depth. For example, for a test pattern simulating a loop branch, the number of loop iterations can be configured to 10, 100, or 1000; for a test pattern simulating a conditional branch, the probability of jumping to "Taken" can be configured to 50%, 90%, or 99%. Through parameterized configuration, the same test pattern template can generate countless specific test instances, thereby greatly expanding the test coverage and avoiding the problems of fixed parameters and narrow coverage when manually writing targeted test cases. This design makes test incentives both targeted (for specific microarchitectural behaviors) and diverse (covering boundary conditions through parameter changes).

[0068] Step S200: Receive a random seed, select a target test mode from multiple test modes based on the random seed, and determine parameters for the target test mode.

[0069] Specifically, the random seed is the core input driving the entire test generation process. The system receives an integer input from the user as the random seed and uses it to initialize a pseudo-random number generator (RNG). The RNG generates a series of seemingly random but actually deterministic numerical sequences based on the seed. The system uses these random numerical sequences to perform two core actions: first, selecting a target test pattern from the test pattern library; and second, determining specific parameter values ​​for the selected target test pattern.

[0070] For example, the system can determine the type of test mode based on the first random number generated by the RNG, and determine parameters such as the number of iterations and bias ratio for that mode based on subsequent random numbers. This "random seed driven" mechanism has a dual technical effect: First, due to the characteristics of the pseudo-random number generator, as long as the input random seed is the same, the subsequently generated random number sequence will be exactly the same, thus ensuring that the selected test mode sequence and its parameter configuration are completely consistent under the same seed input. This provides a basis for verifying the repeatability of the results, making it easier for engineers to reproduce and debug when problems are discovered. Second, by changing the random seed, the system can quickly generate a large number of different test scenarios, realizing the automated generation and broad coverage of test stimuli, and solving the problem of low efficiency in manually writing test cases.

[0071] Step S300: Generate the corresponding RISC-V assembly test program according to the target test mode and its parameters to perform closed-loop verification of the RISC-V branch predictor.

[0072] Specifically, after determining the target test mode and its specific parameters, the system calls a pre-defined assembly code generation function to instantiate the abstract test mode template into a concrete sequence of RISC-V assembly instructions. The generated assembly test program includes branch instructions conforming to the RISC-V instruction set architecture specification (such as BEQ, BNE, BLT, JAL, etc.) and necessary auxiliary code (such as data segment definitions, register initialization code, etc.). This assembly test program can be assembled and linked by a standard RISC-V cross-compilation toolchain and ultimately run on an RTL simulation environment or FPGA prototype.

[0073] The RISC-V assembly test program generated here is a crucial step in closed-loop verification. "Closed-loop verification" refers to a test process that includes not only inputting stimuli into the design under test (DUT) but also determining the expected output results. Although this step primarily describes the generation of the assembly program, its design aims to subsequently obtain the actual running data of the branch predictor and compare it with the expected theoretical data (this comparison process will be described in detail in subsequent embodiments), thus forming a complete closed loop from stimulus generation and simulation execution to result determination. Through the above steps, this embodiment achieves rapid generation of effective test stimuli during the RTL simulation stage, laying the foundation for early performance verification of the branch predictor.

[0074] Next, the specific classification and definition of test modes will be described in detail. In some embodiments, the multiple test modes may include: a first type of test mode, which is a stress test mode designed for the branch predictor microarchitecture submodule; and a second type of test mode, which is a prediction rate benchmark mode used to reproduce typical branch behavior characteristics in a standard benchmark program.

[0075] Specifically, the first type of test mode focuses on functional correctness and boundary stress verification. Its core purpose is to construct extreme or specific branch instruction sequences to detect whether the various microarchitectural sub-modules within the branch predictor can still function properly when faced with design boundary conditions. This type of mode is not intended to simulate the performance of real applications, but rather to actively "attack" the weak points of the predictor to expose potential design flaws.

[0076] The second type of test mode focuses on performance evaluation and verification. Its purpose is to highly condense the branch behavior characteristics of the real workload into a very short instruction sequence, thereby quickly evaluating the predictor's performance level during the RTL simulation phase without running a time-consuming full benchmark program. By dividing the test modes into these two categories, this embodiment achieves a unified framework for functional verification and performance verification. Engineers can flexibly choose the testing focus according to the current verification stage, effectively improving verification efficiency.

[0077] For the first type of test mode, the microarchitectural submodules targeted by the stress test mode include at least one of the following: Branch Target Buffer (BTB), Branch History Table (BHT), Return Address Stack (RAS), Indirect Branch Target Buffer (iBTB), and Pipeline; each stress test mode corresponds to a specific microarchitectural behavior, which includes at least one of the following: BTB capacity overflow, BHT saturation counter hysteresis, RAS deep overflow, and iBTB polymorphic jump.

[0078] Specifically, the stress test mode for BTB capacity overflow involves generating different jump target addresses far exceeding the BTB entry capacity through parameterized configuration, forcing BTB to frequently replace entries. This verifies the correctness of the BTB replacement algorithm and whether there are performance drops caused by conflicts or missing entries. The stress test mode for BHT saturation counter hysteresis involves constructing specific jump direction sequences, such as repeatedly switching rapidly between "strong jumps" and "strong no jumps," to test whether there is hysteresis or error in the state machine transition of the 2-bit saturation counter, verifying the predictor's sensitivity to branch direction changes. For the RAS deep overflow mode, the overflow handling logic of the return address stack is stress-tested using deeply nested function call instructions to verify whether the prediction behavior meets design expectations when RAS is full or empty. For the iBTB polymorphic jump mode, a scenario is constructed where the same indirect jump instruction points to multiple different target addresses to verify iBTB's ability to handle polymorphism. These stress test modes are highly configurable. For example, parameters such as the number of loops, address span, and nesting depth can be dynamically adjusted using random seeds, thus ensuring both specificity and test diversity.

[0079] For the second type of test mode, the typical branching behavior characteristics reproduced by the prediction rate benchmark mode are derived from Dhrystone, CoreMark, or SPEC CPU standard benchmark programs. The prediction rate benchmark mode includes at least one of the following modes: re-loop mode, used to simulate high-bias loop branches; biased if-else mode, used to simulate data-dependent conditional branches; nested loop mode, used to simulate multi-level loop structures in matrix operations; correlated branch pair mode, used to construct branch sequences with global historical correlation; call return mode, used to test the return address stack; periodic mode, used to test historical pattern matching; and phase change branch mode, used to test the predictor's adaptation speed to changes in branching behavior.

[0080] Specifically, the recursive loop mode simulates the main loop structure commonly found in benchmark programs such as Dhrystone or CoreMark. It is characterized by an extremely high number of loop iterations and a very high bias rate in the jump direction; for example, 99% of the jumps are to Taken. This mode is used to verify the predictor's ability to capture strongly biased branches. The biased if-else mode simulates the uneven branch distribution caused by data dependencies in real programs; for example, it has an 80% probability of taking the if branch and a 20% probability of taking the else branch. This is used to test the predictor's accuracy in predicting asymmetric probability branches. The nested loop mode simulates multi-level loop structures in matrix operations, used to verify the predictor's ability to manage historical information in multi-level nested loop scenarios. The correlated branch pair mode carefully constructs a branch sequence with global historical correlation; for example, the result of the previous branch affects the jump direction of the next branch. This is specifically used to test the effectiveness of advanced predictor algorithms such as Gshare or TAGE that rely on the Global History Register (GHR). Phase-change branching modes simulate abrupt changes in branching behavior during program execution, such as a sudden switch from a long-term Taken state to a Not-Taken state. This is used to test the predictor's adaptability and recovery capabilities in response to changes in behavior patterns. Through these carefully designed prediction rate benchmark modes, this embodiment can reproduce prediction rate distribution characteristics comparable to running large benchmark programs such as SPEC CPU within a very short simulation time, thus providing a reliable reference baseline for performance evaluation in the RTL phase.

[0081] In some embodiments, the specific process of generating a RISC-V assembly test program based on the target test mode and its parameters, and the mechanism for generating an ideal prediction rate report, can be implemented based on the following scheme. Specifically, generating the corresponding RISC-V assembly test program based on the target test mode and its parameters may include: simultaneously generating branch execution trajectories logically consistent with the RISC-V assembly test program using a random seed; inputting the branch execution trajectories into multiple preset branch predictor software models for simulation analysis; outputting the theoretical prediction rate data corresponding to each model; and forming an ideal prediction rate report associated with the assembly test program.

[0082] Specifically, this embodiment employs a "dual-channel parallel generation" mechanism to ensure strict logical consistency between the assembly test program and the branch execution trajectory. The core logic of this mechanism lies in the precise control of the pseudo-random number generator (RNG) state. Since the assembly code generation process (such as determining the number of loops and branch bias ratios) consumes random numbers, and the generation of branch trajectories also depends on these parameters, if the RNG is called separately in two independent generation processes, even slight differences in the order or number of calls can easily lead to a mismatch between the generated trajectory and the assembly code. To solve this problem, this embodiment designs the following steps:

[0083] First, before generating the code for a specific target test mode, save a snapshot of the current RNG state, denoted as st0. At this point, RNG has not yet consumed any random numbers for that mode.

[0084] Subsequently, the assembly generation logic is executed in channel A. The assembly generation function corresponding to this test mode is called. This function obtains a random number from the RNG to determine the specific parameter configuration (e.g., 100 loop iterations, 90% jump probability) and generates a RISC-V assembly code snippet accordingly. During this process, the state of the RNG changes and is updated to st1.

[0085] Next, the execution trajectory generation logic for channel B is entered. The key is to first forcibly restore the RNG's state to the previously saved snapshot st0. Then, the trajectory generation function corresponding to this test mode is called. Since the RNG is in the exact same initial state st0 as channel A, the random number sequence consumed by the trajectory generation function will be completely identical to that of channel A, thus deterministically generating branch execution trajectories that correspond one-to-one with the assembly code logic. This trajectory records the execution result of each branch instruction, in a format such as [(pc address, jump result, branch type), ...].

[0086] Finally, the RNG state is restored to st1 to ensure that the generation of the next test mode can continue the previous random number sequence and maintain the overall generation continuity. Through this "state snapshot - channel A generation - state restoration - channel B generation" mechanism, this embodiment achieves synchronous generation of assembly stimuli and theoretical trajectories without introducing additional random number consumption. This ensures a strict mathematical correspondence between the ideal prediction rate report and the actual test program, providing a reliable data foundation for subsequent closed-loop verification.

[0087] For generating the ideal prediction rate report, this embodiment pre-sets multiple branch predictor software models. These models include multiple models with a stepped distribution of complexity. Among them, the branch predictor software models include: Bimodal predictor model; Gshare predictor model; Tournament predictor model; TAGE or TAGE-lite predictor model.

[0088] Specifically, these four models represent different stages and complexity levels in the development of branch prediction technology, forming a performance evaluation ladder. The Bimodal predictor model is the most basic form, using only the low-order bits of the program counter (PC) to index a 2-bit saturated counter table, lacking utilization of the global history, and thus having the lowest complexity. The Gshare predictor model, building upon this, introduces a Global History Register (GHR), indexing the counter table by XORing the PC with the GHR, enabling it to capture global dependencies between branches, thus increasing complexity. The Tournament predictor model is a hybrid predictor, containing both Bimodal and Gshare sub-predictors and introducing a selector table to dynamically select the better-performing sub-predictor, further increasing complexity. The TAGE or TAGE-lite predictor model is an advanced predictor architecture commonly used in high-performance processors. Through multiple tagged components with different history lengths, it can capture long-distance branch dependencies with extreme accuracy, representing a high level of complexity in current predictor design.

[0089] During simulation analysis, the generated branch execution trajectories are input one by one into the four models for simulation. Each model independently maintains its own prediction state (such as counter values, history register values, etc.) and predicts each branch instruction in the trajectory. The predictions are then compared with the actual jump results in the trajectory, and the number of correct and incorrect predictions is counted. Finally, the theoretical prediction rate data for each model under this specific test program is calculated and summarized into an ideal prediction rate report. This report not only provides numerical values ​​for prediction accuracy but also reveals the stress characteristics of the current test program on the predictor microarchitecture through performance differences between different models. For example, if the prediction rate of the Gshare model is significantly higher than that of Bimodal, it indicates that the test program contains strong global historical correlations; if the prediction rate of the TAGE model is significantly higher than that of other models, it indicates that the test program contains complex long-range patterns. This tiered model layout allows engineers to quickly determine the performance level achieved by the branch predictor design to be verified based on the position of the actual prediction rate obtained from RTL simulation within the tier, thus enabling precise location of design flaws.

[0090] In some embodiments, the determination logic for verifying the closed loop and the configuration method for the test run mode can be implemented through the following scheme: run the RISC-V assembly test program in the RTL simulation environment to obtain the actual branch misprediction rate; compare the actual branch misprediction rate with the theoretical prediction rate data in the ideal prediction rate report, and determine whether the branch predictor design meets the performance requirements based on the comparison results.

[0091] Specifically, the core of closed-loop verification lies in "expectation and determination." After generating the assembly test program and the ideal prediction rate report, the assembly program is compiled into a binary image and loaded into an RTL simulation environment (such as VCS or Xcelium) for execution. During the simulation, the number of correct and incorrect predictions by the branch predictor in the actual hardware model is counted in real time through hardware performance counters or dedicated monitoring logic, thereby calculating the actual branch misprediction rate.

[0092] The judgment logic is not a simple threshold comparison, but rather based on an established ladder-like model baseline. The actual misprediction rate is compared with the theoretical data in the report from multiple dimensions: if the actual value is close to the theoretical value of the TAGE model, it indicates that the design under test has reached the level of a high-performance predictor; if the actual value is only close to the theoretical value of the Bimodal model, it indicates that the advanced prediction mechanism in the design may not be effective; if the actual value is significantly lower than the baseline of the Bimodal model, it often means that there is a functional defect. Through this comparison, engineers can not only determine whether the design meets the standards, but also quickly locate the performance bottleneck, achieving a closed loop from "discovering the problem" to "locating the problem".

[0093] This embodiment provides a flexible configuration mechanism for selecting test modes. Selecting a target test mode from multiple test modes based on a random seed further includes: selecting a test mode from a corresponding set of test modes according to received running mode parameters; the running modes include: stress mode, selected only from the first type of test modes; predict mode, selected only from the second type of test modes; and mixed mode, selected from a combined set of the first and second types of test modes.

[0094] Specifically, different verification phases have different requirements for test stimuli. In the early functional verification phase of chip design, engineers are more concerned with the correctness of each submodule of the branch predictor under boundary conditions, and the stress mode can be used at this time. The system will select only the target mode from the stress test mode pool to focus on testing extreme scenarios such as BTB overflow and RAS overflow. In the performance evaluation phase, engineers need to evaluate the accuracy level of the predictor, and the predict mode can be used at this time. The system selects only the prediction rate benchmark mode to simulate the branch behavior characteristics of real workloads. The mixed mode provides a comprehensive verification method. It breaks down the boundaries between functional testing and performance testing, randomly selecting from the merged mode pool, thus taking into account both stress and performance.

[0095] Specifically, the mixed mode includes: randomly inserting stress test modes between prediction rate benchmark modes to generate mixed test sequences for testing the branch predictor's ability to recover after being subjected to extreme microarchitectural stress.

[0096] Specifically, this is a more advanced verification scenario that simulates the dynamic process of "normal load - sudden anomaly - recovery" in real program operation. For example, after a nested loop pattern simulating matrix operations (baseline pattern), a stress test pattern targeting BTB capacity (stress pattern) might be inserted immediately, forcing the predictor's internal state to fluctuate drastically, followed by a regular loop pattern. This construction method is used to test the predictor's "recovery capability" after being subjected to extreme microarchitectural stress. If the predictor design is flawed, it may not be able to recover to normal prediction levels for a long time after the stress pattern ends, causing a significant drop in the prediction rate of the subsequent baseline pattern. Through mixed patterns, engineers can discover hidden problems that only surface during stress scenario transitions, greatly improving the completeness of verification.

[0097] Furthermore, this embodiment emphasizes the repeatability of the verification process. During the selection of the target test mode from multiple test modes based on a random seed, the generated test mode sequence and parameter configuration are completely identical under the same random seed input, thus ensuring the repeatability of the verification results.

[0098] Specifically, the determinism of the pseudo-random number generator is fundamental to this feature. In the chip verification process, when engineers discover that a specific seed has triggered a design flaw, they need to be able to accurately reproduce the test scenario for debugging. Since all random decisions (including mode selection, parameter determination, and assembly instruction generation) are uniquely determined by the seed, as long as the same seed is input, the generated assembly code, branch trajectories, and even the ideal prediction rate report will be exactly the same. This determinism eliminates the common pain point of "non-reproducibility" in random testing, enabling the method provided in this embodiment to be seamlessly integrated into the continuous integration (CI) process as a standard tool for performance regression testing.

[0099] As an example, such as Figure 2 As shown, this method can be implemented through the following steps:

[0100] Input parameters and initialization, corresponding Figure 2 The upper left part.

[0101] Input parameters: Users enter five key parameters via the command line:

[0102] seed S: A random seed (integer) that determines the determinism of the entire test generation process.

[0103] mode M: Run mode (stress / predict / mixed), determines which test modes to select.

[0104] red-line R: Prediction rate red line (floating-point number, such as 99.0%), used to determine whether a test passes.

[0105] num-tests N: The number of tests to generate.

[0106] no-tage: Optional parameter used to control whether the TAGE advanced predictor model is enabled.

[0107] (101), Seed random number generator: Initialize the pseudo-random number generator RNG =Random(S) using the input seed S.

[0108] Key feature: As long as the seed is the same, all subsequent random number sequences are completely deterministic and repeatable.

[0109] Pattern selection and sequence generation correspond to the upper middle part of the diagram.

[0110] (102) Mode selection: Based on the mode parameter input by the user, determine which mode to select from the mode pool.

[0111] (103), Weight Pool: It has three preset mode pools with weights:

[0112] STRESS(37): Includes 37 stress test modes (for microarchitecture units such as BTB, BHT, and RAS).

[0113] PREDICT(9): Includes 9 predictive rate benchmark test modes (simulating real workload characteristics).

[0114] ALL(46): The combination of the two above (37+9=46).

[0115] Each pattern has a weight, and patterns with higher weights are more likely to be selected.

[0116] (104) Pattern sequence generation: Call RNG.choices(pool, weights, k=N) to randomly select N patterns from the selected pattern pool according to the weights to form the pattern sequence [P1, P2, ..., PN].

[0117] Each pattern is assigned a unique identifier uid_i.

[0118] Dual-channel parallel generation, corresponding Figure 2 (The middle loop part).

[0119] This is the most critical technical step in this application, ensuring that the assembly code and the branch traces correspond strictly one-to-one.

[0120] Iterate through each pattern Pi:

[0121] Enter the loop and process each pattern in the pattern sequence in turn.

[0122] Save RNG state (st0):

[0123] Before processing the current mode Pi, save a snapshot of the current RNG state, denoted as st0 = getstate().

[0124] Branch 1: (105a), Assembly generation channel:

[0125] Call the assembly generation function gen_func() for the current mode.

[0126] This function consumes random numbers from the RNG (currently in state st0) to determine the specific parameters of the mode (such as the number of loops, the bias ratio, etc.).

[0127] Output: (106), an assembly code snippet, which is a RISC-V instruction that can be run in RTL simulation.

[0128] At this point, RNG's status has been updated (because a random number was consumed), but the system internally records the new status.

[0129] Branch 2: (105b), Trajectory Generation Channel:

[0130] Restore RNG's status to the previous st0.

[0131] Call the trajectory generation function `trace_func()` for the current mode.

[0132] Since RNG starts from the same st0, the random number sequence consumed inside trace_func is exactly the same as that in gen_func.

[0133] Output: Branch trace (107), in the format [(pc, taken, type), ...], which precisely records the program counter, whether a jump occurred, and the branch type (condition / call / return / jump) for each branch instruction.

[0134] Status recovery:

[0135] After processing the current mode, the system restores the RNG state to the state after the assembly was completed (although not shown in the figure) to ensure that the random number sequence of the next mode Pi+1 is not affected by the trajectory generation of the current mode.

[0136] Post-processing and output, corresponding Figure 2 The right and bottom sides.

[0137] (110), Assembly and Output:

[0138] The assembly code snippets generated by all modes are concatenated and wrapped with necessary initialization code, stack space, exception handling, etc.

[0139] Final output file 1: Test assembly file (.S). This file can be run directly in the RTL simulator.

[0140] (109) Prediction rate analysis engine: inputs all branch trajectories collected in step (107) into the multi-model parallel simulator.

[0141] The simulator includes four software predictor models with increasing complexity: Bimodal 2K; Gshare 4K; Tournament; and TAGE-lite.

[0142] Each model runs independently, calculating the theoretical prediction accuracy on that specific branch trajectory.

[0143] Based on the user-defined red line judgment rules (such as whether the accuracy rate is ≥99.0%), determine whether the trajectory passes the verification.

[0144] (111), Ideal Predictability Report Output:

[0145] The results of the multi-model analysis are formatted and output as file 2: Ideal Predictive Rate Report (.txt).

[0146] The report includes a detailed analysis of each pattern, the overall accuracy of each model, and a conclusion on whether the red line has been crossed.

[0147] As another example, such as Figure 3 As shown, the closed-loop verification method for RISC-V branch predictors driven by random seeds specifically includes the following steps:

[0148] Step S301: Obtain user input parameters.

[0149] Users can enter the following parameters via the command line:

[0150] seed: A random seed (integer) that determines the determinism of the entire test generation process;

[0151] mode: Run mode (stress / predict / mixed), determines which types of test modes to select;

[0152] num_tests: Number of tests (integer), determines how many test patterns to generate;

[0153] red_line: Prediction rate red line (floating-point number), used to determine whether the test passes;

[0154] no_tage: Optional parameter, controls whether the TAGE advanced predictor model is enabled.

[0155] Step S302: Initialize environment variables.

[0156] The pseudo-random number generator RNG = Random(seed) can be initialized using the input seed; key feature: the same seed will always produce the exact same random number sequence, ensuring the repeatability of the verification results.

[0157] Step S303: Determine the selected mode pool based on mode.

[0158] Based on the user's selected operating mode, determine which mode pool to select the test mode from:

[0159] Stress mode: Mode pool = STRESS (37 stress test modes)

[0160] predict patterns: Pattern pool = PREDICT (9 prediction rate benchmark patterns)

[0161] Mixed mode: Mode pool = ALL_RESTRICTED (a combined set of 46 modes)

[0162] Step S304: Randomly select N test modes.

[0163] Call RNG.choices(pattern_pool, weights, k=N) to randomly select N patterns from the selected pattern pool based on their weights.

[0164] Each mode has a weight, and modes with a weight of 0 are not selected by default.

[0165] Output: Pattern sequence [P1, P2, ..., P n Each pattern corresponds to a unique identifier.

[0166] Step S305: Traverse each pattern Pi and execute the core generation logic.

[0167] For each pattern Pi in the pattern sequence, the system performs the following sub-steps:

[0168] S3051, saves a snapshot of RNG's status.

[0169] st0 = RNG.getstate(), saves the current RNG state.

[0170] S3052, Channel A — Assembly code generation.

[0171] Call the assembly generation function gen_func(RNG, uid_i, params) for this mode;

[0172] Consume random numbers from RNG to determine mode parameters (such as loop count, bias ratio, LFSR seed, etc.).

[0173] Output: RISC-V assembly code snippet;

[0174] Record the new state after RNG is consumed: st1 = RNG.getstate().

[0175] S3053, Channel B - Branch Trajectory Generation.

[0176] Restore the RNG state to st0 (i.e., the state before channel A was executed).

[0177] Call the trajectory generation function trace_func(RNG, uid_i, params) for this mode;

[0178] Since RNG starts from the exact same state st0, the random number sequence consumed inside trace_func is exactly the same as that in gen_func;

[0179] Output: Branch execution path, in the format [(pc, taken, type), ...], where:

[0180] pc: Virtual program counter for branch instructions;

[0181] taken: Whether to jump during this execution (True / False);

[0182] type: Branch type (cond / call / ret / jump).

[0183] S3054, RNG is back in form.

[0184] Restore RNG's state to st1 to ensure P in the next mode. i+1 The random number sequence is unaffected by channel B;

[0185] Step S306: Assembly and assembly.

[0186] Concatenate the assembly code snippets of all modes in the order they were generated;

[0187] Wrap the following structure to output the final .S test assembly file:

[0188] The tohost communication area (simulation environment termination protocol), stack space (64KB), BSS segment (scratch_area), data segment (test_num + dedicated data tables for each mode), and code segment (register initialization, stack pointer setting, CSR initialization, assembly code for each mode, test_pass / test_fail exit logic, Helper Functions, Trap Handler).

[0189] Step S307: Multi-model prediction rate analysis.

[0190] Perform the following processing on all branch trajectories collected in step S303:

[0191] S3071, trajectory filtering.

[0192] Extract only the trajectory records where type == 'cond' (conditional branch), ignoring unconditional jumps, function calls, and returns.

[0193] S3072, multi-model parallel simulation.

[0194]

[0195] The filtered trajectories are then input into the following four branch predictor software models for line-by-line simulation:

[0196] Each model independently maintains its own state, and the output is:

[0197] accuracy: Number of correct predictions / Total number of branches;

[0198] mispred_rate: 1 - accuracy;

[0199] The correct / total / mispred count.

[0200] S3073, Pattern-by-pattern analysis.

[0201] For each model Pi, calculate independently: total number of conditional branches, proportion of Taken, prediction accuracy of each model, and accuracy of the best model (the highest value among the four models).

[0202] Red line judgment: Optimal accuracy ≥ red_line → PASS, otherwise FAIL.

[0203] S3074, Aggregation analysis.

[0204] The trajectories of all prediction rate baseline models (non-stress test models) are merged to calculate the overall prediction rate, which is then compared with the red line.

[0205] Step S308: Output the Ideal Predictive Rate Report. Output the analysis results from step S307 as a plain text .txt report file, with the following format:

[0206] Report header: Seed value, operating mode; red line setting (e.g., accuracy > 99.00%, i.e., mispred < 1.00%); target description (Dhrystone / CoreMark / SPECint2017 mispred < 1%); list of predictor models used.

[0207] Pattern-by-pattern table: Pattern name, number of branches, T-Ratio, Bimodal, Gshare, Tournament, TAGE, PASS / FAIL.

[0208] Aggregate statistics: overall prediction accuracy and misprediction rate of each model; whether each model passes the red line.

[0209] Final conclusion: X patterns are below the red line / all patterns pass the red line.

[0210] Step S309: RTL simulation and comparative verification.

[0211] Run the .S test assembly file in the RTL simulation environment to obtain the actual branch misprediction rate;

[0212] Directly compare the actual misprediction rate with the theoretical prediction rate data in the .txt report:

[0213] The fact that the actual value is close to the TAGE theoretical value indicates that the BP design has reached the TAGE level and the performance is qualified.

[0214] The fact that the actual value is close to the theoretical value of Gshare indicates that the BP design has not met expectations and the advanced predictor logic needs to be investigated.

[0215] A value lower than the Bimodal theoretical value indicates that the BP has a serious functional defect.

[0216] like Figure 4 As shown, this embodiment provides a RISC-V branch predictor closed-loop verification system. This system aims to implement the closed-loop verification method described in the preceding embodiments through a modular architecture design, transforming abstract verification logic into concrete hardware or software functional entities. The system mainly comprises three core parts: a pattern library 401, a receiving module 402, and a generation module 403. These modules interact through data interfaces to collaboratively generate and output test stimuli.

[0217] Pattern library 401 is specifically used to provide multiple test patterns for branch predictor microarchitectures, each test pattern corresponding to a branch behavior feature and having parameterized configuration.

[0218] Specifically, the pattern library 401 serves as the data foundation of the entire verification system, internally storing a set of pre-designed test patterns. These test patterns are not fixed sequences of instructions, but rather templated structures containing variable parameters. In the system architecture, the pattern library 401 can manifest as a non-volatile storage area, a database, or a collection of configuration files. Each entry in the pattern library 401 records the generation logic for specific branch behavior characteristics, such as pattern templates for BTB overflows or loop branches. When the system runs, the pattern library 401 responds to external call commands, outputting the corresponding test pattern definitions and their parameterized interfaces for use by subsequent modules. It should be understood that the physical form of the pattern library 401 can be diverse, ranging from a local file system to a database on a remote server, as long as it can provide a stable pattern reading service.

[0219] The receiving module 402 is specifically used to receive a random seed, select a target test mode from multiple test modes based on the random seed, and determine parameters for the target test mode.

[0220] Specifically, the receiving module 402 is the interface unit for the system to interact with the user or other external control logic. Its main responsibility is to acquire the input data required to drive the verification process and execute preliminary decision logic. The receiving module 402 obtains the random seed provided by the user through standard input interfaces (such as command-line parameters, API calls, or graphical interface controls). Subsequently, the receiving module 402 integrates the control logic of a pseudo-random number generator (RNG), initializes the RNG using the seed, and performs the operation of selecting a target test mode from the mode library 401 based on the random number sequence generated by the RNG. At the same time, the receiving module 402 is also responsible for parsing and determining the specific parameter values ​​of each target test mode, such as the number of loops and the jump probability. This process realizes the transformation from unordered random input to ordered test configuration, providing a deterministic blueprint for subsequent code generation.

[0221] The generation module 403 is specifically used to generate a corresponding RISC-V assembly test program based on the target test mode and its parameters, so as to perform closed-loop verification of the RISC-V branch predictor.

[0222] Specifically, the generation module 403 is the core processing unit of the system, responsible for instantiating abstract test patterns into concrete executable code. The generation module 403 has pre-built assembly code generation functions for various test patterns. When the receiving module 402 determines the target test pattern and its parameters, the generation module 403 calls the corresponding generation function, fills the parameters into the template, and outputs an assembly instruction sequence conforming to the RISC-V instruction set architecture specification. The generated RISC-V assembly test program contains a complete program structure, such as code segments, data segments, and stack space settings, and can be directly processed by the compilation toolchain and run in the RTL simulation environment. The existence of the generation module 403 enables the verification system to automatically generate test stimuli, greatly reducing the workload of manually writing test cases. Through the collaborative work of the pattern library 401, the receiving module 402, and the generation module 403, this embodiment constructs a complete RISC-V branch predictor closed-loop verification system, realizing full-process automation from pattern definition and parameter configuration to program generation.

[0223] Specifically, the pattern library 401 is not merely a static storage unit; it is configured to be dynamically indexed based on microarchitectural characteristics. Internally, the pattern library 401 maintains a mapping table recording the correspondence between each stress test pattern and a specific microarchitectural submodule. For example, when the system needs to verify the performance of the Branch Target Buffer (BTB), the pattern library 401 can quickly retrieve all BTB-related test patterns, such as the "BTB Overflow Pattern," which is configured to generate different jump target addresses far exceeding the BTB entry capacity to test the correctness of the replacement algorithm. Similarly, for prediction rate benchmark patterns, the pattern library 401 stores typical branch behavior characteristic parameters extracted from standard benchmarks such as Dhrystone and CoreMark. For example, the "Re-loop Pattern" stores parameters in the pattern library including extremely high loop iteration counts (e.g., hundreds of times) and extremely high jump bias rates (e.g., 99% Taken), enabling this pattern to highly condensedly simulate loop hotspots in real workloads. Through this refined pattern storage and classification, Pattern Library 401 provides rich and accurate materials for subsequent test generation, ensuring the coverage and effectiveness of verification.

[0224] Specifically, the generation module 403 integrates a dual-channel parallel generation engine, which is the core component for ensuring strict consistency between the assembler and the branch trajectory. The generation module 403 is configured to execute the following logic: First, when processing each target test mode, the generation module 403 reads the current random number generator (RNG) state and saves it as a snapshot. Then, the generation module starts the first channel, calls the assembly generation function, consumes random numbers to determine parameters, and generates assembly code snippets. Next, the generation module restores the RNG state to the previously saved snapshot, starts the second channel, and calls the trajectory generation function. Because the RNG states are consistent, the branch execution trajectory generated by the second channel corresponds logically completely to the assembly code generated by the first channel. The generation module 403 is further configured to input the collected branch execution trajectories into a built-in prediction rate analysis engine. This engine has pre-built software implementations of various predictor models, can read branch records in the trajectory line by line, simulate the predictor's prediction behavior, and count the number of correct and incorrect predictions, ultimately calculating the theoretical prediction rate. This design enables the generation module to not only produce test stimuli but also to simultaneously produce expected results, greatly simplifying the subsequent verification and judgment process.

[0225] Specifically, the prediction rate analysis engine within generation module 403 employs a tiered model layout. The Bimodal predictor model, as the most basic tier, uses only the program counter (PC) for indexing and is used to evaluate whether the design under test has achieved basic predictive capabilities. The Gshare predictor model, which incorporates global historical information and resides in a higher tier, is used to verify whether the design under test has the ability to capture branch correlations. The Tournament predictor model and the TAGE or TAGE-lite predictor model represent more complex dynamic selection mechanisms and labeled geometric history length algorithms, and reside at the top of the tier.

[0226] To achieve closed-loop verification, the system also includes a running module for: running the RISC-V assembly test program in an RTL simulation environment to obtain the actual branch misprediction rate; comparing the actual branch misprediction rate with the theoretical prediction rate data in the ideal prediction rate report; and determining whether the branch predictor design meets the performance requirements based on the comparison results.

[0227] Specifically, the execution module acts as a bridge connecting test stimuli and final verification conclusions. It is configured to interface with standard RTL simulators (such as VCS and Xcelium). After the generation module 403 outputs the assembly test program, the execution module automatically calls the cross-compilation toolchain to compile it into a binary image and loads it into the RTL simulation environment for execution. During simulation, the execution module collects real-time data on the actual behavior of the branch predictor by monitoring hardware performance counters or inserting probes, calculating the actual branch misprediction rate. After simulation, the execution module reads the ideal prediction rate report generated by the generation module and executes comparison logic. This comparison logic is not a simple numerical comparison but a location analysis based on the ladder model. The execution module determines which theoretical range the actual misprediction rate falls within and generates a judgment result accordingly. For example, if the actual misprediction rate is significantly higher than the theoretical value of the TAGE model, the execution module will determine that the design meets the high-performance requirements; conversely, if the actual value is close to or higher than the theoretical value of the Bimodal model, the execution module will mark the design as having a performance bottleneck and output corresponding warning information. This automated comparison and judgment mechanism eliminates the tediousness of manual data analysis and achieves automatic convergence of the verification loop.

[0228] In some embodiments, an electronic device is also provided for implementing the methods described in the above embodiments. Figure 5 As shown, the electronic device includes a processor and a memory. The electronic device 500 provided in this application embodiment includes at least: a processor 501, a memory 502, and a computer program stored in the memory 502 and executable on the processor 501. When the processor 501 executes the computer program, it implements the method provided in this application embodiment.

[0229] The electronic device 500 provided in this application embodiment may further include a bus 503 connecting different components (including processor 501 and memory 502). The bus 503 represents one or more types of bus structures, including memory bus, peripheral bus, local area bus, etc.

[0230] Memory 502 may include a readable storage medium in the form of volatile memory, such as random access memory (RAM) 5021 and / or cache memory 5022, and may further include read-only memory (ROM) 5023. Memory 502 may also include a program tool 5025 having a set (at least one) of program modules 5024, including but not limited to an operating subsystem, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0231] Processor 501 can be a single processing element or a collective term for multiple processing elements. For example, processor 501 can be a central processing unit (CPU) or one or more integrated circuits configured to implement the methods provided in the embodiments of this application. Specifically, processor 501 can be a general-purpose processor, including but not limited to CPUs, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0232] Electronic device 500 can communicate with one or more external devices 504 (e.g., keyboard, remote control, etc.), and also with one or more devices that enable a user to interact with electronic device 500 (e.g., mobile phone, computer, etc.), and / or with any device that enables electronic device 500 to communicate with one or more other electronic devices 500 (e.g., router, modem, etc.). This communication can be performed through input / output (I / O) interface 505. Furthermore, electronic device 500 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) through network adapter 506. Figure 5 As shown, network adapter 506 communicates with other modules of electronic device 500 via bus 503. It should be understood that, although... Figure 5 As not shown, other hardware and / or software modules may be used in conjunction with the electronic device 500, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, Redundant Arrays of Independent Disks (RAID) subsystems, tape drives, and data backup storage subsystems.

[0233] It should be noted that, Figure 5 The electronic device 500 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0234] The computer-readable storage medium provided in the embodiments of this application is described below. The computer-readable storage medium provided in the embodiments of this application stores computer instructions, which, when executed by a processor, implement the methods provided in the embodiments of this application. Specifically, the computer instructions may be built into or installed in a processor, so that the processor can implement the methods provided in the embodiments of this application by executing the built-in or installed computer instructions.

[0235] Furthermore, the method provided in this application embodiment can also be implemented as a computer program product, which includes program code that implements the method provided in this application embodiment when run on a processor.

[0236] The computer program product provided in this application embodiment may employ one or more computer-readable storage media, which may be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination thereof. Specifically, more specific examples (a non-exhaustive list) of computer-readable storage media include: electrical connections having one or more wires, portable disks, hard disks, RAM, ROM, erasable programmable read-only memory (EPROM), optical fibers, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0237] The computer program product provided in this application embodiment can be a CD-ROM and include program code, and can also run on electronic devices such as computers. However, the computer program product provided in this application embodiment is not limited thereto. In this application embodiment, the computer-readable storage medium can be any tangible medium that contains or stores program code, which can be used by or in conjunction with an instruction execution system, device, or apparatus.

[0238] It should be noted that although several units or sub-units of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units.

[0239] Furthermore, although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0240] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Clearly, those skilled in the art can make various alterations and variations to the embodiments of this application without departing from the spirit and scope of the embodiments of this application.

Claims

1. A method for closed-loop verification of a RISC-V branch predictor, characterized in that, The method includes: It provides multiple test modes for branch predictor microarchitectures, each test mode corresponding to a branch behavior feature and having parameterized configuration; Receive a random seed, select a target test mode from multiple test modes based on the random seed, and determine parameters for the target test mode; Based on the target test mode and its parameters, a corresponding RISC-V assembly test program is generated to perform closed-loop verification of the RISC-V branch predictor. The generation of the corresponding RISC-V assembly test program based on the target test mode and its parameters includes: simultaneously generating a branch execution trajectory logically consistent with the RISC-V assembly test program based on the random seed; inputting the branch execution trajectory into multiple preset branch predictor software models for simulation analysis; outputting theoretical prediction rate data corresponding to each model; and forming an ideal prediction rate report associated with the assembly test program.

2. The method according to claim 1, characterized in that, The test modes include: The first type of test mode is a stress test mode designed for the branch predictor microarchitecture sub-module; The second type of test mode is the prediction rate benchmark mode, which is used to reproduce the typical branch behavior characteristics in standard benchmark test programs.

3. The method according to claim 2, characterized in that, The microarchitectural submodules targeted by the stress test modes include at least one of the following: Branch Target Buffer (BTB), Branch History Table (BHT), Return Address Stack (RAS), Indirect Branch Target Buffer (iBTB), and Pipeline; each stress test mode corresponds to a specific microarchitectural behavior, which includes at least one of the following: BTB capacity overflow, BHT saturation counter hysteresis, RAS deep overflow, and iBTB polymorphic jump. The typical branching behavior characteristics reproduced by the prediction rate benchmark pattern are derived from Dhrystone, CoreMark, or SPECCPU standard benchmark programs. The prediction rate benchmark mode includes at least one of the following modes: a re-loop mode, used to simulate high-biased loop branches; The biased if-else pattern is used to simulate conditional branches that depend on data dependencies. Nested loop pattern, used to simulate multi-level loop structures in matrix operations; related branch pair pattern, used to construct branch sequences with global historical relevance; The call return mode is used to test the return address stack; the periodic mode is used to test historical pattern matching; and the phase change branch mode is used to test the predictor's speed of adaptation to changes in branch behavior.

4. The method according to claim 1, characterized in that, Multiple preset branch predictor software models include multiple models with a stepped distribution of complexity, wherein the branch predictor software models include: Bimodal predictor model, Gshare predictor model, Tournament predictor model, TAGE predictor model or TAGE-lite predictor model.

5. The method according to claim 1, characterized in that, Also includes: The RISC-V assembly test program was run in an RTL simulation environment to obtain the actual branch misprediction rate. The actual branch misprediction rate is compared with the theoretical prediction rate data in the ideal prediction rate report, and the branch predictor design is determined to meet the performance requirements based on the comparison results.

6. The method according to claim 2, characterized in that, The step of selecting a target test mode from multiple test modes based on the random seed further includes: Based on the received operating mode parameters, select a test mode from the corresponding test mode set; The operating modes include: The stress mode is selected only from the first type of test modes; The predict mode is selected only from the second type of test modes; The mixed mode is selected from the combined set of the first type of test mode and the second type of test mode.

7. The method according to claim 6, characterized in that, The mixed mode includes randomly inserting stress test modes between prediction rate benchmark modes to generate a mixed test sequence for testing the branch predictor's ability to recover after being subjected to extreme microarchitectural stress.

8. The method according to claim 1, characterized in that, In the process of selecting a target test mode from multiple test modes based on the random seed, the generated test mode sequence and parameter configuration are completely consistent under the same random seed input, thereby ensuring the repeatability of the verification results.

9. A RISC-V branch predictor closed-loop verification system, characterized in that, The system includes: The pattern library provides multiple test patterns for branch predictor microarchitectures, each corresponding to a branch behavior feature and having parameterized configuration. A receiving module is configured to receive a random seed, select a target test mode from a plurality of test modes based on the random seed, and determine parameters for the target test mode; The generation module is used to generate a corresponding RISC-V assembly test program based on the target test mode and its parameters, so as to perform closed-loop verification of the RISC-V branch predictor; wherein, the generation module is specifically used to: generate a branch execution trajectory with the same logic as the RISC-V assembly test program while generating the RISC-V assembly test program based on the random seed; input the branch execution trajectory into multiple preset branch predictor software models for simulation analysis, output the theoretical prediction rate data corresponding to each model, and form an ideal prediction rate report associated with the assembly test program.

Images