Design and Implementation of a Prefetcher in a Key Performance Subsystems of RISC-V Processors

Abstract

The prefetcher is one of the key performance subsystems in RISC-V processors, and its design can significantly enhance memory access efficiency, reduce latency, and improve overall processor performance. This paper conducts in-depth research on the design methods of the prefetcher for RISC-V processors and proposes a practical prefetcher implementation scheme that balances performance and usability. The hybrid prefetching technology proposed in this scheme, on the basis of integrating two classic modes, automatic hardware prefetching and software-prefetch instructions, introduces a software template prefetcher and elaborates on its specific implementation logic in detail. For the hardware prefetcher, this paper further proposes a hierarchical prefetching strategy based on the cache hierarchical architecture and clarifies the design methods of the prefetcher corresponding to each level of cache. This design balances prediction accuracy, performance, power consumption, and design complexity. It employs different prefetching strategies and algorithms to achieve efficient memory access, thus boosting the processor’s overall performance. Both the processor and the prefetcher are designed using Verilog HDL and the implementation and verification are completed on the FPGA prototype verification platform, while the design and implementation of the 12 nm processor chip are carried out. The resulting processor core occupies an area of 5.128 mm². Performance comparison between the processor equipped with this prefetcher and Xuantie C908 and Xuantie C910 shows that on the FPGA platform, the performance of this processor is improved by 25% to 35.8% compared with the comparison objects. In addition, when the processor with the prefetcher enabled is compared with that with the prefetcher disabled, it is shown that the processor performance can be improved by 25.67% to 61%.

1. Introduction

Since its initial release in 2010 by the University of California, Berkeley, the RISC-V instruction set has been developing for 15 years. The RISC-V instruction set architecture has experienced rapid development, and research on it has become a major focus in both academia and industry in recent years [1]. In 2024, the market size for RISC-V microprocessors in China reached 18.5 billion RMB. The Chinese RISC-V microprocessor market is currently in a period of rapid development and explosive growth, expected to reach approximately 30 billion RMB by 2025. The vigorous development of RISC-V processors is based on its streamlined instruction set derived from the synthesis of multiple architectures, as well as academia’s continuous exploration and refinement of underlying micro-architectures [2,3].

A prefetcher is a passive hardware mechanism whose goal is to predict future memory accesses and load the corresponding data into the cache in advance, thereby reducing access latency [4]. Prefetchers can automatically issue prefetches according to observed access patterns and optimize the use of memory bandwidth [5]. Major hardware-prefetch algorithms include the Next-Line prefetcher [6], Stride prefetcher [7], Best-Offset (BO) prefetcher [8], Spatial-Memory-Streaming (SMS) prefetcher [9], and others. The Next-Line prefetcher is the most basic hardware algorithm. It performs sequential prefetching; whenever the CPU accesses a cache line, the prefetcher fetches the next line into the cache. Exploiting the locality of instruction and data references, it works well for consecutive memory streams. The Stride prefetcher targets regular, fixed-stride data accesses. It therefore works best for loop-based array codes, matrix operations, and image-processing kernels. The Best-Offset prefetcher dynamically learns the most profitable offset (in cache-line units) for each memory page. It keeps an Offset History Table (OHT) that scores the usefulness of every possible offset [10]; the offset with the highest score is used for future prefetches. BO is especially effective for multi-stride and non-linear patterns such as sparse-matrix traversals. The Spatial-Memory-Streaming prefetcher groups a page into small blocks and records which blocks tend to be accessed together. When any block in this spatial template is touched, SMS prefetches every other block marked in the corresponding spatial bitmap. SMS delivers high coverage with modest storage and is well suited to codes with stable spatial signatures.

Hybrid prefetching combines automatic hardware prefetching with software-initiated prefetch instructions. Hardware detects regular patterns (sequential/stride), while compiler-inserted PREFETCH instructions [11,12] handle irregular accesses such as linked lists or indirect arrays. The two techniques complement each other, raising both accuracy and coverage.

