Pseudo-random route selection

Abstract

A method (1100) includes receiving a first request for allocation of a way in an N-way set-associative cache (1102), and allocating the way for the first request in response to a cache coherency state of the way indicating that a cache line stored in the way is invalid (1104). The method also includes randomly selecting one of the ways in the set in response to none of the ways in the set having a cache coherency state indicating that the cache line stored in the way is invalid (1106). The method also includes allocating the selected way for the first request in response to a cache coherency state of the selected way indicating that another request is not pending for the selected way (1108).

Description

Background Technology

[0001] Some memory systems incorporate multi-level cache systems, where the hierarchy of memory (e.g., caches) provides different access speeds to cached data. The Level 1 (L1) cache is tightly coupled to the Central Processing Unit (CPU) core and provides the CPU core with faster access to cached data (e.g., relative to main memory). The Level 2 (L2) cache is also coupled to the CPU core and, in some instances, is larger and therefore holds more data than the L1 cache, but provides relatively slower access to cached data compared to the L1 cache. Additional memory levels within this hierarchy are possible. Summary of the Invention

[0002] In some instances, a method includes receiving a first request to allocate a line in an N-way set-associative cache, and allocating the line for the first request in response to a cache coherence state of the line indicating that a cache line stored in the line is invalid. The method further includes randomly selecting one of the lines in the group in response to no line in the group having a cache coherence state indicating that a cache line stored in the line is invalid. The method further includes allocating the selected line for the first request in response to a cache coherence state of the selected line indicating that another request is not pending for the selected line.

[0003] In some instances, a method includes receiving a first request to allocate a line in an N-way set-associative cache, and allocating the line for the first request in response to a cache consistency state of the line indicating that the cache stored in the line is invalid. The method further includes, in response to no line in the set having a cache consistency state indicating that the cache line stored in the line is invalid, creating a masked subset of lines in the set by masking lines having cache consistency states indicating that another request is pending for any line, randomly selecting one of the lines in the masked subset, and allocating the selected line for the first request.

[0004] In some instances, a Level 2 (L2) cache subsystem includes: an L2 cache configured as an N-way set-associative cache; and an L2 controller configured to receive a first request to allocate a line in the L2 cache and, in response to a cache coherence state of the line indicating that a cache line stored in the line is invalid, allocate the line for the first request. The L2 controller is also configured to randomly select one of the lines in the group in response to no line in the group having a cache coherence state indicating that a cache line stored in the line is invalid. The L2 controller is further configured to allocate the selected line for the first request in response to a cache coherence state of the selected line indicating that another request is not pending for the selected line.

[0005] In some instances, a method includes receiving a first transaction from a preceding stage in a pipeline via a first stage in the pipeline; determining whether the first transaction includes a high-priority transaction or a low-priority transaction; processing the high-priority transaction by sending it to an output buffer in response to the first transaction including a high-priority transaction; receiving a second transaction from the preceding stage; and determining whether the second transaction includes a high-priority transaction or a low-priority transaction. In response to the second transaction including a low-priority transaction, the method includes processing the low-priority transaction by monitoring a full signal from the output buffer when sending the low-priority transaction to the output buffer; pausing the processing of the low-priority transaction in response to the full signal being asserted and no high-priority transaction is available from the preceding stage; stopping the processing of the low-priority transaction and processing the high-priority transaction in response to the full signal being asserted and a high-priority transaction is available from the preceding stage; and processing the low-priority transaction by sending it to the output buffer in response to the full signal being deasserted.

[0006] In some instances, a method includes receiving a first transaction from a preceding stage in a pipeline via a first stage in the pipeline; determining whether the first transaction includes a high-priority transaction, a medium-priority transaction, or a low-priority transaction; and processing the high-priority transaction by sending it to an output buffer in response to the first transaction including a high-priority transaction. The method further includes receiving a second transaction from the preceding stage; determining whether the second transaction includes a medium-priority transaction or a low-priority transaction. In response to the second transaction including a medium-priority transaction, the method includes processing the medium-priority transaction by monitoring a full signal from the output buffer when sending the medium-priority transaction to the output buffer; pausing the processing of the medium-priority transaction in response to the full signal being asserted and no high-priority transaction is available from the preceding stage; stopping the processing of the medium-priority transaction and processing the high-priority transaction in response to the full signal being asserted and a high-priority transaction is available from the preceding stage; and processing the medium-priority transaction by sending it to the output buffer in response to the full signal being deasserted. The method further includes, in response to the second transaction including a low-priority transaction, processing the low-priority transaction by monitoring the full signal from the output buffer when sending the low-priority transaction to the output buffer; pausing the processing of the low-priority transaction in response to the full signal being asserted and no high- or medium-priority transaction being available from the previous stage; stopping the processing of the low-priority transaction and processing the high- or medium-priority transaction in response to the full signal being asserted and a high- or medium-priority transaction being available from the previous stage; and processing the low-priority transaction by sending the medium-priority transaction to the output buffer in response to the full signal being deasserted.

[0007] In some instances, a method includes a Level 2 (L2) cache subsystem comprising an L2 pipeline and a state machine within the L2 pipeline. The state machine is configured to receive a first transaction from an input buffer of a preceding stage coupled to the L2 pipeline; determine whether the first transaction comprises a high-priority, medium-priority, or low-priority transaction; and, in response to the first transaction comprising a high-priority transaction, process the high-priority transaction by sending it to an output buffer. The state machine is also configured to receive a second transaction from the input buffer; determine whether the second transaction comprises a medium-priority or low-priority transaction; and, in response to the second transaction comprising a medium-priority transaction, process the medium-priority transaction. When the state machine processes the medium-priority transaction, the state machine is further configured to monitor full signals from the output buffer when sending the medium-priority transaction to the output buffer; suspend processing of the medium-priority transaction in response to an assertion that no high-priority transaction is available from the input buffer; stop processing the medium-priority transaction and process the high-priority transaction in response to an assertion that a full signal is available from the input buffer; and process the medium-priority transaction by sending it to the output buffer in response to an assertion that the full signal is canceled. The state machine is also configured to process the low-priority transaction in response to the second transaction including a low-priority transaction. When the state machine processes the low-priority transaction, the state machine is further configured to monitor the full signal from the output buffer when sending the low-priority transaction to the output buffer; suspend the processing of the low-priority transaction in response to the full signal being asserted and no high or medium priority transaction is available from the input buffer; stop the processing of the low-priority transaction and process the high or medium priority transaction in response to the full signal being asserted and no high or medium priority transaction is available from the input buffer; and process the low-priority transaction by sending the medium priority transaction to the output buffer in response to the full signal being deasserted.

[0008] In some instances, a device includes a CPU core, a first cache subsystem coupled to the CPU core, and a second memory coupled to the cache subsystem. The first cache subsystem includes a configuration register, a first memory, and a controller. The controller is configured to: receive a request booted to an address in the second memory and, in response to the configuration register having a first value, operate in a non-cached mode. In the non-cached mode, the controller is configured to provide the request to the second memory without caching data returned by the request in the first memory. In response to the configuration register having a second value, the controller is configured to operate in a cache mode. In the cache mode, the controller is configured to provide the request to the second memory and cache data returned by the request in the first memory.

[0009] In some instances, a method includes receiving a request via a Level 2 (L2) controller, including a configuration register, for an address booted into Level 3 (L3) memory; and, in response to the configuration register having a first value, operating the L2 controller in a non-cached mode by providing the request to the L3 memory and not caching the data returned by the request in the L2 cache. In response to the configuration register having a second value, the method includes operating the L2 controller in a cached mode by providing the request to the second memory and caching the data returned by the request in the L2 cache.

[0010] In some instances, a Level 2 (L2) cache subsystem includes a configuration register, a first memory, and an L2 controller. The L2 controller is configured to receive requests directed to an address in a second memory coupled to the L2 cache subsystem and operates in a non-cached mode in response to a first value in the configuration register. In the non-cached mode, the L2 controller is configured to provide the request to the second memory without caching the data returned by the request in the first memory. In response to a second value in the configuration register, the L2 controller operates in a cached mode. In the cached mode, the L2 controller is configured to provide the request to the second memory and cache the data returned by the request in the first memory.

[0011] In some instances, a device includes a first CPU and a second CPU core, an L1 cache subsystem coupled to the first CPU core and including an L1 controller, and an L2 cache subsystem coupled to the L1 cache subsystem and the second CPU core. The L2 cache subsystem includes L2 memory and an L2 controller configured to operate in an alias mode in response to an assertion of a value in a memory mapping control register. In the alias mode, the L2 controller receives a first request from the first CPU core to boot into a virtual address in the L2 memory, receives a second request from the second CPU core to boot into the virtual address in the L2 memory, boots the first request to physical address A in the L2 memory, and boots the second request to physical address B in the L2 memory.

[0012] In some instances, a method includes operating an L2 controller of a Level 2 (L2) cache subsystem in alias mode in response to an assertion of a memory mapping control register value. Operating the L2 controller in alias mode further includes receiving a first request from a first CPU core for a virtual address booted into the L2 memory of the L2 cache subsystem, receiving a second request from a second CPU core for the virtual address booted into the L2 memory, booting the first request to physical address A in the L2 memory, and booting the second request to physical address B in the L2 memory.

[0013] In some instances, a method includes receiving a write request for an address not allocated as a cache line in the L2 cache via a Level 2 (L2) controller. The write request specifies data to be written. The method further includes generating a read request for the address via the L2 controller; reserving an entry in a register file for read data returned in response to the read request via the L2 controller; updating a data field of the entry with the write data via the L2 controller; updating an enable field of the entry associated with the write data via the L2 controller; and receiving the read data via the L2 controller and merging the read data into the data field of the entry.

[0014] In some instances, a Level 2 (L2) cache subsystem includes an L2 cache, a register file with entries, and an L2 controller. The L2 controller is configured to receive a write request for an address not allocated as a cache line in the L2 cache, the write request including write data; generate a read request for the address; retain the entry in the register file for read data returned in response to the read request; update the data field of the entry with the write data; update the enable field of the entry associated with the write data; and receive the read data and merge the read data into the data field of the entry.

[0015] In some instances, a device includes a central processing unit (CPU) core and a Level 1 (L1) cache subsystem coupled to the CPU core. The L1 cache subsystem includes an L1 cache and an L1 controller. The device also includes a Level 2 (L2) cache subsystem coupled to the L1 cache subsystem. The L2 cache subsystem includes an L2 cache, a register file with entries, and an L2 controller. The L2 controller is configured to receive a write request for an address not allocated as a cache line in the L2 cache, the write request including write data; generate a read request for the address; retain the entry in the register file for read data returned in response to the read request; update the data field of the entry with the write data; update the enable field of the entry associated with the write data; and receive the read data and merge the read data into the data field of the entry.

