A collaborative prefetcher for large-capacity on-chip cache and its control method

Abstract

The present invention discloses a collaborative prefetcher for large-capacity on-chip cache and a control method thereof. The collaborative prefetcher has four levels of cache, L1 / L2 / L3 / L4. The L2 cache is equipped with a traditional prefetcher for SRAM Cache, and the L4 is equipped with a prefetcher for large-capacity cache. The prefetcher of the L2 cache transmits ordinary memory access requests together with prefetch information to the L3 cache; the L3 cache controller is used to receive the prefetch request sent by the prefetcher, and when judging that the prefetch request carries historical information according to the flag information, the prefetch request is sent to the L4 cache; the L4 cache controller is used to expand the prefetch request based on the historical information and perform prefetching. The present invention transmits the prefetcher information in the high-level cache to the low-level cache, and reuses the information to achieve the purpose of reducing redundant historical information in the prefetcher and reducing the chip area. At the same time, by expanding the information transmitted to the low-level cache, the purpose of further improving the system performance is achieved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a collaborative prefetcher for large-capacity on-chip cache and a control method thereof. Background Art

[0002] The prefetcher is a key module that affects processor performance. The prefetcher generally works in conjunction with the cache to store instructions and data in the memory into the cache before they are accessed, thereby speeding up the execution of the processor.

[0003] From the perspective of the required on-chip storage area, prefetchers are divided into two categories, namely shared information prefetchers and private information prefetchers. Shared information prefetchers store relevant prefetch history information in the same shared storage space for all prefetch addresses; private information prefetchers store different prefetch address segments, and each segment has its own separate history information.

[0004] Stride Based Prefetcher was the first to be proposed. Its performance is relatively average, but the required on-chip storage area is also the smallest. As the prefetcher design becomes more and more complex, the required on-chip storage area is also increasing. For example, Bingo Prefetcher was proposed in 2019. It has good prefetching performance, but requires a larger on-chip storage area to implement.

[0005] For large-capacity on-chip caches, the prefetchers currently used still follow the traditional cache prefetchers. Since the amount of data cached in large-capacity on-chip caches is large, shared information prefetchers are not suitable. Therefore, most of them use private information prefetchers, such as Bingo Prefetcher, Spatial Memory Prefetcher (SMP), Access Map Pattern Matching Prefetcher (AMPM), etc.

[0006] The FHT prefetcher is proposed for large-capacity caches. Its core idea is to use a table entry to store the access history information of each memory page. When the page is kicked out of the cache, the historical information is saved. When the page is accessed again next time, the saved historical information is used to prefetch the data. FHT is a table for storing historical information. The tag array will record information such as valid / dirty. When a page is kicked out, its historical information will be written into FHT.

[0007] From the perspective of storage space, FHT requires a large on-chip SRAM area. A 256MB on-chip cache requires 144KB (storing 16K entries) of SRAM storage space. As the on-chip cache capacity increases, FHT also needs to increase accordingly to ensure its effectiveness. Taking Intel's Knights Landing processor as an example, a 16GB on-chip cache requires 9.2 megabytes of SRAM storage space, which is too expensive to be used on a large scale in commercial processors.

[0008] To sum up, in the existing methods, in a system using a large-capacity chip manufacturer's cache, the historical information in the private information prefetcher and the prefetcher for the large-capacity cache run independently and cannot share the prefetch information, thus causing a waste of chip area, and the prefetcher performance still has much room for improvement. Summary of the invention

[0009] The object of the present invention is to provide a collaborative prefetcher for large-capacity on-chip cache and a control method thereof. For a large-capacity on-chip cache system, by expanding or reusing historical information in a high-level cache prefetcher system in a low-level cache prefetcher, redundant information is reduced and the chip area is reduced. At the same time, the prefetch information is expanded to achieve the purpose of improving system performance.

[0010] The technical solution adopted by the present invention is:

[0011] A collaborative prefetcher for large-capacity on-chip cache, the collaborative prefetcher having at least one high-level cache matched with a conventional prefetcher for general capacity and at least one low-level cache matched with a prefetcher for large-capacity cache, the conventional prefetcher corresponding to the high-level cache being used to obtain ordinary memory access requests, query historical memory access request information recorded in the high-level cache according to the ordinary memory access requests, generate corresponding prefetch requests after operating corresponding flag bits according to whether the historical information is carried, and pass the prefetch requests and ordinary memory access requests together to the low-level cache; the low-level cache controller being used to receive the prefetch requests sent by the high-level cache, and further operate according to the flag bit information and the current cache level: if the current cache level does not need to prefetch data according to the prefetch request, then pass the prefetch request to the next level cache; if the current cache needs to prefetch data according to the request, then expand and prefetch the prefetch request according to the flag bit information.

[0012] Furthermore, as an implementation method, the collaborative prefetcher has four levels of cache: L1 / L2 / L3 / L4, the L2 cache is matched with a traditional prefetcher corresponding to a general cache capacity, and the L4 is matched with a prefetcher for a large-capacity cache, and is characterized in that: the prefetcher corresponding to the L2 level is used to obtain a normal memory access request from the L1 level cache, and generates a prefetch request after operating the corresponding flag bit according to whether the historical information corresponding to the normal memory access request is carried, and passes it to the L3 level cache together with the normal memory access request; the L3 level cache controller is used to receive the prefetch request sent by the prefetcher corresponding to the L2 level, and when it is determined according to the flag bit information that the historical information is carried, the prefetch request is sent to the L4 level cache; the L4 level cache controller is used to expand the prefetch request based on the historical information and perform prefetching.

[0013] Further, as an implementation method, the L4 level cache is a 16GB large-capacity on-chip cache, and the L1 / L2 / L3 level caches are 64KB / 1MB / 32MB respectively.

[0014] Furthermore, as a preferred implementation, the Bingo prefetcher maintains three structures, namely FT (Filter Table), AT (Accumulation Table) and PHT (Pattern History Table). The entire address space is divided into multiple regions (4KB) of the same size; FT is used to record the address information of the region that is accessed for the first time, and the region that is not accessed for the first time will be transferred to AT; AT is used to accumulate and generate Bitmap history information of region access; when cache replacement occurs, the corresponding region is transferred from the AT table to PHT, indicating that the corresponding region is no longer "hot" in a short time. Query PHT to obtain the prefetch address Bitmap and use it to guide the prefetch operation for the region.

[0015] A control method for a collaborative prefetcher for a large-capacity on-chip cache adopts L1 / L2 / L3 / L4 four-level cache, L2 cache is equipped with a Bingo prefetcher, and L4 is equipped with a Footprint prefetcher. The method comprises the following steps:

[0016] Step 1: The prefetcher corresponding to L2 obtains a common memory access request from the L1 cache, generates a new prefetch request based on whether the prefetcher corresponding to L2 carries the corresponding historical information, and transmits the prefetch request together with the memory access request to the L3 cache;

[0017] Step 2, the L3 cache controller receives the prefetch request sent by the Bingo prefetcher, and determines whether it is prefetching historical information according to the flag information; if prefetching historical information is required, execute step 5; otherwise, execute step 3;

[0018] Step 3, determine whether L3 hits; if yes, return data and end; otherwise, execute step 4;

[0019] Step 4, determine whether the pre-fetch request has been sent; if yes, end; otherwise, execute step 5;

[0020] Step 5: Send the pre-fetch request to the L4 cache controller and extend the pre-fetch address;

[0021] Step 6: The L4 cache controller expands and pre-fetches according to the historical information and ends.

[0022] Further, as a preferred implementation, the specific steps applicable to step 1 of the Bingo prefetcher based on private information are:

[0023] Step 1-1-1, the Bingo prefetcher divides the prefetch address and history information of the prefetch request into two separate transactions that share the same transaction code.

[0024] Step 1-1-2, the Bingo prefetcher adds two bus bit fields, isBitmap and FollowingCDCP, and performs corresponding bit operations on the bus bit fields according to whether the current transaction sends a prefetch address or historical information;