Building upon the implementation of hybrid prefetching, this design further introduces a software-configurable template prefetcher. The template prefetcher can be pre-configured before program execution to define prefetching strategies for large batches of data based on the characteristics of different applications. This approach eliminates the need for instruction insertion within the program itself, enabling high-performance processor operation by achieving efficient memory access and computational parallelism. The CPU core in this design features a 13-stage pipeline, operates at a maximum frequency of 2.5 GHz in a 12 nm process technology, and incorporates a private L2 cache. This design addresses the requirements for both data and instruction prefetching by implementing a two-level hardware prefetcher architecture: a hardware prefetcher for the L1 D-cache and another for the L2 cache. The L1 D-cache hardware prefetcher employs two techniques: stride prefetching and the software template prefetcher. The active prefetching technique can be selected via register configuration. The L2 cache hardware prefetcher comprises two independent prefetchers: one is an optimized implementation of the SMS prefetcher within this design, and the other is a Best-Offset prefetcher. These two prefetchers can be configured individually via registers to run exclusively, or they can operate simultaneously. In the latter case, the hardware learns from the program’s characteristics and selects the prefetch output from the prefetcher it has higher confidence in. This design proposes a more adaptive hybrid prefetching mechanism. Interface signals are reserved for each level and each type of hardware prefetcher, allowing for flexible software configuration and control.

The rest of this paper is organized as follows. Section 2 reviews the baseline algorithms. Section 3 details the micro-architecture and configuration options of each prefetcher level. Section 4 presents synthesis results and performance analysis. Section 5 summarizes our findings and outlines future work.

2. Backgroud

2.1. Analysis of Stride Prefetcher

When the processor accesses address A, if a stride N exists, the prefetcher will prefetch data from addresses $A+N$, $A+2N$, etc. Characteristics of the stride prefetcher include stride detection, automatically identifying and recording the stride value of data accesses (e.g., +4, +8); it predicts subsequent addresses based on historical access patterns and loads data in advance. Internally, this prefetcher has a structure called a Reference Prediction Table (RPT) [13]. This table records the access history for currently monitored cache lines. The table includes a Tag, identifying which memory region’s access history is recorded (typically a part of the address); the Previous Address, the last address accessed; the Stride, the calculated address difference between the last two accesses; and a State, used to judge the confidence in the current access pattern (e.g., initial, transient, steady). When an access occurs to a Current_Addr, especially on a cache miss, the prefetcher checks the RPT for a historical record corresponding to the Tag of Current_Addr. If a record is found, the recorded Previous_Address is retrieved. The new stride is calculated as follows: New_Stride = Current_Addr − Previous_Address. If the New_Stride matches the existing Stride in the record, it indicates a regular access pattern, increasing its “confidence” and potentially changing the state from “transient” to “steady”. If the New_Stride differs from the recorded Stride, it indicates the previous pattern is broken, thus reducing its “confidence,” and the record’s Stride is updated with the new New_Stride. The Previous_Address in the RPT record is updated to Current_Addr. When confidence reaches a certain threshold, the prefetcher predicts the next address: Next_Addr = Current_Addr + Stride, and initiates a prefetch request. It prefetches data for Next_Addr and several subsequent addresses from the main memory or the next level cache into the current cache. This prefetcher is suitable for applications with regular strided access, such as matrix operations in scientific computing, pixel traversal in image processing, and array and vector processing. Compared to sequential prefetching, it can more accurately prefetch non-contiguous data. However, it may prefetch incorrect data when the access stride changes and struggles with handling patterns that lack fixed regularity or are highly non-linear.

2.2. Analysis of Best-Offset Prefetcher

