Microprocessor, cache memory system and method implemented therein

Abstract

A microprocessor, a cache memory system, and methods implemented therein are provided. In one embodiment, a microprocessor includes a first data cache and a second data cache configured to handle both a miss in the first data cache caused by a first load or store operation and an eviction from the first data cache to accommodate the first load or store operation. The second data cache is configured to indicate to the first data cache that the eviction is complete before the eviction is actually complete based on a first state corresponding to the eviction.

Description

TECHNICAL FIELD

[0001] The present invention relates generally to microprocessors, and more particularly, to cache memory systems in microprocessors. BACKGROUND

[0002] Most modern computer systems include a microprocessor that performs computations required to execute software programs. The computer system also includes other devices (such as memory, etc.) connected to (or built into) the microprocessor. The memory stores software program instructions to be executed by the microprocessor. The memory also stores data manipulated by the program instructions to achieve the desired functionality of the program.

[0003] Devices in the computer system (such as memory, etc.) external to the microprocessor (or external to the processor core) are connected directly or indirectly to the microprocessor (or core) through a processor bus. The processor bus is a collection of signals that enables the microprocessor to transfer data in relatively large chunks. When the microprocessor executes program instructions that perform computations on data stored in the memory, the microprocessor uses the processor bus to fetch the data from the memory into the microprocessor. Similarly, the microprocessor uses the processor bus to write the results of the computations back to the memory.

[0004] The time required to fetch data from the memory or to write data to the memory is many times longer than the time required for the microprocessor to perform computations on the data. Thus, the microprocessor must inefficiently, idly, etc. wait for the data to be fetched from the memory. To reduce this problem, modern microprocessors include at least one cache memory. A cache memory or cache is a much smaller memory than the system memory, generally inside the microprocessor (or processor core), and it stores a subset of the data in the system memory. When the microprocessor executes an instruction that references data, the microprocessor first checks to see if the data is present in the cache and is valid. If so, the instruction can be executed much faster than if the data had to be retrieved from the system memory because the data is already present in the cache. That is, the microprocessor does not have to wait while the data is fetched from the memory to the cache using the processor bus. The case where the microprocessor detects that the data is present in the cache and is valid is commonly referred to as a cache hit. The case where the referenced data is not present in the cache is commonly referred to as a cache miss. When the referenced data is already in the cache, a significant time savings is achieved by avoiding the extra clock cycles required to retrieve the data from the external memory.

[0005] In some microprocessors, the cache is actually composed of multiple caches. The multiple caches are arranged in a hierarchical, multi-level structure. For example, a microprocessor can have two types of caches, referred to as a first level or level one (LI) cache and a second level or level two (L2) cache. The LI cache is closer to the computational elements of the microprocessor than the L2 cache. That is, the LI cache is able to provide data to the computational elements faster than the L2 cache. Although not necessarily, the L2 cache is typically larger than the LI cache. There can even be a third level (L3) cache, which is even larger than the LI and L2 caches, with the system memory ultimately accessed after the L3 (in the event of a miss).

[0006] In many microprocessor architectures, the LI cache is actually composed of two caches, an LI instruction (LIi) cache and an LI data (LId) cache. For the purposes of the present invention, particular emphasis is placed on the LId cache, as it is desired for load and store instructions to hit in the LId cache for speed and efficiency. If there is a miss, then the cache line needs to be brought in from elsewhere, and preferably the L2 cache. However, it can also be necessary to evict a cache line from the LId cache to make room for a new cache line. To handle these tasks, the L2 cache accesses a tag and data array pipeline, which also receives requests from other sources (e.g., I-cache requests, external snoops, evictions from the L2 cache to the L3 cache, etc.). While it is desirable from a performance perspective to satisfy, for example, a load request in the L2 cache every single clock cycle, it is complicated to achieve this benchmark due to other request sources trying to access the tag array / tag data pipeline, which can hinder the L2's ability to process load requests. In fact, it has been observed that evictions to the L2 cache are often delayed due to a backlog of LI d cache evictions in the L2 cache, primarily due to an inability to keep up with a steady stream of simultaneous loads and evictions. SUMMARY

[0007] In one embodiment, a microprocessor includes a first data cache and a second data cache configured to handle both a miss in the first data cache caused by a first load or store operation and an eviction from the first data cache to accommodate the first load or store operation, the second data cache configured to indicate to the first data cache that the eviction is complete prior to actually completing the eviction based on a first state corresponding to the eviction.