[0025] In step 1-1-3, the Bingo prefetcher sends two transactions with the newly added bus bit field to the L3 cache controller through the bus.

[0026] Further, as a preferred implementation, in step 1-1-2, in the first transaction, isBitmap=0 and FollowingCDCP=1, indicating that the current transaction is a prefetch address, followed by historical information of the current prefetch address; in the second transaction, isBitmap=1 and FollowingCDCP=0, indicating that the current transaction is historical information, not followed by any CDCP information, and the Addr bit in the second transaction stores historical information.

[0027] Further, as a preferred implementation, the specific determination method of the next-level cache controller in step 2 is:

[0028] The L3 cache controller queries the information of the newly added bus bit field in the current transaction: when FollowingCDCP=1, it means that the current transaction is a prefetch address and the subsequent historical information follows the current prefetch address, then wait for the next transaction to arrive; when isBitmap=1, it means that the current transaction (transation) is historical information, and there is no subsequent historical information; then bypass is performed and the expected request is directly sent to the L4 large-capacity cache for prefetching.

[0029] Further, as a preferred implementation, the specific steps applicable to step 1 of the Bingo prefetcher based on shared information are:

[0030] Step 1-2-1, after the Stride prefetcher of the L2 cache receives the normal memory access request Addr1, it obtains the prefetch address Addr2, stride (Stride, 4 bits) and confidence (Confidence, 1 bit) based on the information recorded by the Stride prefetcher;

[0031] Step 1-2-2, the stride, credibility and valid bit are integrated into the lower 6 bits of the prefetch request address, and the valid bit is operated according to whether the prefetch request carries historical information, and finally a prefetch request with integrated prefetch information is formed and sent to the L3 cache storage;

[0032] Further, as a preferred implementation, the prefetch request integrating the prefetch information is 52 bits, and the specific format is ({Addr2[51:6]: Confidence[5:5]: Stride[4:1]: Valid[0:0]}).

[0033] Further, the Stride prefetcher sets the valid bit to 1 when carrying history information in the prefetch request.

[0034] Further, as a preferred implementation, the specific determination method of the L3 cache controller in step 2 is:

[0035] Step 2-1, the L3 cache controller obtains prefetch information and decodes the address of the valid bit in the prefetch request;

[0036] Step 2-2, determine whether the valid bit is zero; if so, determine that no historical information is carried and process it according to the normal access process; otherwise, determine that the history is carried and bypass it to directly send the expected request to the L4 large-capacity cache for pre-fetching.

[0037] Further, as a preferred implementation, the L3 cache controller sends the expected request to the L4 large-capacity cache and records the historical information (CDCP) request in a historical information queue (CDCP Queue) of the L3 cache controller.

[0038] Further, as a preferred implementation, the controller of the L4-level large-capacity cache queries whether the valid bit (Valid) of the pre-fetch request is set to 1; if so, the Addr is expanded according to the Conf (Confidence) and Stride (stride) information to generate a pre-fetch Bitmap.

[0039] Furthermore, as a preferred implementation, a specific method for generating a prefetch Bitmap is as follows: assuming that the prefetch address Addr belongs to page P, that is, Addr=P + Offset. When Conf is 0, it means that the credibility of the prefetch command based on the current stride is low, and then a prefetch Bitmap is generated: P+ Offset, P+ Offset + Stride* cache Line, P+Offset + 2* Stride* cache Line, until the address P+ PageSize / 2, and finally a prefetch Bitmap is generated; wherein P represents a pointer to the page, Offset represents the offset within the page, and PageSize represents the page size.

[0040] When Conf is 1, it means that the prefetch command based on the current stride has a high credibility, and a prefetch Bitmap is generated: P+ Offset, P+ Offset + Stride* Cache Line, P+ Offset + 2* Stride* Cache Line, with a cutoff address of P+ PageSize, and finally a prefetch Bitmap is generated; data is prefetched for a cache line of a page granularity.

