Patent ID: 12197331

DETAILED DESCRIPTION

FIG.1shows a block diagram of a system100in accordance with an example of this disclosure. The example system100includes multiple CPU cores102a-102n. Each CPU core102a-102nis coupled to a dedicated L1 cache104a-104nand a dedicated L2 cache106a-106n. The L2 caches106a-106nare, in turn, coupled to a shared third level (L3) cache108and a shared main memory110(e.g., double data rate (DDR) random-access memory (RAM)). In other examples, a single CPU core102is coupled to a L1 cache104, a L2 cache106, a L3 cache108, and main memory110.

In some examples, the CPU cores102a-102ninclude a register file, an integer arithmetic logic unit, an integer multiplier, and program flow control units. In an example, the L1 caches104a-104nassociated with each CPU core102a-102ninclude a separate level one program cache (L1P) and level one data cache (L1D). The L2 caches106a-106nare combined instruction/data caches that hold both instructions and data. In certain examples, a CPU core102aand its associated L1 cache104aand L2 cache106aare formed on a single integrated circuit.

The CPU cores102a-102noperate under program control to perform data processing operations upon data. Instructions are fetched before decoding and execution. In the example ofFIG.1, L1P of the L1 cache104a-104nstores instructions used by the CPU cores102a-102n. A CPU core102first attempts to access any instruction from L1P of the L1 cache104. L1D of the L1 cache104stores data used by the CPU core102. The CPU core102first attempts to access any required data from L1 cache104. The two L1 caches104(L1P and L1D) are backed by the L2 cache106, which is a unified cache. In the event of a cache miss to the L1 cache104, the requested instruction or data is sought from L2 cache106. If the requested instruction or data is stored in the L2 cache106, then it is supplied to the requesting L1 cache104for supply to the CPU core102. The requested instruction or data is simultaneously supplied to both the requesting cache and CPU core102to speed use.

The unified L2 cache106is further coupled to a third level (L3) cache108, which is shared by the L2 caches106a-106nin the example ofFIG.1. The L3 cache108is in turn coupled to a main memory110. As will be explained in further detail below, memory controllers facilitate communication between various ones of the CPU cores102, the L1 caches104, the L2 caches106, the L3 cache108, and the main memory110. The memory controller(s) handle memory centric functions such as cacheabilty determination, cache coherency implementation, error detection and correction, address translation and the like. In the example ofFIG.1, the CPU cores102are part of a multiprocessor system, and thus the memory controllers also handle data transfer between CPU cores102and maintain cache coherence among CPU cores102. In other examples, the system100includes only a single CPU core102along with its associated L1 cache104and L2 cache106.

FIG.2shows a block diagram of a system200in accordance with examples of this disclosure. Certain elements of the system200are similar to those described above with respect toFIG.1, although shown in greater detail. For example, a CPU core202is similar to the CPU core102described above. The L1 cache104subsystem described above is depicted as L1D204and L1P205. The L2 cache106described above is shown here as L2 cache subsystem206. An L3 cache208is similar to the L3 cache108described above. The system200also includes a streaming engine210coupled to the L2 cache subsystem206. The system200also includes a memory management unit (MMU)207coupled to the L2 cache subsystem206.

The L2 cache subsystem206includes L2 tag ram212, L2 coherence (e.g., MESI) data214, shadow L1 tag ram216, and L1 coherence (e.g., MESI) data218. Each of the blocks212,214,216,218are alternately referred to as a memory or a RAM. The L2 cache subsystem206also includes tag ram error correcting code (ECC) data220. In an example, the ECC data220is maintained for each of the memories212,214,216,218.

The L2 cache subsystem206includes L2 controller222, the functionality of which will be described in further detail below. In the example ofFIG.2, the L2 cache subsystem206is coupled to memory (e.g., L2 SRAM224) including four banks224a-224d. An interface230performs data arbitration functions and generally coordinates data transmission between the L2 cache subsystem206and the L2 SRAM224, while an ECC block226performs error correction functions. The L2 cache subsystem206includes one or more control or configuration registers228.

In the example ofFIG.2, the L2 SRAM is depicted as four banks224a-224d. However, in other examples, the L2 SRAM includes more or fewer banks, including being implemented as a single bank. The L2 SRAM224serves as the L2 cache and is alternately referred to herein as L2 cache224.

The L2 tag ram212includes a list of the physical addresses whose contents (e.g., data or program instructions) have been cached to the L2 cache224. In an example, an address translator translates virtual addresses to physical addresses. In one example, the address translator generates the physical address directly from the virtual address. For example, the lower n bits of the virtual address are used as the least significant n bits of the physical address, with the most significant bits of the physical address (above the lower n bits) being generated based on a set of tables configured in main memory. In this example, the L2 cache224is addressable using physical addresses. In certain examples, a hit/miss indicator from a tag ram212look-up is stored.

The L2 MESI memory214maintains coherence data to implement full MESI coherence with L2 SRAM224, external shared memories, and data cached in L2 cache from other places in the system200. The functionalities of system200coherence are explained in further detail below.

The L2 cache subsystem206also shadows L1D tags in the L1D shadow tag ram216and L1D MESI memory218. The tag ram ECC data220provides error detection and correction for the tag memories and, additionally, for one or both of the L2 MESI memory214and the L1D MESI memory218. The L2 cache controller222generally controls the operations of the L2 cache subsystem206, including handling coherency operations both internal to the L2 cache subsystem206and among the other components of the system200.

FIG.3shows a block diagram of a system300that demonstrates various features of cache coherence implemented in accordance with examples of this disclosure. The system300contains elements similar to those described above with respect toFIGS.1and2. For example, the CPU core302is similar to the CPU cores102,202.FIG.3also includes a L1 cache subsystem304, a L2 cache subsystem306, and an L3 cache subsystem308. The L1 cache subsystem304includes a L1 controller310coupled to L1 SRAM312. The L1 controller310is also coupled to a L1 main cache314and a L1 victim cache316, which are explained in further detail below. In some examples, the L1 main and victim caches314,316implement the functionality of L1D204and/or L1P205.