[0008] Other systems, methods, features, and advantages of the present application will be or become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features, and advantages be included within this description, be within the scope of the present application, and be protected by the accompanying claims. BRIEF DESCRIPTION OF DRAWINGS

[0009] Various aspects of the application can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the application. Furthermore, in the drawings, like reference numerals designate corresponding parts throughout the several views.

[0010] Figure 1 is a block diagram of an exemplary multi-core processor that implements an embodiment of a cache data eviction system.

[0011] Figure 2 is a block diagram illustrating certain features of a cache memory that is primarily used for communication with other system components.

[0012] Figure 3 is a block diagram of an embodiment of a cache data eviction system.

[0013] Figure 4 is a flow diagram of an embodiment of an exemplary cache data eviction method. DETAILED DESCRIPTION

[0014] Certain embodiments of a cache data eviction system and method are disclosed that alleviate the backlog of level one (LI) data cache evictions in a level two (L2) data cache, particularly in the presence of a steady stream of simultaneous loads and evictions. In one embodiment, the L2 data cache recognizes that an eviction from the LI data cache corresponds to a state of the evicted data (e.g., cache line) having a clean or unmodified state, and in such a case, immediately (e.g., within about two clock cycles) indicates to the LI data cache that the eviction is complete (e.g., via an update to the L2 cache directory) before the eviction is actually completed. By doing so, the eviction of a replacement to the same entry as the last eviction can proceed to the L2 data cache without delay, thus preventing a backlog of LI data cache evictions for such states.

[0015] In short, existing cache memory systems often experience a backlog of Ll data cache evictions because access to the L2 tag and / or data array pipelines needed for the evictions compete with other sources trying to access the tag and / or data array. Because of these multiple competitions for the pipeline resources, lower priority evictions are often delayed, resulting in a backlog. That is, while processing evictions, the Ll data cache waits for an indication from the L2 data cache that the eviction is complete, and until that time, the entry in the Ll data cache for enabling processing of the evictions cannot process a subsequent eviction from the same entry until the L2 data cache has completed processing of the front-most eviction. In contrast, because for cache coherency, a clean cache line does not need to be evicted, but only the directory of the L2 data cache is updated, certain embodiments of the cache data eviction system recognize when the data or cache line to be evicted is clean (e.g., exclusive or shared MESI state), thereby enabling the cache data eviction to indicate to the Ll data cache that the eviction is complete before the eviction is actually complete, preventing a backlog of Ll data cache evictions for clean cache lines.

[0016] Having summarized certain features of the cache data eviction system of the present invention, a cache data eviction system as illustrated in the accompanying drawings will now be described in detail. While the cache data eviction system will be described in connection with these drawings, it is not intended to limit the scope of the application to the embodiments disclosed herein. Rather, it is intended to cover all alternatives, modifications, and equivalents as can be included within the spirit and scope of the application. For instance, while examples are provided for load / store allocation to the Ll data cache and evictions from the Ll data cache to the L2 cache, one of ordinary skill in the art will appreciate that similar principles can be applied to other cache hierarchies, including in some embodiments allocation and evictions from, for example, the L2 cache to the L3 cache. Thus, it is to be understood that the drawings and detailed description thereto are not intended to limit the application to the particular form disclosed. Rather, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the application as defined by the appended claims. As used in this application, the word "can" is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words "include," "including," and "includes" mean including, but not limited to.

[0017] Various units, modules, circuits, logic, or other components can be described herein as being "configured to" perform a particular task or tasks. In this context, "configured to" means that the components of the structure are arranged to perform the task or tasks during operation. The "configured to" can include both special-purpose circuitry and / or encodings of general-purpose circuitry (e.g., encodings of microinstructions at the circuit level) that are specifically designed to carry out the task or tasks during operation.

[0018] Further, units / modules / circuits / logic / components can be configured to perform tasks even when the units / modules / circuits / logic / components are not currently in operation. Units / modules / circuits / logic / components recited as being configured to perform one or more tasks are clearly not intended to be limited to only those units / modules / circuits / logic / components that are in operation at the time the task or tasks are being performed. In this regard, those skilled in the art will appreciate that the particular structure of circuit elements or interconnections will generally be determined by the compiler of the design automation tool (such as a register transfer language (RTL) compiler), which is in turn determined by the script that is run on the compiler. The script is very similar to assembly language code, and is compiled into a form that is used to layout or manufacture the final circuit.