The Best-Offset (BO) prefetcher is a hardware prefetching technique based on dynamic learning. It evaluates the effectiveness of different offsets in real-time and selects the optimal prefetching strategy. The BO prefetcher focuses not on absolute addresses but on offsets relative to the current access address [8,14]. For example, using the cache line size as a unit, an offset of +1 means prefetching the next line, and an offset of −2 means prefetching the data two lines ahead. A cache miss triggers the prefetcher. The address where this miss occurs is used as the trigger for prefetching. The BO prefetcher maintains a history record for each memory page. For the most recent cache miss, it records the Trigger Address and the Miss Address. When a new cache miss occurs at address Addr_current, the prefetcher generates candidate offsets. It calculates the offset: Offset = (Addr_current − Addr_previous)/Cache_Line_Size. This offset represents the stride of the current access pattern. The BO prefetcher, internally, has a counter table (Offset History Table) that maintains a score for each possible offset. After a period of operation, a “best offset” for a page is determined. When a cache miss occurs within that page (trigger_address = Addr_miss), the prefetcher triggers the prefetch address: Addr_miss + (Best_Offset * Cache_Line_Size). This prefetcher is particularly suitable for handling multi-stride, non-linear access patterns (such as sparse matrix accesses in scientific computing) and can effectively improve the cache hit rate.

2.3. Analysis of SMS Prefetcher

The Spatial Memory Streaming (SMS) prefetcher is a hardware prefetching technology based on spatial correlation. It learns access patterns by dividing memory addresses into fixed-size spatial regions and prefetches data likely to be accessed in the future when it detects similar patterns. Its core advantages are low hardware overhead (only requiring the storage of offsets or deltas as metadata) and effectively reducing compulsory cache misses. The SMS prefetcher actively learns and records which cache lines tend to be accessed together during program execution. This forms templates of “neighboring addresses,” called “spatial pages”. When a program accesses a cache line belonging to a “spatial page”, SMS immediately prefetches all other cache lines within that “spatial page” that are not already in the cache.SMS operates on a per-page basis for learning, not on individual cache lines or fixed offsets. It divides a standard memory page into multiple “chunks” and records the access relationships between these chunks. When a page’s access pattern is recognized, a “spatial entry” is generated, containing two parts: a Trigger Cache Line, whose access activates prefetching, and a Spatial Bitmap, where each bit represents a cache line within the page. If a bit is set to 1, it indicates that when the “trigger cache line” is accessed, the cache line corresponding to this bit should also be prefetched. A single cache access can trigger the prefetching of multiple “neighbor” cache lines, preparing this data before the CPU actually needs it [15]. It shows great potential in handling modern applications that rely on complex pointer-based data structures and is applicable to applications with regular spatial access patterns (e.g., scientific computing, image processing), capable of significantly improving performance.

3. Proposed Hardware Prefetcher Implementation

3.1. Proposed L1 Dcache Hardware Prefetcher Implementation

The hardware structure of the Dcache data prefetcher is illustrated in Figure 1. At this level, the hardware prefetcher implements both stride prefetching and software template prefetching. The selection of whether to use the template prefetching results is controlled by configuring the template_en register.

When the templata_en signal is high, the address generated by the software template is selected as the output. When the templata_en signal is low, the address generated by the hardware stride prefetcher is selected as the output.

Figure 2 demonstrates the prefetching behavior of the L1 dcache prefetcher, which utilizes the stride prefetcher and the software template prefetcher, respectively, following the configuration of its CSR control registers.

3.1.1. Proposed Stride Prefetcher Implementation

The hardware Stride Prefetcher uses the middle bits of the input virtual address vaddr to select the corresponding tag, pre_addr, stride, and state from a two-dimensional array. It checks if the high bits of the vaddr equal the read-out tag. If they do not match, it updates the tag, pre_addr, stride, and state entries with tag = high bits of vaddr, prev_addr = middle bits of vaddr.

If the high bits of vaddr match the read-out tag, it checks if the difference between the middle bits of vaddr and pre_addr equals the stored stride. If they are equal and the state is in the `steady’ state, the prefetch valid signal is asserted high. A prefetch address is generated, calculated as full vaddr bits + (h_step + 1) * stride, and the pre_addr is updated. If they are not equal or the state is not `steady’, the prefetch valid signal is driven low, and the corresponding pre_addr, stride, and state are updated.

3.1.2. Proposed Software Template Prefetcher Implementation

A template prefetch mode is also provided for greater flexibility: software can preload large, stride-based descriptors that automatically generate multiple prefetches without per-instruction hints.

The software template is configured through a custom templata_cfg register within the CSR register set, which is used for setting up the software template in the prefetcher. The field division of this register is shown in Figure 3.