[0041] Taking Stride equal to 2 as an example, when Conf is 0, the generated prefetch Bitmap is: P+ Offset, P+Offset +2*cache Line, P+ Offset + 4*cache Line, until address P+ PageSize / 2.

[0042] The present invention adopts the above technical solution, and for a large-capacity on-chip cache system, by merging the historical information in the prefetcher system, the purpose of reducing redundant information, thereby reducing the chip area and improving system performance is achieved. The use of historical information can save a lot of on-chip SRAM storage space while bringing an 8.7% performance improvement. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] The present invention is further described in detail below with reference to the accompanying drawings and specific embodiments;

[0044] Figure 1 It is a schematic diagram of the overall structure of a collaborative prefetcher for large-capacity on-chip cache according to the present invention;

[0045] Figure 2 A schematic diagram of the Bingo prefetcher and CDCP modification thereof according to the present invention (dark grey part);

[0046] Figure 3It is a schematic diagram of modification of L2 Cache by CDCP of the present invention;

[0047] Figure 4 This is a schematic diagram of the modification of Bus by CDCP of the present invention;

[0048] Figure 5 Schematic diagram of a stride-based CDCP shared information prefetcher of the present invention;

[0049] Figure 6 This is a schematic diagram of CDCP modification of L3 Cache according to the present invention. DETAILED DESCRIPTION

[0050] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application.

[0051] like Figure 1 As shown, the present invention discloses a collaborative prefetcher for large-capacity on-chip cache, the collaborative prefetcher has at least one high-level cache matched with a general-capacity traditional prefetcher and at least one low-level cache matched with a large-capacity cache prefetcher, the traditional prefetcher corresponding to the high-level cache is used to obtain ordinary memory access requests, query historical memory access request information recorded in the high-level cache according to the ordinary memory access request, generate corresponding prefetch requests after operating the corresponding flag bit according to whether the historical information is carried, and pass the prefetch request and the ordinary memory access request to the low-level cache together; the low-level cache controller is used to receive the prefetch request sent by the high-level cache, and further operate according to the flag bit information and the current cache level: if the current cache level does not need to prefetch data according to the prefetch request, then pass the prefetch request to the next level cache; if the current cache needs to prefetch data according to the request, then expand and prefetch the prefetch request according to the flag bit information.

[0052] Furthermore, as an implementation method, the processor has four levels of cache, L1 / L2 / L3 / L4, the L2 cache is equipped with a traditional prefetcher corresponding to a general capacity, and the L4 is equipped with a Footprint prefetcher for a large-capacity cache, wherein L4 is a 16GB large-capacity on-chip cache, and L1 / L2 / l3 are 64KB / 1MB / 32MB respectively. The prefetcher corresponding to the L2 level is used to obtain a normal memory access request from the L1 level cache, and generates a prefetch request after operating the corresponding flag bit according to whether the historical information corresponding to the normal memory access request is carried, and passes it to the L3 level cache together with the normal memory access request; the L3 level cache controller is used to receive the prefetch request sent by the prefetcher corresponding to the L2 level, and when it is determined that the historical information is carried according to the flag bit information, the prefetch request is sent to the L4 level cache; the L4 level cache controller is used to expand the prefetch request based on the historical information and perform prefetching. The core ideas of the FHT prefetcher and the Bingo prefetcher are similar. They both record the footprint history of page accesses. Therefore, there is redundancy in the prefetch information in the independently running FHT prefetcher and Bingo prefetcher. Removing this redundant information can reduce the on-chip storage area required by the prefetcher, thereby reducing the overall area of ​​the processor chip. For large-capacity on-chip cache systems, by expanding or reusing historical information in a high-level cache prefetcher system in a low-level cache prefetcher, the purpose of reducing redundant information, thereby reducing chip area and improving system performance is achieved. In addition, it can also be used in systems with only two levels of cache. In my embodiment, L4 is written as L4 Cache, but in the actual system it can also be SRAM or other caches.

[0053] like Figures 2 to 6 As shown in one, a control method for a collaborative prefetcher for a large-capacity on-chip cache is provided.