[0019] That is, integrated circuits such as those of the present application are designed using more advanced software tools to model the desired functional operation of the circuit. As is well known, "electronic design automation" (or EDA) is a category of software tools for designing electronic systems such as integrated circuits. EDA tools are also used to program designs into field-programmable gate arrays (FPGAs). Hardware description languages (HDLs) such as Verilog and very high speed integrated circuit hardware description language (VHDL) are used to create a high-level representation of the circuit from which a lower-level representation and ultimately the actual wiring can be inferred. In practice, because modern semiconductor chips can have billions of components, EDA tools are considered indispensable to their design. In practice, circuit designers use programming languages such as C / C++ to specify the functional operation. The EDA software tools convert the specified functionality into RTL. Hardware description languages (e.g., Verilog) then convert the RTL into a discrete netlist of gates. The netlist defines the actual circuit that is produced by, for example, a foundry. In practice, these tools are well known and understood for their role and use in facilitating the design process of electronic and digital systems, and thus need not be described here.

[0020] As will be described herein, the present application is directed to a cache data eviction system. However, prior to describing an exemplary cache data eviction system, an exemplary architecture in which the cache data eviction system can be utilized is described. In this regard, reference is now made to Figure 1 , Figure 1 is a diagram illustrating a multi-core processor 100 (also referred to herein as microprocessor 100). As will be appreciated by those of ordinary skill in the art from the description provided herein, the present application can be implemented in a variety of different circuit configurations and architectures, and Figure 1 the architecture illustrated in Figure 1 is but one of many suitable architectures. Specifically, in the embodiment illustrated in

[0021] In the illustrated embodiment, a large number of circuit components and details are omitted that are not closely related to the understanding of the application. As will be appreciated by those of skill in the art, each processing core (110_0 through 110_7) includes certain associated or attendant circuitry that is repeated throughout the processor 100. Each such associated sub-circuit is represented in the illustrated embodiment as a slice. In the case of eight processing cores 110_0 through 110_7, there are correspondingly eight slices 102_0 through 102_7. Other circuitry not described herein is represented simply as "other slice logic" 140_0 through 140_7.

[0022] In the illustrated embodiment, a three-level cache system is employed that includes a level one (LI) cache, a level two (L2) cache, and a level three (L3) cache. The LI cache is split into a data cache and an instruction cache, labeled LI d and LI i, respectively. The L2 cache also resides on the core, meaning that both the level one and level two caches are in the same circuit as the core that is each slice. That is, each core of each slice has its own dedicated LI d, LI i, and L2 cache. The L3 cache is outside the core, but within each slice. In the preferred embodiment, the L3 cache 130_0 through 130_7 (also referred to herein collectively as 130) is a distributed cache, meaning that 1 / 8 of the L3 cache resides in slice 0 (102_0), 1 / 8 of the L3 cache resides in slice 1 (102_1), and so on. In the preferred embodiment, each LI cache is 32k in size, each L2 cache is 256k in size, and each slice of the L3 cache is 2 megabytes in size. From this, the total size of the L3 cache is 16 megabytes.

[0023] Bus interface logic 120_0 through 120_7 is provided in each slice to manage communications from various circuit components between different slices. As shown in each of the slices, Figure 1 The communication bus 190 is used to allow communication between various circuit slices as well as communication with non-core circuitry 160, as shown. The non-core circuitry 160 represents only additional circuitry on the processor chip, but is not part of the core circuitry associated with each slice. As with each of the illustrated slices, the non-core circuitry 160 includes bus interface circuitry 162. Also shown is a memory controller 164 for connection with processor off-chip memory 180. Finally, other non-core logic 166 is represented by the block broadly, which represents other circuitry that can be included as part of the non-core processor circuitry (and again, need not be described for an understanding of the present invention).

[0024] To better illustrate certain communications between and within some of these circuit components, the following example will be presented. This example illustrates communications associated with a hypothetical load miss in core 6 cache. That is, the hypothetical assumes that the processing core 6 (110_6) is executing code that requests data at address 1000. When this load request is encountered, the system first makes a lookup in the LI d 114_6 to see if the data is present in the LI d cache. Assuming that the data is not in the LI d cache, a lookup is made in the L2 cache 112_6. Again, assuming that the data is not in the L2 cache, a lookup is made to see if the data is present in the L3 cache. As noted above, the L3 cache is a distributed cache, so if in fact the data resides in the L3 cache, the system first needs to determine in which slice of the L3 cache the data resides. As known, this can be handled using a hash function (which is simply an XOR of the bits) to obtain a three bit address (sufficient to identify in which slice (slice 0 through slice 7) the data will be stored).