The Template Prefetcher has 16 entries. Each entry stores a 6-bit SUB (difference), an 8-bit s_step, and a 6-bit s_stride. The content of each entry is configured by a custom CSR register named templata_cfg. When a CSR instruction writes to the templata_cfg register, the csr_refile module generates a write signal and outputs the register value to the dcache data prefetcher, which then configures the software template accordingly.

The 16 template entries are content-addressable. When a virtual address vaddr arrives, the last requested address stored in the last_vaddr register is used. The middle bits of the difference (vaddr − last_vaddr) are used as content to compare against the SUB (difference) fields of all 16 templates. If a match is found, the corresponding template entry is hit and its contents are used. If multiple entries match, the entry with the lowest index is selected. The prefetch address generated is vaddr + (s_step + 1) * s_stride.

3.1.3. Proposed L1 Dcache Hardware Prefetcher Control Register Configuration

The L1 Dcache hardware prefetcher designs a custom CSR register L1dpref_cfg to enable flexible configuration of the L1 Dcache hardware prefetcher’s operational behavior. Its field division is shown in Figure 4:

The L1dpref_cfg register has four valid fields:

• templata_en: Used to select either the software template prefetch address or the hardware stride prefetch address as the output. The reset value is 0, selecting the hardware stride prefetch address by default.
• pref_en: Used to control the enable signal of the l1_dcache hardware prefetcher. The reset value of this field is 1, meaning the hardware prefetcher is enabled by default. It can be disabled by configuring this bit to 0 via a CSR instruction.
• Cnt_limit: Used to control the threshold for the confidence counter. Each entry in the l1_dcache hardware prefetcher has a confidence counter. When the confidence counter value exceeds the set threshold, data is prefetched into the L1 cache; otherwise, it is only prefetched into the L2 cache. The confidence threshold is set as cnt_limit + 3. Thus, if cnt_limit is not explicitly set, the default threshold is 3.
• H_step: Used to set the number of prefetch strides. When h_step is not set, each prefetch adds one stride, i.e., prefetch_addr = vaddr + stride. When h_step is set, each prefetch adds (h_step + 1) strides, i.e., prefetch_addr = vaddr + (h_step + 1) * stride.

3.2. Proposed L2 Cache Hardware Prefetcher Implementation

The L2 cache hardware prefetcher consists of two independent prefetchers: one is the optimized implementation of the SMS prefetcher in this design, and the other is the optimized implementation of the best_offset prefetcher in this design. Both prefetchers learn from physical addresses and generate prefetch addresses. In this design, the SMS hardware prefetcher learns physical addresses from the L1 miss queue to generate prefetch addresses, while the best_offset hardware prefetcher learns addresses from L2 cache misses or prefetch hits to generate prefetch addresses.

3.2.1. Optimization of SMS Prefetcher Implementation

SMS is an advanced spatial prefetching method. Whenever a spatial region is accessed for the first time, SMS records the accesses to that region. When the spatial region is no longer in use, SMS stores the observed access pattern in a Pattern History Table (PHT). When that region is accessed again, the previously accessed data blocks are prefetched sequentially.

Figure 5 provides an illustrative example of the SMS prefetcher’s behavior, showcasing both the recorded data structures and specific prefetch triggering instances.

This design sets each spatial region size to 2 KB. With each cache line being 64 B, 32 bits are required to record the access status of each cache line within the region. The tag for the spatial region is the high bits of the physical address, and bits [10:6] indicate the position of each cache line within the region.

Figure 6 shows the SMS hardware block diagram.

SMS consists of two main parts: the Active Generation Table (AGT) and the Pattern History Table (PHT).

SMS learns spatial patterns by recording which blocks are accessed within a spatial region in the AGT. When access to a spatial region begins, SMS allocates an entry in the AGT. When a cache block within the region is accessed, SMS updates the pattern recorded in the AGT. At the end of the generation phase, the AGT transfers the spatial pattern to the PHT.