[0016] In some instances, a method includes receiving a request to perform a global operation on an L2 cache via an L2 controller and allowing new non-blocking transactions to enter the pipeline coupled to the L2 cache while preventing new blocking transactions from entering. Blocking transactions include read transactions and non-victim write transactions. Non-blocking transactions include response transactions, listening transactions, and victim transactions. The method further includes preventing new listening transactions from entering the pipeline while allowing new response and victim transactions to enter the pipeline in response to an indication that the pipeline does not contain any pending blocking transactions; preventing all new transactions from entering the pipeline in response to an indication that the pipeline does not contain any pending listening transactions; and performing the global operation on the L2 cache in response to an indication that the pipeline does not contain any pending transactions.

[0017] In some instances, a device includes a central processing unit (CPU) core and a Level 1 (L1) cache subsystem coupled to the CPU core. The L1 cache subsystem includes an L1 cache, an L1 controller, and a Level 2 (L2) cache subsystem coupled to the L1 cache subsystem. The L2 cache subsystem includes an L2 cache and an L2 controller. The L2 controller is configured to receive requests to perform global operations on the L2 cache and to prevent new blocking transactions from entering the pipeline coupled to the L2 cache while allowing new non-blocking transactions to enter the pipeline. Blocking transactions include read transactions and non-victim write transactions. Non-blocking transactions include response transactions, listener transactions, and victim transactions. The L2 controller is further configured to, in response to an indication that the pipeline does not contain any pending blocked transactions, prevent new listening transactions from entering the pipeline and allow new response transactions and victim transactions to enter the pipeline; in response to an indication that the pipeline does not contain any pending listening transactions, prevent all new transactions from entering the pipeline; and in response to an indication that the pipeline does not contain any pending transactions, perform the global operation on the L2 cache.

[0018] In some instances, the Level 2 (L2) cache subsystem includes an L2 cache and an L2 controller. The L2 controller is configured to receive requests to perform a global operation on the L2 cache and to prevent new blocking transactions from entering the pipeline coupled to the L2 cache while allowing new non-blocking transactions to enter the pipeline. Blocking transactions include read transactions and non-victim write transactions. Non-blocking transactions include response transactions, listening transactions, and victim transactions. The L2 controller is further configured to, in response to an indication that the pipeline contains no pending blocking transactions, prevent new listening transactions from entering the pipeline while allowing new response and victim transactions to enter the pipeline; in response to an indication that the pipeline contains no pending listening transactions, prevent all new transactions from entering the pipeline; and in response to an indication that the pipeline contains no pending transactions, perform the global operation on the L2 cache. Attached Figure Description

[0019] For a detailed description of various examples, please refer to the accompanying drawings, in which:

[0020] Figure 1 Block diagrams showcasing multi-level caching systems in various examples;

[0021] Figure 2 Another block diagram showing a multi-level caching system in various examples;

[0022] Figure 3 Another block diagram showing a multi-level caching system that includes a primary (L1) cache and a victim cache in various instances;

[0023] Figure 4 Block diagrams showcasing multi-stage pipelines in various examples;

[0024] Figure 5 P4 level block diagrams show various examples of pipelines that include transaction arbitration;

[0025] Figure 6 These are flowcharts of methods used for transaction arbitration in various instances;

[0026] Figure 7 These are flowcharts of various methods used to pause the cache pipeline to perform global operations;

[0027] Figure 8a Showcases various instances of improved cache allocation in response to write allocations;

[0028] Figure 8b Showing various examples Figure 8a An example of the register file used;

[0029] Figure 9 Flowcharts illustrating methods for improving cache allocation in response to write allocations in various instances;

[0030] Figure 10 Examples and flowcharts of masked route selection strategies using random number generators are shown in various instances.

[0031] Figure 11 Flowcharts illustrating alternative path selection strategies using random number generators in various examples;

[0032] Figure 12 Flowcharts illustrating the operation of the cache controller in cached and non-cached modes in various examples;

[0033] Figure 13 Examples of alias and non-alias memory operations are shown in various instances; and

[0034] Figure 14 Flowcharts show various examples of methods for performing aliased and non-aliased memory operations. Detailed Implementation

[0035] Figure 1A block diagram of system 100 in the example described herein is shown. Example system 100 includes multiple CPU cores 102a to 102n. Each CPU core 102a to 102n is coupled to dedicated L1 caches 104a to 104n and dedicated L2 caches 106a to 106n. L2 caches 106a to 106n are then coupled to a shared L3 cache 108 and a shared main memory 110 (e.g., Double Data Rate (DDR) Random Access Memory (RAM)). In other examples, a single CPU core 102 is coupled to L1 cache 104, L2 cache 106, L3 cache 108, and main memory 110.

[0036] In some instances, CPU cores 102a to 102n include a register file, an integer arithmetic logic unit, an integer multiplier, and a program flow control unit. In some instances, the L1 caches 104a to 104n associated with each CPU core 102a to 102n contain a separate Level 1 program cache (L1P) and Level 1 data cache (L1D). L2 caches 106a to 106n are combined instruction / data caches that store both instructions and data. In some instances, CPU core 102a and its associated L1 cache 104a and L2 cache 106a are formed on a single integrated circuit.

[0037] CPU cores 102a to 102n operate under program control to perform data processing operations. Instructions are fetched before decoding and execution. Figure 1 In this example, L1 caches 104a to 104n store L1P instructions used by CPU cores 102a to 102n. CPU core 102 first attempts to access any instructions from L1P in L1 cache 104. L1 cache 104 stores data used by CPU core 102. CPU core 102 first attempts to access any required data from L1 cache 104. Both L1 caches 104 (L1P and L1D) are supported by L2 cache 106, which is a unified cache (e.g., containing both data and instructions). In the event of a cache miss in L1 cache 104, the requested instruction or data is searched from L2 cache 106. If the requested instruction or data is in L2 cache 106, it is provisioned to the requesting L1 cache 104 for provisioning to CPU core 102. The requested instructions or data are simultaneously supplied to both the request cache and CPU core 102 to accelerate their use.

[0038] The unified L2 cache 106 is further coupled to the third-level (L3) cache 108, which is in... Figure 1In this instance, the L2 caches 106a to 106n are shared. The L3 cache 108 is then coupled to the main memory 110. As will be described in further detail below, the memory controller facilitates communication between the CPU core 102, L1 cache 104, L2 cache 106, L3 cache 108, and the various components in the main memory 110. The memory controller handles memory-centric functions such as cacheability determination, cache coherence enforcement, error detection and correction, address translation, and the like. Figure 1 In one example, CPU core 102 is part of a multiprocessor system, and therefore the memory controller also handles data transfers between CPU cores 102 and maintains cache coherency within CPU cores 102. In other examples, system 100 contains only a single CPU core 102 and its associated L1 cache 104 and L2 cache 106.

[0039] Figure 2 Block diagrams of system 200 are shown in some examples. Some components of system 200 are similar to those described above. Figure 1 The components are described, but shown in more detail. For example, CPU core 202 is similar to CPU core 102 described above. The L1 cache 104 subsystem described above is depicted as L1D 204 and L1P 205. The L2 cache 106 described above is shown here as L2 cache subsystem 206. L3 cache 208 is similar to L3 cache 108 described above. System 200 also includes a streaming engine 210 coupled to L2 cache subsystem 206. System 200 also includes a memory management unit (MMU) 207 coupled to L2 cache subsystem 206.

[0040] L2 cache subsystem 206 includes L2 tag random access memory 212, L2 coherent (e.g., modified, exclusive, shared, invalid (“MESI”)) data memory 214, shaded L1 tag random access memory 216, and L1 coherent (e.g., MESI) data memory 218. Each of blocks 212, 214, 216, and 218 is alternatively referred to as memory or RAM. L2 cache subsystem 206 also includes tag random access memory error correction code (ECC) data memory 220. In this example, ECC data memory 220 is maintained for each of memories 212, 214, 216, and 218.

[0041] The L2 cache subsystem 206 includes an L2 controller 222, the functionality of which will be described in further detail below. Figure 2In this example, the L2 cache subsystem 206 is coupled to a memory comprising four groups 224a to 224d (e.g., L2 SRAM 224). Interface 230 performs data arbitration and typically coordinates data transfers between the L2 cache subsystem 206 and the L2 SRAM 224, while ECC block 226 performs error correction. The L2 cache subsystem 206 includes one or more control or configuration registers 228.

[0042] exist Figure 2 In this instance, the L2 SRAM is depicted as four groups 224a to 224d. However, in other instances, the L2 SRAM contains more or fewer groups, including those implemented as a single group. The L2 SRAM 224 is used as an L2 cache and is referred to herein, alternatively, as L2 cache 224.

[0043] L2 tag random access memory 212 contains a list of physical addresses, the contents of which (e.g., data or program instructions) are cached in L2 cache 224. In one example, an address translator translates virtual addresses into physical addresses. In another example, the address translator directly generates a physical address from a virtual address. For instance, the lower n bits of the virtual address are used as the least significant n bits of the physical address, where the most significant bits (above the lower n bits) of the physical address are generated based on a set of tables configured in main memory. In this example, L2 cache 224 can be addressed using the physical address. In some instances, a hit / miss indicator from a lookup in tag random access memory 212 is stored in memory.

[0044] L2 MESI memory 214 maintains consistent data to implement full MESI consistency with L2 SRAM 224, external shared memory, and data cached in L2 caches from other locations in system 200. The consistency functionality of system 200 is described in further detail below.

[0045] The L2 cache subsystem 206 also tracks or hides L1D tags in the L1D shadow tag random access memory 216 and the L1D MESI memory 218. Tag random access memory ECC data 220 provides error detection and correction for the tag memory and also for one or both of the L2 MESI memory 214 and the L1D MESI memory 218. The L2 cache controller 222 controls the operation of the L2 cache subsystem 206, including consistent handling of both internal processes within the L2 cache subsystem 206 and other components of the system 200.

[0046] Figure 3A block diagram of system 300 is shown, demonstrating various features of cache coherency implemented in some instances. System 300 contains features similar to those described above. Figure 1 and 2 The component being described. For example, CPU core 302 is similar to CPU cores 102 and 202. Figure 3 It also includes an L1 cache subsystem 304, an L2 cache subsystem 306, and an L3 cache subsystem 308. The L1 cache subsystem 304 includes an L1 controller 310 coupled to an L1 SRAM 312. The L1 controller 310 is also coupled to an L1 main cache 314 and an L1 victim cache 316, which are described in further detail below. In some instances, the L1 main and victim caches 314, 316 implement the functionality of L1D 204 and / or L1P 205.