[0025] Consistent with this example, assume that the hash function yields the following indication: the data, if present in the L3 cache, would be present in the portion of the L3 cache that resides in slice 7. Then, communication is made from the L2 cache of slice 6 (102_6) through bus interfaces 120_6 and 120_7 to the L3 slice present in slice 7 (102_7). This communication is represented in the figure by circled number 1. If the data is present in the L3 cache, then communication will be made from L3 (130_7) back to the L2 cache 112_6. However, and in this example, assume that the data is not present in the L3 cache either, resulting in a cache miss. As a result, communication is made through memory controller 164 from the L3 cache 130_7 through bus interface 7 (120_7) through the non-core bus interface 162 to the off-chip memory 180. This communication is represented in the figure by circled number 2. Then, through memory controller 164 and non-core bus interface 162, a cache line including the data residing at address 1000 is communicated from the off-chip memory 180 back into the L3 cache 130_7, as represented by circled number 3. After this data is written into the L3 cache, then the data is communicated through bus interfaces 120_7 and 120_6 to the requesting core (core 6 (110_6)).

[0026] At this point, once the load request has been completed, the data will reside in each of the cache L3, L2 and Ll d. Certain embodiments of the present invention relate to a cache memory data eviction system that resides in the cache memory system (and in the following example, in the Ll d and L2 caches). Before describing the details of the cache data eviction system, first refer to Figure 2 , Figure 2 is a block diagram showing various circuit components of each of the L2 caches 112. In particular, Figure 2 The components shown in Figure 1 The components shown in Figure 1As shown, in each core, there are both L1 d and L1 i caches as well as a higher level L2 cache. L1 d interface 210 and L1 i interface 220 connect the L2 cache with the L1 caches. These interfaces implement, for example, load queues, eviction queues, and query queues as mechanisms to facilitate this communication. Prefetch interface 230 is circuitry that facilitates communication associated with prefetching. In one embodiment, the prefetcher implements both a bounding box prefetch algorithm and a stream prefetch algorithm and ultimately makes a prefetch determination that is the result of a combination of the results of these two algorithms. The bounding box prefetch algorithm can be similar to the algorithm described in US 8,880,807, which is incorporated herein by reference. There are many known stream prefetch algorithms that can be used by the prefetcher.

[0027] As will be appreciated by those skilled in the art, the prefetch algorithm is performed in part by monitoring load requests from the corresponding core to the associated L1 i and L1 d caches. Thus, these are shown as inputs to prefetch interface 230. The output of prefetch interface 230 takes the form of requests to access tag pipe 250, the relevant functionality of which will be understood by those skilled in the art, as described briefly here. Finally, external interface 240 provides an interface to components outside the L2 cache and indeed outside the processor core. As described in connection with Figure 1 Such communication, particularly off-chip communication, is routed through bus interface 120, as described.

[0028] As Figure 2As shown, each of the circuit blocks 210, 220, 230, and 240 has an output denoted as a tag pipeline (access) request. A tag pipeline 250 is provided as a central point through which almost all L2 cache traffic travels. In the illustrated embodiment, there are two tag pipelines denoted as A and B. Two such tag pipelines are provided merely for load balancing, and as such, tag pipeline requests output from the circuit 210, 220, 230, and 240 (different interface circuits) can be directed to tag pipeline A or tag pipeline B again based on load balancing. In one embodiment, the tag pipeline is a four-stage pipeline, the stages of which are denoted by the letters A, B, C, and D. Transactions accessing the tag / data arrays via the tag pipeline (sometimes referred to herein as "tag pipeline requests") progress through the stages of the tag pipeline 250. During the A stage, the transaction requests access to the tag pipeline. During the B stage, the tag is sent to the arrays (tag array 260 and data array 270). During the C stage, MESI information is received from the arrays as well as an indication of whether the tag hit or missed, and a determination is made as to what action to take given the information received from the arrays. During the D stage, the action decision (complete / re-do, push FillQ, etc.) is made back to the request queue.