The AGT is internally divided into an Accumulation Table and a Filter Table. New spatial region generations are initially allocated in the Filter Table. Since a significant portion of spatial regions are never accessed a second time, predicting them is not very meaningful. Using the Filter Table for initial allocation reduces pressure on the Accumulation Table.

When a miss request arrives, the PHT is searched. If a record exists in the PHT for the corresponding region, the cache lines whose corresponding bits in the historical pattern are ’1’ are prefetched.

As the prefetcher operates at cache line granularity, address bits [5:0] are ignored. Examples use addr corresponding to address bits [high bits of addr: 6].

3.2.2. Optimization of Best-Offset Prefetcher Implementation

This prefetcher operates at the cacheline granularity and ignores the [5:0] bits of the address.

In this design, there is an offset list containing 46 entries. These 46 offsets are divided into 23 groups, with each group consisting of the positive and negative values of the same number. These 23 numbers are 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 18, 20, 24, 30, 32, 36, and 40, respectively.

It has a Recent Requests (RR) Table, which receives addresses from L2 Cache misses, prefetched hits, and BIU prefetched refill addresses. It has a Best-Offset Learning module responsible for learning the best offset.

As shown in Figure 7, when a request address X arrives, it sequentially selects an offset d from the list. It calculates address $X-d$ and checks if $X-d$ exists in the RR Table. If it exists, the score for the selected offset d is incremented. Sequentially checking all 46 offsets constitutes one learning round. n rounds of learning form one learning session. The number of rounds n per session can be set via a variable. There is a maximum score threshold and a minimum score threshold for learning, both configurable via registers. If during a learning session the highest score among the offsets exceeds the maximum score threshold, the learning session can end early. After the learning session completes, if the highest score is greater than the minimum score threshold, the learning is considered successful, and that offset is recorded as the Best Offset D. If the highest score is less than the minimum score threshold, the learning fails, and prefetching stops until a new learning session produces a valid Best Offset. When a request address X arrives and a valid Best Offset D exists, it generates the prefetch address $X+D$.

Storing the request address in the RR table immediately upon arrival offers better timeliness for prefetching. Storing the requested address in the RR table upon refill offers better prefetch accuracy. Introducing a Delay Queue between the request address and the RR table allows tuning the delay to find a better balance point between timeliness and coverage, thus achieving optimal prefetch performance. When the Delay Queue latency is set to T cycles, requested addresses wait for T clock cycles in the Delay Queue before entering the RR Table. The Delay Queue latency is configurable via a register.

3.2.3. L2 Cache Prefetcher Control Register Configuration

This design defines three custom CSR registers: mprefetch$\_c$fg, sprefetch$\_c$cfg, and uprefetch$\_c$cfg, used to control the behavior of the L2 cache hardware prefetcher in Machine (M), Supervisor (S), and User (U) modes, respectively, providing greater flexibility for software configuration in different privilege modes. They can be read from and written to via CSR instructions. Its field division is shown in Figure 8:

The field divisions of these three CSR registers are largely consistent, with only bit 0 differing. Using sprefetch_cfg as an example, the function of each field on the hardware prefetcher’s behavior is described below.