[0047] The L1 controller 310 is coupled to the L2 controller 320 of the L2 cache subsystem 306. The L2 controller 320 is also coupled to the L2 SRAM 322. The L2 controller 320 is coupled to the L2 cache 324 and to the shadow of the L1 main cache 326 and the shadow of the L1 victim cache 328. For ease of description, the L2 cache 324 and L2 SRAM 322 are shown separately, but they can be physically implemented together (e.g., included in a grouped configuration as part of the L2 SRAM 224, as described above). Similarly, the shadow of the L1 main cache 326 and the shadow of the L1 victim cache 328 can be physically implemented together, similar to the L1D shadow tag random access memory 216 and L1DMESI 218 described above. The L2 controller 320 is also coupled to the L3 controller 309 of the L3 cache subsystem 308. For simplicity, the L3 cache and main memory (e.g., DDR110 described above) are not shown.

[0048] Cache coherence is a technique that allows data and program caches, as well as different requesters (including those without caches), to determine the latest data value at a given address in memory. Cache coherence enables this consistent data value to be determined by observers present in system 300 (e.g., caches or requesters issuing commands to read a given memory location). Some specific instances refer to exemplary MESI coherence schemes where cache lines are configured with one of four cache coherence states: modified, exclusive, shared, or invalid. Other instances refer to subsets of MESI coherence schemes, while still others contain more coherence states than the MESI coherence scheme. Regardless of the coherence scheme, the cache coherence state of a given cache line is stored (for example) in the L2 MESI memory 214 described above.

[0049] A cache line with a modified cache coherence state indicates a modification of the cache line relative to main memory (e.g., DDR110), and the cache line is exclusively stored in the current cache (e.g., L2 cache 324). Modifying the cache coherence state also indicates that the cache line explicitly does not exist in any other cache (e.g., L1 or L3 cache).

[0050] A cache line with an exclusive cache coherence state indicates that the cache line has not been modified relative to main memory (e.g., DDR110), but the cache line is exclusively stored in the current cache (e.g., L2 cache 324). An exclusive cache coherence state also indicates that the cache line is explicitly not present in any other cache (e.g., L1 or L3 cache).

[0051] A cache line with a shared cache coherence state indicates that the cache line has not been modified relative to main memory (e.g., DDR110). The shared cache state also indicates that the cache line may exist in multiple caches (e.g., caches other than L2 cache 324).

[0052] A cache line with an invalid cache coherence state indicates that the cache line is not present in the cache (e.g., L2 cache 324).

[0053] Some instances utilize hardware technology, control logic, and / or state information to implement a consistent system. Each observer can issue a read request—and some observers can issue write requests—to a memory location marked as shareable. The cache, in particular, can also issue listener requests, requiring its cache state to be read, returned, or even updated, depending on the type of listener operation. In the exemplary multi-level cache hierarchy described above, the L2 cache subsystem 306 is configured to both send and receive listener operations. The L1 cache subsystem 304 receives listener operations but does not send them. The L3 cache subsystem 308 sends listener operations but does not receive them. In some instances, the L2 cache controller 320 maintains state information (e.g., in the form of hardware buffers, memory, and logic) to also track the state of the consistent cache lines present in both the L1 main cache 314 and the L1 victim cache 316. Tracking the state of the consistent cache lines enables the implementation of a consistent hardware caching system.

[0054] Some examples refer to various types of consistent transactions, including read transactions, write transactions, listener transactions, victim transactions, and cache maintenance operations (CMO). These transactions are sometimes referred to as read, write, listener, victim, and CMO, respectively.

[0055] The read returns the current value at the given address, regardless of whether the value is stored at an endpoint (e.g., DDR 110) or in a cache within the coherent system 300. The write updates the current value at the given address and invalidates any other copy of the data stored at that address in the cache within the coherent system 300. The listener reads a copy of the data stored in the cache or invalidates it (or both). The listener initiates a process from a higher-level cache in the hierarchy to the next lower-level cache in the hierarchy (e.g., from L2 controller 320 to L1 controller 310), and can further propagate to even lower levels of the hierarchy as needed. The victim initiates a process from a lower-level cache in the hierarchy to the next higher-level cache in the cache hierarchy (e.g., from L1 controller 310 to L2 controller 320). The victim transfers the modified data to the next level in the hierarchy. In some cases, the victim is further propagated to higher levels of the cache hierarchy (e.g., if L2 controller 310 sends the victim to L2 controller 320 for an address in DDR 110, and the line is not present in L2 cache 324, then L2 controller 320 forwards the victim to L3 controller 309). Finally, the COM causes an action to be taken in one of the caches for the given address.

[0056] Still referencing Figure 3 In one instance, L1 primary cache 314 is a directly mapped cache for service read and write hits and listeners. L1 primary cache 314 also maintains cache consistency state information (e.g., MESI state) that tracks its cache lines. In this instance, L1 primary cache 314 is a read allocation cache. Therefore, writes that miss L1 primary cache 314 are sent to L2 cache subsystem 306 if no space is allocated in L1 primary cache 314. In instances where L1 primary cache 314 is directly mapped, when a new allocation occurs in L1 primary cache 314, the current line in the group is moved to L1 victim cache 316, regardless of whether the line is clean (e.g., unmodified) or dirty (e.g., modified).

[0057] In this example, the L1 victim cache 316 is a fully associative cache whose preservation (for example,) is attributed to replacing cache lines that have been removed from the L1 main cache 314. The L1 victim cache 316 preserves both clean and dirty lines. The L1 victim cache 316 serves read and write hits and listeners. The L1 victim cache 316 also maintains cache consistency state information (e.g., MESI state) tracking its cache lines. When a cache line in a modified state is replaced from the L1 victim cache 316, that cache line is sent as a victim to the L2 cache subsystem 306.

[0058] As described above, the L2 cache subsystem 306 includes a unified L2 cache 324, which serves requests from multiple requester types, including L1D and L1P (via L1 controller 310), streaming engine 210, memory management unit (MMU 207), and L3 cache (via L3 controller 309). In this example, the L2 cache 324 is not included with the L1 cache subsystem 304, meaning that the L2 cache 324 does not need to include all cache lines stored in L1 caches 314 and 316, but some lines can be cached in both levels. Continuing with this example, the L2 cache 324 is also non-exclusive, meaning that cache lines are not explicitly prevented from being cached in L1 and L2 caches 314, 316, and 324. For example, due to allocation and random replacement, cache lines may exist in one, both, or none of the L1 and L2 caches. The combination of non-inclusion and non-exclusive cache policies enables the L2 controller 320 to manage its cache contents without the L1 controller 310 invalidating or removing cache lines. This simplifies processing in the L2 cache subsystem 306 and improves the performance of the CPU core 302 by allowing critical data to remain cached in the L1 cache subsystem 304 (even if it has been evicted from the L2 cache 324).

[0059] In some instances, the L2 cache subsystem 306 includes a control pipeline for handling different types of transactions. In some instances described herein, transactions are classified as blocking or non-blocking based on whether the receiving device is allowed to delay or pause transactions. Examples of blocking transactions include read and write requests and instruction fetching. Examples of non-blocking transactions include victims, listeners, and responses to read and / or write requests. See also... Figure 3The L2 controller 320 described herein combines both local coherence (e.g., handling requests to designate its local L2 SRAM 322 as an endpoint) and external coherence (e.g., handling requests to designate external memory (e.g., L3 SRAM (not shown for simplicity) or DDR110) as an endpoint). An endpoint refers to a memory target, such as L2 SRAM 322 or DDR110, residing at a specific location on the chip, directly acted upon by a single controller and / or interface, and may be cached in, for example... Figure 3 The various levels of the consistent cache hierarchy are described in the diagram. A host (e.g., a hardware component, circuit, or the like) is the party that issues requests for read and write access to the endpoint. In some instances, the host stores the results of these read and write accesses in a cache, but the host may not necessarily store such results in a cache.

[0060] In this example, endpoints (e.g., L3 cache subsystem 308 for cached transactions originating from L2 controller 320 and L1 cache subsystem 304 for listening transactions originating from L2 controller 320) will not pause non-blocking transactions after another blocking transaction. Therefore, non-blocking transactions are guaranteed to be consumed by the endpoints. However, blocking transactions can be paused indefinitely by the endpoints. L2 controller 320 sends both blocking and non-blocking transactions to both L3 controller 309 and L1 controller 310. If L2 controller 320 has a blocking transaction to be sent but it is paused, then the pipeline controller (e.g., arbitration logic) ensures that non-blocking transactions can bypass the paused blocking transaction and be sent to the endpoints. As an example, the L2 pipeline is filled with reads from streaming engine 205, which are blocking transactions. L3 controller 309 is able to pause such streaming reads. However, if the L1 controller 310 needs to send the victim to the L2 controller, or if the L2 controller 320 needs to respond to a listener from the L3 controller 309, then some instances allow such non-blocking transactions to be sent over the same control pipeline.

[0061] Figure 4Pipeline 400 of the L2 cache subsystem 306 is shown in some examples. Certain instances specifically involve transaction arbitration implemented in pipeline level P4 428. However, for additional context and clarity, pipeline 400 is described below. Pipeline 400 receives transactions from various hosts, such as program memory controller 402 (e.g., PMC or L1P 205), data memory controller 404 (e.g., DMC or L1D 204), streaming engine 406 (e.g., SE 210), multi-core shared memory controller 408 (e.g., MSMC or L3 controller 309), and memory management unit 410 (e.g., MMU 207). Multiple FIFOs 412 contain different types of transactions from various hosts 402, 404, 406, 408, 410, and resource allocation units (RAUs) 414, 416, 418 (for example) arbitrate transactions from each requester based on the specific type of the requester and the type of transaction that can originate from said requester. For the purposes of this description, transactions are classified as blocking and non-blocking.

[0062] RAU levels 414, 416, and 418 arbitrate among different transaction types with certain characteristics. For example, blocking reads and writes include data loading and storage, code fetching, and SE 406 reads. These blocking transactions can be paused after a non-blocking transaction or response. Another example includes non-blocking writes, which involve DMC 404 victims (from the local CPU core or a different CPU core from the DMC 404 cache). These types of transactions are arbitrated with other non-blocking and response transactions based on consistency rules. Another example includes non-blocking listeners, which are listeners from MSMC 408, and these listeners are arbitrated with other non-blocking and response transactions based on consistency rules. Another example includes, for example, responses to reads sent to MSMC 408 or cache line allocation transactions, or responses to listeners sent to DMC 404. In both cases, responses are arbitrated with other non-blocking and response transactions based on consistency rules. Finally, DMA transactions are possible, which are generally allowed to pause after other non-blocking or blocking transactions.

[0063] Not all requesters initiate all of these types of transactions. For example, the DMC 404 can initiate blocking reads, blocking writes, non-blocking writes (e.g., a DMC 404 victim), non-blocking listener responses, and non-blocking DMA responses (e.g., for L1D 204 SRAM). For the DMC 404, non-blocking transactions take precedence over blocking transactions to win arbitration. Among the various non-blocking transactions, non-blocking commands are processed in the order they arrive. DMA responses are used to access the L1D 204 SRAM and do not necessarily follow any command order.