[0029] Finally, Figure 2 The tag array 260 and data array 270 are shown. The tag array 260 effectively or substantially comprises metadata, while the data array is memory space comprising actual cache lines of data. The metadata in the tag array 260 includes MESI state as well as Ll i and Ll d valid bits. As known, the MESI state defines whether the data stored in the data array is in a modified ("M"), exclusive ("E"), shared ("S"), or invalid ("I") state.

[0030] A similar, but prior version of this architecture is described in US 2016 / 0350215, which is incorporated herein by reference. As the understanding of the details regarding communication of components within the circuit is not essential to understanding the present invention, and in fact is within the skill level of one of ordinary skill in the art, no further description is required here.

[0031] Having provided a description of an exemplary overall environment in which certain embodiments of a cache data eviction system can be implemented, attention will now be directed to Figure 3 , Figure 3An embodiment of a cache data eviction system 300 is shown. The cache data eviction system 300 includes an L1 data (L1d) cache 114 and an L2 cache 112. The L1 data cache 114 includes an L1d load queue (L1d LoadQ) 302, an L1d store queue (L1d StoreQ) 304, and an L1d fill queue (L1d FillQ) 306. The L2 cache includes an L2 data load queue (L2 DataLoadQ) 308, an L2 data eviction queue (L2 DataEvictQ) 310, and a tag and data array pipeline 312, where the L2 DataLoadQ 308 and the L2 DataEvictQ 310 compete with other sources 314 (e.g., 314a, 314b) for access. Note that the tag and array pipeline 312 can correspond to the components (e.g., 250, 260, and 270) shown in FIG. 2. Figure 2

[0032] Referring first to the shown components of the L1 data cache 114, the L1d load queue 302 includes a load operation queue, where some of the load operation queue can require access to the L2 cache 112, and thus further provides an indication (e.g., bit state) of whether an entry will be allocated in the L1d fill queue 306. To determine whether the L1 data cache 114 has data for a given load operation, the L1d load queue 302 requests access to the tag array, and if there is a hit, accesses the L1 data cache array and satisfies the request, and makes any needed changes to the MESI state as is conventional. In the event that the requested cache line is not identified in the tag array (e.g., a miss), the L1d load queue 302 attempts to service the load operation via the L2 cache 112. As such, the L1d load queue 302 requests allocation of an entry in the L1d fill queue 306 (e.g., to bring the cache line in from the L2 cache 112, or possibly out). In one embodiment, the L1d load queue 302 includes seventy-two (72) entries for respective load operations, although a different number of entries can be used in some embodiments.

[0033] The L1d store queue 304 includes a store operation queue, where some of the store operation queue can require access to the L2 cache 112, and thus further provides an indication (e.g., bit state) of whether an entry will be allocated in the L1d fill queue 306 based on similar processing as described above for load requests handled by the L1d load queue 302, and thus, the same or similar discussion is omitted here for brevity. In one embodiment, the L1d store queue 304 includes forty-four (44) entries for respective store operations, although a different number of entries can be used in some embodiments. ​

[0034] The LI d fill queue 306 includes a queue of load and / or store operations that require access to the L2 cache 112. Individual entries of the LI d fill queue 306 correspond to an LI d load queue entry, an LI d store queue entry, or a prefetch, or in some embodiments, a table walk request (e.g., to walk a linear to physical mapping based on a miss in a translation lookaside buffer). The LI d fill queue 306 is also configured to allocate space for new cache lines (e.g., evict data from the LI data cache 114) and bring new cache lines into the LI data cache 114 (e.g., into the location of the previously evicted data). In one embodiment, the LI d fill queue 306 includes a number of entries for load or store operations, with individual entries tracking their respective allocation and eviction. In one embodiment, there are ten (10) entries, although a different number of entries can be used in some embodiments.

[0035] Referring now to the illustrated components of the L2 cache 112, the L2 data load queue 308 includes a queue of LI d allocation requests and an indication of the status of individual entries of the allocation request at the L2 cache 112 (e.g., a status such as pending). In one embodiment, the L2 data load queue 308 includes ten (10) entries, although a different number of entries can be used in some embodiments. As Figure 3 As represented by the exemplary arrow lines in FIG. 3, individual entries of the L2 data load queue 308 are mapped one-to-one to corresponding entries of the LI d fill queue 306 (e.g., LI d FillQ[0] always uses L2DataLoadQ[0] for its LI d load allocation request).