[0054] L1 / L2 / L3 / L4 four-level cache is adopted, L2 cache is equipped with a traditional prefetcher corresponding to general capacity, and L4 is equipped with a Footprint prefetcher for large-capacity cache. The method includes the following steps:

[0055] Step 1, the conventional prefetcher corresponding to the L2 level obtains a common memory access request from the L1 level cache, generates a prefetch request after operating the corresponding flag bit according to whether the historical information corresponding to the common memory access request is carried, and transmits the prefetch request and the common memory access request together to the L3 level cache;

[0056] Step 2, the L3 cache controller receives the prefetch request sent by the prefetcher corresponding to the L2 level, and determines whether it is prefetch history information according to the flag information; if prefetch history information is required, execute step 5; otherwise, execute step 3;

[0057] Step 3, determine whether L3 hits; if yes, return data and end; otherwise, execute step 4;

[0058] Step 4, determine whether the pre-fetch request has been sent; if yes, end; otherwise, execute step 5;

[0059] Step 5: Send the pre-fetch request to the L4-level large-capacity cache and expand the pre-fetch address;

[0060] Step 6: The L4 cache controller expands and pre-fetches according to the historical information and ends.

[0061] The working principles of the prefetcher based on private information and the prefetcher based on shared information are described in detail below:

[0062] Embodiment 1 of the present invention: The L2 level is equipped with a collaborative prefetcher CDCP (Collaborative Data Cache Prefetcher) based on a private information prefetcher (Bingo Prefetcher).

[0063] Comparing with the prior art, it can be seen that the PHT in the Bingo prefetcher and the FHT in the Footprint Cache are actually similar structures and have information redundancy.

[0064] Figure 2 The architecture of the Bingo prefetcher is shown, which maintains three structures, namely the Filter Table (FT), Accumulation Table (AT) and Pattern History Table (PHT). The entire address space is divided into multiple regions (4KB) of the same size. FT is used to record the address information of the region that is accessed for the first time, and the region that is not accessed for the first time will be transferred to AT. AT is used to accumulate and generate Bitmap history information of region access. When a cache replacement occurs, it indicates that the corresponding region is no longer "hot" in a short period of time, so the corresponding region is transferred from the AT table to the PHT. By querying the PHT, you can obtain the prefetch address Bitmap and use it to guide the prefetch operation for the region.

[0065] When a domain address is accessed for the first time, the domain segment address is recorded in the Filter Table (FT). When the same domain segment is accessed again, the domain segment address is transferred to the AT. When a data block in a domain segment is replaced from the cache, the domain segment is transferred to the PHT to guide the prefetching of the domain segment. If the request to access a domain segment queries the PHT and hits, the data is prefetched according to the query result.

[0066] The prefetch address and prefetch information are sent to the L4 Cache controller via the bus twice. In the bus request bit field encoding, the above two requests share the same transaction code (Transaction ID).

[0067] A new 1-bit bit field isBitmap is added to identify whether the current prefetch request contains a memory access address or a bitmap. For the prefetch request address, a new 1-bit FollowingBitmap is added to indicate whether a prefetch bitmap will follow. Since the two requests share the same transaction code, after receiving the above information, the next level of storage can decode the corresponding prefetch request and prefetch bitmap based on the above information. Prefetch requests and prefetch bitmaps can be issued back-to-back. Even if the system bus is congested due to too many transactions, the bus will dynamically generate signals to relieve congestion (such as the "Completer Busy" signal in the AMBA CHI protocol

[90] ). Therefore, the prefetch information issued based on CDCP will not cause bus congestion and affect system performance.

[0068] like Figure 3 As shown in the figure, the Bingo prefetcher in the L2 Cache needs to be modified. The dark gray part is the modification content. 1. The prefetch information is transmitted. 2. The Stride prefetcher does not add a new Bus bit field, reuses the lower 6 bits, and uses one transaction. 3. Bingo adds two new Bus bit fields, isBitmap / FollowingCDCP. 4. The Bingo prefetcher is divided into two transactions, sharing the same transaction ID (TransID).