[0064] Instance PMC 402 can initiate only blocking reads. Within an instance, reads from PMC 402 are processed sequentially.

[0065] Instance SE 406 can initiate blocking reads and CMOs. Within an instance, reads and CMO accesses from SE 406 are processed sequentially.

[0066] The instance MMU 410 can initiate only blocking reads. Within a single instance, reads from the MMU 410 are processed sequentially.

[0067] Finally, the MSMC 408 instance can initiate blocking DMA reads, blocking DMA writes, non-blocking writes (e.g., from an L1D 204 victim on another CPU core), non-blocking listeners, and non-blocking read responses. For the MSMC 408, non-blocking transactions take precedence over blocking transactions to win arbitration. Arbitration between non-blocking transactions depends on the ordering required to maintain memory consistency. However, in the instance, read responses are arbitrated in any order because there is no danger between read responses.

[0068] Levels P0(420) through P3(426) are non-pausing and non-blocking. The non-pausing property means that transactions do not pause in these pipeline levels. In the instance, a transaction takes 1 or 2 cycles and has a guaranteed time slot in the next pipeline level. The non-blocking property relies on the fact that arbitration prior to P0 420 guarantees that FIFO entries are available to transactions entering P0 420 and any secondary transactions that may be generated there.

[0069] Level P0 420 typically performs credit management functions, where certain transactions "consume" credit based on transaction type. These consumed credits are later released in pipeline 400. The concept of credit is an exemplary method of ensuring that a transaction is allowed to proceed only if it allows memory elements to be in place in a later pipeline level, thus ensuring the non-blocking nature of the pipeline. However, other instances do not necessarily rely on credits but employ other methods to ensure that transactions are allowed to proceed only if there is sufficient pipeline space to allow the transaction to continue through a non-blocking pipeline level.

[0070] Levels P0 420, P1 422, and P2 424 perform various cache and SRAM functionalities, such as setting reads from various caches, performing ECC checks and / or corrections for various caches, and determining cache hits and misses. Level P3 426 performs additional cache hit and miss control and also releases credits for certain transaction types.

[0071] Some examples involve pipeline-level P4 428 and cache miss arbitration, as well as dynamic arbitration of various transactions in the send stage, which are described in further detail below. References Figure 5The system 500 is shown, which includes an exemplary P4 level 428 from one of the pipelines 400. Although not shown for simplicity, it should be understood that other pipelines contain similar P4 levels that function in a manner similar to the P4 level 428 described below. As shown, the P4 level 428 includes FIFOs for various transaction types. For example, the P4 level 428 includes FIFOs for type 0 blocking transactions 502, FIFOs for type 1 non-blocking transactions 504, and FIFOs for type 2 non-blocking transactions 506. Specific transaction types are described in further detail below. The outputs of each FIFO 502, 504, 506 are input to a multiplexer 508, which is controlled by a dynamic arbitration state machine 510, which will also be described in further detail below. The output of each P4 stage 428 can be used for various FIFOs 512 of the cache miss arbitration and send stage, which is a single stage in which transactions from all pipes are arbitrated, multiplexed, and sent (for example) from the L2 cache subsystem 306 to the L3 cache subsystem 308.

[0072] FIFO 502 receives type 0 transactions from the previous pipeline level, which contain all blocking read and write transactions. FIFO 504 receives type 1 transactions from the previous pipeline level, which contain non-blocking victim or listener responses from L1D 204. FIFO 506 receives type 2 transactions from the previous pipeline level, which contain non-blocking L2 victim or listener responses that hit L2 cache 324.

[0073] As described, the cache miss arbitration and send stage is the stage that handles transactions from all pipes. In this stage, transactions from any pipe intended for use with the L3 cache subsystem 308 are arbitrated. In this instance, this arbitration is isolated from and independent of transactions from each pipe intended for use with the L1 cache subsystem 304. The cache miss arbitration and send stage evaluates the type and number of credits required to send a specific transaction to the L3 cache subsystem 308 endpoint based on the transaction type, and arbitrates one outgoing transaction from the pipe (e.g., using arbitration logic 514 to control entry into various FIFOs 512).

[0074] In one instance of cache miss arbitration and the send stage, output FIFO 512 comprises different structures with variable, configurable depths. In this instance, the global FIFO accepts both blocking and non-blocking transactions. The blocking FIFO accepts cache allocations and blocking read and write transactions. When the global FIFO is full, blocking transactions are pushed into the blocking FIFO. The non-blocking FIFO accepts listener responses and victims of L1 cache subsystem 304 and L2 cache subsystem 306. When the global FIFO is full, non-blocking transactions are pushed into the non-blocking FIFO. For example, transactions are released from FIFO 512 based on interactions with L3 cache subsystem 308, indicating whether and / or how much transaction processing bandwidth is available in L3 cache subsystem 308, and for what type of transaction (e.g., a credit-based scheme). A read response FIFO is used for DMA read responses, which are released to L3 cache subsystem 308 on the DMA thread.

[0075] In this example, the full FIFO signal is sent from output FIFO 512 to P4 stage 428. In one instance, the full FIFO signal actually comprises a separate signal for each of the FIFOs 512. These separate signals are asserted when the corresponding FIFO 512 is full and deasserted when the corresponding FIFO 512 is not full. As will be further described below, this insight into the state of FIFO 512 in the next stage allows the dynamic arbitration state machine 510 of P4 stage 428 to arbitrate more efficiently among various transactions (e.g., type 0, type 1, type 2).

[0076] Specifically, a full FIFO signal indicates that a transaction (e.g., considered by the dynamic arbitration state machine 510) is attempting to advance to a FIFO 512 that does not have an empty slot. The state machine 510 monitors specific signals of the full FIFO signals that allow it to advance a transaction to the FIFO 512. In instances where a transaction includes two data phases, as further described below, the full FIFO signal indicates the availability of two data slots in the FIFO 512.

[0077] In some instances, the dynamic arbitration state machine 510 of P4 level 428 monitors transactions from the preceding level P3 426, as well as the availability of the FIFO 512 (e.g., via full FIFO semaphore). As described, the preceding level P3 426 can send type 2, type 1, or type 0 transactions to P4 level 428. Based on the blocking and non-blocking rules described above, type 2 transactions have the highest priority, while type 0 transactions have the lowest priority.

[0078] Figure 6A flowchart 600 illustrates the operation of the dynamic arbitration state machine 510. Flowchart 600 (e.g., state machine 510) begins in state 602, where state machine 510 monitors transactions from level P3 426. For example, FIFOs 502, 504, and 506 are initially empty, and therefore, upon receiving a transaction from level P3 426, state machine 510 knows that the transaction exists in one of FIFOs 502, 504, and 506. When a transaction is received in one of FIFOs 502, 504, and 506, state machine 510 proceeds to block 604 to determine if the transaction has the highest priority (e.g., type 2 in FIFO 506 in the example above). If type 2 transactions are available, then state machine 510 proceeds to block 606.

[0079] exist Figure 6 In this example, suppose a transaction is processed as two data phases (DP). For instance, the consistency unit of the cache line is 128 bytes, while the physical bus width is only 64 bytes (e.g., the data phase), and therefore the transaction is divided into a first and a second data phase. In another instance where the transaction is a single DP transaction, state machine 510 is simplified by eliminating the need to send a second DP before monitoring for new transactions from FIFOs 502, 504, and 506 again.

[0080] Since it is assumed that the transaction has two DPs, state machine 510 proceeds to block 606, where a first DP and command are sent to arbitrate the entry into FIFO 512. When the cache miss arbitration level accepts the first DP, it transmits an ACK signal to state machine 510. State machine 510 waits to receive the ACK before proceeding to block 608 and sending a second DP to arbitrate the entry into FIFO 512. In this example, the ACK arrives in the cycle after the first DP and command are sent to the cache miss arbitration level via P4 level 428.

[0081] After sending the second DP, state machine 510 proceeds to block 610 to determine if a transaction has the highest priority (e.g., type 2). If a type 2 transaction is available in FIFO 506, then state machine 510 returns to block 606 and continues as described above. Therefore, as long as type 2 transactions are available in FIFO 506, state machine 510 continues to assign the highest priority to those transactions.

[0082] However, if a type 2 transaction does not exist in FIFO 506 (as determined in block 604 or block 610), then the state machine proceeds to block 612 to determine if the transaction is available in FIFO 504 (e.g., if it is a type 1 transaction). If a type 1 transaction is available in FIFO 504, then state machine 510 proceeds to block 614. As mentioned above, assuming the transaction has two DPs, the state machine therefore continues in block 614 to send the first DP and command to arbitrate entry into FIFO 512.

[0083] Unlike when processing the highest-priority Type 2 transaction, when an ACK has not yet been received, state machine 510 proceeds to block 616 to verify the FIFO full signal. As long as the FIFO full signal is not asserted (e.g., for FIFO 512 involving a Type 1 transaction), state machine 510 returns to block 614 to continue waiting for an ACK. However, if the FIFO full signal is asserted, then there is no space in FIFO 512 involving a Type 1 transaction, and state machine 510 proceeds to block 618 to determine if a Type 2 transaction is available in FIFO 506. As described above, if a lower-priority transaction cannot be completed (e.g., due to FIFO 512 being full), then state machine 510 prioritizes the highest-priority Type 2 transaction (if it is available in FIFO 506). If a Type 2 transaction is available, then state machine 510 returns to block 606 to process the Type 2 transaction as described above. If it is determined in box 618 that a type 2 transaction is unavailable, then state machine 510 returns to box 616 to determine whether the FIFO full signal is still asserted.

[0084] The aforementioned loop between boxes 616, 614, and 618 continues until an ACK is received. At this point, state machine 510 proceeds from box 614 to box 620 and sends a second DP to arbitrate the entry into FIFO 512. Once the second DP has been sent, state machine 510 waits for an ACK in box 620 and continues back to box 602 to monitor transactions in FIFOs 502, 504, and 506.

[0085] Referring back to box 612, if a type 1 transaction is unavailable in FIFO 504, then a type 0 transaction is available in FIFO 502 and state machine 510 continues to box 624. As mentioned above, assume the transaction has two DPs, and therefore the state machine continues in box 624 to send the first DP and command to arbitrate entry into FIFO 512.

[0086] As described above for handling type 1 transactions, when an ACK has not yet been received, state machine 510 proceeds to block 626 to verify the FIFO full signal. As long as the FIFO full signal is not asserted (e.g., for FIFO 512 involving type 0 transactions), state machine 510 returns to block 624 to continue waiting for an ACK. However, if the FIFO full signal is asserted, then there is no space in FIFO 512 involving type 0 transactions, and state machine 510 proceeds to block 628 to determine whether type 2 transactions are available in FIFO 506 or type 1 transactions are available in FIFO 504. As mentioned above, if a lower-priority transaction cannot be completed (e.g., due to FIFO 512 being full), then state machine 510 prioritizes higher-priority type 2 transactions (if available in FIFO 506) and type 1 transactions (if available in FIFO 504). If a type 2 or type 1 transaction is available, then state machine 510 returns to box 604 to determine whether type 2 or type 1 is available, and state machine 510 operates as described above. If, in box 628, it is determined that a type 2 or type 1 transaction is not available, then state machine 510 returns to box 626 to determine whether the FIFO full signal is still asserted.