• Sms_enable: Controls the enable signal for the SMS prefetcher. The reset value of this field is 1, meaning the SMS prefetcher is enabled by default. It can be disabled by setting this bit to 0 via a CSR instruction.
• Delay_q_cycle: Controls the delay time (in cycles) for the Best-Offset prefetcher’s Delay Queue. Tuning this delay helps find the optimal balance between timeliness and coverage for best prefetch performance. The reset value is 60, meaning after reset, missed addresses wait 60 cycles in the Delay Queue before entering the RR Table. This value can be adjusted via CSR instructions for better prefetch performance.
• Max_score: Represents the maximum score threshold. During a learning session, if the current highest score is greater than or equal to this threshold, it indicates a Best Offset has been learned, and the learning session will end, outputting this Best Offset. The reset value is 31, adjustable via CSR instruction.
• Min_score: Represents the minimum score threshold. Upon completion of a BO learning session, if the highest score among the 46 offsets is below this threshold, it is concluded that no suitable prefetch offset for the current program flow was found. In this case, the Best Offset is set to 0, instructing the L2 Cache not to perform prefetching until the next BO learning session completes successfully. The reset value is 10, adjustable via CSR instruction.
• Max_round: Represents the number of learning rounds per session. The Best-Offset prefetcher has a list of 46 offsets. When a miss_addr arrives, it sequentially selects an offset, calculates miss_addr - offset, and checks if the result exists in the RR Table. If found, the score for that offset is incremented. Processing from the first to the last offset constitutes one round. Max_round defines how many rounds comprise one learning session. The reset value is 100, meaning each session learns for 100 rounds. Adjustable via CSR instruction, a valid range is 0–127.
• Fixed_best_offset and Fixed_bo_en: Fixed_bo_en indicates whether the prefetcher should use a fixed Best Offset. When fixed_bo_en is set, the prefetcher uses the value in Fixed_best_offset as the fixed Best Offset. The reset value of Fixed_bo_en is 0 (do not use fixed BO). The reset value of Fixed_best_offset is 1. Can be set via CSR instruction to control whether a fixed value is used for prefetching.
• Bo_clear: BO prefetcher clear. Setting this bit to 1 causes all learning states of the BO prefetcher to be cleared. The reset value is 0. Setting this bit achieves the effect of clearing the BO prefetcher.
• Bo_enable: BO prefetcher enable. The reset value of this bit is 1, meaning the Best-Offset prefetcher is enabled by default. It can be disabled by configuring this bit to 0 via a CSR instruction.
• Pcue: This is a unique field for the sprefetch_cfg register, used to select the BO prefetcher configuration in User (U) mode. When in U mode and this field is set to 0, the prefetcher uses the configuration from sprefetch_cfg. When set to 1, it uses the configuration from uprefetch_cfg.

4. Results of the Hardware Implementation

4.1. Performance Analysis

Prefetching exploits temporal and spatial locality by bringing data into the cache before it is actually needed, thereby hiding the latency of cache misses. A prefetch scheme is usually evaluated along two dimensions: coverage and accuracy [16,17].

Coverage is the fraction of original cache misses that are eliminated by prefetches. For example, if a baseline run suffers 100 misses and prefetching reduces this number to 30, the coverage is 70/100 = 70%.

Accuracy is the fraction of issued prefetches that are actually useful. Continuing the example, if 140 prefetches were generated in total and only 70 were useful, the accuracy is 70/140 = 50%. Maximizing coverage alone is trivial—“prefetch everything” can push coverage close to 100%, but accuracy collapses, wasting memory bandwidth and often degrading performance. An ideal prefetcher achieves high coverage while preserving high accuracy.

Before tape-out, we used the FPGA platform to run large-scale functional and performance tests on both the hardware prefetcher and the processor that integrates it. These experiments fixed the optimal reset values for all prefetcher-configuration registers, ensuring that the out-of-box settings match a broad range of applications.

We adopted the Xilinx Virtex UltraScale+ VU19P FPGA experimental platform, with the clock frequency set to 100 MHz. Regarding the FPGA resource utilization: CLB LUTs (Configurable Logic Block Look-Up Tables) are 966,967, CLB Registers (Configurable Logic Block Registers) are 298,540, Block RAM Tiles are 287.5, URAMs (Ultra RAM) are 64, and DSPs (Digital Signal Processors) are 5.

We ran both the STREAM [18] and SPEC CPU2006 [19] suites on our FPGA prototype.

Table 1. Comparison of bandwidth results for the STREAM benchmark with prefetcher on CPU.

(a) Performance and L1 Data Cache (DC) Metrics
Program	Prefetch	Bandwidth (MB/S)	Perf. Boost	dc_access	dc_access _miss	dc miss rate
stream _copy	off	8081	42.08%	1124991	839928	74.66%
	on	11,481		1124983	588008	52.27%
stream _scale	off	5934	61.22%	2125010	800728	37.68%
	on	9566		2125014	550407	25.90%
stream _add	off	7520	50.29%	2124985	1724361	81.15%
	on	11,301		2124981	961775	45.26%
stream _triad	off	7119	32.06%	3124976	1638880	52.44%
	on	9401		3124985	996264	31.88%