[0069] Specifically, two more are needed on the basis of the original Bingo, located at isBitmap / FollowingCDCP. After obtaining the prefetch address from the Bingo prefetcher, the historical information of the corresponding prefetch address is taken out and passed to the next level of large capacity cache. The specific transmission method is:

[0070] (1) The prefetch address and history information are divided into two transactions. The first one is the prefetcher address. At this time, isBitmap=0 and FollowingCDCP=1, which means that the current transaction is the prefetch address, followed by the history information of the current prefetch address.

[0071] (2) In the second transaction, the address stored in the address is historical information, isBitmap=1, FollowingCDCP=0, indicating that the current transaction is historical information and is not followed by any CDCP information.

[0072] (3) Two transactions share the same ID. When the next-level cache controller receives the first transaction and decodes it and finds that FollowingCDCP=1, it waits for the next transaction to arrive.

[0073] when Figure 3 After the information in the transaction is transferred from L2 Cache to L3, the L3 controller will process it according to the information in the transaction.

[0074] like Figure 4 As shown in the figure, CDCP needs to add two bits in RSVDC for the bus: isBitmap / FolloingCDCP, which is used to transmit the information from the prefetcher. L4 Cache prefetches data based on the above information.

[0075] Embodiment 2 of the present invention: L2 level is equipped with a collaborative prefetcher CDCP (Collaborative Data Cache Prefetcher) based on shared information Stride prefetcher.

[0076] like Figure 5 As shown in the figure, when the memory access request Addr1 reaches the L2 prefetcher, the prefetch address Addr2, stride (Stride, 4 bits) and confidence (Confidence, 1 bit) are obtained based on the information recorded in the prefetcher. The stride, confidence and valid bit (Valid) are 6 bits in total, which can be integrated in the lower 6 bits of the prefetch request address. Therefore, there is no need to add a bit field outside the original request. Finally, a 52-bit prefetch request ({Addr2[51:6]: Confidence[5:5]: Stride[4:1]: Valid[0:0]}) with integrated prefetch information is formed and sent to the next level of storage.

[0077] When the above prefetch information reaches the L3 controller, it first decodes the last address of the prefetch request. Figure 6As shown, L3 queries whether the Valid Bit of the pre-fetch request (Request) is 1 to determine whether it can be bypassed; if it is, it is bypassed and sent directly to the next level large-capacity cache for pre-fetching. If Valid is found to be zero, it means that the request does not come with CDCP information, and it is processed according to the normal access process; if Valid is found to be set, it means that the current request comes with CDCP pre-fetch information, and the request can be sent directly to the L4 Cache controller to reduce CDCP processing delay, and the CDCP request is recorded in the CDCP Queue, and the L3 Cache is queried according to the normal process. If an L3 Cache hit occurs, the data is returned to L2 and the process ends. If a miss occurs, the CDCP Queue continues to be queried. If the request has been recorded in the CDCP Queue, it means that the pre-fetch has been issued, and the current memory access request is canceled, otherwise it needs to be sent to the L4 Cache controller.

[0078] When CDCP information is transmitted to the L4 Cache controller through the bus, it is first decoded by the controller. If Valid is found to be set, Addr is expanded according to Conf and Stride information. Specifically, assuming that the prefetch address Addr belongs to page P, that is, Addr=P + Offset, taking Stride equal to 2 as an example, if Conf is 0, it means that the credibility of the prefetch command based on the current stride is low, then a prefetch Bitmap is generated: P+ Offset, P+ Offset +2*CacheLine, P+ Offset + 4*CacheLine, until address P+ PageSize / 2. If Conf is 1, it means that the prefetch command based on the current stride has a high credibility, and the method of generating the prefetch address is the same, with the cutoff address being P+ PageSize. Finally, a prefetch Bitmap is generated to prefetch data for a cache line of a page granularity.

[0079] The present invention adopts the above technical solution, and aims at a large-capacity on-chip cache system, by merging historical information in the prefetcher system, so as to reduce redundant information, thereby reducing chip area and improving system performance.