[0036] The L2 data eviction queue 310 includes a queue of LI d eviction requests and an indication of the status of individual entries of the eviction at the L2 cache 112 (e.g., a status such as pending). In one embodiment, the L2 data eviction queue 310 includes ten (10) entries, although a different number of entries can be used in some embodiments. As Figure 3As represented by the exemplary arrow lines, each entry of the L2 data eviction queue 310 is mapped one-to-one to a corresponding entry of the L1d fill queue 306 (e.g., L1d FillQ[0] always uses L2DataEvictQ[0] for its evictions). The L2 cache 112 also includes a bus (e.g., a multi-hot bus) from the L2 data eviction queue 310 to the L1d fill queue 306, where the valid bit of each entry of the L2 data eviction queue 310, when asserted, indicates that the eviction is still being processed (e.g., EvQValid[0] = 1 indicates to the corresponding L1d fill queue entry, L1dFillQ[0], that the eviction is still pending). Moreover, when an L1d fill queue entry (e.g., L1dFillQ[n]) is allocated, it must wait for the corresponding valid bit to be de-asserted (e.g., EvQValid[n] = 0) before sending its eviction, otherwise its eviction can overwrite a previous eviction from the same entry (e.g., L1dFillQ[n]).

[0037] The L2 data load queue 308 and the L2 data eviction queue 310 request access to the pipeline 312 to access the tag array to determine whether the L2 cache 112 owns the cache line requested by the L1, and in the case of a hit, to access the data array and return the data (cache line) to the L1 data cache 114. In the case of a miss in the tag array, a different cache (e.g., L3 cache) can be accessed to obtain the requested cache line. The L2 data eviction queue 310 requests access to, for example, write dirty data to the L2 cache array, update directory bits (of the L2 tag array) to reflect that the L1 data cache 114 no longer owns the cache line being evicted. Note that the L2 cache 112 includes a directory (not shown) as known, which enables the L2 cache 112 to record information such as L2 cache MESI state, whether the cache line is valid in the L1 data cache 114 (and L1i cache) (using valid bits), etc. While both the L2 data load queue 308 and the L2 data eviction queue 310 potentially require access to the tag and / or data arrays of the pipeline 312, note that other sources 314 also compete for pipeline resources. The other sources 314 can include I-cache requests, external snoop, other processing demands on the L2 cache 112 (e.g., data returned from the L3 cache to be written into the data array and / or tag array). Despite the competition for pipeline resources, the L2 cache 112 should also maintain suitable performance. For example, one benchmark can be to process one load request in the L2 cache 112 per single clock cycle, which is a challenge given all of these sources 314 attempting to request access to the pipeline 312.

[0038] In one example operation, a load or store operation is queued in the L1 d load queue 302 or the L1 d store queue 304. When the load or store operation misses in the L1 data cache 114, an entry is allocated in the L1 d fill queue 306. The L1 d fill queue 306 in turn sends a load request to the L2 cache 112, which is tracked in the L2 data load queue 308. The L1 d fill queue 306 can also need to evict a cache line to make room for or accommodate a new cache line, and if eviction is needed, the L2 data eviction queue 310 tracks the eviction. The L2 data eviction queue 310 signals the L1 d fill queue 306 that eviction is in progress using valid bits (e.g., EvQValid, as described above), where each bit corresponds to a particular entry of the L2 data eviction queue 310 (and thus to a particular L1 d fill queue entry).

[0039] Before describing embodiments of the cache data eviction system 300, a brief aside can help to understand how an eviction backlog can exist using conventional cache eviction techniques. Each L2 data eviction queue entry tracks only one eviction for that entry at a time. Thus, the L1 d fill queue entry must wait for its corresponding valid bit to de-assert for a previous eviction (assuming it was asserted) before the L1 d fill queue 306 can send a new eviction from that reallocated entry to the same L2 data eviction queue entry. This behavior is implemented to prevent the L1 d fill queue entry from overwriting an eviction from a previous L1 d fill queue entry (e.g., if that eviction has not completed when the L1 d fill queue entry is reused). However, as noted above, it has been observed that, using past techniques, L1 d fill queue entries generally cannot send their evictions to the L2 data eviction queue in a timely manner due to a backlog of L1 data evictions in the L2 cache (primarily due to the L2 being unable to keep up with a steady stream of simultaneous loads and evictions).