(b) L2 Cache Metrics Details
Program	Prefetch		l2_request		l2_request _miss	l2 miss rate
stream _copy	off		250033		164288	65.71%
	on		390762		177908	45.53%
stream _scale	off		250024		160212	64.08%
	on		414970		178314	42.97%
stream _add	off		375024		332491	88.66%
	on		590056		349182	59.18%
stream _triad	off		375021		333398	88.90%
	on		587287		353557	60.20%

compares STREAM bandwidth with the prefetcher disabled and enabled, together with the speed-up ratio.

Table 2. Comparison of STREAM bandwidth across different CPU platforms.

CPU Name	Year	Micro-Arch.	Clock (GHz)	Stream_ Copy (MB/s)	Stream_ Scale (MB/s)	Stream_ Add (MB/s)	Stream_ Triad (MB/s)
Intel i3-550 [20]	2010	Nehalem	3.2	8916	8703	9299	9335
Intel Atom J1900 [21]	2014	Bay Trail	2.4	7082	7051	7404	7597
XuanTie C908 [22]	2022	RISC-V 64	2.0	5953	3477	5568	4534
XuanTie C910 [23]	2024	RISC-V 64	2.0	8106	8115	6027	6063
HCC75 (this work)	2025	RISC-V 64	2.5	11,481	9566	11,301	9401

contrasts STREAM bandwidth across different CPU platforms.

Table 3. SPEC2006 performance improvement with the prefetcher ON vs. OFF.

Benchmark	Speed-Up
400. perlbench	1.33%
401. bzip2	13.87%
403. gcc	17.99%
429. mcf	1.30%
445. gobmk	2.07%
456. hmmer	117.46%
458. sjeng	−3.12%
462. libquantum	32.05%
464. h264ref	1.15%
471. omnetpp	187.73%
473. astar	17.96%
483. xalancbmk	26.31%

quantifies the performance gain from enabling the prefetcher on SPEC2006.

As shown in Table 1, the overall STREAM bandwidth improvement after enabling the prefetcher, measured on the FPGA prototyping platform with this processor core design, reaches 46% compared to the bandwidth with the prefetcher disabled. The data in Table 2 was obtained by running the Lmbench official application on the relevant chip development board. In Table 3, the same FPGA resource configuration of this processor core design was used to run the SPEC2006 performance test program with the prefetcher both disabled and enabled. The performance improvement of the SPEC2006 test program after enabling the prefetcher reaches 28%.

These results confirm that the prefetcher converts high-latency, bursty, unpredictable memory traffic into low-latency, smooth, predictable cache hits, yielding significant gains in both energy efficiency and overall performance.

4.2. Physical Implementation

The processor containing the proposed hardware prefetcher is now ready for tape-out. The physical design was carried out in 12 nm CMOS technology and partitioned into timing-critical blocks to push the core frequency. Figure 9 shows the CPU CORE final layout. The CPU core has a height of 2.246 mm and a width of 2.283 mm, with a total area of 5.128 mm². Operating voltage is 0.8 V. In Figure 9, the lower left is the L2 cache region where the L2 prefetcher is implemented, and the lower right is the memory access region where the L1 prefetcher is deployed. The design of this processor core’s physical implementation is completely identical to that used for performance testing on the FPGA prototype verification platform.

Figure 10 shows the L2 cache region, where the red cell area corresponds to the implementation region of the L2 prefetcher.

Figure 11 shows the memory access region, where the red cell area is the implementation region of the L1 prefetcher.

5. Conclusions

This paper presents a hybrid prefetcher implemented in a RISC-V processor targeting high-performance embedded and desktop applications. The core fully supports the RISC-V RV64 [11,12] and RVA23 [24] specifications. We have integrated this two-level prefetcher into the L1 cache and L2 cache of the RISC-V processor. To validate the design’s performance, we evaluated both the hardware prefetcher and the processor core on an FPGA platform, and later implemented the design in 12 nm CMOS technology. The results clearly demonstrate that our design outperforms most commercial processors in terms of performance and operating frequency.