[0080] Obviously, the described embodiments are part of the embodiments of the present application, rather than all of the embodiments. In the absence of conflict, the embodiments in the present application and the features in the embodiments can be combined with each other. The components of the embodiments of the present application generally described and shown in the drawings here can be arranged and designed in various different configurations. Therefore, the detailed description of the embodiments of the present application is not intended to limit the scope of the application claimed for protection, but merely represents the selected embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians of the art without making creative work are within the scope of protection of the present application.

Claims

1. A control method for a collaborative prefetcher for a large-capacity on-chip cache, wherein the cache structure used has at least one high-level cache for a conventional prefetcher of general capacity and at least one low-level cache for a large-capacity cache prefetcher, characterized in that: The method comprises the following steps: Step 1: The traditional prefetcher corresponding to the high-level cache obtains a common memory access request. The high-level cache queries the historical memory access request information recorded in the prefetcher matched with the high-level cache according to the common memory access request, generates a corresponding prefetch request according to the historical memory access information and the prefetcher structure, and combines or separately transmits the prefetch request and the common memory access request to the low-level cache. Step 2: The low-level cache controller receives the prefetch request sent by the high-level cache, and further operates according to the flag information and the current cache level: if the current cache level does not need to prefetch data according to the prefetch request, the prefetch request is passed to the next-level cache; If the current cache needs to pre-fetch data according to the request, the pre-fetch request is extended and pre-fetched according to the flag information.

2. The control method of a collaborative prefetcher for a large-capacity on-chip cache according to claim 1, characterized in that: The cache structure adopts L1 / L2 / L3 / L4 four-level cache, L2 cache is equipped with a traditional prefetcher for general capacity, and L4 is equipped with a prefetcher for large capacity cache. The specific steps of the method are as follows: Step 1: The traditional prefetcher corresponding to the L2 level obtains a common memory access request from the L1 level cache. The L2 level queries the historical memory access request information recorded in the L2 according to the common memory access request, generates a corresponding prefetch request after operating the corresponding flag bit according to whether the historical information is carried, and passes the prefetch request and the common memory access request together to the L3 level cache; Step 2, the L3 cache controller receives the prefetch request sent by the prefetcher corresponding to the L2 level, and determines whether it is prefetch history information according to the flag information; when prefetch history information is required, execute step 5; Otherwise, go to step 3; Step 3, determine whether L3 hits; if yes, return data and end; Otherwise, go to step 4; Step 4, determine whether a pre-fetch request has been sent for the current request; if yes, end; Otherwise, go to step 5; Step 5: Send the prefetch request to the L4 cache and extend the prefetch address; Step 6: The L4 cache controller expands and pre-fetches according to the historical information and ends.

3. The control method of a collaborative prefetcher for a large-capacity on-chip cache according to claim 2, characterized in that: The specific steps for step 1 applicable to L2 level with private information based Bingo prefetcher are: Step 1-1-1, the Bingo prefetcher divides the prefetch address and history information of the prefetch request into two separate transactions that share the same transaction code; Step 1-1-2, the Bingo prefetcher adds two bus bit fields, isBitmap and FollowingCDCP, and performs corresponding bit operations on the bus bit fields according to whether the current transaction sends a prefetch address or historical information; In step 1-1-3, the Bingo prefetcher sends two transactions with the newly added bus bit field to the L3 cache controller through the bus.

4. The control method of a collaborative prefetcher for a large-capacity on-chip cache according to claim 3, characterized in that: In step 1-1-2, in the first transaction, isBitmap=0 and FollowingCDCP=1, indicating that the current transaction contains the prefetch address instead of historical information, and is followed by a historical information transaction for the current prefetch address; in the second transaction, isBitmap=1 and FollowingCDCP=0, indicating that the current transaction contains historical information instead of address information, and is not followed by any historical information. The Addr bit field in the second transaction is used to store historical information.