[0040] The handling of cache line evictions in the cache data eviction system 300 is premised, at least in part, on the recognition that in some cases the L2 cache 112 can safely ignore certain evictions and immediately allow a subsequent eviction without violating cache coherency, thus enabling the subsequent L1 d fill queue entry to send its eviction (e.g., based on the de-asserted valid bit) without waiting for the prior eviction to complete. The handling of cache line evictions in the cache data eviction system 300 is further premised on the recognition that an eviction is being performed can be a result of a need to bring the cache line into the L1 data cache 114, meaning that servicing or handling the load needs higher priority. In one embodiment, if the L1 data cache 114 is evicting a dirty cache line (e.g., with a Modified (M) MESI state), the L2 cache 112 needs to handle the eviction to maintain cache coherency (and thus delay the subsequent eviction from the same L1 d fill queue entry). However, in the case where the L1 data cache 114 is evicting a clean cache line (e.g., with a Shared (S) or Exclusive (E) MESI state), the eviction is not actually needed for cache coherency. Instead, the eviction is used only by the L2 cache 112 to update its directory (e.g., by clearing the L1 data cache valid bit corresponding to the evicted cache line), thus preventing a potential unnecessary snoop request.

[0041] In an embodiment of the cache data eviction system 300, the L2 data eviction queue 310, upon receiving an eviction from the L1 d fill queue 306, asserts its valid bit signal (EvQValid) to the L2 cache 112, and then de-asserts the valid bit signal to the L1 d fill queue 306 along the bus immediately (e.g., within about two clock cycles) if the state of the cache line being evicted is clean (e.g., S or E MESI state). Note that if the cache line being evicted is dirty (e.g., M MESI state), the standard eviction process continues until completion before the valid bit is de-asserted. For the case of a clean eviction, the L2 data eviction queue 310 continues to handle the eviction until the earlier of completion of the eviction and receipt of a subsequent eviction from the same L1 d fill queue entry (e.g., which overwrites the older clean eviction in the L2 data eviction queue 310). Thus, the L2 data eviction queue 310 indicates to the L1 d fill queue 306 that its eviction has completed early (even before the eviction is actually completed via the update to the L2 cache directory) so that the same entry in the L1 d fill queue 306 can begin its eviction process immediately when the entry is reallocated for a later allocation.

[0042] Note that in some embodiments, as will be appreciated by those of ordinary skill in the art, in addition to the control logic for the overall or aggregate operation of the LI data cache 114 and the L2 cache 112, Figure 3 Each entry of the illustrated queue includes its own control logic or state machine for the parallel operation.

[0043] Having described certain embodiments of a cache data eviction system, one of ordinary skill will appreciate that in Figure 4 One embodiment of a data cache eviction method, depicted in FIG. 4 and denoted as method 400, can be implemented in a microprocessor and in particular in the cache data eviction system 300 Figure 3 ) In one embodiment, the method 400 includes handling both a miss in a first data cache caused by a first load or store operation and an eviction from the first data cache to accommodate the first load or store operation with a second data cache (402) and indicating to the first data cache that the eviction is complete from the second data cache prior to the eviction actually being complete based on a first state corresponding to the eviction (404).

[0044] Any process descriptions or blocks in flow charts should be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process, and alternate implementations are included within the scope of embodiments in which functions can be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as will be understood by those skilled in the art.

[0045] While the application has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative or exemplary and not restrictive; the application is not limited to the disclosed embodiments. Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed application, from a study of the drawings, the disclosure, and the appended claims.

[0046] Note that various combinations of the disclosed embodiments can be used, so reference to an embodiment or one embodiment does not preclude features being used from other embodiments. In the claims, the word "comprising" does not exclude the other elements or steps not mentioned in the claims.

Claims

1. A microprocessor comprising: a first data cache; and a second data cache configured to handle both a miss in the first data cache caused by a first load or store operation and an eviction from the first data cache to accommodate the first load or store operation, the second data cache configured to indicate to the first data cache that the eviction is complete before the eviction is actually complete based on a first state corresponding to the eviction.

2. The microprocessor of claim 1, wherein, The second data cache continues to handle the eviction after sending the indication to the first data cache until the earlier of both actually completing the eviction by updating a directory in the second data cache and rewriting the eviction.

3. The microprocessor of claim 1, wherein, The first state corresponds to an evicted cache line that has not been modified since being allocated in the first data cache.

4. The microprocessor of claim 1, wherein, The first state corresponds to an evicted cache line that includes a modified or shared MESI state.