The L1 controller310is coupled to a L2 controller320of the L2 cache subsystem306. The L2 controller320also couples to L2 SRAM322. The L2 controller320couples to a L2 cache324and to a shadow of the L1 main cache326as well as a shadow of the L1 victim cache328. L2 cache324and L2 SRAM322are shown separately for ease of discussion, although may be implemented physically together (e.g., as part of L2 SRAM224, including in a banked configuration, as described above. Similarly, the shadow L1 main cache326and the shadow L1 victim cache328may be implemented physically together, and are similar to the L1D shadow tag ram216and the L1D MESI218, described above. The L2 controller320is also coupled to a L3 controller309of the L3 cache subsystem308. L3 cache and main memory (e.g., DDR110described above) are not shown for simplicity.

Cache coherence is a technique that allows data and program caches, as well as different requestors (including requestors that do not have caches) to determine the most current data value for a given address in memory. Cache coherence enables this coherent data value to be accurately reflected to observers (e.g., a cache or requestor that issues commands to read a given memory location) present in the system300. Certain examples of this disclosure refer to an exemplary MESI coherence scheme, in which a cache line is set to one of four cache coherence states: modified, exclusive, shared, or invalid. Other examples of this disclosure refer to a subset of the MESI coherence scheme, while still other examples include more coherence states than the MESI coherence scheme. Regardless of the coherence scheme, cache coherence states for a given cache line are stored in, for example, the L2 MESI memory214described above.

A cache line having a cache coherence state of modified indicates that the cache line is modified with respect to main memory (e.g., DDR110), and the cache line is held exclusively in the current cache (e.g., the L2 cache324). A modified cache coherence state also indicates that the cache line is explicitly not present in any other caches (e.g., L1 or L3 caches).

A cache line having a cache coherence state of exclusive indicates that the cache line is not modified with respect to main memory (e.g., DDR110), but the cache line is held exclusively in the current cache (e.g., the L2 cache324). An exclusive cache coherence state also indicates that the cache line is explicitly not present in any other caches (e.g., L1 or L3 caches).

A cache line having a cache coherence state of shared indicates that the cache line is not modified with respect to main memory (e.g., DDR110). A shared cache state also indicates that the cache line may be present in multiple caches (e.g., caches in addition to the L2 cache324).

A cache line having a cache coherence state of invalid indicates that the cache line is not present in the cache (e.g., the L2 cache324).

Examples of this disclosure leverage hardware techniques, control logic, and/or state information to implement a coherent system. Each observer can issue read requests—and certain observers are able to issue write requests—to memory locations that are marked shareable. Caches in particular can also have snoop requests issued to them, requiring their cache state to be read, returned, or even updated, depending on the type of the snoop operation. In the exemplary multi-level cache hierarchy described above, the L2 cache subsystem306is configured to both send and receive snoop operations. The L1 cache subsystem304receives snoop operations, but does not send snoop operations. The L3 cache subsystem308sends snoop operations, but does not receive snoop operations. In examples of this disclosure, the L2 cache controller320maintains state information (e.g., in the form of hardware buffers, memories, and logic) to additionally track the state of coherent cache lines present in both the L1 main cache314and the L1 victim cache316.

Tracking the state of coherent cache lines enables the implementation of a coherent hardware cache system.

Examples of this disclosure refer to various types of coherent transactions, including read transactions, write transactions, snoop transactions, victim transactions, and cache maintenance operations (CMO). These transactions are at times referred to as reads, writes, snoops, victims, and CMOs, respectively.

Reads return the current value for a given address, whether that value is stored at the endpoint (e.g., DDR110), or in one of the caches in the coherent system300. Writes update the current value for a given address, and invalidate other copies for the given address stored in caches in the coherent system300. Snoops read or invalidate (or both) copies of data stored in caches. Snoops are initiated from a numerically-higher level of the hierarchy to a cache at the next, numerically-lower level of the hierarchy (e.g., from the L2 controller320to the L1 controller310), and are able be further propagated to even lower levels of the hierarchy as needed. Victims are initiated from a numerically-lower level cache in the hierarchy to the next, numerically-higher level of the cache hierarchy (e.g., from the L1 controller310to the L2 controller320). Victims transfer modified data to the next level of the hierarchy. In some cases, victims are further propagated to numerically-higher levels of the cache hierarchy (e.g., if the L2 controller310sends a victim to the L2 controller320for an address in the DDR110, and the line is not present in the L2 cache324, the L2 controller320forwards the victim to the L3 controller309). Finally, CMOs cause an action to be taken in one of the caches for a given address.

Still referring toFIG.3, in one example, the L1 main cache314is a direct mapped cache that services read and write hits and snoops. The L1 main cache314also keeps track of cache coherence state information (e.g., MESI state) for its cache lines. In an example, the L1 main cache314is a read-allocate cache. Thus, writes that miss the L1 main cache314are sent to L2 cache subsystem306without allocating space in the L1 main cache314. In the example where the L1 main cache314is direct mapped, when a new allocation takes place in the L1 main cache314, the current line in the set is moved to the L1 victim cache316, regardless of whether the line is clean (e.g., unmodified) or dirty (e.g., modified).

In an example, the L1 victim cache316is a fully associative cache that holds cache lines that have been removed from the L1 main cache314, for example due to replacement. The L1 victim cache316holds both clean and dirty lines. The L1 victim cache316services read and write hits and snoops. The L1 victim cache316also keeps track of cache coherence state information (e.g., MESI state) for its cache lines. When a cache line in the modified state is replaced from the L1 victim cache316, that cache line is sent to the L2 cache subsystem306as a victim.

As explained above, the L2 cache subsystem306includes a unified L2 cache324that is used to service requests from multiple requestor types, including L1D and L1P (through the L1 controller310), the streaming engine210, a memory management unit (MMU207), and the L3 cache (through the L3 controller309). In an example, the L2 cache324is non-inclusive with the L1 cache subsystem304, which means that the L2 cache324is not required to include all cache lines stored in the L1 caches314,316, but that some lines may be cached in both levels. Continuing this example, the L2 cache324is also non-exclusive, which means that cache lines are not explicitly prevented from being cached in both the L1 and L2 caches314,316,324. For example, due to allocation and random replacement, cache lines may be present in one, both, or neither of the L1 and L2 caches. The combination of non-inclusive and non-exclusive cache policies enables the L2 controller320to manage its cache contents without requiring the L1 controller310to invalidate or remove cache lines. This simplifies processing in the L2 cache subsystem306and enables increased performance for the CPU core302by allowing critical data to remain cached in the L1 cache subsystem304even if it has been evicted from the L2 cache324.

Still referring toFIG.3, the L2 controller320described herein combines both local coherence (e.g., handling requests targeting its local L2 SRAM322as an endpoint) and external coherence (e.g., handling requests targeting external memories, such as L3 SRAM (not shown for simplicity) or DDR110as endpoints). An endpoint refers to a memory target such as L2 SRAM322or DDR110that resides at a particular location on the chip, is acted upon directly by a single controller and/or interface, and may be cached at various levels of a coherent cache hierarchy, such as depicted inFIG.3. A master (e.g., a hardware component, circuitry, or the like) refers to a requestor that issues read and write accesses to an endpoint. In some examples, a master stores the results of these read and write accesses in a cache, although the master does not necessarily store such results in a cache.

Local coherence requests are received by the L2 controller320from, for example, the CPU core302or as a direct memory access (DMA) request from another CPU core or a master associated with another CPU core. External coherence requests are received by the L2 controller320from, for example, the CPU core302or L3 controller309. Thus, the single L2 controller320is configured to address both local and external coherence.

In accordance with various examples, the L2 controller320manages the CPU core302coherent view of three endpoints: L2 SRAM322, L3 SRAM (part of the L3 cache subsystem308, not shown for simplicity), and main memory or DDR110, described above. For ease of discussion, L3 SRAM and DDR110are grouped together and referred to as an “external” memory or endpoint, which distinguishes them from the L2 SRAM322as a “local” (e.g., to the L2 controller320) memory or endpoint.

A master refers to a requestor that issues read and write accesses to an endpoint. In some examples, a master stores the results of these read and write accesses in a cache, although the master does not necessarily store such results in a cache. Coherent masters (e.g., masters for whom coherence must be handled by L2 controller320) are classified as either caching or non-caching. Non-coherent masters (e.g., masters that do not require coherent data) are not distinguished as caching or non-caching due to their being non-coherent. Referring briefly back toFIG.2, in some examples non-coherent masters include L1P205. Coherent, non-caching masters include MMU207, SE210, and L3208. Coherent, caching masters include L1D204.

The L2 controller320is configured to provide coherent access to both internal and external endpoints for coherent masters, while also providing access to those internal and external endpoints for non-coherent masters. As will be explained in further detail below, the L2 controller manages coherent state information, issues coherence transactions (e.g., snoop, victim) to maintain proper coherence states, and propagates information as needed to the downstream controllers such as the L3 controller309to provide a coherent view of the memory stored in the L2 cache subsystem306.

As will be explained further below, the L2 controller320is configured to perform normal cache allocation, replacement, and victimization operations, while also sending coherent transactions to communicate the storage of coherent locations within the L2 cache subsystem306or L1 cache subsystem304. As a result, downstream cache controllers such as the L3 controller309are able to maintain the directory information, if so enabled, about what addresses are held in the L1 and L2 cache subsystems304,306.

In accordance with examples of this disclosure, the L2 controller320is part of a system that includes a non-coherent master; a non-caching, coherent master; and a caching, coherent master. The L2 controller320is configured to receive and process transactions from each of these masters, while maintaining global coherence (e.g., with respect to external memories) and local coherence (e.g., with respect to its local memory) as required by the particular master. Thus, the L2 controller320also enables interleaving of coherent and non-coherent traffic among the various masters.

The following table summarizes interactions between various masters and the L2 controller320in accordance with various examples. In particular, Table 1 indicates for a particular master what transaction types that master can initiate to the L2 controller320, what transaction types the L2 controller320can initiate to that master, and whether global and/or local coherence is supported by the L2 controller320for that master.

TABLE 1Master-initiatedL2-initiatedGlobalLocalMastertransactiontransactioncoherence?coherence?L1P 205ReadNoneNoYesMMU 207ReadNoneYesYesSE 210Read, CMONoneYesYesL1D 204R, W, VictimSnoopYesYesL3 208SnoopR, W, VictimYesNoDMARead, WriteNoneNoYes

FIG.4ashows a method400carried out by the L2 controller320in response to a read request from a non-coherent master, such as L1P205. The method400begins in block402with the L2 controller320receiving a read request from a non-coherent master, and continues in block404with reading data from an endpoint based on the read request. Although not explicitly shown, if the read request hits in the L2 cache324, the L2 controller320is configured to read the data from the L2 cache324. On the other hand, if the read request does not hit in the L2 cache324, the L2 controller320is configured to read the data from an endpoint, such as the L3 cache subsystem308or DDR110. Once the L2 controller320has read response data (either from L2 cache324or from an endpoint), the method400continues to block406in which the L2 controller320returns the read response data to the non-coherent master.

FIG.4bshows a method410carried out by the L2 controller320in response to a read request from a coherent, non-caching master, such as MMU207, SE210, and L3208. When coherent, non-caching masters issue read commands to the L2 controller320, either to a local endpoint or external endpoint, the L2 controller320determines if the line is present in the L1 cache314,316, and if so, whether a snoop command should be issued to obtain the latest copy from L1 caches314,316, or if the data can be obtained from the endpoint (e.g., L2 SRAM322) or the L2 cache324(if present). Due to variations in access latency for a local endpoint (faster) compared to an external endpoint (slower), the L2 controller320makes multiple decisions for where and how to obtain a coherent memory location in response to a read command from a non-caching master.

The method410begins in block412with the L2 controller320receiving a read request from a coherent, non-caching master, and continues in block414with the L2 controller320determining whether the read request hits in the shadow L1 main cache326or the shadow L1 victim cache328, which indicates that the requested data may be present in the L1 cache subsystem304.

If, in block414, the read request does not hit in the shadow L1 caches326,328, the method410continues in block416in which the L2 controller320reads the data from an endpoint and returns the data as a read response. However, if in block414the read request hits one of the shadow L1 caches326,328, the method410continues in block418with the L2 controller320generating a snoop read to the L1 controller310. If a snoop response from the L1 controller310contains valid data in block420, then the L2 controller320returns the snoop response data as a read response to the requesting master in block422. If the snoop response from the L1 controller310contains invalid data in block420, then the L2 controller320returns endpoint data as the read response to the requesting master in block416.

FIG.4cshows a method430carried out by the L2 controller320in response to a read request from a coherent, caching master, such as L1D204. The method430makes reference to various sideband signals that describe allocations that will occur in the L1 cache subsystem304(e.g., movements of cache lines in L1 main cache314and L1 victim cache316) as a result of the read request. These sideband signals are described in further detail below with respect toFIG.9.

In particular, the method430begins in block432with the L2 controller320receiving an allocating read request from a coherent, caching master, which in this examples is the L1 cache subsystem304. This read request includes sideband signals that indicate it is an allocating request (e.g., alloc==1). The method430then proceeds to block434in which the L2 controller320writes an address and, optionally, a secure bit, indicated by the sideband signals to the shadow L1 main cache326, which now indicates the address that is being allocated to the L1 main cache314as a result of this read request.

The method430continues in block436with determining whether a main_valid sideband signal is asserted, which indicates that a cache line is moving from the L1 main cache314to the L1 victim cache316as a result of this read request. If the main_valid signal is asserted, the method430continues to block438in which the L2 controller320updates its shadow L1 victim cache328to include an address specified by main_address, a coherence state specified by main_mesi, and optionally a secure bit specified by main_secure. As a result, the shadow L1 victim cache328now includes the address and coherence state information of the line that is being moved from the L1 main cache314to the L1 victim cache316as a result of this read request.

If the main_valid signal is de-asserted, then a line is not being moved from the L1 main cache314to the L1 victim cache316as a result of this read request, and the method430continues to block440with determining whether a victim_valid sideband signal is asserted, which indicates that a cache line is moving out of the L1 victim cache316as a result of this read request (e.g., is being displaced by the L1 main cache314to L1 victim cache316movement described above). If the victim_valid signal is asserted, the method430continues in block442with determining whether the coherence state specified by victim_mesi (e.g., the coherence state of the line being moved out of the L1 victim cache316) is invalid, modified, or shared/exclusive.

If victim_mesi is invalid, the method430proceeds to block448in which the L2 controller320returns read response data from an endpoint, or the L2 cache324.

If victim_mesi is shared/exclusive, the method430continues to block444where the L2 controller320removes an entry from its shadow L1 victim cache328having an address that matches victim_address and, optionally, victim_secure. As explained further below, the L2 controller320removes the entry in this case because a subsequent victim transaction from the L1 controller310does not result when the line evicted from L1 victim cache316is in the shared/exclusive state, and thus it is safe to also remove from the shadow L1 victim cache328. The method430then proceeds to block448in which the L2 controller320returns read response data from an endpoint, or the L2 cache324.

If victim_mesi is modified, the method430continues to block446where the L2 controller320retains an entry from its shadow L1 victim cache328having an address that matches victim_address and, optionally, victim_secure. As explained further below, the L2 controller320retains the entry in this case because a subsequent victim transaction from the L1 controller310is expected when the line evicted from L1 victim cache316is in the modified state. The method430then proceeds to block448in which the L2 controller320returns read response data from an endpoint, or the L2 cache324.

FIG.4dshows a method450carried out by the L2 controller320in response to a write request from a coherent, non-caching master, such as a DMA request from a different CPU core. The method450begins in block452when the write request is received and continues to block454with the L2 controller320determining whether the write request hits in the shadow L1 main or victim caches326,328. If the write request does not hit in the shadow L1 main or victim caches326,328, then the L2 controller320does not need to invalidate any line in the L1 cache subsystem304and the method450proceeds to block456where the L2 controller320writes the data to an endpoint.

However, if the write request hits in the shadow L1 main or victim caches326,328, then the method450proceeds to block458in which the L2 controller320issues a snoop read and invalidate request to the L1 cache subsystem304. If the snoop response has dirty (e.g., modified) data in block460, then the L2 controller320merges the write data over the snoop response data and writes to an endpoint in block462. If the snoop response contains unmodified data in block460, then the L2 controller320writes the write data to the endpoint in block456.

FIG.4eshows a method470carried out by the L2 controller320in response to a victim from a L1D204, which is a coherent, caching master. The method470begins in block472with the L2 controller320receiving a victim from the L1 controller310. If a victim address and, optionally, secure bit hits in the shadow L1 victim cache328in block474, the L2 controller320is configured to update the shadow L1 victim cache328to invalidate a corresponding address if necessary. The method470then continues in block478, in which the L2 controller320updates an endpoint with the victim data. However, if the victim address and, optionally, secure bit does not hit in the shadow L1 victim cache328in block474, then the method470proceeds to block478and the L2 controller320updates an endpoint with the victim data without modifying the shadow L1 victim cache328.

FIG.4fshows a method480carried out by the L2 controller320in response to a snoop command from L3208, which is a coherent, non-caching master. The method480begins in block482in which the L2 controller320receives a snoop request from the L3 controller309. If, in block484, the snoop request hits in the shadow L1 main or victim caches326,328, the method480continues in block486with the L2 controller320issuing a snoop read486to the L1 controller310. The method480then continues in block488with the L2 controller320determining whether the snoop response from the L1 controller310has valid data.

If the snoop response from the L1 controller310contains invalid data (or if the snoop request did not hit in the shadow L1 main or victim caches326,328in block484), the method480continues to block490in which the L2 controller320determines whether the snoop read hits in the L2 cache324. If the snoop read does not hit in the L2 cache324, the method480continues to block492and the L2 controller320issues a snoop miss to the L3 controller309. However, if the snoop read hits in the L2 cache324, the method480continues to block493in which the L2 controller320reads the data from the L2 cache324and to block494in which the L2 controller320updates a coherence state as needed. Then the L2 controller320returns the data from the L2 cache324as snoop response data to the L3 controller309in block495.

If the snoop response from the L1 controller310contains valid data in block488, the method480continues to block496in which the L2 controller320determines whether the snoop response from the L1 controller310hits in the L2 cache324. If the snoop response from the L1 controller310hits in the L2 cache324, the method480continues to block497in which the L2 controller320updates a coherence state of the L2 cache324as needed. Then, the L2 controller320returns the snoop response data from the L1 controller310as a snoop response to the L3 controller309in block498. If the snoop response from the L1 controller310does not hit in the L2 cache324, the method480proceeds directly to block498, in which the L2 controller320returns the snoop response data from the L1 controller310as a snoop response to the L3 controller309.

The foregoing are examples of ways in which the L2 controller320receives and processes various types of transactions from various types of masters, including non-coherent masters; coherent, non-caching masters; and coherent, caching masters. By handling such diverse combinations of transactions and master requirements in a single, unified controller, overall system flexibility is enhanced.

As explained, there is a need for the L2 cache subsystem306to include hardware, control logic, and/or state information to allow the L2 controller at320to accurately track and process the state of coherent, cache lines in the lower-level L1 cache subsystem304. In this example, the L1 cache subsystem304is utilizing a heterogeneous cache system, including the L1 main cache314and the L1 victim cache316. Examples of this disclosure allow the L2 controller320to maintain appropriate state information to accurately track the state of all coherent cache lines present in both the L1 main cache314and L1 victim cache316.

FIG.5shows an example of the L1 main cache314and the L1 victim cache316. In this example, as explained above, the L1 main cache314is a direct mapped cache, which thus has one way (Way 0) and sets 0 through M. Continuing this example, as explained above, the L1 victim cache316is a fully associative cache, which thus has one set (Set 0) and ways 0 through X.

FIG.6shows an example of the shadow L1 main cache326and the shadow L1 victim cache328, contained in the L2 cache subsystem306. The shadow L1 main cache326is a shadow copy of the address tag and MESI state information for the cache lines held in the L1 main cache314. The maintenance of this shadow copy enables the L2 controller320to track the lines that are cached in the L1 main cache314, for example to correctly decide when to send snoop transactions to either read or invalidate cache lines in the L1 main cache314. In this example, the shadow L1 main cache326also has one way (Way 0) and sets 0 through M, permitting the shadow L1 main cache326to reflect the L1 main cache314.

The shadow L1 victim cache328is a shadow copy of the address tag and MESI state information for the cache lines held in the L1 victim cache316. As above with respect to the shadow L1 main cache326, the maintenance of the shadow L1 victim cache328enables the L2 controller320to accurately determine when to send snoop transactions to the L1 controller310. For example, if the shadow tags were not maintained in the L2 cache subsystem306, then the L2 controller320would need to snoop the L1 cache subsystem304for each request that could possibly be held in the L1 main or victim caches314,316, which could reduce performance due to the resulting snoop traffic bandwidth. In this example, the shadow L1 victim cache328includes one set (Set 0) and ways 0 through X, along with floating entries, which render the shadow L1 victim cache328to reflect more entries than can be stored in the L1 victim cache316. The floating entries are explained in further detail below.

In both the shadow L1 main cache326and the shadow L1 victim cache328, only the tag (e.g., address) and coherence state information is shadowed. That is, in at least this example, it is not necessary to shadow the cached data itself.

When the L2 controller320receives a snoop transaction or a read or write transaction occurs from the L3 controller310to the L2 controller320, the L2 controller320first checks the shadow L1 main and shadow L1 victim caches326,328. If a match is found (e.g., a hit), then the L2 controller320initiates a snoop transaction to the L1 controller310. When the snoop transaction returns, the L2 controller320uses the snoop response to update the shadow L1 main and shadow L1 victim caches326,328, if necessary.

Similarly, when the L1 controller310allocates a line in its L1 main cache314, or moves or relocates a line from the L1 main cache314to the L1 victim cache316, the L1 controller310communicates such movement to the L2 controller320to enable the L2 controller320to update the shadow L1 main and shadow L1 victim caches326,328. When the L1 controller310evicts a line from either the L1 main cache314or the L1 victim cache316, the line is either modified (e.g., dirty) or unmodified (e.g., clean) with respect to main memory (e.g., DDR110). The L1 controller310is configured to communicate both clean line evictions and dirty line victims to the L2 controller320, which enables the L2 controller320to accurately update its shadow L1 main and shadow L1 victim caches326,328. The signaling protocol to communicate such movement, relocation, and evictions between the L1 controller310and the L2 controller320is discussed in further detail below.

In an example, the L2 controller320learns that the L1 controller310is kicking a line out of its L1 victim cache316(e.g., to make room for a line coming from the L1 main cache314) before the L2 controller320receives the displaced victim from the L1 victim cache316. The line kicked out of the L1 victim cache316is held in a victim buffer702(e.g., as shown inFIG.7) prior to being sent to the L2 controller320across the interface between the two controllers310,320. During this time period, the L2 controller320is aware of the transfer of a line from the L1 main cache314to the L1 victim cache316, which the L2 controller will cause to be mirrored in the shadow L1 main and shadow L1 victim caches326,328. However, the L2 controller320has not yet received the displaced victim from the L1 victim cache316, as the displaced victim is still in the victim buffer702.

The floating entries in the shadow L1 victim cache328address this issue. These floating entries extend the size of the shadow L1 victim cache328to include at least the number of victim buffers in the L1 cache subsystem304. In one example, the floating entries result in the shadow L1 victim cache328having twice the number of entries as the L1 victim cache316. In an example, the exact location of entries in the L1 victim cache316does not need to match the location of the same cache line as it is shadowed in the shadow L1 victim cache328. Decoupling the locations between the L1 victim cache316and the shadow L1 victim cache328improves the safety of the protocol, as a full address comparison is performed when the L2 controller320looks for an entry in the L1 victim cache316. Subsequently, when the L2 controller320receives the displaced victim across the interface from the victim buffer, the L2 controller320causes the line to be removed from its shadow L1 victim cache328.

FIG.7shows an example of an L1 cache subsystem304allocation of a new line at address C (e.g., line C), both before and after the allocation takes place.FIG.8shows the corresponding example from the view of the L2 cache subsystem306. Referring first toFIGS.7and8at once, before the allocation takes place, the L1 main cache314contains a cache line A that is in the modified (M) state, and the L1 victim cache316contains a cache line B that is also in the modified state. At the same time, the shadow L1 main cache326also contains the cache line A (e.g., tag and MESI data for the cache line A), which is in the same relative physical location within the shadow L1 main cache326as the cache line A in the L1 main cache314. Similarly, the shadow L1 victim cache328also contains the cache line B (e.g., tag and MESI data for the cache line B), which is not necessarily in the same relative physical location within the shadow L1 victim cache328as the cache line B in the L1 victim cache316.

When the L1 controller310decides to allocate line C, the L1 controller310conveys this allocation to the L2 controller (e.g., as part of a read request issued by the L1 controller310). In this example, the address of line C maps to the same location in the L1 main cache314as the line A, and thus the L1 controller310relocates line A to the L1 victim cache316, in a location occupied by the line B. As a result of the line B being modified, the L1 controller310determines to send line B to the L2 cache subsystem306as a victim and moves the line B to the victim buffer702. After the read allocate for the line C, the L1 main cache314contains the line C in the location that formerly held the line A, the L1 victim cache316contains the cache line A that was relocated from the L1 main cache314, and the victim buffer702contains the cache line B that was evicted from the L1 victim cache316.

Similarly, after the read allocate for the line C (e.g., communicated by the L1 controller310to the L2 controller320as part of the read request for the line C), the shadow L1 main cache326contains the line C in the location that formerly held the line A and the shadow L1 victim cache328contains the relocated line A in one of its floating entries, while the line B also remains in the shadow L1 victim cache328. As explained above, there is a period of time in which the L2 controller320is aware that the L1 controller is moving the line A from the L1 main cache314to the L1 victim cache316, but the L2 controller320has not yet received the line B as a victim (e.g., the line B is still in the victim buffer702). The floating entries of the shadow L1 victim cache328provide an additional storage buffer, and the L2 controller320is configured to remove the line B from the shadow L1 victim cache328when the line B is received as a victim on the interface between the L2 cache subsystem306and the L1 cache subsystem304.

In general and as explained above, the L2 controller320is configured to receive an indication from the L1 controller310that a cache line is being relocated from the L1 main cache314to the L1 victim cache316(e.g., the cache line A in the example ofFIGS.7and8). In response to receiving the indication, the L2 controller320updates the shadow L1 main cache326to reflect that the cache line A is no longer located in the L1 main cache314. Similarly, in response to receiving the indication, the L2 controller320updates the shadow L1 victim cache328to reflect that the cache line A is located in the L1 victim cache316. The signaling protocol by which the L1 controller310communicates movement of cache lines between its L1 main cache314, L1 victim cache316, and victim buffer702are explained in further detail below. However, in one example the indication from the L1 controller310is a response to a snoop request from the L2 cache subsystem306to the L1 cache subsystem304. In another example, the indication from the L1 controller310is a read request from the L1 cache subsystem304to the L2 cache subsystem306.

These examples, in particular the floating entries of the shadow L1 victim cache328, enable cleaner handoff of a victim line from the L1 cache subsystem304to the L2 cache subsystem306by removing the timing window where a line is removed from the L1 victim cache316, but has not yet been received by the L2 cache subsystem306as a victim Additionally, the L2 controller320maintaining accurate shadows of the L1 main cache314and the L1 victim cache316allows the L2 controller to only generate snoop transactions when necessary (e.g., when the L2 controller320is aware that a line is held in one of the L1 caches314,316).

As explained above, the L1 controller310communicates movement of cache lines between its L1 main cache314, L1 victim cache316, and victim buffer702to the L2 controller320. In some examples, this communication occurs in conjunction with a response to a snoop request from the L2 cache subsystem306to the L1 cache subsystem304. In other examples, this communication occurs in conjunction with a read request from the L1 cache subsystem304to the L2 cache subsystem306.

Referring back toFIG.3, in some examples a transaction bus or interface between the L1 cache subsystem304and the L2 cache subsystem306contains a greater bandwidth than is needed to pass a transaction between the subsystems304,306. The transaction bus is represented schematically by the coupling between the L1 cache subsystem304and the L2 cache subsystem306(or similar couplings between L1 and L2 structures inFIGS.1and2). The transaction bus has a bandwidth of m+n bits, while a transaction (e.g., a read, a write, a snoop, a victim) only requires m bits, leaving n bits of the transaction bus unused. Examples of this disclosure leverage this excess bandwidth on the transaction bus between the L1 cache subsystem304and the L2 cache subsystem306to communicate information from the L1 controller310to the L2 controller320in order to allow the L2 controller320to maintain its shadow L1 main cache326(e.g., tag and MESI information corresponding to the L1 main cache314) and shadow L1 victim cache328(e.g., tag and MESI information corresponding to the L1 victim cache316).

In particular, the L1 controller310is configured, in some examples, to send sideband signals in conjunction with a functional read transaction to the L2 controller320. The sideband signals contain information related to cache line movement (e.g., as described above with respect to the example ofFIGS.7and8) occurring in the L1 cache subsystem304. Thus, the cache line movement information is communicated in parallel (e.g., as a part of a single transaction) with the functional read transaction that causes the cache line movement(s). The L2 controller320not only responds to transactions and information from the L1 controller310, but the L2 controller320also creates and enforces snoop transactions as required to maintain I/O (e.g., direct memory access (DMA)) coherence from non-caching requestors within the system (e.g., other CPU cores102in the system100may initiate a DMA request that is passed to the L2 controller320from a L3 controller, shared across CPU cores102as shown inFIG.1). In examples, these snoop transactions also cause the L2 controller320to initiate changes to its shadow L1 main cache326and shadow L1 victim cache328, as well as the L1 main cache314and the L1 victim cache316. For example, if the L1 controller310invalidates a line as a result of a snoop transaction (e.g., because the snoop transaction required invalidation, or because of a requirement due to the current state of the L1 main cache314or L1 victim cache316), the snoop response will indicate that the line transitioned to the invalid state. The L2 controller320then uses this information to update its shadow L1 main cache326or shadow L1 victim cache328. Thus, in addition to functional read transactions, the L1 controller310is configured to send additional sideband signals in conjunction with a response to a snoop transaction.

Examples of this disclosure reduce bandwidth on the transaction bus by avoiding the need for multiple messages to communicate both the functional read transaction and movements of cache lines within the L1 cache subsystem304that will result from that read transaction. Further, examples of this disclosure reduce timing dependencies and implementation complexity by avoiding the use of a separate asynchronous interface to communicate cache line movement information.

FIG.9shows a table900of sideband signaling protocol data in accordance with an example of this disclosure. The scope of this disclosure is not limited to any particular arrangement of signals within a transaction bus. For a given read transaction, the L1 controller310indicates to the L2 controller320whether the read transaction will allocate (the alloc signal) into the L1 main cache314, and if so, which line is moving from the L1 main cache314to the L1 victim cache316, and which line is moving out of the L1 victim cache316. If the alloc signal is de-asserted, then the L2 controller320disregards the remaining sideband signals.

In the table900, the main_valid and victim_valid signals indicate whether the other main* and victim* signals, respectively, are valid. For example, the L1 controller310is configured to de-assert the valid signals when transmitted in parallel with a transaction that does not result in cache line movement(s) in the L1 main cache314and the L1 victim cache, respectively. The main_mesi and victim_mesi signals indicate the cache coherence state (e.g., MESI state) for a cache line moving from the L1 main cache314to the L1 victim cache316and for a cache line moving out of the L1 victim cache316, respectively. The main_secure and victim_secure signals indicate whether the cache line moving from the L1 main cache314to the L1 victim cache316and the cache line moving out of the L1 victim cache316, respectively, is secure. The main_address and victim_address signals indicate the addresses for the cache line moving from the L1 main cache314to the L1 victim cache316and for the cache line moving out of the L1 victim cache316, respectively.

The L2 controller320is thus configured, in this example, to receive, in a single transaction, a read request in parallel with the aforementioned sideband signals that detail the cache line movement(s) that will occur in the L1 cache subsystem304as a result of the read request. In order for the L1 controller310to allocate space for data returned in response to the read request, the sideband signals indicate an address and coherence state of the cache line moving from the L1 main cache314to the L1 victim cache316and for the cache line moving out of the L1 victim cache316.

The L2 controller320is configured to update the shadow L1 main cache326to reflect that the cache line moving from the L1 main cache314to the L1 victim cache316is no longer present in the L1 main cache314. Similarly, the L2 controller320is configured to update the shadow L1 victim cache328to reflect that the cache line moving from the L1 main cache314to the L1 victim cache316is now present in the L1 victim cache316. If one or more of the valid bits in the sideband signals900are de-asserted, the L2 controller320is configured not to update its shadow L1 main cache326(main_valid de-asserted) or its shadow L1 victim cache328(victim_valid de-asserted).

In some examples, the L2 controller320is also configured to update the shadow L1 victim cache328to reflect that a cache line is no longer located in the L1 victim cache316. In particular, if the victim_mesi signal indicates that the cache line moving out of the L1 victim cache316has a coherence state other than modified (e.g., exclusive or shared), then the L2 controller320does not expect to receive a corresponding victim transaction because it is not necessary to write back a cache line that is not dirty. On the other hand, if the victim_mesi signal indicates that the cache line moving out of the L1 victim cache316has a modified coherence state, then the L2 controller320waits to receive a victim transaction (e.g., from the victim buffer702). Upon receiving the victim transaction, the L2 controller320is configured to update the shadow L1 victim cache328to reflect that a cache line is no longer located in the L1 victim cache316.

The foregoing examples reduce bandwidth on the transaction bus between the L1 cache subsystem304and the L2 cache subsystem306by avoiding the need for multiple messages to communicate both the functional read transaction and the movements of cache lines within the L1 cache subsystem304that will result from that read transaction.

The sideband signaling protocol discussed above leverages unused bandwidth on a transaction bus to facilitate communication of both the functional read transaction and the movements of cache lines within the L1 cache subsystem304that will result from that read transaction. However, in certain cases, the L1 controller310makes changes to the L1 main cache314and/or L1 victim cache316that are not coupled to a transaction that would be communicated to the L2 controller320. In these cases, the L2 controller320needs to be made aware of the changes to L1 main cache314and/or L1 victim cache316in another way.

In particular, for accurate coherent behavior, the L2 controller320maintains an accurate directory of the lines held in the L1 main cache314and L1 victim cache316(e.g., as shadow copies). This enables the L2 controller320to send snoop transactions to the L1 controller320to get the most up to date copy of the data when the L2 controller320knows the line is cached in the L1 cache subsystem304.

When the L1 controller310determines it must evict a non-modified line from the L1 victim cache316(e.g., for various reasons dependent on workload), the L1 controller310is configured in an example to inform the L2 controller320that the line is no longer held in the L1 cache subsystem304. In an example, the L1 controller310does not inform the L2 controller320that the line is no longer held in the L1 cache subsystem304. If the L1 controller310did not notify the L2 controller320that the line is no longer present, the L2 controller320may send at least one more snoop transaction to the address at a later time, believing that the line is still held in the L1 cache subsystem304. When the line is not found, the L1 controller will return a snoop response indicating that the line was not present. This concept is described as a snoop miss, and results in unnecessary delays when the line was evicted knowingly by the L1 controller.

Examples of this disclosure address the foregoing by utilizing a tag update bus to employ a single cycle, pulsed protocol that enables the L1 controller310to communicate with the L2 controller320outside of the transaction-based sideband signaling protocol explained above. The tag update bus is separate from the transaction bus described above. Similarly to the transaction bus, the tag update bus is represented schematically by the coupling between the L1 cache subsystem304and the L2 cache subsystem306(or similar couplings between L1 and L2 structures inFIGS.1and2). Further, unlike transactions received over the transaction bus, which are held in a buffer and arbitrated before being utilized by the L2 controller320, the information provided over the tag update bus is usable by the L2 controller320upon receipt. The tag update bus protocol allows the L2 controller320to accurately maintain the shadow L1 main cache326and the shadow L1 victim cache328. In some cases, the tag update bus protocol is in the form of parallel signal groups, allowing the L1 controller310to communicate two or more cache updates to the L2 controller320per cycle.

By communicating the invalidations to the L2 controller320, unnecessary snoop transactions can be avoided, resulting in shorter latencies for processing transactions in the L2 cache subsystem306. Additionally, power savings may be realized by reducing the number of RAM accesses required by multiple arbitrations for the command that resulted in a snoop miss.

FIG.10shows a table1000of tag update bus protocol data in accordance with an example of this disclosure. The scope of this disclosure is not limited to any particular arrangement of signals within the tag update bus. In the table1000, the t0_req and t1_req signals indicate whether the other t0 and t1 signals, respectively, are valid for use. When the L2 controller320detects that the t0_req or t1_req signals are asserted, the L2 controller320processes the remaining tag update bus signals. The t0_address and t1_address signals indicate the addresses for the cache line having its coherence state updated. The t0_mesi and t1_mesi signals indicate the cache coherence state (e.g., MESI state) for the cache line identified by t0_address and t1_address, respectively. The main_secure and victim_secure signals indicate whether the cache line identified by t0_address and t1_address, respectively, is secure.

In certain examples, t0_address and t1_address comprises an address in either the L1 main cache314or the L1 victim cache316, while in other examples the tag update bus is used solely to communicate updates to coherence state information for cache lines in the L1 victim cache316. In some examples, t0_mesi and t1_mesi could indicate any final cache coherence state for the cache line identified by t0_address and t1_address. The tag update bus provides the L1 controller310a means to communicate the cache line invalidations that result from the L1 controller310, while avoiding the snoop miss scenario described above.

The L2 controller320is thus configured to receive, over the tag update bus separate from a transaction bus, a message from the L1 controller310that includes a valid signal (e.g., t0_req), an address (e.g., t0_address), and a cache coherence state (e.g., t0_mesi). The message thus details an update to cache line coherence state(s) that will occur in the L1 cache subsystem304.

The L2 controller, in response to the valid signal being asserted, is configured to identify an entry in the shadow L1 main cache326or the shadow L1 victim cache328having an address corresponding to the address of the message and update a coherence state of the identified entry to be the coherence state of the message. In one example, the L2 controller320is configured only to identify an entry in the shadow L1 victim cache328having the address of the message.

Concurrently, the L2 controller320may receive transactions over the transaction bus from the L1 controller310. These transactions are separate from the message received over the tag update bus.

In some examples, the L2 cache subsystem306includes a transaction first-in, first-out buffer (FIFO, not shown for simplicity) coupled to the transaction bus that stores transactions received from the L1 cache subsystem304pending processing of those transactions by the L2 controller320. Messages received by the L2 controller320over the tag update bus are not stored in the transaction FIFO, and are instead processed by the L2 controller320upon receipt of an asserted valid signal (e.g., t0_req).

In accordance with some examples of this disclosure, the L2 controller320exists in a system-wide MESI cache coherence implementation as described above. However, the L2 controller320is configured to remap certain transactions from certain masters to implement a local MEI protocol between the L2 controller320and the L1 controller310or the L3 controller309. In certain circumstances, remapping from MESI to MEI by the L2 controller320enables higher performance on read/write software workloads where memory locations are frequently read before being written to. For example, in a multi-core coherence solution, multiple caches can hold a cache line in the shared state. When one cache needs to modify the line, it must first initiate messaging to a downstream (e.g., numerically higher) controller which results in each of the other caches receiving an invalidating snoop to remove their copy. Finally, once snoop responses have been received, the initiating cache updates the cache coherence state of the line from shared to exclusive. The initiating cache then performs its cache line write and transitions the cache line to the modified state. Thus, when a line is actively shared between multiple different caches, and modified frequently, the number of coherence messages (read, write, victim, snoop) that are required can become large, negatively impacting the performance of software executing on the CPU core302. Suppression of the shared state by the L2 controller320causes each cache line allocation to bring the line in the exclusive state, reducing the need for future coherent messaging when a modification of the cache line occurs.

FIG.11shows a block diagram of an exemplary flow1100of a transaction from the L1 controller, shown here as block1102, to the L2 instruction pipeline1112, prior to being processed by the L2 controller320. In the example ofFIG.11, it is assumed that the transaction originates from the L1 controller1102; however, as will be explained further below, multiple masters could also issue the transaction. Regardless of the issuing master, the transaction is represented by block1104as a transaction that would invoke or generate a cache line in the shared coherence state.

In accordance with examples of this disclosure, the L2 controller320suppresses the shared state by applying opcode mapping logic1106to the transaction1104. As will be explained further below, the opcode mapping logic1106maps a transaction opcode to a subset of opcodes for the final coherent cache state of the cache line comprising the modified, exclusive, or invalid states. In particular, opcodes that would have resulted in a final cache line coherence state of shared are remapped to one of this subset of opcodes. The opcode mapping logic1106need not map opcodes that would have resulted in a final cache state of modified, exclusive, or invalid.

The first request, or transaction1104, is thus mapped to a second request demonstrated by block1108, which avoids invoking the shared coherence state. The second request is then arbitrated as normal by L2 arbitration logic1110and enters the L2 instruction pipeline1112, to be subsequently processed by the L2 controller320.

In some examples, the L2 cache subsystem306includes a configuration register shown as block1107, which includes a shared field. The shared field allows the L2 cache subsystem306to be programmatically configured to either suppress the shared state, or not to suppress the shared state (e.g., not perform opcode mapping and function as a part of the larger MESI-based coherence system, described above). For example, if the shared field in configuration register1107is asserted, then the opcode mapping logic1106is not employed to map transaction opcodes to that would have resulted in a final cache line coherence state of shared. Thus, if a transaction1104is received as a third request when the shared field is asserted, the third request is processed by the L2 controller320without having its opcode mapped by the opcode mapping logic1106.

FIG.12shows a flow chart of a method1200in accordance with various embodiments. The method1200begins in block1202with the L2 controller320receiving a first request for a cache line in a shared cache coherence state. The request may be received from the L1 controller310as a read request, from the streaming engine210as a CMO that requires the L2 controller320to issue a snoop to the L1 controller310, or from the L3 controller309as a snoop that requires the L2 controller320to issue a snoop to the L1 controller310.

The method1200continues in block1204with the L2 controller320mapping the first request to a second request for a cache line in an exclusive cache coherence state, as explained above. For example, opcode mapping logic1106is applied to the opcode of the first request (e.g., invoking the shared coherence state) to map to the opcode of the second request (e.g., invoking the exclusive coherence state). As explained, the opcode mapping logic1106is carried out prior to the request entering the L2 arbitration logic1110and the L2 instruction pipeline1112, and thus being processed by the L2 controller320. In an example, read requests are either allocating or non-allocating, and either non-coherent or coherent. In this example, the opcode mapping logic1106maps non-coherent allocating reads to a read command without snoop, because no snooping is required for a non-coherent read and reading without snooping does not invoke the shared state. Similarly, the opcode mapping logic1106also maps non-coherent non-allocating reads to a read command without snoop. The opcode mapping logic1106maps coherent allocating reads to a read exclusive command, which guarantees that the line will be allocated in the exclusive state. The opcode mapping logic1106maps coherent non-allocating reads to a read once command, since these only need to sample the coherent data (e.g., not allocate), and thus the current owner can keep the line without invoking the shared state. In another example, certain snoop commands (e.g., from the L3 controller309) or CMOs have an opcode that would normally require a line to transition to the shared state. In this example, the opcode mapping logic1106maps such snoop commands and CMOs to a snoop command or CMO, respectively, that requires the line to instead transition to the invalid state. Additionally, if the L2 controller320determines to send a snoop command to the L1 controller310, the opcode mapping logic1106maps such a snoop command to a snoop command that requires the L1 controller310to instead transition the line to the invalid state.

The method1200then continues in block1206with the L2 controller320responding to the second request, if the second request is of a type that warrants a response (e.g., if the second request is a read response, a read response is warranted). In the event that the requested cache line is stored in the L2 cache subsystem306, as part of its response, the L2 controller320transitions a coherence state of the cache line to invalid rather than shared. Alternately, the method1200continues in block1208with forwarding the second request. For example, where the first request results in a snoop being issued by the L2 controller320, the L2 controller forwards the second request for the cache line in the exclusive state, rather than the shared state.

In some examples, the L1 controller310determines to change a size of the L1 main cache314. For example, the L1 main cache314may be an allocated region of the larger L1 SRAM312that can grow (e.g., from 32 KB to 64 KB) or shrink (e.g., from 32 KB to 16 KB) in size over time, depending on requirements communicated to the L1 controller310, for example from the CPU core302or software executing thereon. The L2 controller320needs to be aware of changes in size to the L1 main cache314, so that the L2 controller320can properly maintain (e.g., change the size of) its shadow L1 main cache326.

The following protocol enables the L2 controller320, in an example, to change the size of its shadow L1 main cache326while avoiding data corruption and/or transaction deadlocks (e.g., where a first transaction relies on a second transaction, which is pending resolution of the first transaction). In one example, sideband signals of the transaction bus (explained above) are used by the L1 controller310to communicate the size change of the L1 main cache314to the L2 controller320. In this example, reference is made to certain ones of the sideband signals of the transaction bus, in particular referred to as: global_on, global_coh_type, and cache_size. The global_on signal indicates that the L1 controller310is performing a global operation on its L1 main cache314. The global_coh_type signal indicates the type of global coherence operation being performed on the L1 main cache314. In the specific example of a size change of the L1 main cache314, the global_coh_type will be a writeback invalidate operation. During a cache size change, coherence is maintained by writing the data to the endpoint and by invalidating the cacheline. The cache_size signal indicates the size to which the L1 main cache314is transitioning.

FIG.13shows a flow chart of a method1300for changing the size of the L1 main cache314, and the resultant change in size of the shadow L1 main cache326. The method1300begins in block1302with determining, by the L1 controller310, to change a size of the L1 main cache314. This determination to change the cache size is, for example, the result of a control or configuration register write programming a configuration register of the L1 controller310to indicate the desired new cache size and initiate the cache size change.

The method1300continues in block1304with the L1 controller310servicing pending read and write requests from a CPU core, such as the CPU core302. The method1300then continues in block1306in which the L1 controller310stalls new read and write requests from the CPU core302. This allows the L1 controller310to work through pending requests but restrict new requests so that it may perform the global operation (e.g., writeback invalidate and cache size change) on the L1 main cache314.

The method1300continues in block1308with the L1 controller310writing back and invalidating the L1 main cache314. At this point in the method1300, the L1 controller310asserts the global_on signal to indicate it is performing a global operation, and the global_coh_type indicates a writeback invalidate as explained above. The L1 controller310is configured to send victims to the L2 controller320during this stage, which enables the L2 controller320to update the shadow L1 main and victim caches326,328. If the victim hits in the L2 cache324, the L2 controller320is also configured to update that cache line with the victim data. If the victim is not present in L2 cache324, the L2 controller320forwards the victim (e.g., to the L3 controller309). During the size change of the L1 main cache314, coherence is maintained writing the data back to the endpoint and invalidating the cache line. While the L1 controller310writes back and invalidates the L1 main cache314, the L1 controller310is also configured to accept and stall a snoop request from the L2 controller320.

While the L1 controller310asserts the global_on signal (e.g., during a global operation), the L1 controller310also de-asserts a ready signal, which indicates to the CPU core302not to send the L1 controller310additional requests for a cache size change or other global coherence operations. The ready signal remains de-asserted until the global operation is completed (e.g., the global_on signal is de-asserted).

Once the global_on signal is de-asserted, the L1 controller310responds to any pending snoop transactions that were received from the L2 controller320and stalled by the L1 controller310during the writeback invalidate (e.g., the global coherence operation for L1 main cache314size change). In an example, the L1 controller310responds to the pending snoop transactions with a response indicating a cache miss because the L1 main cache314is invalidated as part of the size change protocol. Once the global_on signal is de-asserted, the L1 controller310also begins accepting read and write requests from the CPU core302using the new cache size for the L1 main cache314. At this point the L1 controller310has implemented the functionality to change the size of its L1 main cache314.

The method1300then continues to block1310in which the L2 controller320receives an indication that the L1 main cache314has been invalidated and had its size changed. In an example, the L1 controller310sends such an indication to the L2 controller in response to the L1 controller310having received write responses for all victims written back by the L1 controller310, while no further victims are pending to be written back by the L1 controller310.

In this example, the L1 controller310uses sideband signals of global_on, global_coh_type, and cache_size to communicate that the L1 main cache314has been invalidated and had its size changed. For example, when global_coh_type indicates a writeback invalidate and the cache_size signal has changed, the L1 controller310de-asserting global_on indicates to the L2 controller320that the L1 main cache314has been invalidated and had its size changed. This indication allows the L2 controller320to begin the process of resizing its shadow L1 main cache326. To begin resizing the shadow L1 main cache326, the L2 controller320flushes its pipeline, or completes all transactions that are present in its pipeline while stalling transactions from other masters.

In some examples, the L2 controller320flushes its pipeline in separate phases, which include a blocking soft stall phase, a non-blocking soft stall phase, and a hard stall phase. In general, blocking transactions include read requests and write requests that are not victims, which have the potential to create a secondary transaction (e.g., a snoop), while non-blocking transactions include victims, snoops, and all responses.

In an example, during the blocking soft stall phase, the L2 controller320stalls all blocking transactions, such as fetches, read requests, and write requests from the CPU core302and DMA read/write accesses (e.g., from another CPU core) but allows response transactions, non-blocking snoop and victim transactions to be accepted and arbitrated. In some examples the L2 controller320flushes its pipeline over several cycles. Following the blocking soft stall phase, the L2 controller320enters the non-blocking soft stall phase, in which the L2 controller320allows response transactions and victims but stalls snoop transactions, in addition to the blocking transactions already stalled in the blocking soft stall phase. As a result, the L2 controller320does not initiate new snoops to the L1 main cache314for lines previously cached in in the L1 main cache314.

After the L2 controller320pipeline is flushed, the method1300continues to block1312in which the L2 controller320stalls requests received from any master. This phase is the hard stall phase referred to above. In particular, the L2 controller320pipeline is flushed, the L2 controller320enforce a hard stall where all transactions, including response transactions, are stalled from all masters.

In some examples, the L2 controller320also de-asserts or causes the ready signal (explained above with respect to the L1 controller) to be de-asserted. By de-asserting the ready signal, the L2 controller320prevents the CPU core302from sending requests for a cache size change or other global coherence operation until the L2 controller320has completed the currently-pending request (e.g., a cache size change). In one example, the ready signal provided to the CPU core302comprises a logical AND of a ready signal from the L1 controller310and the L2 controller320. That is, the CPU core302only receives an asserted ready signal when both the L1 controller310and the L2 controller320assert their ready signals (e.g., when the cache size change operation is complete).

When the hard stall is enforced in block1312, the method1300then continues to block1314in which the L2 controller320reinitializes the shadow L1 main cache326to clear its previous contents (e.g., invalidate cache lines previously held in the shadow L1 main cache326) and change a size of the shadow L1 main cache326. In some examples, reinitializing the shadow L1 main cache326takes several cycles, during which the L2 controller320continues to enforce the hard stall on other masters. Once the shadow L1 main cache326is reinitialized, the L2 controller320unstalls the masters and asserts its ready signal. The L2 controller320then begins to process pending transactions from one or more holding buffers, and accepts new transactions. At this point the size change protocol execution is complete. In some cases, the L1 controller310sends a transaction (e.g., a read request) to the L2 controller320while the L2 controller320is flushing its pipeline in block1310or stalled in block1312, and thus the transaction from the L1 controller310is stalled as well. The L2 controller320responds to such transactions after reinitializing the shadow L1 main cache326.

In the foregoing discussion and in the claims, the terms “including” and “comprising” are used in an open-ended fashion, and thus should be interpreted to mean “including, but not limited to . . . .” Also, the term “couple” or “couples” is intended to mean either an indirect or direct connection. Thus, if a first device couples to a second device, that connection may be through a direct connection or through an indirect connection via other devices and connections. Similarly, a device that is coupled between a first component or location and a second component or location may be through a direct connection or through an indirect connection via other devices and connections. An element or feature that is “configured to” perform a task or function may be configured (e.g., programmed or structurally designed) at a time of manufacturing by a manufacturer to perform the function and/or may be configurable (or re-configurable) by a user after manufacturing to perform the function and/or other additional or alternative functions. The configuring may be through firmware and/or software programming of the device, through a construction and/or layout of hardware components and interconnections of the device, or a combination thereof. Additionally, uses of the phrases “ground” or similar in the foregoing discussion are intended to include a chassis ground, an Earth ground, a floating ground, a virtual ground, a digital ground, a common ground, and/or any other form of ground connection applicable to, or suitable for, the teachings of the present disclosure. Unless otherwise stated, “about,” “approximately,” or “substantially” preceding a value means+/−10 percent of the stated value.

The above discussion is meant to be illustrative of the principles and various embodiments of the present disclosure. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.