[0087] The aforementioned loop between boxes 626, 624, and 628 continues until an ACK is received. At this point, state machine 510 proceeds from box 624 to box 600 and sends a second DP to arbitrate the entry into FIFO 512. Once the second DP has been sent, state machine 510 waits for an ACK in box 630 and continues back to box 602 to monitor transactions in FIFOs 502, 504, and 506.

[0088] Therefore, the dynamic arbitration state machine 510 often prioritizes higher-priority transactions to ensure that the inability of lower-priority transactions to proceed to the next level will not interfere with the processing of such higher-priority transactions.

[0089] Furthermore, by verifying the FIFO full signal during the processing of various transactions, state machine 510 keeps track of whether a particular transaction can continue from level P4 428. For example, if the FIFO full signal is asserted, then the transaction cannot continue from level P4 428 to the cache miss arbitration and send level. A low FIFO full signal indicates that the transaction will eventually be able to enter one of the FIFOs 512 through dynamic arbitration state machine 510 (but in some cases, it may be temporarily suspended). For example, if level P4 of another pipeline can advance the transaction to the cache miss arbitration and send level, then FIFO 512 may become full, causing the FIFO full signal to be asserted. However, if FIFO 512 has available slots, then the FIFO full signal remains unasserted. Finally, if state machine 510 is suspended (for example, because the FIFO full signal is asserted), then the transaction cannot proceed. If a transaction with higher priority arrives, then state machine 510 switches to process the higher priority transaction. A transaction being processed can be temporarily saved or shelved (e.g., in memory structures, which differ from FIFO 502, 504, 506, 512 in some instances) until state machine 510 has processed a higher priority transaction, at which point state machine 510 returns to process a lower priority transaction.

[0090] exist Figure 6 In some instances, the data phase size is smaller than the transaction size, assuming the transaction is processed as two data phases (DP). However, in other instances, the transaction is processed as a single data phase, and therefore... Figure 6 State machine removal boxes 608, 620, and 630 are used. In another instance, instead of transactions with high, medium, and low priorities (e.g., type 2, type 1, and type 0 transactions respectively), transactions are classified as high or low priority. In this instance, from Figure 6 The state machine is removed from boxes 612 and 624 to 630. In yet another instance, instead of having multiple input transaction buffers 502, 504, 506, these buffers are reduced to fewer buffers, and in some instances, a single buffer is included. Similarly, instead of having multiple output buffers 512, these buffers are reduced to fewer buffers, and in some instances, a single buffer is included.

[0091] In some instances, global cache operations are pipelined to leverage the grouped configuration of the L2 cache subsystem 306 described above. Global cache operations are transactions performed on more than one cache line. Additionally, the L2 controller 320 manages the global cache operations on the L2 cache subsystem 306 to avoid any blocking conditions encountered during global cache operations.