5. The microprocessor of claim 1, wherein, The second data cache is further configured to handle both a miss in the first data cache caused by a second load or store operation and another eviction from the first data cache to accommodate the second load or store operation, the second data cache configured to indicate to the first data cache that the other eviction is pending until the other eviction is actually complete based on a second state corresponding to the other eviction.

6. The microprocessor of claim 5, wherein, The second state corresponds to an evicted cache line that has been modified since being allocated in the first data cache.

7. The microprocessor of claim 5, wherein, The second state corresponds to an evicted cache line that includes a modified MESI state.

8. A cache memory system comprising: a primary data cache including a primary data load queue, a primary data store queue, and a primary data fill queue, the primary data fill queue configured to allocate an entry in the primary data fill queue corresponding to a first load or store operation in the primary data load queue or the primary data store queue, respectively, based on a miss in the primary data cache and evict first data from the primary data cache to allocate space for the first load or store operation; and a secondary data cache including a secondary data load queue and a secondary data eviction queue, the secondary data load queue configured to receive a primary data cache allocation request for the first load or store operation, the secondary data eviction queue configured to receive the first data mapped to a respective entry of the secondary data load queue and the secondary data eviction queue, the secondary data eviction queue configured to indicate to the primary data fill queue that eviction of the first data is complete before the eviction of the first data is actually complete based on a first state corresponding to the first data.

9. The cache memory system of claim 8, wherein, The second data cache further comprises a tag array and a data array pipeline, wherein the second data eviction queue is further configured to request access to the pipeline after sending the indication to the first data fill queue until the earlier of actually completing the eviction of the first data by updating a directory in the second data cache and overwriting the eviction by reassigning data to the same entry of the first data fill queue.

10. The cache memory system of claim 8, further comprising a bus, the bus comprising a bit value configured to communicate the indication, wherein, The bit value is asserted upon receiving the eviction and then de-asserted immediately upon reassigning an entry for a second eviction for a second load or store operation based on another miss in the first data cache to enable the first data fill queue to evict second data.

11. The cache memory system of claim 8, wherein, The first state corresponding to the first data comprises an indication that the first data has not been modified since being assigned to the first data cache.

12. The cache memory system of claim 8, wherein, The first state corresponding to the first data comprises an exclusive or shared MESI state.

13. The cache memory system of claim 8, wherein, The first data fill queue is further configured to assign an entry corresponding to a third load or store operation in the first data load queue or the first data store queue, respectively, based on a miss in the first data cache and evict third data from the first data cache to allocate space for the third load or store operation, the second data load queue is further configured to receive a first data cache assignment request for the third load or store operation, and the second data eviction queue is further configured to receive an entry corresponding to the third load or store operation mapped to respective entries of the second data load queue and the second data eviction queue, the second data eviction queue being configured to indicate to the first data fill queue that eviction of the third data is pending based on a second state corresponding to the third data until the eviction is actually completed.

14. The cache memory system of claim 13, wherein, The second state corresponding to the third data comprises an indication that the third data has been modified since being assigned to the first data cache.

15. The cache memory system of claim 13, wherein, The second state corresponding to the third data comprises a modified MESI state.

16. A method implemented in a cache memory system of a microprocessor, the method comprising: handling, with a second data cache, both a miss in a first data cache caused by a first load or store operation and an eviction from the first data cache to accommodate the first load or store operation; and indicating from the second data cache to the first data cache that the eviction is complete before the eviction is actually completed based on a first state corresponding to the eviction.

17. The method of claim 16, further comprising: The second data cache continues to handle the eviction after sending the indication to the first data cache until the earlier of actually completing the eviction by updating a directory in the second data cache and overwriting the eviction. The second data cache continues to handle the eviction after sending the indication to the first data cache until the earlier of actually completing the eviction by updating a directory in the second data cache and overwriting the eviction.

18. The method of claim 16, wherein, The first state corresponds to evicted cache lines that have not been modified since being allocated into the first data cache.

19. The method of claim 16, further comprising: The second data cache handles both a miss in the first data cache caused by a second load or store operation and another eviction from the first data cache to accommodate the second load or store operation; and The second data cache indicates to the first data cache that the other eviction is pending until the other eviction is actually completed based on a second state corresponding to the other eviction.

20. The method of claim 19, wherein, The first state corresponds to evicted cache lines that have not been modified since being allocated into the first data cache. The second state corresponds to evicted cache lines that have been modified since being allocated into the first data cache.

Images