5. The control method of a collaborative prefetcher for a large-capacity on-chip cache according to claim 3, characterized in that: The specific determination method of the L3 cache controller in step 2 is: The L3 cache controller queries the information of the newly added bus bit field in the current transaction: when FollowingCDCP=1, it means that the current transaction is the prefetch address and the subsequent historical information follows the current prefetch address, then wait for the next transaction to arrive; When isBitmap=1, it means that the current transaction is historical information and there is no subsequent historical information; then bypass is performed to directly send the expected request to the L4-level large-capacity cache for pre-fetching.

6. The control method of a collaborative prefetcher for a large-capacity on-chip cache according to claim 2, characterized in that: The specific steps of step 1 for L2 level with shared information based stride prefetcher are: Step 1-2-1, after the Stride prefetcher of the L2 cache receives the normal memory access request Addr1, it obtains the prefetch address Addr2, the stride Stride and the confidence Confidence based on the information recorded by the Stride prefetcher; Step 1-2-2, integrate the stride, credibility and valid bit into the lower 6 bits of the prefetch request address, and perform the bit operation on the valid bit according to whether the prefetch request carries historical information. Finally, the prefetch request with integrated prefetch information is sent to the L3 cache storage.

7. The control method of a collaborative prefetcher for a large-capacity on-chip cache according to claim 6, characterized in that: The specific determination method of the L3 cache controller in step 2 is: Step 2-1, the L3 cache controller obtains prefetch information and decodes the address of the valid bit in the prefetch request; Step 2-2, determine whether the valid bit is zero; if so, determine that no historical information is carried and process it according to the normal access process; otherwise, determine that the history is carried and bypass it to directly send the expected request to the L4 large-capacity cache for pre-fetching.

8. The control method of a collaborative prefetcher for a large-capacity on-chip cache according to claim 6, characterized in that: In step 5, the L3 cache controller sends the expected request to the L4 large-capacity cache and records the historical information request in the historical information queue of the L3 cache controller.

9. The control method of a collaborative prefetcher for a large-capacity on-chip cache according to claim 6, characterized in that: In step 6, the controller of the L4-level large-capacity cache queries whether the valid bit of the prefetch request is set to 1; if so, the Addr is expanded according to the Conf and Stride information to generate a prefetch Bitmap; wherein Conf stands for Confidence and Stride stands for stride; The specific method of generating a prefetch Bitmap is as follows: Assume that the prefetch address Addr belongs to page P, that is, Addr=P +Offset. When Conf is 0, it means that the credibility of the prefetch command based on the current stride is low, then generate the prefetch Bitmap: P+ Offset, P+ Offset + Stride* Cache Line, P+ Offset + 2* Stride* Cache Line, until the address P+ PageSize / 2, and finally generate a prefetch Bitmap; P represents the pointer to the page, Offset represents the offset inside the page, and PageSize represents the page size; When Conf is 1, it means that the prefetch command based on the current stride has a high credibility, and a prefetch Bitmap is generated: P+ Offset, P+ Offset + Stride* Cache Line, P+ Offset + 2* Stride* Cache Line, with a cutoff address of P+ PageSize, and finally a prefetch Bitmap is generated; data is prefetched for a cache line of a page granularity.

10. A collaborative prefetcher for a large-capacity on-chip cache, using the control method for a collaborative prefetcher for a large-capacity on-chip cache as claimed in claim 1, characterized in that: The collaborative prefetcher has at least one high-level cache matched with a conventional prefetcher for general capacity and at least one low-level cache matched with a prefetcher for large capacity cache. The conventional prefetcher corresponding to the high-level cache is used to obtain ordinary memory access requests, query the historical memory access request information recorded in the high-level cache according to the ordinary memory access request, generate a corresponding prefetch request after operating the corresponding flag bit according to whether the historical information is carried, and transmit the prefetch request and the ordinary memory access request to the low-level cache together; The low-level cache controller is used to receive the prefetch request sent by the high-level cache and further operate according to the flag information and the current cache level: if the current cache level does not need to prefetch data according to the prefetch request, the prefetch request is passed to the next-level cache; If the current cache needs to pre-fetch data according to the request, the pre-fetch request is extended and pre-fetched according to the flag information.

Images