[0092] As described, in some instances, the L2 cache subsystem 306 contains multiple groups (e.g., as described above). Figure 2 Groups 224a to 224d are shown in the diagram. In some instances, the number of groups is configurable. Each group has an independent pipeline 400 associated with it. Therefore, the L2 controller 320 is configured to facilitate up to four transactions in parallel on the L2 cache 324 (in... Figure 2 (In some instances, such as one transaction per group). In some instances, this enables the L2 controller 320 to simultaneously facilitate global consistency operations on groups of L2 cache 324.

[0093] Figure 7 A flowchart illustrates a method 700 for pausing the pipeline of the L2 cache subsystem 306 (e.g., pipeline 400 described above) to perform a global cache operation, in various instances. Method 700 begins at block 702, which is the start of the global operation state machine. In block 702, the L2 controller 320 receives a request to perform a global operation on the L2 cache 324. In some instances, the request is in the form of a procedure (e.g., executed by CPU core 302) asserting fields in a control register (e.g., ECR 228).

[0094] Various global cache operations can be requested from the L2 controller 320. In one instance, a global cache operation is an invalidation operation that invalidates every cache line in the L2 cache 324. In another instance, the global operation is a write-back invalidation operation, where dirty cache lines in the L2 cache 324 (e.g., with a modified consistent state) are written back to their endpoints and subsequently invalidated. In yet another instance, the global operation is a write-back operation, where dirty cache lines in the L2 cache 324 are written back to their endpoints. The write-back and dirty cache lines in the L2 cache 324 then update their consistent state to a shared cache consistent state. In some of these instances, the global operation includes querying the cache consistent state of each line in the L2 cache 324 and updating the cache consistent state of each line in the L2 cache 324. For example, if the global operation is a write-back operation, then after the modified cache line in L2 cache 324 is written back to its endpoint, L2 controller 320 queries the consistency status of the line in L2 cache 324 and updates the consistency status of the modified cache line to be shared.

[0095] Regardless of the type of global cache operation (for example, as indicated in the request to L2 controller 320, such as based on an assertion field of a control register (e.g., ECR228)), method 700 continues to block 704, where L2 controller 320 enforces a blocking soft pause. During the blocking soft pause phase, L2 controller 320 suspends all new blocking transactions from entering the pipeline, while allowing non-blocking transactions, including response transactions, non-blocking listeners, and victim transactions, to be accepted into the pipeline and arbitrated.

[0096] In this example, L2 controller 320 requires multiple cycles to flush its pipeline during the blocking soft pause phase 704. Therefore, method 700 continues in block 706 to determine if all blocking transactions have been flushed from the pipeline. In response to an indication that the pipeline no longer contains blocking transactions, method 700 proceeds to block 708, where L2 controller 320 enforces a non-blocking soft pause. During the non-blocking soft pause phase, L2 controller 320 suspends new listening transactions from entering the pipeline, while allowing new response transactions and victim transactions to enter. Therefore, the non-blocking soft pause phase prevents new listening requests from being initiated to L1 controller 310 for lines previously cached in L1 cache 314.

[0097] Method 700 continues in block 710 to determine whether all listening transactions have been flushed from the pipeline. In response to an indication that the pipeline no longer contains any pending listening transactions, method 700 proceeds to block 712, where L2 controller 320 enforces a hard pause. During the hard pause phase, L2 controller 320 prevents all new transactions containing the response transaction from entering the pipeline.

[0098] In some instances, the L2 controller 320 cancels the assertion ready signal during both soft and hard pause phases. Canceling the assertion ready signal instructs the CPU core 302 not to send additional requests to the L1 controller 310 for global consistency operations or cache size changes. Therefore, the L2 controller 320 can complete pending global consistency operations while ensuring that the CPU core 302 will not issue additional global consistency operations. The ready signal remains canceled until the global operation is completed.

[0099] The method continues in block 714 to determine whether all transactions have been flushed from the pipeline. In response to L2 controller 320 determining that the pipeline no longer contains pending transactions, method 700 continues to block 716. Steps 702 to 714 of method 700 are executed independently (e.g., as a state machine implemented for each pipeline) and in parallel by L2 controller 320 (for example). However, in block 716, L2 controller 320 waits for confirmation from all pipelines that it has flushed all pending transactions (e.g., all pipelines have proceeded to block 716). Once confirmation that all pipelines have flushed all pending transactions is received, method 700 continues to block 718, where a global operation is performed. In this instance, the global operation also continues independently and in parallel on each of the pipelines to grouped L2 cache 324. Applications executing on CPU core 302 that request to perform global operations (e.g., by asserting fields in control registers such as ECR 228) are also configured to poll the same field, and L2 controller 320 is configured to de-assert the field after the global operation is completed.

[0100] By pausing its pipeline in a phased manner as described above, L2 controller 320 first avoids continuing to process transactions that could alter the state of L2 cache 324 (e.g., read requests that cause a change in the cache coherence state of the cache line). While L2 cache 324 will no longer receive transactions that could alter its state, L2 controller 320 continues to process certain transactions that occurred before the global operation was requested. For example, if L1 controller 310 issues a victim to L2 controller 320 as the result of a read prior to the global operation, L2 controller 320 may not know which read request caused the victim from L2 controller 310, and therefore continues to process such victims (and listener responses) as a safer approach. L2 controller 320 does not continue to send new transactions, as this could lead to a circular condition. Listener transactions prior to the global operation continue to be processed (e.g., in box 710), and once those listener transactions are processed, L2 controller 320 has successfully stopped processing new transactions and processes those transactions already in progress until completion. Therefore, the parallel performance of global operations enabled by the L2 controller 320 is improved by the parallel nature of the grouped L2 cache 324 and the parallel implementation of global operations.

[0101] A write request received from CPU core 302 that can be cached in L2 cache 324 but misses L2 cache 324 can be called a "write allocation". Some instances involve certain improvements enabled by the associated structure of L2 controller 320 and L2 cache subsystem 306 for such write allocation transactions.

[0102] In this example, the L2 cache subsystem 306 includes memory storage elements (e.g., buffers) for servicing write allocation transactions. These are referred to herein as register files, but this description should not be construed as limiting to a particular type of memory element. Further discussion follows. Figure 8b This example demonstrates a register file used for service write allocation transactions.

[0103] When the L2 controller 320 determines to perform a write allocation (e.g., when a write request misses the L2 cache 324), the L2 controller 320 is configured to generate a read request for the address to be written to in the L2 cache subsystem 306. Therefore, instead of forwarding the write request to the L3 controller 309 or DDR 110, the L2 controller 320 is configured to bring the data to be written into the L2 cache subsystem 306 for final storage in the L2 cache 324.

[0104] The write request received by L2 controller 320 contains write data in the data field, and in some cases, also includes an enable field that specifies the valid portion of the data field (e.g., those containing valid write data). The enable field is further described below. In some cases, however, L2 controller 320 allocates space in the register file for the data associated with the write request (e.g., the data field and possibly the enable field). Furthermore, L2 controller 320 allocates space in the register file for read responses expected to be generated by read requests issued by L2 controller 320 as a result of write allocation. When a read response is received, L2 controller 320 writes the read response data to a line in L2 cache 324 and then writes the write data to the same line in L2 cache 324, thus completing the initial write request. However, this method requires more storage in the register file and increases the number of transactions performed for the final write request.

[0105] In some instances, the L2 controller 320 is configured to retain entries in the register file for read data returned in response to read requests generated by write allocation transactions. The L2 controller 320 updates the data field of the retained entry with the write data (e.g., the data field of the initial write request) and updates the enable field of the retained entry based on the write data. Then, when a read response is returned, the L2 controller 320 is configured to merge the returned read data into the data field of the retained entry. The retained entry is then written to the L2 cache 324. This reduces the space required in the register file to serve this write allocation transaction. Furthermore, it reduces transactions to the L2 cache 324 because merging occurs in the register file of the L2 cache subsystem 306.

[0106] Figure 8aExample 800, demonstrating the aforementioned functionality, enables the L2 controller 320 to improve cache allocation, particularly in response to write requests. Example 800 contains an initial snapshot of the entries in the register file after the L2 controller 320 receives a write request from an L2 cache 324 that has missed a write request. In this example 800, the write request is for address A. The write data includes x0A in the first portion 802 of the data field and x0B in the second portion 804 of the data field. In this example, the enable field comprises one bit of data per byte in the data field, which is asserted when the corresponding data field portion is valid. Therefore, the enable fields of the first and second portions 802, 804 are asserted. Conversely, the enable fields of the third and fourth portions 806, 808 are deasserted, and therefore the data fields in the third and fourth portions 806, 808 are irrelevant as invalid write data.

[0107] Example 800 also includes a later snapshot of the entries in the register file after a read response (e.g., a response to a read request resulting from a write allocation transaction) has been received by the L2 controller 320. In this example 800, the data contained at address A is xCDEF9876. As described above, the L2 controller 320 is configured to merge the write data with the read response in the entries. Specifically, valid write data (indicated by the corresponding enable field of the assertion) overwrites the read response data in sections 810 and 812, while read response data that is not overwritten (due to the corresponding enable field of the deassertion) remains in the entries in sections 814 and 816. Specifically, merging the write data with the read response in the entries includes discarding the read data when a subfield or section of the enable field (e.g., sections 802 and 804) is asserted. Similarly, when a subfield or portion of an enabled field (e.g., portions 806 and 808) is deasserted, the write data and read response are merged by replacing a portion of the data field associated with the deasserted subfield (e.g., bytes in instance 800) with the corresponding portion of the read data (e.g., bytes in instance 800). Although not depicted, the read response may also be returned as a mutex fragment and thus the merge is handled in a similar manner.

[0108] Figure 8bAn instance register file 850 containing entries as described above is shown. Instance register file 850 is contained within L2 cache subsystem 306. Specifically, instance 850 depicts the register file as a schematic, separate block containing a write allocation address FIFO 852, a write allocation data FIFO 854, and a write allocation enable FIFO 856. Although these are labeled FIFOs, the structure of the register file is not necessarily a first-in-first-out (FIFO) structure in all instances. In some instances, when L2 controller 320 generates a read request for the next-level cache (e.g., L3 cache subsystem 308), write data is written to entries in each of FIFOs 852, 854, and 856. In this instance, the write data includes a write allocation address, which is written to write allocation address FIFO 852. The write data also includes the actual write data itself, which is written to write allocation data FIFO 854. Finally, the write data includes enable data (e.g., one bit of write data per byte) specifying whether the write data field is valid, which is written to the write allocation enable FIFO 856. When data is returned from the address in the form of a read response (e.g., from L3 cache subsystem 308), (for example) based on the above regarding Figure 8a The corresponding enabled data in the write allocation enabled FIFO 856 is described, and the read data is merged with the write data in the entry of the write allocation data FIFO 854.

[0109] Figure 9 A flowchart illustrates a method 900 for improving cache allocation in response to a write request. Method 900 begins at block 902, where L2 controller 320 receives a write request for an address not allocated as a cache line in L2 cache 324. The write request contains write data.

[0110] Method 900 continues in block 904, where the L2 controller 320 generates a read request for the address of the write request. Then, method 900 continues in block 906, where the entry in the register file is reserved for the read data returned in response to the generated read request.

[0111] Method 900 further continues in blocks 908 and 910, wherein the L2 controller 320 updates the data field of an entry in the register file with the written data, and updates the enable field of the entry associated with the written data. As described above, the enable field indicates the validity of the corresponding portion of the written data, and in Figure 8a The example includes writing data one bit per byte. Finally, method 900 ends at box 912, where the L2 controller 320 receives the read data and merges it into the data field of the entry, for example, as described above regarding... Figure 8a describe.

[0112] These improvements to write allocation in L2 cache subsystem 306 reduce the space required to serve such a write allocation transaction in the register file. Furthermore, transactions to L2 cache 324 are reduced because merging occurs in the register file of L2 cache subsystem 306.

[0113] The choice of cache replacement algorithm can affect the performance of cache subsystems (such as the L2 cache subsystem 306 described above).

[0114] In this example, L2 cache 324 is a read- and write-assignable 8-way cache. The allocation of cache lines in L2 cache 324 depends on various page attributes, cache mode settings, and the like. When a line is detected to be missing in L2 cache 324 (e.g., a cache miss), L2 controller 320 decides to allocate a line. For simplicity, it is assumed that L2 controller 320 is allowed to allocate lines even in the event of a cache miss. The following example illustrates how L2 controller 320 allocates lines.

[0115] In some instances, the L2 controller 320 is configured to pipeline the allocation to the L2 cache 324. Therefore, the L2 controller 320 may end up with a situation where multiple cache lines are allocated to the same path. Since response data can become corrupted, this can lead to data corruption if multiple lines are allocated to the same path in the L2 cache 324. On the other hand, if multiple cache lines are to the same group, it is advantageous to avoid limiting the L2 controller 320 by the number of allocated paths (8).

[0116] As described above, each line in the L2 cache 324 includes a coherence state (e.g., MESI state, requiring 2 bits). Furthermore, the L2 controller 320 tracks the safe or unsafe state of the line (e.g., requiring 1 bit). However, the safe state of a line with an invalid coherence state is irrelevant, and therefore the additional cache line state can be tracked by the L2 controller 320 without any additional replacement bit overhead. Reducing the replacement bit overhead employed by a particular replacement algorithm is advantageous.

[0117] As an example, here are the possible consistency states of lines in L2 cache 324:

[0118] • "000": INVALID - The path is empty and can be used for allocation.

[0119] • “001”: PENDING - The path is empty, but has been marked for allocation.

[0120] • "010": SHARED__NON_SECURE - The line assigned to this path is in a shared MESI state and is a non-secure line.

[0121] • "011": SHARED__SECURE - The line assigned to this route is in a shared MESI state and is a secure line.

[0122] • "100": EXCLUSIVE__NON_SECURE - The line assigned to this path is in exclusive MESI state and is not secure.

[0123] • "101": EXCLUSIVE__SECURE - The line assigned to this path is in exclusive MESI status and is a secure line.

[0124] • "110": MODIFIED__NON_SECURE - The line assigned to this path is in a modified MESI state and is a non-secure line.

[0125] • "111": MODIFIED__SECURE - The line assigned to this path is in a modified MESI state and is a secure line.

[0126] As described above, this allows Bit_0 of this status field to be used in two ways: to indicate a line is pending, and as a safe bit (if the line has been allocated). This reduces the storage required to store this status information. For ease of explanation, and for the purpose of describing the cache replacement strategy below, pending is also considered a cache coherence state.

[0127] As used in this document, "pending" refers to a situation where the L2 controller 320 has decided on an allocation path and made a decision about which path it will be allocated to. This path is essentially locked to another allocation and stores response data upon arrival. In some instances, the L2 controller 320 uses the pending bit to determine which paths are available for new allocations, which improves performance compared to a purely random cache replacement strategy.

[0128] In some instances, the L2 controller 320 employs a pseudo-random replacement strategy. If at least one path is available in the group (e.g., with an invalid cache consistency state), the L2 controller 320 is configured to select that path for allocation. However, if all paths in the group have pending cache consistency states, the L2 controller 320 cannot select a path for allocation. Instead of pausing the transaction, the L2 controller 320 is configured to convert the transaction to a non-allocatable access and forward the transaction to an endpoint (e.g., the L3 cache subsystem 308). Therefore, the L2 controller 320 continues pipelined output access without unnecessary transaction pauses.

[0129] Finally, if there are no empty (e.g., invalid) paths in the group, the L2 controller 320 uses a random number generator to identify paths in the group. Figure 10 Example 1000 demonstrates masked path selection using a random number generator. Specifically, the group comprises eight paths as shown in box 1002. Box 1004 demonstrates paths 0, 1, 4, and 7 with pending cache consistency states. Masking logic 1006 is applied to boxes 1002 and 1004 to create a masked subset containing the group's pending paths, namely paths 2, 3, 5, and 6 as shown in box 1008. If all paths are pending in box 1010, or the masked subset in box 1008 is empty, then the L2 controller 320 converts the transaction to non-allocatable access in box 1012 (e.g., to the L3 controller 309), as described above. However, if not all paths are pending in box 1014, then the L2 controller 320 applies a random number generator to select from the eligible paths in box 1008. In box 1016, the path selected in box 1014 updates its cache state to pending and the L2 controller 320 sends the allocation request to (for example) the L3 controller 309.

[0130] Figure 11 A flowchart illustrating an alternative method 1100 for route selection using a random number generator is provided. Method 1100 begins at block 1102, where the L2 controller 320 receives a first request to allocate a line in an L2 cache 324, which serves as an N-way group-associated cache as described. In response to a cache coherence state of the route indicating that the cache line stored in said route is invalid, method 1100 continues at block 1104, where the L2 controller 320 allocates said route in response to the first request. This is similar to the behavior described above.

[0131] However, in response to no path in the group having a cache coherence state indicating that the cache line stored in the path is invalid, method 1100 continues in block 1106, where the L2 controller 320 uses a random number generator to randomly select one of the paths in the group. In method 1100, the random number generator is used without first masking the pending path, which reduces processing requirements. In response to the cache coherence state of the randomly selected path indicating that another request is not pending for the selected path (e.g., the randomly selected path has a coherence state other than pending), method 1100 continues in block 1108, where the L2 controller assigns the selected path for the first request.

[0132] In the case that the randomly selected path in method 1100 has a pending consistency state, the L2 controller 320 may (for example) choose to serve the first request without allocating a line in the L2 cache 324 by converting the first request into a non-allocation request and sending the non-allocation request to the memory endpoint identified by the first request. In other instances, when the randomly selected path has a pending consistency state, the L2 controller 320 is configured to randomly select another path in the group. In some instances, the L2 controller 320 is configured to randomly reselect in this manner until the cache consistency state of the selected path does not indicate that another request is pending for the selected path. In other instances, the L2 controller 320 is configured to randomly reselect in this manner until a threshold number of random selections have been performed.

[0133] Regardless of the specific method of random route selection used, as described above, in the case where the L2 controller 320 is not assigned a line (e.g., converting a request into an unassigned request), performance is enhanced by not pausing the CPU core 302, and the L2 controller 320 continues to send access to the L3 controller 309 (for example).

[0134] As described above, the L3 cache subsystem 308 includes L3 SRAM, and in some instances, the L3 SRAM address region exists outside the address space of the L2 cache subsystem 306 and the CPU core 302. Depending on the performance requirements of various applications, the L3 SRAM address region is considered to be shared L2 or L3 memory. One way to implement the L3 SRAM address region as shared L2 or L3 memory is to disable the ability of the L2 cache subsystem 306 to cache any addresses in the L3 SRAM address region. However, if the application does not need to use L3 SRAM as shared L2 or L3 memory (e.g., to enable the L2 cache subsystem 306 to cache addresses in the L3 SRAM address region), then the physical L3 SRAM region is mapped (e.g., via the MMU described above) to an external, virtual address. This mapping requires additional programming (e.g., for the MMU), and the L2 controller 320 must manage different addresses mapped to the same physical L3 SRAM address region. This increases the complexity for those applications that enable the L2 cache subsystem 306 to cache addresses in the L3 SRAM address region.

[0135] In some instances, the L2 cache subsystem 306 includes a cache configuration register (e.g., a register or field of ECR ​​228) that allows configurable control over whether the L2 cache subsystem 306 can cache addresses in the L3 SRAM address region. In some instances, the L3 SRAM contains multiple address regions, and the cache configuration register establishes whether each address region is cacheable or not by the L2 cache subsystem 306. For simplicity, it is assumed that the L3 SRAM is a single address region, and therefore the cacheability of the L3 SRAM address region can be controlled by a single bit in the cache configuration register (for example).

[0136] For example, in response to a cache configuration register having a first (e.g., cancel assertion) value, L2 controller 320 is configured to operate in a non-cached mode, wherein L2 controller 320 provides a request to L3 cache subsystem 308 but does not cache any data returned by the request. However, in response to a cache configuration register having a second (e.g., assertion) value, L2 controller 320 is configured to operate in a cache mode, wherein L2 controller 320 provides a request to L3 cache subsystem 308 and caches (for example) any data returned by the request in L2 cache 324.

[0137] Therefore, when the L2 controller 320 operates in non-cached mode, the L3 SRAM address region can be shared across multiple CPU cores (e.g., CPU cores 102a to 102n) without any cache-related performance penalty, such as increased transaction volume to maintain cache coherency (e.g., victim transactions). However, the L2 controller 320 also has the flexibility to cache the L3 SRAM address region when (for example) a particular application benefits from this behavior (e.g., data stored in the L3 SRAM is rarely shared among CPU cores).

[0138] In this example, when the L2 controller 320 transitions from non-cached mode to cached mode (e.g., when the cache configuration register or its fields are asserted), the L2 controller 320 can begin caching addresses from the L3 SRAM address region without taking any additional action. For instance, because the L2 controller 320 has not previously cached these addresses, there is no obstacle to the L2 controller 320 simply starting to operate in cached mode.

[0139] However, when it is determined (e.g., via CPU core 302) that the L2 controller 320 will transition from cached mode to non-cached mode (e.g., when the cache configuration register or its fields are de-asserted), additional steps can be performed before the L2 controller 320 transitions to non-cached mode. For example, steps can be taken to evict any lines cached from the L3 SRAM address region from the L2 cache 324.

[0140] In this example, traffic from CPU core 302 to addresses mapped to L3 address regions is paused. For instance, CPU core 302 (or an application running on it) that requests L2 controller 320 to switch from cached mode to non-cached mode (e.g., via a cancellation assertion in a configuration register) pauses sending requests to L2 controller 320 for addresses booted into L3 SRAM. Meanwhile, CPU core 302 can continue sending requests to L2 cache subsystem 306 for addresses booted into addresses outside the L3 SRAM address region.

[0141] Next, for example, in response to a cancellation assertion in the cache configuration register, the L2 controller 320 is configured to evict cache lines in its L2 cache 324 that correspond to L3 SRAM address regions. The L2 controller 320 may evict all cache lines in its L2 cache 320 or only those corresponding to L3 SRAM address regions. In one instance, the L2 controller 320 invalidates every line in the L2 cache 324 that corresponds to an L3 SRAM address region. In another instance, the L2 controller 320 writes back every line in the L2 cache 324 that corresponds to an L3 SRAM address region. In yet another instance, the L2 controller 320 performs a write-back invalidation on every line in the L2 cache 324 that corresponds to an L3 SRAM address region. Some instances are not necessarily limited to the specific form of evict lines from the L2 cache 324 corresponding to L3 SRAM address regions.

[0142] Continuing with the write-back invalidation instance, the L2 controller 320 performs a write-back invalidation of its entire L2 cache 324 or a portion of the L2 cache 324 corresponding to the L3 SRAM address region. In one instance, the L2 controller 320 performs the write-back invalidation operation, while in another instance, the streaming engine 205 performs a blocking write-back (e.g., for addresses in the L2 cache 324 corresponding to the L3 SRAM address region). The L2 controller 320 (for example) indicates the completion of the write-back invalidation by asserting a signal to the CPU core 302 or by changing the value of the write-back invalidation register polled by the CPU core 302. Once the CPU core 302 receives the indication that the write-back invalidation is complete, the CPU core 302 deasserts the cache configuration register to disable the L3 SRAM address region cached by the L2 cache subsystem 306. The CPU core 302 is then able to resume sending requests to the L2 cache subsystem 306 for addresses in the L3 SRAM address region that will not be cached by the L2 controller 320.

[0143] Figure 12 A flowchart illustrating method 1200 for operating a cache controller (e.g., L2 controller 320) in cached or non-cached modes in various instances is provided. Method 1200 begins at block 1202, where the L2 controller 320 receives a request directed to an address in an L3 SRAM address region. In block 1204, it is determined that the cache configuration register has a first value (e.g., deassertion) or a second value (e.g., assertion). If the cache configuration register is deasserted, then method 1200 continues to block 1206, where the L2 controller 320 operates in non-cached mode by providing a request to the L3 SRAM (e.g., via L3 controller 309). Method 1200 then continues to block 1208, where the L2 controller 320 does not cache the data returned by the request in its L2 cache 324.

[0144] Returning to box 1204, if the cache configuration register is asserted, then method 1200 continues to box 1210, where the L2 controller 320 operates in cache mode by providing a request to the L3 SRAM (e.g., via L3 controller 309). Next, method 1200 continues to box 1212, where the L2 controller 320 caches the data returned by the request in its L2 cache 324.

[0145] Some instances involve operating the L2 controller 320 to allow access to the L2 SRAM 322 in both aliased and non-aliased modes. In some cases, previous versions of processors utilized an unprogrammable, statically implemented (e.g., using a multiplexer) mechanism in hardware to operate in aliased mode. In this approach, the memory is statically constructed as three separate memories that cannot be merged into a single common memory map. Moreover, multiplexing is applied to all transactions and requesters, making operation in non-aliased mode impossible. The examples described herein allow legacy applications to continue utilizing aliased mode as needed when accessing the L2 SRAM 322, without limiting the L2 SRAM 322 to strict aliased access, thus more generally increasing the functionality and flexibility of the L2 cache subsystem 306.

[0146] Figure 13 Examples and block diagrams 1300 illustrate various instances (e.g., L2 controller 320 interacting with L2 SRAM 322) of non-aliased and aliased modes of operation. Instance 1300 includes a CPU core 1302 (e.g., similar to CPU core 302 described above) and a DMA engine 1304. In this instance 1300, the DMA engine 1304 is similar to... Figure 1 Another of the CPU cores 102 shown is also capable of accessing the L2 cache subsystem 102a (e.g., by sharing the L2 cache subsystem 108). In instance 1300, CPU core 1302 is alternatively referred to as the "producer" of data written to L2 SRAM 322, while DMA engine 1304 is alternatively referred to as the "consumer" of data read from L2 SRAM 322.

[0147] Both the CPU core 1302 and the DMA engine 1304 are coupled to an L2 controller 320, which in turn is coupled to an L2 SRAM 322 as described above. Furthermore, the L2 controller 320 is coupled to a memory mapping control register 1306 and a memory switching control register 1308, the functions of which are further described below. In some instances, control registers 1306 and 1308 are part of a single control register, while in other instances, control registers 1306 and 1308 are separate structures, as shown in the illustration.

[0148] In some instances, control registers 1306 and 1308 are controlled as memory-mapped registers via software (e.g., executed on CPU core 1302). In one instance, memory-mapped control register 1306 specifies whether CPU core 1302 and DMA engine 1304 are able to view and access the full memory map of L2 SRAM 322 (e.g., non-aliased mode) or the aliased memory map of L2 SRAM 322 (e.g., aliased mode).

[0149] If the memory mapping control register 1306 is set to operate in the non-aliased mode shown in example 1310 of the L2 SRAM 322, then both the CPU core 1302 and the DMA engine 1304 can route transactions to virtual addresses in buffers IBUFLA, IBUFHA, IBUFHLB, and IBUFHB. In non-aliased mode 1310, the L2 controller 320 is configured to route such transactions to the corresponding physical addresses in those same buffers. Therefore, in non-aliased mode, the L2 controller 320 is configured to route transactions (from the CPU core 1302 or the DMA engine 1304) to virtual addresses in buffer IBUFLA, to the corresponding physical addresses in buffer IBUFLA of the L2 SRAM 322, and so on.

[0150] If the memory mapping control register 1306 is set to operate in the alias mode shown in example 1312 of L2 SRAM 322, then both CPU core 1302 and DMA engine 1304 are only able to route transactions to certain virtual addresses (e.g., in buffers IBUFLA and IBUFHA in this example). Attempting to route transactions to other virtual addresses (e.g., in buffers IBUFLB and IBUFHB in this example) results in an error described further below. In alias mode 1312, L2 controller 320 is configured to route transactions from CPU core 1302 to a virtual address (e.g., in buffer IBUFLA) to a first physical address (e.g., also in IBUFLA) and transactions from DMA engine 1304 to the same virtual address in buffer IBUFLA to a second, different physical address (e.g., in IBUFLB). This is depicted as mapping virtual addresses in operating alias mode 1312 to different physical addresses 1314.

[0151] By operating the L2 controller 320 in alias mode, the CPU core 1302, acting as a producer, writes to a virtual address while the DMA engine 1304, acting as a consumer, reads from the same virtual address. However, due to the alias operation mode, the physical address generated by the CPU core 1302 differs from the physical address consumed by the DMA engine 1304. This allows the CPU core 1302 to generate to physical buffer A (e.g., IBUFLA and IBUFHA) while the DMA engine 1304 consumes from physical buffer B (e.g., IBUFLB and IBUFHB), even though both address transactions to virtual addresses.

[0152] In this example, the memory switching control register 1308 specifies which physical address a virtual address alias should be sent to based on whether the CPU core 1302 and the DMA engine 1304 "own" a particular buffer. Ownership in this context is mutually exclusive; therefore, if the memory switching control register 1308 specifies that the CPU core 1302 owns buffer A (e.g., IBUFLA and IBUFHA), then the DMA engine 1304 cannot also own buffer A. In this example, suppose the owner of a buffer aliases its transactions to a physical address in a named buffer, while the non-owner of a buffer aliases its transactions to a physical address in an aliased buffer. For instance, if the CPU core 1302 owns buffer A, then the L2 controller 320 is configured to direct CPU core 1302 transactions to a physical address that is also in buffer A. Similarly, since the DMA engine 1304 does not own buffer A, the L2 controller 320 is configured to direct DMA engine 1304 transactions to a physical address in buffer B.

[0153] By managing the memory switching control register 1308, a ping-pong effect is enabled, allowing both CPU core 1302 and DMA engine 1304 to believe they are generating from and consuming from a buffer (e.g., by directing transactions to a virtual address in buffer A). However, when the memory switching control register 1308 indicates that CPU core 1302 is the owner of buffer A, CPU core 1302 generates physical addresses to buffer A while DMA engine 1304 consumes physical addresses from buffer B. Subsequently (e.g., when CPU core 1302 is close to filling physical addresses in buffer A with data), the memory switching control register 1308 is updated to indicate that DMA engine 1304 is the owner of buffer A. Therefore, DMA engine 1304 begins consuming physical addresses from buffer A while CPU core 1302 begins generating physical addresses to buffer B.

[0154] In a more general instance, the L2 SRAM 322 includes a working buffer (WBUF) and a first buffer A (e.g., containing...). Figure 13 IBUFLA and IBUFHA) and the second buffer B (e.g., containing Figure 13 (IBUFLB and IBUFHB in the example). Because the first, second, and working buffers are portions of the L2 SRAM 322, in one instance, a base address control register (not shown for simplicity) is used, which specifies the base address in the L2 SRAM 322 for each of the first, second, and working buffers. Figure 13 In a specific instance, the base address control register specifies the base address for each buffer: IBUFLA, IBUFHA, IBUFLB, IBUFHB, and WBUF. This allows for further configurability regarding where these buffers reside within the L2 SRAM 322. In one instance, the IBUF buffer size is fixed at 32KB as shown (e.g., from the specified base address), while the WBUF buffer extends to the end of the L2 SRAM 322 (from its specified base address). However, in another instance, the buffer size is configurable.

[0155] In some instances, the L2 controller 320 is configured to indicate various error conditions (for example, by asserting bits in an error status register, such as in the L2 cache subsystem 306). For instance, the L2 controller 320 is configured to indicate an error in response to a request for the working buffer (WBUF) that is outside the address range where various buffers reside (e.g., in the L2 SRAM 322).

[0156] In another example, the L2 controller 320 is configured to indicate an error in response to a request for (for example) buffer A that is directed to an address outside the address range of buffer A. The address range of buffer A is based on the base address of buffer A and the size of buffer A, which may be fixed or configurable.

[0157] In another instance, when L2 controller 320 operates in alias mode, L2 controller 320 is configured to indicate an error in response to a request to a virtual address mapped to a physical address in the alias buffer. For example, returning to reference... Figure 13 When operating in alias mode 1312, if the CPU core 1302 or DMA engine 1304 attempts to directly access an alias buffer (which in this case is buffer B (e.g., IBUFLB and IBUFHB)), an error is indicated. In general, in alias mode, access to a virtual address in one buffer (e.g., buffer A) is permitted, but access to a virtual address in another alias buffer (e.g., buffer B) is not. Therefore, in alias mode, the only way to access the physical address of alias buffer B is through alias mode operation of the L2 controller 320.

[0158] In any of the aforementioned error instances, the error clearing register (e.g., in L2 cache subsystem 306) contains a field corresponding to a field in the error status register. When a field in the error clearing register is asserted, for example, the corresponding field in the error status register is cleared.

[0159] Figure 14 A flowchart illustrating method 1400 for operating L2 SRAM 322 via L2 controller 320 in alias mode in various instances is provided. Method 1400 begins at block 1402, where L2 controller 320 operates in alias mode in response to a memory mapping control register value being asserted. Method 1400 continues at block 1404, where L2 controller 320 receives a first request from a first CPU core (e.g., CPU core 1302) for a virtual address (e.g., in buffer A) in L2 memory (e.g., L2 SRAM 322) booted into L2 cache subsystem 306. Method 1400 continues at block 1406, where a second request is received from a second CPU core (e.g., DMA engine 1304) for the same virtual address booted into L2 SRAM 322. Since the L2 controller 320 is operating in alias mode, method 1400 continues in block 1408, where the first request is directed to physical address A in the L2 SRAM 322 (e.g., as in...). Figure 13 (as shown in 1314) and continues in box 1410, where the second request is directed to physical address B in L2 SRAM 322 (e.g., as shown in 1314). Figure 13 (Exhibition 1314 in the middle).

[0160] In the foregoing description and in the claims, the terms “comprising” and “including” are used in an open-ended manner and therefore mean “including but not limited to…”. Furthermore, the term “coupled” means an indirect or direct connection. Thus, if a first device is coupled to a second device, the connection can be a direct connection or an indirect connection via other devices and connections. Similarly, devices coupled between a first component or location and a second component or location can be a direct connection or an indirect connection via other devices and connections. Elements or features “configured to” perform a task or function may be configured (e.g., programmed or structurally designed) by the manufacturer to perform a function and / or may be configured (or reconfigured) by the user after manufacturing to perform a function and / or other additional or alternative functions. Configuration can be achieved through firmware and / or software programming of the device, through the construction and / or layout of the device’s hardware components and interconnections, or combinations thereof. Moreover, the use of the phrase “grounded” or similar in the foregoing description includes chassis grounding, earth grounding, floating grounding, virtual grounding, digital grounding, common grounding, and / or any other form of grounding connection applicable to or suited to the teachings of this description. Unless otherwise stated, “approximately,” “around,” or “substantially” preceding a value means + / - 10% of the value stated.

[0161] The foregoing description illustrates the principles and various embodiments of this description. Once the above description is fully understood, those skilled in the art will recognize many variations and modifications. The following claims encompass all such variations and modifications.

Claims

1. A method comprising: Receive the first request to allocate lines in the N-way set-associative cache; In response to a cache consistency status indication that a cache line stored in the path is invalid, the path is allocated for the first request; In response to the fact that no path in the group has a cache coherence state indicating that the cache line stored in the path is invalid: Randomly select one of the paths in the group; and In response to a cache coherence status indication that another request is not pending for the selected path, the selected path is allocated for the first request. The cache coherence status of the cache line includes a bit, which is used for: Based on the fact that the cache line is not allocated, indicate whether other requests are pending for the path; and The status of the cache line is indicated based on the fact that the cache line has been allocated, rather than indicating whether other requests are pending for the path.

2. The method of claim 1, further comprising, in response to the cache coherence state indication of the selected path indicating that another request is pending for the selected path, serving the first request without allocating a line in the cache.

3. The method of claim 2, wherein serving the first request without allocating a line in the cache further comprises converting the first request into a non-allocation request and sending the non-allocation request to a memory endpoint identified by the first request.

4. The method of claim 1, further comprising, in response to the cache coherence state indication of the selected path indicating another request pending for the selected path, randomly selecting another path in the group.

5. The method of claim 4, further comprising continuing to randomly select another of the paths in the group until the cache consistency state of the selected path does not indicate that another request is pending for the selected path.

6. The method of claim 4, further comprising continuing to randomly select another of the paths in the group until a threshold number of random selections has been performed.

7. The method of claim 1, wherein allocating the selected path for the first request further comprises updating the cache coherence state of the selected path to indicate that the first request is pending for the selected path and sending the first request to a memory endpoint identified by the first request.

8. A method comprising: Receive the first request to allocate lines in the N-way set-associative cache; In response to a cache consistency status indication that a cache line stored in the path is invalid, the path is allocated for the first request; In response to the fact that no path in the group has a cache coherence state indicating that the cache line stored in the path is invalid: A masked subset of the paths in the group is created by masking the path that indicates a cache consistency state pending for any other request; Randomly select one of the paths in the shielded subset; and Assign a selected path to the first request. The cache coherence status of the cache line includes a bit, which is used for: Based on the fact that the cache line is not allocated, indicate whether other requests are pending for the path; and The status of the cache line is indicated based on the fact that the cache line has been allocated, rather than indicating whether other requests are pending for the path.

9. The method of claim 8, further comprising, in response to the masked subset being empty, serving the first request without allocating a line in the cache.

10. The method of claim 9, wherein serving the first request without allocating a line in the cache further comprises converting the first request into a non-allocation request and sending the non-allocation request to a memory endpoint identified by the first request.

11. The method of claim 8, wherein allocating the path for the first request further comprises updating the cache coherence state of the selected path to indicate that the first request is pending for the selected path and sending the first request to a memory endpoint identified by the first request.

12. A Level 2 (L2) cache subsystem, comprising: The L2 cache is configured as an N-way set-associative cache; and The L2 controller is configured to: Receive the first request to allocate a line in the L2 cache; In response to a cache consistency status indication that a cache line stored in the path is invalid, the path is allocated for the first request; In response to the fact that no path in the group has a cache coherence state indicating that the cache line stored in the path is invalid: Randomly select one of the paths in the group; and In response to a cache coherence status indication that another request is not pending for the selected path, the selected path is allocated for the first request. The cache coherence status of the cache line includes a bit, which is used for: Based on the fact that the cache line is not allocated, indicate whether other requests are pending for the path; and The status of the cache line is indicated based on the fact that the cache line has been allocated, rather than indicating whether other requests are pending for the path.

13. The L2 cache subsystem of claim 12, wherein the L2 controller is further configured to, in response to the cache coherence state indication of the selected path indicating another request pending for the selected path, serve the first request without allocating a line in the cache.

14. The L2 cache subsystem of claim 13, wherein when the L2 controller serves the first request without allocating a line in the cache, the L2 controller is further configured to convert the first request into a non-allocation request and send the non-allocation request to a memory endpoint identified by the first request.

15. The L2 cache subsystem of claim 12, wherein the L2 controller is further configured to randomly select another path in the group in response to a cache coherence state indication of the selected path pending another request for the selected path.

16. The L2 cache subsystem of claim 15, wherein the L2 controller is further configured to continue randomly selecting another of the paths in the group until the cache consistency state of the selected path does not indicate that another request is pending for the selected path.

17. The L2 cache subsystem of claim 15, wherein the L2 controller is further configured to continue randomly selecting another path in the group until a threshold number of random selections has been performed.

18. The L2 cache subsystem of claim 12, wherein when the L2 controller allocates the selected path for the first request, the L2 controller is further configured to update the cache coherence state of the selected path to indicate that the first request is pending for the selected path and to send the first request to a memory endpoint identified by the first request.

Images