Multiple requestor memory access pipeline and arbiter

Abstract

In described examples, a coherent memory system (600) includes a central processing unit (CPU) and first and second levels of cache. The memory system (600) can include a pipeline (630) for accessing data stored in one of the caches. A requestor (e.g., 601) can access the data stored in one of the caches by sending requests that can be arbitrated (e.g., 63) by the pipeline (630) concurrently.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to a multi-requestor memory access pipeline and an arbiter. BACKGROUND

[0002] A processing device can be formed as part of an integrated circuit, such as part of a system on a chip (SoC). In some examples, a SoC includes at least one central processing unit (CPU), where each CPU of the SoC is coupled to an integrated (e.g., shared) memory system. The memory system can include, for example, a multi-level cache memory (e.g., static RAM (SRAM) formed on the integrated circuit of the SoC) and at least one main memory (e.g., dynamic RAM (DRAM and / or DDR) that can be external to the integrated circuit of the SoC).

[0003] As more and more powerful CPUs are added (or coupled) to a processing device, increasingly complex memory architectures continue to provide scalability challenges. The scalability challenges remain, and can become even greater, when multiple CPUs share a common address space of a memory system. Portions of the common address space of the shared memory can include various levels of coherent caches (e.g., where the various levels can contain different memories with unique addresses for storing data).

[0004] In one example, a CPU in a cached memory system can consume an entire cache line every 4 cycles, which places additional processing demands on a cache designed to consistently share stored cache information among various CPUs. Such latencies can be extended when a cache is configured to protect certain regions of cache memory from being read or altered by at least one CPU that would otherwise be permitted to access the cache line. Improving data security for such systems can require increased processing power and / or a more efficient processing architecture. SUMMARY

[0005] In described examples, a coherent memory system includes a central processing unit (CPU) and first and second levels of cache. The memory system can include a pipeline for accessing data stored in one of the caches. Requestors can access data stored in one of the caches by sending requests that can be arbitrated by the pipeline at the same time. BRIEF DESCRIPTION OF DRAWINGS

[0006] Figure 1 is a high level system diagram showing an example dual-core scalar / vector processor formed as a system on a chip.

[0007] Figure 2 is a high level diagram showing levels of an example hierarchical memory system.

[0008] is a high level diagram showing levels of an example hierarchical memory system.Figure 3 An example one- or optionally two-core scalar and / or vector processor system 300 is shown having a coherent and hierarchical memory architecture.

[0009] Figure 4 An example unified memory controller of a second level of a coherent and hierarchical memory architecture.

[0010] Figure 5A An example level 2 memory bank interface of a system of Figure 4 An example level 2 memory bank interface of a system of

[0011] Figure 5B An example level 2 memory bank interface of a system of Figure 4 An example level 2 memory bank interface of a system of

[0012] Figure 6 is a flow diagram of an example bank-selective blocking cache controller pipeline with reservation-based arbitration and scheduling of cache transactions. DETAILED DESCRIPTION

[0013] In the drawings, like reference numerals refer to like elements, and various features not necessarily drawn to scale.

[0014] A processing device can be formed as part of an integrated circuit, such as a system on a chip (SoC). As described below, a processing device can include example security features for securing data in a memory system, such as a multi-level cache system.

[0015] Figure 1 is a high-level system diagram showing an example dual-core scalar / vector processor formed as a system on a chip. The SoC 100 is an example dual-core scalar and / or vector processor including a central processing unit (CPU) 110 core. The CPU 110 core includes a level-one instruction cache (LI I) 111, a level-one data cache (LID) 112, and a streaming engine (SE) 113, such as a dual streaming engine (2xSE). The SoC 100 can further include an optional CPU 120 core including a level-one instruction cache (LI I) 121, a level-one data cache (LID) 122, and a streaming engine 123. In various examples, the CPU 110 core and / or the CPU 120 core can include a register file, an arithmetic logic unit, a multiplier, and a program flow control unit (not specifically shown) that can be arranged for scalar and / or vector processing. The SoC 100 includes a level-two unified (e.g., combined instruction / data) cache (L2) 131 arranged to selectively cache both instructions and data.

[0016] In one example, CPU 110, level one instruction cache (LI I) 111, level one data cache (LID) 112, streaming engine 113, and level two unified cache (L2) 131 are formed on a single integrated circuit. In one example, scalar central processing unit (CPU) 120 core, level one instruction cache (LI I) 121, level one data cache (LID) 122, streaming engine 123, and level two unified cache (L2) 131 are formed on a single integrated circuit that includes CPU 110 core.

[0017] In one example, SoC 100 is formed on a single integrated circuit that also includes auxiliary circuits such as dynamic power control (DPC) power up / down circuit 141, analog / tracking circuit 142, design for testability (DFT) programmable built-in self-test (PBIST) and serial message system (SMS) circuit 143, and clock circuit 144. A memory controller (e.g., multi-core shared memory controller level 3, "MSMC3") 151 is coupled with SoC 100 and can be integrated on the same integrated circuit as SoC 100. The MSMC3 can include memory access functions such as direct memory access (DMA) so that the MSMC3 can act as (or work in cooperation with) a DMA controller.

[0018] CPU 110 operates under program control to perform data processing operations after data is stored in a memory system (e.g., including memory shared by multiple cores). The program for controlling CPU 110 includes a plurality of instructions that are fetched prior to decoding and execution by CPU 110.

[0019] SoC 100 includes a number of cache memories. In one example, level one instruction cache (LI I) 111 stores instructions used by CPU 110. CPU 110 accesses (including attempts to access) any of a plurality of instructions from level one instruction cache 111. Level one data cache (LID) 112 stores data used by CPU 110. CPU 110 accesses (including attempts to access) any addressed data (e.g., any data pointed to by any of a plurality of instructions) from level one data cache 112. The level one cache (e.g., LI I 111, LID 112, and 2xSE 113) of each CPU (e.g., 110 and 120) core is backed up by level two unified cache (L2) 131.

[0020] In the event of a cache miss of a corresponding level-one cache by any memory request, the requested information (e.g., instruction code, non-streaming data, and / or streaming data) is sought from the level-two unified cache 131. In the event that the requested information is stored in the level-two unified cache 131, the requested information is supplied to the requesting level-one cache to forward the requested information to the CPU 110. The requested information can be simultaneously forwarded to both the requesting cache and the CPU 110 to reduce access latency to the CPU 110.

[0021] The streaming engines 113 and 123 can be similar in structure and operation. In the SoC 100, the streaming engine 113 passes data from the level-two unified cache 131 (L2) to the CPU 110. The streaming engine 123 passes data from the level-two unified cache 131 to the CPU 110. In an example, each streaming engine 113 and 123 controls (and otherwise manages) at most two data streams.

[0022] Each streaming engine 113 and 123 is arranged to pass data of a defined type (e.g., a defined structure and / or protocol), where the data is passed as a stream. A stream contains a series of elements of the selected defined type. A program that operates on (e.g., consumes) a stream is instantiated (e.g., configures a processor as a special-purpose machine) to sequentially read the contained data and then process each element of the data.

[0023] In an example, streaming data contains an indication of defined start and end times (e.g., where the indication can be used to determine the respective start and / or end time points). Streaming data contains elements that generally have a fixed element size and type throughout the stream. Streaming data can contain a fixed sequence of elements, where a program cannot randomly seek elements contained within the stream. In an example, streaming data is read-only while active, such that a program cannot write to the stream while simultaneously reading from the stream.

[0024] When a stream is opened by an example streaming engine, the streaming engine: computes an address; fetches a defined data type from the level-two unified cache; performs data type manipulations; and passes the processed data directly to a requesting programming execution unit within the CPU. Data type manipulations can include, for example, zero extension, sign extension, and data element ordering / swapping (e.g., matrix transposition).

[0025] In various examples, a streaming engine is arranged to perform real-time digital filtering operations on a defined data type (e.g., benign data). Such engines reduce memory access time (e.g., that would otherwise be encountered by a requesting processor), which frees the requesting processor to perform other processing functions.

[0026] In various examples, the streaming engine increases the operational efficiency of the level one cache. For example, the streaming engine can minimize the number of cache misses stalled, as the stream buffer can bypass the L1 D cache (e.g., 111). Further, the streaming engine can reduce the number of scalar operations otherwise needed to maintain control loops and manage respective address pointers. The stream engine can include a hardware memory address generator that reduces software execution otherwise encountered (e.g., freeing up the CPU to perform other tasks) when generating addresses and managing control loop logic.

[0027] The level two unified cache 131 is further coupled to higher level memory system components via a memory controller 151. The memory controller 151 handles cache misses that occur in the level two unified cache 131 by accessing external memory Figure 1 (not shown in the middle). The memory controller 131 is arranged to control memory hub functions such as cache coherency determination, error detection and correction, and address translation.

[0028] The example SoC 100 system includes multiple CPUs 110 and 120. In a system that includes multiple CPUs, the memory controller 151 can be arranged to control data transfer between the multiple CPUs and maintain cache coherency among processors that can access external memory.

[0029] Figure 2 is a high level diagram showing the levels of an example hierarchical memory system. The memory system 200 is an example hierarchical memory system that includes a CPU 210 and controllers (e.g., 222, 232, and 241) for maintaining memory coherency of three respective levels of cache and memory. The first level cache (e.g., L1 data cache) includes an L1 static RAM (SRAM) 221, a level 1 controller 222, an L1 cache tag 223, and a victim cache tag 224. For example, the first level cache includes memory that is accessible by the CPU 210 and is arranged to temporarily store data on behalf of the CPU 210. The second level cache (e.g., L2 unified cache) includes an L2 SRAM 231, a level 2 controller 232, an L2 cache tag 233, a shadow L1 master cache tag 234, and a shadow L1 victim cache tag 234. For example, the second level cache includes memory that is accessible by the CPU 210 and is arranged to temporarily store data on behalf of the CPU 210. The memory system 200 is coherent and the memory regions of the various levels of cache can include local memory (e.g., including cache lines) that is addressable by the CPU. Table 1 shows the different memory regions that exist in the memory system 200, and whether each memory region is configurable to be coherent.

[0030] Table 1

[0031]

[0032] CPU 110 is bidirectionally coupled to level 1 controller 222, which is in turn bidirectionally coupled to level 2 controller 232, which is in turn bidirectionally coupled to level 3 controller 234, such that at least three levels of cache memory are coupled to CPU 210. Data is transferred into and out of Ll SRAM 221 cache memory, which is controlled by level 1 controller 222. Data is transferred into and out of L2 SRAM 231 cache memory, which is controlled by level 2 controller 232.

[0033] Level 1 controller 222 is coupled to (and in some instances includes) Ll cache tag 332 and victim cache tag 224. Ll cache tag 223 is a non-data portion of a respective Ll cache line, which has respective data stored in SRAM 221 cache memory. Ll victim cache tag (e.g., stored in a tag ram) 224 is a non-data portion of a cache line, where each cache line includes a respective line of data stored in SRAM 221 cache memory. In an instance, a cache line evicted from the Ll cache is copied into the victim cache, such that, for example, Ll cache tag 223 is copied into (or otherwise mapped into) Ll victim cache tag 224. The victim cache may, for example, store data that would otherwise be evicted at the Ll level, such that memory requested by CPU 210 that "hits" a line stored in the victim cache can be responsive, but not necessarily, access the L2 level cache (e.g., such that access time is reduced in such cases).

[0034] Level 2 controller 232 is coupled to (e.g., includes) two sets of cache tags. A first set of cache tags includes L2 cache tags 233, which are non-data portions of respective L2 cache lines, and where each cache line includes a respective line of data stored in SRAM 231 cache memory. A second set of cache tags includes shadow LI master cache tags 234 and shadow LI victim cache tags 235. Shadow LI master cache tags 234 generally correspond to (e.g., point to or include the same information as) LI cache tags 223. Shadow LI victim cache tags 235 generally correspond to (e.g., point to or include the same information as) LI victim cache tags 224. Shadow LI master cache tags 234 include at least valid and dirty states for corresponding cache lines in LI cache tags 223, while shadow LI victim cache tags 235 include at least valid and dirty states for corresponding cache lines in LI victim cache tags 224.

[0035] Level 2 controller 232 generates snoop transactions to maintain (e.g., include updates and enforce) read and write coherency of the state of the second level cache with the first level cache. For example, level 2 controller 232 sends snoop transactions to level 1 controller to determine the state of LI D cache lines and update shadow tags (e.g., 234 or 235) that involve the LI D cache lines being queried. Shadow tags (e.g., 234 or 235) can be used only for snooping transactions for maintaining L2 SRAM coherency with the level one data cache. In one example, updates of all cache lines in the higher level cache can be ignored to improve efficiency of the LI to L2 cache interface.

[0036] In response to snoop request data returned by level 1 controller 222, level 2 controller 232 updates shadow tags (e.g., 234 or 235) that correspond to LI cache lines being snooped. Events for which updates are performed include events such as allocation of LI D cache lines and dirty and invalidation modifications of data stored in LI SRAM 221.

[0037] Hardware cache coherency is a technique that allows different groups, called "shareability domains" (e.g., shared across different CPUs, or even within a single CPU), and different requesters (including those that can not contain caches) of data and program caches to have permission to access (e.g., read) the most recent data value at a given address in memory. Ideally, this "coherent" data value is needed to accurately reflect every observer in the shareability domain. An observer can be a device such as a cache or a requester that issues a command to read a given memory location.

[0038] By using memory attributes, certain memory locations can be marked as "shareable" and others as "non-shareable." To maintain full coherency in an ideal system, only shareable memory regions (e.g., where a region can be one or more contiguous locations) need to maintain coherency between caches / requesters (observers) that are part of the same shareability domain. Non-shareable memory locations do not need to maintain coherency. Described below are methods and apparatus arranged to efficiently implement coherency for shareable memory regions. When a shareable memory region is coherent, it is shareable, e.g., because all data locations of the shareable memory region have the most recent value of data assigned to each location of the shareable memory region.

[0039] Described below are techniques, control logic, and state information for an example functionally correct coherence system. Each observer can issue read (and optionally write) requests to locations marked as shareable. In addition, caches can also have snoop requests issued to them, requiring them to read, return, or even update their cache state in response to the type of snoop operation.

[0040] In a multi-level cache hierarchy, an intermediate level of the cache hierarchy (e.g., L2) is capable of sending as well as receiving snoop operations (e.g., maintaining coherency between different levels of the cache). In contrast, a first level of the cache hierarchy (e.g., level 1 controller 222) receives snoop operations but does not dispatch snoop operations. In addition, a last level of the cache hierarchy (e.g., level 3 controller 241) can dispatch snoop operations but does not receive snoop operations. In general, snoop operations are inherently dispatched from higher cache levels to lower cache levels within the cache hierarchy (e.g., where lower means closer to the CPU processing element and higher means further away from the CPU processing element).

[0041] Level 2 controller 232 includes hardware, control logic, and state information for accurately querying, determining, and processing the current state of a coherent (shareable) cache line in a level 1 cache (e.g., L1D 112), where the lower level caches are arranged as a heterogeneous cache system. In one example, level 1 controller 222 manages the heterogeneous cache system, which includes a home cache (e.g., set associative) and a victim cache (e.g., fully associative).

[0042] Coherence for memory system 200 can be enforced by recording the state of each cache line of the cache for each cache line using a modified-exclusive-shared-invalid (MESI) coherence scheme (including derivatives thereof). The standard MESI cache coherence protocol includes four states for each cache line: modified, exclusive, shared, invalid (or derivatives thereof).

[0043] The modified state indicates that the value in the corresponding cache line is modified with respect to the main memory, and the value in the cache line is exclusively held in the current cache. The modified state indicates that the value in the line does not exist or is not valid in any other cache in the same shareability domain.

[0044] The exclusive state indicates that the value in the corresponding cache line is not modified with respect to the main memory, but the value in the cache line is exclusively held in the current cache. This indicates that the value in the line does not exist or is not valid in any other cache in the same shareability domain.

[0045] The shared state indicates that the value in the corresponding cache line is not modified with respect to the main memory. The value in the cache line can exist in multiple caches in the same shareability domain.

[0046] The invalid state indicates that any value in the corresponding cache line is to be treated as if it does not exist in the cache (e.g., due to invalidation or eviction).

[0047] A shareability domain can be defined as a set of caches that must be kept coherent with each other. Not all MESI states are necessary to implement a coherent system with multiple levels of cache hierarchy. For example, the shared state can be eliminated (e.g., at the expense of performance), resulting in a MEI coherent system. In a MEI coherent system, exactly one cache in the entire system can hold a copy of each MEI cache line at a given time, regardless of whether the cache line is modified (or will be modified in the future).

[0048] The unit of coherency in a coherent cache system is a single cache line, such that the length of data (e.g., the number of addresses used to access data within a cache line, whether 32, 64, or 128 bytes) is treated as an atomic unit of coherency. In the example system 300 (described below with respect to Figure 3 The cache mechanism shared between the L1 D and the L2 includes a unit of coherency of 128 bytes, in the example system 300 (described below with respect to

[0049] Various coherency transactions can be initiated for the purpose of maintaining cache coherency. Such coherency transactions include transaction types such as read, write, snoop, victim. Each transaction type can have multiple forms / variations, which are included by the bus signaling protocol (such as the VBUS M.C protocol specification).

[0050] A read coherency transaction includes returning the "current" (e.g., most recent) value for a given address, whether the value is stored at an endpoint (e.g., in external memory) or in a cache in the coherent system.

[0051] A write coherency transaction includes updating the current value for a given address, and invalidating copies stored in caches in the coherent system.

[0052] A cache maintenance operation (CMO) includes an operation that initiates an action to be taken in the coherent caches (L1 D and L2) for a single address.

[0053] A snoop coherency transaction ("snoop") includes reading data stored in a cache, invalidating data stored in a cache, or both. A snoop is initiated by a higher level controller of a hierarchy of caches at a next lower level of the hierarchy. A snoop can be further propagated by a controller of a lower level cache to even lower levels of the hierarchy as needed to maintain coherency.

[0054] A victim coherency transaction includes sending a victim cache line ("victim") from a lower level cache in a hierarchy to a next higher level of the cache hierarchy. A victim is used to pass modified data up to a next level of the hierarchy. In some cases, a victim can be further propagated up to higher levels of the cache hierarchy. In example cases where the L1 D sends a victim to the L2 for an address in DDR or L3 SRAM and a line does not exist in the L2 cache, the L2 controller is arranged to forward the victim to a next level of the cache hierarchy.

[0055] Table 2 describes instance coherency commands that can be initiated between L2 and various masters that interact with the L2 cache.

[0056] Table 2

[0057]

[0058] Level 2 controller 232 maintains local information (e.g., in level 2 shadow tags) that is updated to reflect each change in monitored state information that occurs within the hardware FIFOs, RAMs, and logic within the first level cache, so that the current (e.g., most recent) state of all coherency cache lines that exist in both the home cache and victim cache in the LI controller can be determined locally at the level 2 cache. Pipelined hardware on a dedicated bus between the level 1 cache and the level 2 cache can improve the speed at which the level 2 shadow registers are kept updated and reduce the need for a bidirectional data access bus for reading and writing data between the level 1 cache and the level 2 cache. Accurate updating of the shadow information maintains correct data values and functionality of the coherent hardware cache system.

[0059] Figure 3 An example one- or optionally two-core scalar and / or vector processor system 300 with a coherent and hierarchical memory architecture is shown. System 300 is an example coherent shared memory system, such as memory system 200 or SoC 100. System 300 includes at least one CPU core. For example, a first core can include a first CPU 310, a DMC 361, a 32 KB LI D cache 312, a PMC 362, a 32 KB LI I cache 311, and a double-stream buffer 313. An optional second core can include similar components as the first core. CPU 310 (and second core 320, if present) is coupled to a UMC 363 via respective interfaces, which UMC is arranged to control L2 cache tags and memory.

[0060] In general, system 300 includes various cache controllers, such as a program memory controller (PMC) 362 (e.g., for controlling data transfer to and from the level 1 program 311 cache) and a data memory controller (DMC) 361 (e.g., for controlling data transfer to and from the LI D cache 312). As Figure 1As shown in the middle, the L2 cache can be shared between two processing cores. The system 300 also includes a unified memory controller (UMC) 363 (e.g., for controlling data transfers between the level 2 cache and the level 3 cache). For example, the UMC 363 is included by the level 2 cache, which is described below with respect to Figure 4 The UMC 363 is coupled to a memory management unit (MMU) 391 and the MSMC 351. The DMC 361, the PMC 362, the SE 313, the MSMC 351, and the MMU 391 are requestors, all of which can access memory stored in the L2 cache.

[0061] In one example, the system 300 is a pipelined cache and memory controller system for fixed and / or floating point digital signal processors (DSPs). The system 300 includes at least one such CPU core (with each CPU core including a respective private L1 cache, controller, and stream buffer), and a shared L2 cache controller. The system 300 can provide up to 2048 bits of data per cycle bandwidth, which is an 8x improvement over previous generation systems. The L1D can maintain 512 bits of data per cycle transfer to the CPU, and the L2 cache can transfer 1024 bits of data per cycle to the dual stream buffer. The L1 and L2 controllers are capable of queuing multiple transactions to the next higher level of memory, and can reorder out-of-order data returns. The L1P 311 controller supports branch exit prediction from the CPU and can queue multiple pre-fetch misses to the L2 cache included by the UMC 363.

[0062] The system 300 includes full soft error correction code (ECC) on its data and tag ram (e.g., described below with respect to Figure 4 In addition to error correction of memory stored data, the ECC scheme employed provides error correction of data transferred via processor pipelines and interface registers. The system 300 supports full memory coherency, where, for example, internal (e.g., level 1 and level 2 cache included) caches and memory are kept coherent with respect to each other and with respect to external caches and memory (as the MSMC 351 for level 3 cache and as external memory at the fourth and final level memory hierarchy). The UMC 363 maintains coherency between multiple L1Ds and maintains coherency between the L1Ds and each of the higher successive levels of cache and memory. The UMC 363 can maintain coherency with the dual stream engines in response to stream engine reads by snooping (e.g., via a pipeline separate from the stream data path) the L1D cache lines.

[0063] System 300 supports coherency throughout the virtual memory scheme and includes address translation, micro translation lookaside buffer (μTLB), L2 page table walk, and L1P cache invalidation. UMC 363 can support one or two stream buffers, each with two streams. Stream buffer data maintains coherency to the L1D cache, with each stream buffer having a pipelined high bandwidth interface to the L2 cache.

[0064] System 300 includes example interfaces between various components of different levels in system 300. In addition to CPU to DMC (CPR-DMC) and CPU to PMC (CPR-PMC) interfaces, the inter-level interfaces and data paths can be architected for pipelined multi-transaction standards (e.g., VBUSM or MBA).

[0065] The example interfaces include CPU-DMC, CPU-PMC, DMC-UMC, PMC-UMC, SE-UMC, UMC-MSMC, MMU-UMC, and PMC-MMU interfaces. CPU-DMC includes 512-bit vector read and 512-bit vector write and 64-bit scalar write. CPU-PMC includes 512-bit read. DMC-UMC includes 512-bit read and 512-bit write interfaces for performing cache transactions, snoop transactions, L1D SDRAM DMA, and external MMR accesses (e.g., where each such interface can handle 2 data phase transactions). PMC-UMC interface includes 512-bit read (which supports 1 or 2 data phase reads). SE-UMC interface includes 512-bit read (which supports 1 or 2 data phase reads). UMC-MSMC UMC interface includes 512-bit read and 512-bit write (with overlapping snoop and DMA transactions). MMU-UMC interface includes page table walk from L2. PMC-MMU interface includes μTLB miss to MMU.

[0066] L1P 311 includes a 32 KB L1P cache that is a 4-way set-associative with 64 byte cache line size, where each line is virtually indexed and tagged (48-bit virtual address). L1P 311 includes auto prefetching of L1P misses (where a prefetch miss from L2 can include two data phase data returns). L1P 311 is coupled to (e.g., included by) and controlled by PMC 362.

[0067] PMC 362 supports prefetching and branch prediction capable of queuing a variable number (e.g., up to 8) of fetch packet requests to the UMC (e.g., enabling deeper prefetching in the program pipeline).

[0068] PMC 362 includes an error correction code (ECC) with parity protection for data and tag RAM (e.g., 1-bit error detection for tag and data RAM). Data RAM parity protection is supplied with 1 parity bit per 32 bits. In tag RAM, a parity error can cause automatic invalidate and prefetch operations.

[0069] PMC 362 supports global cache coherency operations. PMC 362 can single-cycle support cache invalidation for three modes (e.g., all cache lines, MMU page table base 0, and MMU page table base 1).

[0070] PMC 362 provides virtual memory through virtual to physical addressing of misses and incorporates a uTLB to handle address translation and for code protection.

[0071] PMC 362 provides emulation and debug capabilities through the inclusion of access code that can be returned on a read to indicate the level of cache from which data was read and a bus error code that can be returned to indicate pass / fail status of all emulated reads and writes. PMC 362 provides extended control register access including L1P ECR registers that can be accessed from the CPU via a non-pipelined interface. The extended control registers are not memory mapped and can actually be mapped via MOVC CPU instructions.

[0072] L1D cache 312 is a direct mapped cache and is mirrored in parallel with a 16 entry fully associative victim cache. L1D cache 312 includes 32 KB of memory that can be configured down to an 8 KB cache. L1D cache 312 includes dual data paths (e.g., for 64-bit scalar or 1-Kb vector operands). L1D cache 312 includes a 128 byte cache line size. LID cache 312 includes a read allocation cache that supports both write back and write through modes. LID cache 312 is indexed physically, tagged physically (44-bit physical address), supports speculative loads and hits on miss, supports issued write misses, and provides write coalescing to all outstanding write transactions within LID. LID cache 312 supports FENCE operations on outstanding transactions. LID is auto-flushed and idle-flushed.

[0073] LID cache 312 includes LID SRAM for support of CPU and DMA accesses. The amount of SRAM available is determined by the sum of L1D memory and L1D cache size.

[0074] The DMC 361 includes lookup table and histogram capabilities to support 16 parallel table lookups and histograms. The DMC 361 can initiate a lookup table and dynamically configure the L1D SRAM into multiple banks / ways in response to a selected degree of parallelism.

[0075] The DMC 361 includes 64-bit and 512-bit CPU load / store bandwidth, 1024-bit LID memory bandwidth. The DMC 361 provides support for 16 interfaces with up to 8 outstanding loads to L2 of 64-bit wide groups. Hereinafter with respect to Figure 5A and Figure 5B Physical and virtual groups are described.

[0076] The DMC 361 includes error detection and correction (ECC). The DMC 361 includes ECC detection and correction on 32-bit granularity. This includes full ECC on data and tag RAMs with 1-bit error correction and 2-bit error detection. The DMC 361 provides ECC correction syndromes for writes and victims output to L2. The DMC 361 provides full ECC on victim cache lines. The DMC 361 provides read-modify-write support to prevent parity corruption on partial line writes. The ECC L2-L1D interface uses correction delays for read-response data pipeline ECC protection.

[0077] The DMC 361 provides simulation and debug execution by returning an access code (e.g., DAS) at read time to indicate the level of cache from which data was read. Bus error codes can be returned to indicate pass / fail status of simulated reads and writes. The contents of the cache tag RAMs can be accessed via extended control registers (ECRs).

[0078] The DMC 361 provides atomic operations on swap operations or compare-and-swap operations to cacheable memory space and provides increments to cacheable memory space.

[0079] The DMC 361 provides coherency including full modified-exclusive-shared-invalid (MESI) support in both the home cache and victim cache. The DMC 361 provides support for global cache coherency operations including snoop and cache maintenance operation support from L2, snoop for L2 SRAM, MSMC SRAM, and external (DDR) addresses, and full tag RAM comparisons to snoop and cache maintenance operations.

[0080] In one example, the DMC 361 provides 48-bit wide virtual memory addressing for physical addressing of memory with 44-bit physical addresses.

[0081] The DMC 361 supports extended control register access. The L1D ECR registers are accessible from the CPU via a non-pipelined interface. These registers are not memory mapped and are actually mapped to the MOVC CPU instruction.

[0082] The DMC supports L2 address aliasing (including VCOP address aliasing mode). Aliasing can be extended to multiple separate buffers such as the VCOP-IBUFAH, IBUFAL, IBUFBH, IBUFBL buffers. L2 address aliasing includes out-of-range and ownership checks for all buffers to maintain privacy.

[0083] The UMC 363 controls data flow into and out of the L2 cache 331. The L2 cache 331 is an 8-way set-associative, supporting cache sizes from 64 KB to 1 MB. The L2 cache 331 policy includes random least recently used (LRU) and / or random replacement. The L2 cache 331 has a 128 byte cache line size. The L2 cache 331 has a write allocate policy and supports write back and write through modes. The L2 cache 331 performs cache invalidation on cache mode changes, which is configurable and disableable. The L2 cache 331 is indexed physically, tagged physically (44-bit physical address), including each 4 in a set tag RAM, which allows four independent split pipelines. The L2 cache 331 supports each 2 of 64 byte streams from streaming engines, LID and LIP caches, and configuration and MDMA access on the unified interface to the MSMC 351. The L2 cache 331 caches MMU page tables.

[0084] An example L2 SRAM component of the L2 cache 331 includes each 4 of 512 bit physical sets, with each physical set having 4 virtual sets. Each set (e.g., physical and / or virtual set) has independent access control. The L2 SRAM includes a security firewall to L2 SRAM access. The L2 SRAM supports DMA access to the consolidated MSMC interface.

[0085] The UMC 363 provides pre-fetch hardware and on-demand pre-fetching of external (DDR), MSMC SRAM, and L2 SRAM.

[0086] The L2 cache provides error detection and correction (e.g., ECC) on 256-bit granularity. Full ECC support is provided for both tag and data RAMs with 1-bit error correction and 2-bit error detection for both. The ECC (see, e.g., ECC GEN RMW 471, described below) includes ECC syndromes output on writes and victims to the MSMC 351 and includes read-modify-write on DMA / DRU writes to keep the parity valid and updated. The ECC is arranged to correct and / or generate a number of parity bits for data sent to the LIP 311 and SE 313 via data paths / pipelines. This includes automatic erasure to prevent accumulation of 1-bit errors, and refreshing of parity. The ECC clears and resets parity on system reset.

[0087] The UMC 363 provides emulation and debug by returning access codes on reads to indicate the level of cache from which data was read. Bus error codes are returned to indicate pass / fail status of emulated reads and writes.

[0088] The UMC 363 supports full coherency between the L1D cache 312, 2 streams of the SE 313, L2 SRAM 331, MSMC 351 SRAM, and external memory (DDR). This includes L1D to shared L2 coherency, which can be maintained in response to snoop on L2 SRAM, MSMC SRAM, and external (DDR) addresses. Coherency is maintained via MESI scheme and policy. The UMC 363 includes user coherency commands from the SE 313 and includes support for global coherency operations.

[0089] The UMC 363 supports extended control register access. The L1D ECR registers are accessible from the CPU via a non-pipelined interface. The contents of the ECR registers are accessible in response to MOVC CPU instructions.

[0090] The UMC 363 supports L2 address aliasing (including VCOP address aliasing mode). Aliasing can be extended to multiple separate buffers, such as VCOP-IBUFAH, IBUFAL, IBUFBH, IBUFBL buffers. L2 address aliasing includes out-of-range and ownership checks for all buffers to maintain privacy.

[0091] The MSMC 351 allows the processor module 110 to dynamically share internal and external memory for both program and data within a coherent memory hierarchy. The MSMC 351 includes internal RAM, which provides flexibility to programmers by allowing portions of the internal RAM to be configured as shared level 3 RAM (SL3). The shared level 3 RAM is cacheable in the local L2 cache. The MSMC can be coupled to on-chip shared memory.

[0092] A memory fence (MFENCE) instruction is provided that stalls the instruction execution pipeline of CPU 310 until all processor triggered memory transactions are complete, which can include: cache line fill; L1D write to L2 or processor module write to MSMC 351 and / or other system endpoints; victim writeback; block or global coherence operations; cache mode change; and outstanding XMC prefetch requests. The MFENCE instruction serves as a simple mechanism for stalling a program until dispatched memory requests reach their endpoints. It can also provide ordering guarantees for writes that reach a single endpoint via multiple paths, e.g., where a multi-processor algorithm depends on the ordering of writes to a specific address and data during a manual coherence operation.

[0093] System memory management unit (MMU) 391 invalidates the μTLB in response to a processor context switch, e.g., to maintain privacy.

[0094] Figure 4 An example unified memory controller of a second level of a coherent and hierarchical memory architecture is shown. System 400 is an example coherent shared memory system, like system 300. System 400 includes at least one CPU. For example, a first core (core 0) can include CPU 410, L1D 421, SE 422, L1P 423, and MSMC 461, dynamic power down controller 463, and level 2 memory 480. An optional second core (core 1) can include similar components to the first core. The first core (and the second core 412, if present) is coupled to UMC 430 via a respective interface, which is arranged to control L2 cache tags and memory.

[0095] UMC 430 includes a L2 cache controller, state memory 440 (which includes L2 cache tag RAM 441, L2 MESI 442, L1D shadow tag RAM 443, L1D MESI 444, and tag RAM ECC 445), memory coherency (external, internal, global, user) 450 controller, MSMC interface 451, analog 452 controller, power down controller 453, extended control registers (ECRs) 454, firewall 470, ECC generator read-modify-write (ECC GEN RMW), L2 SRAM / cache arbitration and interface 472, and ECC check 473.

[0096] Generally described (with reference to Figure 3 and Figure 4The system 400 of Figure 4.1 includes six requestor ports (e.g., interfaces) coupled to the UMC 430: one PMC 362, one DMC 361, two SE ports (included in one streaming engine, SE 313), an internal ECR 454 interface from a CPU (e.g., CPU 410), and an MSMC 461. The DMC 361 interface has separate 512-bit read and write paths. This interface can also be used for snoop from the L1 D cache. Each read transaction can be either one or two data phases. The PMC 362 interface consists of a 512-bit read-only path (L1 P fetch only). Each read transaction can be either one or two data phases. The two SE interfaces (of SE 313) are 512-bit read-only. Each read transaction can be either one or two data phases. Read transactions are also used as part of the user block coherence functionality. The MSMC 461 interface consists of separate 512-bit read and write paths. The separate 512-bit read and write path interface is also used for snoop commands, read / write accesses to the L2 SRAM, and read / write accesses to the L1 D SRAM. Each read transaction can be either one or two data phases. The internal ECR 454 interface from each CPU of system 400 is a 64-bit non-pipelined interface and is used for configuration accesses to the ECR 454 registers of the UMC 430.

[0097] The UMC to DMC interface includes: a 512-bit DMC read path; a 512-bit DMC write path; DMC to UMC signals (such as read / write / victim address, address and safety of cache line returned to victim buffer, address and safety of cache line returned from victim buffer, two tag update interfaces to indicate clean lines returned from victim buffer, byte enable, read / write indicator, MMU page table attributes / permissions / safety level indicators, snoop response, L1 D cache mode signals such as size, size change on, global coherence on, and global coherence type); and UMC to DMC signals (such as snoop signaling, response to read and write, and other such handshake signals).

[0098] The UMC to PMC interface includes: a 512-bit PMC read path; PMC to UMC fetch address; and other such handshake signals.

[0099] The UMC to SE interface includes: a 512-bit SE read path; SE to UMC fetch address; SE to UMC user block coherence indicator; and other such handshake signals.

[0100] The MSMC-to-UMC interface is coupled to carry various types of transactions, such as: master DMA (MDMA, which can include cache allocation, victim, long distance write, and non-cacheable read, where such MDMA transactions can originate from the UMC); external configuration (ECFG, which can include read / write access to memory mapped registers that can be physically located outside of the CPU core, where such read / write access can originate from the UMC); DMA transactions (which can originate from the MSMC and are transactions that can transfer data, for example, between different CPU cores, between a CPU core and external DDR, or between a CPU core and non- DDR memory on the SOC, where the transactions can be created by a DMA controller and can be for L2 SRAM or L1 D SRAM); snoop transactions (which can originate from the MSMC and can be generated in response to a transaction from another core so that the other core can snoop data from the first CPU core); and cache warm (e.g., so that the MSMC can initiate transactions that the UMC can use to allocate lines from the 3L cache or external memory to the UMC cache).

[0101] The UMC-to-MSMC interface includes: a 512-bit MSMC read path; a 512-bit MSMC write path; MSMC-to-UMC signals (such as address, byte enable, read / write indicator, MMU page table attribute / permission / security level indicator, snoop transaction, DMA transaction, and cache warm transaction); and UMC-to-MSMC signals (such as snoop response, address, byte enable, read / write indicator, and MMU page table attribute / permission / security level indicator) and other such handshake signals.

[0102] The previously generated UMC ECR interface memory mapped registers have been replaced by an extended control register (ECR) in the system 400 and mapped to the MOVC CPU instruction. The UMC ECR path allows 64-bit read / write access to the control registers of the UMC. For configuration reads, the UMC is arranged to sample the contents of the registers and hold them for the duration of the access. The UMC ECR interface includes: a 64-bit ECR read path; a 64-bit ECR write path; address; permission / security level indicator; index, which can be used for cache tag lookups; and other such handshake signals.

[0103] The example UMC-to-MMU interface includes: a 64-bit read path; address; and other such handshake signals.

[0104] Some examples of UMC-to-L2 interfaces include: any two or four virtual groups; four physical groups of L2 memory, each containing addressable cells of 512 bits wide data; a 512-bit read data path; a 512-bit write data path; an address; a byte enable; a memory enable indicator; a read / write indicator; a virtual group select; and other such handshake signals.

[0105] The UMC 430 includes a Level 2 memory 480 (e.g., SRAM). The L2 memory 480 may contain any suitable number of groups, and four groups 481, 482, 483, and 484 are specified, each such group being coupled by a corresponding set of 512b read / write data paths and ECC data paths. The four groups may be organized with four virtual groups each, or with two virtual groups each, as referenced below. Figure 5A and Figure 5B As described.

[0106] Figure 5A Each physics group has 4 virtual groups. Figure 4 The system's instance level 2 memory group interface. For example, interface 500A includes physical groups 510 (e.g., group 0), 520 (e.g., group 1), 530 (e.g., group 2), and 540 (e.g., group 4). Each of physical groups 510, 520, 530, and 540 contains four virtual groups (virtual group 0, virtual group 1, virtual group 2, and virtual group 3). Each virtual group within each physical group contains a corresponding multiplexer / demultiplexer, such that each corresponding virtual group of a given (e.g., addressed) physical group can be written to or read from a virtual group memory access. Each virtual group in a given physical group can be accessed contiguously using (e.g., by overlapping or separating) virtual group memory accesses.

[0107] Figure 5B Each physics group has 2 virtual groups. Figure 4 The system's instance level 2 memory group interface. For example, interface 500B includes physical groups 510 (e.g., group 0), 520 (e.g., group 1), 530 (e.g., group 2), and 540 (e.g., group 4). Each of physical groups 510, 520, 530, and 540 contains two virtual groups (virtual group 0 and virtual group 1). Each virtual group within each physical group contains a corresponding multiplexer / demultiplexer such that each corresponding virtual group of a given (e.g., addressed) physical group can be written to or read from a virtual group memory access. Each virtual group in a given physical group can be accessed sequentially using (e.g., by overlapping or splitting) virtual group memory accesses.

[0108] Referring again to Figure 4 The UMC 430 includes four 512-bit wide memory ports, which can be referred to as UMC memory access port (UMAP) ports. When the memory banks arranged in SRAM can respond within each UMC cycle, each L2 SRAM interface (e.g., the interface of a requester to an L2 cache) can support one new access per UMC cycle. Accesses to the memory banks can be pipelined over multiple UMC cycles, which can allow the use of higher latency memories. Each of the virtual banks can include different latencies, as each interface verifies the availability of each virtual port, rather than the availability of the physical bank as a whole.

[0109] The UMC L2 SRAM protocol applies to memories directly connected to the UMC 430. The UMC 430 presents addresses and read / write indications on the UMAP boundaries and waits for some period of time (e.g., a latency) during which the L2 SRAM is "expected" to respond. The UMC 430 is able to control the four banks independently. Accesses to these virtual banks are issued consecutively. If the attached memory has a greater than 1 cycle pipeline latency, consecutive requests to the same virtual bank cause a "bank conflict." The second request is delayed until the first request is complete. Consecutive requests to different virtual banks can proceed without delay (e.g., when the latency of the later accessing memory is no more than twice the 1 cycle pipelined latency).

[0110] The UMC 430 can read the returned data after a programmed access latency (e.g., in the absence of a memory error). Two different types of latencies are supported - a pipeline latency and an access latency. The pipeline latency is the number of cycles the UMC must wait before it can access the same virtual bank again. The access latency is the number of cycles the memory takes to present data to the UMC after a read command has been presented. In an example system, the UMC 430 supports latencies from 1 to 6 for both the pipeline latency and the access latency.

[0111] Variations in latency between different types of SRAM can be compensated for by inserting wait states into the memory accesses, where the number of wait states is selected in response to the latency of the memory being accessed. One cycle and 2 cycle access latencies can be referred to as "0 wait states" and "1 wait state," respectively.

[0112] Security is a term that generally applies to the protection of data in memory. The enforcement of security includes the assignment of permissions to specific masters, the specification of certain permissions with certain allowed actions for ranges of memory addresses, and the determination of whether each read and write transaction to each memory address includes sufficient permissions to access the particular address and blocking access to the particular address for each transaction with insufficient permissions.

[0113] The permission information includes permission possibilities that are understood via various axes. For example, the permission possibilities can be understood via axes of privilege, virtual machine monitor, and security (e.g., safety) levels. Along the privilege axis, the permission possibilities include the possibilities of a user or supervisor. Along the virtual machine monitor (if applicable) axis, the permission possibilities include the possibilities of a root or guest. Along the security level axis, the permission possibilities include the possibilities of safe or non-safe. The permission possibilities are enforced across the three levels of the cache.

[0114] An example DSP architecture includes at least two security states, each state having respective associated memory attributes for controlling physical and / or logical security components. A secure / non-secure state is an attribute that accompanies (or is otherwise associated with) transactions presented by a CPU to a cache controller. When the CPU is in a secure state (e.g., which can be indicated by a csecure attribute indicated on each of the transactions generated by the CPU), the cache controller of each of the cache levels allows the CPU to access secure and non-secure memory locations. When the CPU is in a non-secure state (e.g., which can be indicated by a csecure attribute indicated on each of the transactions generated by the CPU), the cache controller of each of the cache levels allows the CPU to access non-secure memory locations but prevents the CPU from accessing secure memory locations. The csecure attribute can be a "security code" (e.g., where the security code includes at least one bit of a security state field and / or a numeric word state for indicating a security level of a process executing on the CPU). The security code can be a "security bit" as described herein.

[0115] In an example, an L2 firewall is used to provide security with respect to a requestor accessing an L2 SRAM generating transactions and with respect to an L2 generating memory transactions accessing higher levels of memory. The L2 firewall cooperates with an L3 firewall such that permission possibilities are accessible for controlling transactions that occur between the L2 cache and the L3 cache. Security firewall components exist at two interfaces: a UMC-MSMC interface (e.g., which protects transactions initiated by an example CPU that go to or turn to external memory), and a UMC-L2 RSAM interface (e.g., to protect accesses that go to or turn to L2 SRAM space).

[0116] Generally, a firewall can be configured in one of two modes: a white list mode (e.g., where indications are listed to indicate which masters / grants are allowed to access a predetermined address region), and a black list mode (e.g., where indications are listed to indicate which masters / grants are blocked from accessing a predetermined address region). In an example, a predetermined address region can be predetermined before a period of time in which the firewall blocks or allows access to addresses in the predetermined address region.

[0117] To protect selected levels of cache memory controlled by a firewall, for example, permission information (e.g., protection policies used to grant access permissions to particular blocks of addresses) can be stored in selected levels of the cache such that selected regions of memory can be specifically protected by lists of permissions or denials of access for respective regions to be protected. For regions on the black list, the firewall is arranged to block access to any cacheable memory locations (e.g., any memory locations with contents that can be stored in the cache). In one example, the firewall is programmed to block access to cacheable memory locations by processes in which access is not explicitly whitelisted can help prevent read-only memory from being cached and then subsequently updated locally in the cache by the process due to cache hits.

[0118] Regions of addresses in which protection is not specified exist between the regions of addresses listed in the whitelist or blacklist of the firewall. Such regions (e.g., "gray list regions") can arise when not every possible memory location is assigned a selected protection policy. Not associating a selected protection policy for every possible memory location can be a compromise design choice due to the limited nature of firewall configuration resources, such as limited memory or address handling requirements.

[0119] Access to caches protected by a firewall can be enhanced in certain cache operations (e.g., beyond the protection of the firewall without requiring additional complexity that would otherwise require higher complexity circuitry and layout space), which affect data stored in gray list regions (e.g., regions that do not intersect the set of the union of the black and white list regions listed in the firewall). In one example, the security level of a process that generates data stored in a particular cache line can be stored in tag memory associated with the particular cache line (including address tags, MESI state, and state bits described herein) to protect data stored in gray list regions without, for example, increasing the complexity of the firewall (e.g., to narrow the scope of the gray list regions).

[0120] For firewall-permitted (e.g., non-blocked) requester-initiated access requests that access selected cache lines of selected level caches, the selected cache lines can be selectively snooped (e.g., read from the LI cache, but remain in the line present in the LI cache), or invalidly snooped (e.g., read from the LI cache and removed from the LI cache), or invalidated (e.g., removed from the cache) in response to a security context of the access request and in response to a stored security code associated with the selected cache line, where the stored security code indicates a security context of a process when the process generated the information stored in the selected cache line. For example, selectively invalidating or reclaiming the selected cache line can be in response to a comparison of the security context of the access request and the security context indicated by the security code. For example, selectively invalidating or reclaiming the selected cache line can be in response to a comparison of the security context of the access request and the security context indicated by the security code. For example, selectively invalidating or reclaiming the selected cache line can be determined in response to the security context of the access request and the security context indicated by the security code being different.

[0121] As described hereinafter, selectively invalidating or reclaiming the selected cache line in response to the security context of the access request and in response to the stored security code indicating the security context of the selected cache line can reduce the complexity of the firewall (e.g., achieve similar levels of performance), can reduce the length of time otherwise spent flushing the LI D cache (e.g., which is performed to inhibit malicious software from accessing the contents of the cache), and can improve the overall performance of the CPU / memory system including the cache of the selected cache line.

[0122] Evicting the reduced subset of cache lines reduces the number of CPU stalls that would otherwise occur during the cache eviction process (e.g., without the security match of the memory request security context and the security context of the cache line addressed by the memory request). By not evicting data having the same security context, this reduces or eliminates the latency encountered in publishing the evicted cache information to the memory endpoint (e.g., external memory) and the additional latency encountered when reloading the evicted line.

[0123] In a write-back cache, values stored in the memory locations of a cache line stored in the cache can be modified (dirty, e.g., by a CPU) with respect to the main memory. When the memory allocated for the modified cache line is determined to be needed for other memory, the modified cache line can be evicted. When a cache line containing modified values is evicted from the cache, the evicted cache line, which contains dirty memory, is gradually sent to the next higher level, which reduces the length of time otherwise spent flushing the L1 D cache, which improves the overall performance of the memory system including the L1 D cache by reducing the number of CPU stalls that occur during cache eviction at the memory hierarchy. (The evicted cache line can also be stored in a victim cache at the same level of the cache hierarchy.) In response to the gradual sending of the dirty cache line to higher levels of the cache, the corresponding portion of the main memory is eventually updated with the modified information stored in the evicted cache line. When the corresponding portion of the main memory is updated with the dirty cache line, all memory contains the modified data, such that the memory system is again consistent and thus the modified data can be considered no longer dirty.

[0124] UMC 430 (as described above with respect to Figure 4 Firewall 470 includes a dedicated whitelist firewall that can be programmed to allow / disallow access to selected L2 SRAM address regions. Each of the selected L2 SRAM address regions can be assigned a respective cache policy. The respective cache policy assigned can be a policy of a selected permission level for each type of access, e.g., memory read access or write access. Table 3 shows example cache policy assignments.

[0125] Table 3

[0126]

[0127] As described above with respect to Figure 2Described, for example, the example L1 D heterogeneous cache implementation can cache the L2 SRAM address of each cached line in the L1 cache tag 223 and the (L1 D) victim cache tag 224. Management of the L1 D master cache and victim cache and the L2 shadow copy is performed in response to a dedicated protocol / interface coupled between the L1 D and L2 controllers, which allows allocation and relocation information from L1 to be communicated to the L2 controller. The L2 controller can respond to transactions and information from L1 and can also create and enforce snoop transactions for maintaining I / O (DMA) coherency from non-cached requestors within the same shareability domain. The snoop transactions can cause the L2 controller to initiate changes to the shadow cache of the L2 cache and the master / victim cache of the L1 D cache.

[0128] The level 1 (e.g., LID) controller 222 can include a program initiated cache maintenance operation (CMO) that can be selected by a programmer to manage occupancy of the caches in the L1 D and L2 controllers at the granularity of individual cache lines.

[0129] In this document Figure 4 In described examples, the CMO transaction can be issued from the streaming engine to the L2 controller (e.g., UMC 430) via a directional transaction on the VBUSM.C protocol interface. The VBUSM.C protocol interface is arranged to couple the SE 422 and the UMC 430 to one another. Table 4 shows an example VBUSM.C protocol interface.

[0130] Table 4

[0131]

[0132] The VBUS.C protocol includes an example csband signal. The csband signal is a packaged bus (e.g., 97 bits wide) that concatenates several sub-signals as shown in Table 4. The csband signal is asserted to maintain coherency during certain changes in cache state (e.g., where such changes can occur in response to allocation of cache lines and cache activity such as updating shadow information in the L2 controller).

[0133] At certain times, software initiating a CMO can need to evict / invalidate blocks of addresses (or a single address) for specific security levels (e.g., secure only and non-secure only). A "security code" (e.g., "security bit") is described herein that can be used to control the L2 cache to maintain fine-grained control over a reduced size (e.g., minimum) subset of L1 D cache lines required by the eviction CMO request. Such a need to evict / invalidate cache lines from the L1 D can arise in response to a change in the level of privilege mode of the CPU (e.g., from secure to non-secure or from non-secure to secure). Table 5 shows an example tag line of an L1 D cache that includes a security bit (csecure in bit 49 position) for each cache line in the L1 D cache.

[0134] Table 5

[0135]

[0136] Table 6 shows a field description of an example tag line of an L1 D cache that includes a security bit (csecure) for each cache line in the L1 D cache.

[0137] Table 6

[0138]

[0139] A selected portion of the cache (e.g., a subset of L1 D cache lines) to be evicted or invalidated is determined in response to determining the state of the respective security code for each cache line. Selecting a subset of the cache to be evicted (e.g., rather than evicting all lines of the cache) reduces the length of time otherwise spent flushing the L1 D cache, which improves the overall performance of the memory system including the L1 D cache by reducing the number of CPU stalls that arise during cache eviction. Table 6 shows a tag line of an L1 D cache that includes a security code bit for determining the security state of a respective line.

[0140] The calloc signal is asserted to initiate a read command from the L1D for reading the L2 cache line. Assertion of calloc (e.g., calloc == 1) indicates that the given cache line (caddress + csecure) is being allocated by the L1D home cache. When calloc is asserted (e.g., calloc == 1), the csband information is used to update the L1D shadow information in the L2 controller. When calloc is not asserted (e.g., calloc == 0), the valid bits (cmain_valid and cvictim_valid) for the addressed cache line are set to 0, such that the (e.g.) L1D cache line does not change when the calloc signal is not asserted.

[0141] In general, the same cache line (e.g., where the cache line is uniquely identified by the address and state of the secure code) cannot be read by two requesters at the same time (e.g., when passing from the home cache to the victim cache, and when passing from the victim cache). To help avoid such conflicts, the values of the cvictim_address and cvictim_secure (secure bits for the L1D victim cache line) signals can be prohibited from matching exactly the corresponding values of the cmain_address and cmain_secure signals during the time in which the calloc signal is asserted (calloc == 1) and the valid bits for the addressed cache line are set (e.g., when cmain_valid == 1 and cvictim_valid == 1).

[0142] Snoop and DMA transactions initiated by the L3 controller operate similarly to CMO transactions issued by the streaming engine. For example, such snoop and DMA transactions include a secure code for indicating the security level of the process that initiated the request.

[0143] Coherent read transactions issued from the MMU or streaming engine also operate similarly to CMO transactions issued by the streaming engine. For example, coherent read transactions include a secure code for indicating the security level of the coherent read request.

[0144] In various examples, an L2 controller (e.g., L2 cache controller 431) is arranged to receive an access request from a requester indicating a selected cache line. The L2 controller is arranged to compare a security code of the received access request with a stored security code associated with a security context of a previous access request that wrote current information into the selected cache line. In response to the comparison, the selected cache line can be selectively invalidated or evicted such that a subset (e.g., a set smaller than the entire set) of the selected cache line is invalidated or evicted in response to a change in a security level (e.g., as indicated by the security code) of the requester.

[0145] The L2 controller is coupled to a level two data cache, which is a stored L2 SRAM physical structure. The L2 SRAM is a monolithic endpoint RAM and is arranged to not store, store one or two cache lines for an address indicated by an access request from a requester. In various examples, the number of cache lines for a single cacheable address that can be stored in the L2 SRAM is equal to the number of security levels that can be indicated by a security code of a received access request. In one example, the security code is a bit (e.g., a "security bit") such that data for storage in a given cacheable address can be stored in a first cache line associated with a first possible value of the security code (e.g., when the security bit is 0) and thus data for storage in the given cacheable address can be stored in a second cache line associated with a second possible value of the security code (e.g., when the security bit is 1).

[0146] Consistency is maintained by including a field (e.g., a bit field) of a security code (e.g., a security bit) in each of the L1 D tag, the L2 tag, and the L2 shadow tag. When an access request causes information to be written into a cache line for any of the L1 D tag, the L2 tag, and the L2 shadow tag, the security code (e.g., a security bit) of the access request (e.g., included with the access request) is further propagated to other caches that include (or will include) information of the cache line indicated by the access request.

[0147] An access request includes a security code for indicating a security level of a security context of a requester that initiates the access code. As described below, the security code (e.g., a security bit) can be included in an L1 D tag, a CMO or snoop transaction, an MMU or SE read transaction, and a DMA read / write transaction. An L2 snoop transaction to an L1 D includes the security code of a CMO / snoop / read / DMA transaction request that is initiated.

[0148] When a transaction is handled by the L2 controller requiring a lookup in the L1 D home cache or a victim cache tag shadow copy, the L2 controller evaluates the security code of the cache line addressed by the transaction being handled to determine a "hit" or "miss" (e.g., by an access to the L1 D cache line). For example, a hit for an incoming transaction is determined: 1) in response to detecting a match between the stored security code of the addressed cache line in the shadow tag and the security code of the incoming transaction; and 2) in response to detecting a match between the address of the cached line in the shadow tag and the cache line address of the incoming transaction. In examples, a miss for an incoming transaction is determined: 1) in response to not detecting a match between the stored security code of the addressed cache line in the shadow tag and the security code of the incoming transaction; or 2) in response to not detecting a match between the address of the cached line in the shadow tag and the cache line address of the incoming transaction.

[0149] To help ensure that the L1 D accurately performs its own hit / miss detection for subsequent snoop transactions handled by the L1 D, the security code associated with the most recent cache line hit by the L2 controller can be passed to the L1 D controller. The security code associated with the most recent cache line hit by the L2 controller can be passed to the L1 D controller via a snoop transaction initiated by the L2 controller (signaled via the VBUSM.C bus interface protocol) in response to the most recent cache line hit (e.g., which includes a hit / miss detection in response to the state of the security code).

[0150] In contrast, some similar solutions lack a security code in the cache tag that indicates the security level of the requester context by which a cache line is tagged. This lack of preservation of the security level of the requester context by which a cache line is tagged can result in a serious security control failure (e.g., because the distinction between the security of the requester context by which a cache line is tagged and the non-secure context security level can potentially allow access requests to be processed at a security level different than the security level of the requester context by which the cache line is tagged.

[0151] The distinction between secure and non-secure contexts in the cache tag enables fine-grained cache eviction / invalidation of cache lines stored according to a first context, for example, without impacting cache performance of cache lines stored according to a context different than the first context. In examples where non-secure cache lines are invalidated via CMO operations, secure lines can remain in the cache, which results in improved cache performance for cache lines stored in secure software contexts. For example, this improvement can occur in cases where both cache lines stored in a non-secure software context and cache lines stored in a secure software context share the same tagged address in the same cache.

[0152] The efficiency of L2 controllers to accurately perform coherency snoop operations on L1D can be improved by performing coherency snoop operations on a subset of cases in which both the cached address and the addressed cache line and the security level of the access request are the same. The selection of which coherency snoop operations on L1D are to be initiated can be determined in response to evaluating the security level of the software context indicated by the security code (e.g., the state of the security bits) of the transaction, where the state of the security bits are stored in the cache tags in the L1D (master or victim) cache and also stored / maintained in the shadowed copies of the L1D / L2 cache tags in the L2 cache.

[0153] Some similar DSP SoCs include a single pipeline (e.g., data pipeline) such that accesses (e.g., where the accesses can include bus traffic caused by load, store, and fetch instructions) by a single CPU, DMA accesses, and local L2 accesses are all sequentially transmitted across the single pipeline. Such DSP system architectures do not support efficient accesses by multiple parallel groups due to the single pipeline through which L2 accesses are carried.

[0154] In some such instances, the L2 cache subsystem is not shared with other sources such as MMUs or any other data streamers due to bandwidth constraints of the single pipeline coupled between the DSP and the L2 cache subsystem. Further, functionality such as IO coherency and security are constrained due to such bandwidth constraints. The problem of limited bandwidth over the single pipeline is further exacerbated by the sequential nature of data processing, where data throughput is limited by processing latency that can extend time, e.g., where DSP accesses block other requesters from accessing the single pipeline.

[0155] As described herein, a hierarchical coherent memory system includes an intermediate level (e.g., L2) memory and a cache controller. In an example, the L2 memory and L2 controller are arranged to increase the bandwidth of requesters to the L2 cache pipeline while increasing the variety of heterogeneous requesters of the L2 cache. In an example, the data path from the L2 cache and through a portion of the controller is multi-banked such that each requester can effectively achieve full throughput of access to each bank (e.g., full throughput of the requester) (e.g., via dynamic assignment of requested banks to parallel portions of the L2 pipeline to the L2 cache).

[0156] Requesters (and corresponding cache transactions) can include LI P (fetch), LI D (load / store), MSMC (DMA to L2 or LI D SRAM, snoop and CacheWarm), MMU (page translation), streaming engine (streaming data on multiple ports, cache coherency / maintenance operations). Destination endpoints of requestor cache transactions can include L2 SRAM, LI D SRAM, L2 cache, MSMC SRAM, L3 cache, external DDR, and other circuitry (e.g., circuitry external to the DSP and support structures closely coupled to the DSP). The L2 controller is arranged to maintain coherency between caches at each level of the hierarchy of the memory system, such that the caches of the hierarchical memory system maintain full coherency. IO coherency to the L2 SRAM can also be maintained by the L2 controller. The L2 controller can include ECC for protecting data stored or transferred through FIFO and pipeline structures in the L2 controller to L2 cache memory data paths.

[0157] The L2 controller is arranged to dynamically arbitrate between multiple requesters and allocate priority of access across multiple groups, such that each requester is able to achieve full throughput (e.g., from the perspective of the requesters). The L2 controller is arranged to select optimized sets in response to the type of requesters and the type of requested cache transactions, such that overall better system performance is achieved due to the parallel selective allocation of groups and corresponding pipelines. Allocation of parallel resources (like groups and corresponding pipelines) can be determined in response to the type of requesters and / or the type of requests, which allows the allocated resources (e.g., groups and pipelines) to be effectively shared in parallel (e.g., in an overlapped manner) by multiple requesters. The parallelism enables a high level of data transfer rate and capacity, such that processor / requester stalls (which would otherwise occur) are reduced and available pipeline resources can be selectively allocated to service requestor cache operations.

[0158] The structures and techniques described herein selectively control and maintain a very high level of parallel data traffic in an example DSP system. The example system can include an arbitrator for selecting and assigning data path resources in response to the capabilities and priorities of each individual requester. The structures and techniques described herein maintain data coherency in the overall scheme of multiple groups (e.g., including group pipelines), dynamic arbitration, optimized grouping, and pipelining.

[0159] Memory and cache controllers are provided. To arrange parallelism of data transfer and achieve high level of data throughput, an L2 cache controller can include banked cache memory, where each such bank is controlled in response to control and data path fabric pipelines. Each such fabric can have independent and dedicated access to its memory by a requestor. The pipelines can include segments for blocking or non-blocking transactions generated by one or more requestors. The non-blocking segments of the pipelines help ensure that transactions that can potentially cause stalls in the system when not handled (e.g., high priority transactions) are allowed to bypass other transactions. The blocking segments of the pipelines are used to store stalled transactions and arbitrate (e.g., selectively block transactions from different requestors) between different requesters and transactions.

[0160] In various examples, cache related memory (e.g., tag RAM, snoop tag RAM, MESI RAM) is banked in parallel in a similar arrangement as the L2 memory, which includes a parallel banked fabric.

[0161] Figure 6 is a flowchart of an example banked arbitration and scheduling of cache transactions selective blocking cache controller pipeline. Pipeline 600 is an example pipeline. Pipeline 600 is individually coupled to instances of various requesters including PMC 601 (as PMC 362), DMC 602 (as DMC 361), SE 603 (as SE 313), MSMC 604 (as MSMC 351), and CMMU 605 (as MMU 391).

[0162] The overall UMC pipeline arbitration control can be arranged in six segments: a) blocking resource allocation units (RAUs) with extended local arbitration (ELA) coupled to respective requesters; b) RAU stage 1 (blocking stage 1 arbitration units) coupled to respective banks (e.g., bank pipes); c) RAU stage 2 (non-blocking stage 2 arbitration units) coupled to respective banks (e.g., bank pipes); d) groups of cascaded non-blocking P0-P3 pipeline stages coupled to respective banks; e) a blocking P4 stage including exit FIFOs of the bank pipelines; and f) cache miss and snoop arbitration and send segments (which include arbiters 691 and 692).

[0163] Each of the requesters (e.g., PMC 601, DMC 602, SE 603, MSMC 604, and CMMU 605) is coupled to the pipeline 600 and can issue at least one cache access operation (transaction) for accessing the L2 RAM data store 672. Each of the transactions is received and buffered in a respective arbitration FIFO 610 (e.g., such that any and all requests in a particular FIFO can be prioritized based on the particular FIFO receiving transactions of a particular class of requesters coupled to the FIFO). In an example, each FIFO 610 is coupled to a respective RAU unit.

[0164] The first section of the RAU ELA includes RAU 621, RAU 622, RAU 623A, RAU 623B, RAU 624, and RAU 625. RAU 621 is coupled to receive fetch transactions from PMC 601. RAU 622 is coupled to receive read / write, victim, snoop / read response, and snoop response transactions from DMC 602 in parallel. RAU 623A is coupled to receive read transactions from SE 603. RAU 623B is coupled to receive read transactions from SE 603. RAU 624 is coupled to receive block read / write, non-blocking write, snoop, and read response transactions from MSMC 604 in parallel. RAU 625 is coupled to receive read transactions from CMMU 605.

[0165] Each RAU ELA is arranged to arbitrate transactions of a particular transaction type received from a respective requester. Transactions sent by a given requester can include various types of transactions, which can be broadly categorized as blocking or non-blocking. Other such attributes that can be orthogonal to the blocking / non-blocking category can be categorized by, as an example, thread, attributes of a response, or other such attributes suitable for arbitration, scheduling, or other prioritization activities for ordering the progress of transactions through the pipeline 600. Such arbitration can be tailored in response to the type of requester and the type of transaction sent from a particular requester, including a particular class of requester.

[0166] Each of the RAU units is a blocking (e.g., selectively blocking) unit, such that any and all transactions can be selectively (and temporarily) stalled at and by the respective RAU unit, e.g., in response to a next subsequent (e.g., downstream) pipeline stage stall.

[0167] The types of transactions that can be arbitrated (e.g., selectively arbitrated) by the RAU include: 1) blocking reads and writes (e.g., including transactions such as data loads and stores, code fetches, and streaming engine reads), where such transactions can stall after non-blocking transactions or non-blocking responses (e.g., stall in response to determining that the transaction has a lower priority than a non-blocking transaction or non-blocking response); 2) non-blocking writes (e.g., including transactions from delivering LI D victims from a local CPU or from a different core with a line cached in a local memory system), where such transactions are arbitrated against other non-blocking and responsive transactions based on coherency rules; 3) non-blocking snoops (e.g., snoops from the MSMC), which are arbitrated against other non-blocking and responsive transactions based on coherency rules; 4) responses (e.g., responses such as responses to read or cache line allocation transactions issued to the MSMC, or for snoops sent to the LI D), where responses are arbitrated against other non-blocking and responsive transactions based on coherency rules; and 5) DMA (e.g., DMA transactions that are prioritized when associated with different threads of different priorities), where generally DMA transactions can stall after other non-blocking or blocking transactions for a relatively long period of time in which arbitration prohibits other cache transactions from blocking any DMA transaction.

[0168] Any given requestor does not necessarily need to initiate (e.g., issue or send) all possible types of transactions. Described subsequently herein are examples of requestors and respective arbitration by respective RAU units.

[0169] First, the DMC 601 (which can be an LI data controller) is a requestor that can initiate the following types of transactions: a) blocking reads; b) blocking writes; c) non-blocking writes (LI D victims); d) non-blocking snoop responses; and e) non-blocking DMA responses (for LI D SRAM). Non-blocking transactions can arbitrate over blocking transactions. Arbitration between various non-blocking transactions and non-blocking commands is handled in order of their arrival (e.g., FIFO). DMA responses that access the LI D SRAM do not necessarily need to be arbitrated in response to ordering commands.

[0170] Second, the PMC 602 (which can be an LI program controller) is a requestor that can only initiate blocking reads (in an example). In various implementations of the example DSP, read transactions sent from the PMC are handled in order (but extensions of arbitration control can allow them to be handled out of order).

[0171] Third, the SE 603 (streaming engine) is a requester that can initiate blocking read and cache maintenance operation (CMO) transactions. In various implementations of the example DSP, read and CMO access transactions from the SE are processed in order (but extensions of the arbitration control can allow them to be processed out of order).

[0172] Fourth, the CMMU 605 (which is a memory management unit) is a requester that can initiate blocking read only (in an example). In various implementations of the example DSP, read transactions from the CMMU are processed in order (but extensions of the arbitration control can allow them to be processed out of order).

[0173] Fifth, the MSMC 604 is a requester that can initiate transactions of the following types: a) blocking DMA read; b) blocking DMA write; c) non-blocking write (L1D victim from another core and / or processor); d) non-blocking snoop; and e) non-blocking read response. Non-blocking transactions are weighted to arbitrate in favor of blocking transactions. Arbitration among non-blocking transactions is adjudicated in response to ordering that can help maintain memory coherency. However, because there is no danger of ordering of parallel read responses, read responses can be arbitrated in any order.

[0174] The level 1 arbitration (S1 Arb) is coupled to one or more of the outputs of the RAU ELA stage to receive transactions from each requester that have been arbitrated by the FIFO 610. The outputs of the RAU can be dynamically selectively coupled and / or structurally coupled to a particular group selected from a parallel coupled set of parallel groups (as described later herein), and / or coupled to a particular requester based on expected processing load, in response to dynamic conditions such as the address of the transaction, the type of transaction. The 'winning' transaction arbitrated from each requester is presented to the level 1 arbitration (S1 Arb) for further arbitration. The level 1 arbitration stage includes blocking units, so a transaction pending in the level 1 arbitration unit can stall within the RAU level 1 in the case of a stall in the next subsequent pipeline stage.

[0175] Bank 630 (e.g., Bank Max) includes an arbiter 631, an arbiter 641, a tag access unit 651, a tag ECC 661, a hit / miss control 671, an L2 RAM data store 672, a data ECC 673, and FIFOs [1..N] 683. Bank 1 can include a pipelined bank that includes arbiters 632 and 642 and other units similar to those in the respective stages of Bank Max (630). Bank 0 can include a pipelined bank that includes arbiters 633 and 643 and other units similar to those in the respective stages of Bank Max (630).

[0176] The RAU stage 1 of the pipeline 600 contains a row of arbiters, including each of arbiters 631, 632, and 633 as an entry point for a respective set of pipes (each of which can be as one of or included by one of the parallel sets of pipes of set 630). The arbiters 631, 632, and 633 are coupled to receive transactions from the outputs of the data paths of the RAU ELAs (e.g., 621-625) such that the parallel arbiters can arbitrate transactions received in parallel from the RAU ELAs. The arbiters 631, 632, and 633 can share information among themselves such that an arbitration of a first arbiter (e.g., 631) can be decided in response to a second arbiter (e.g., 632). Various instance configurations of the RAU stage 1 can include one to eight arbiters such that one to eight pipes / sets can be arranged to arbitrate in parallel the arbitration of received transactions.

[0177] Each of the arbiters of the set of arbiters in the RAU stage 1 includes various checking devices for deciding arbitration in response to a set of determined checks. The result of the arbitration can be to allow the transaction to proceed to a next stage (e.g., RAU stage 2) upon successfully completing the checks of the checking devices.

[0178] A first check includes determining address hazards. Depending on the type of transaction and the type of requester that generated the transaction, the requested address is hazardous to addresses in the pipeline and transactions issued to external devices (which can require stalling dependent transactions). Non-blocking transactions are only hazardous to other non-blocking transactions, while blocking transactions are hazardous to both blocking and non-blocking transactions.

[0179] A second check includes determining fabric and pipeline hazards. Fabric and pipeline hazards are a class of hazards that depend on the pipeline and interface microarchitecture (e.g., arising from limitations of the pipeline and interface microarchitecture). Hazards can manifest in situations where: a) multiple transactions attempt to access the same interface at the same time (e.g., where one transaction can be a read response to an L1D read generated by the MSMC, and where another transaction can be a read hit to the L1D read such that the results of both transactions will be ready to return to the L1D in the same cycle); b) conflicts between simultaneous accesses to tags, snoop and MESI RAM, which can arise because tags, snoop and MESI reads can be accessed from two different stages in the pipeline; and c) conflicts between the L2 cache and SRAM, which can arise because a multi-phase transaction (such as a read-modify-write transaction) will conflict with a 'winning' transaction to access the same set.

[0180] The third check includes determining reservation credits. To help mitigate interactions (e.g., bad interactions, where external factors can otherwise reduce the efficiency of internal arbitration) between internal arbitration and external credits (from other modules), the UMC is arranged to selectively issue (e.g., "spend" reservation credits from a pool of reservation credits) and spend (e.g., "release" reservation credits back to the pool) reservation credits from a pool of reservation credits. Reservation credits from the pool of reservation credits are internally spent and released to the pipeline 600. In one example, the pool of reservation credits includes the depth of each of the exit FIFOs of the P4 pipe stage. The third check can include determining the amount of reservation credits to spend for each transaction in response to the type of requester and the type of transaction.

[0181] Examples of reservation credits include: a) read allocation command credits (e.g., where a reservation credit can be spent from the pool of reservation credits when space is available in the P4 pipe stage "to exit" a read allocation command from the pipeline 600); b) write allocation command and date credits (e.g., where space is available in the P4 pipe stage for exiting a write allocation command, and where space is available for write data to be held so that the write data can be merged later); c) write command credits (e.g., where space is available in the P4 pipe stage for exiting a non-allocated write command); d) L1 D victims (e.g., where space is available in the P4 pipe stage for exiting L1 D victim commands and data); e) L2 victims (e.g., where space is available in the P4 pipe stage for exiting L2 victim commands and data); f) snoop (e.g., where space is available in the snoop response queue in response to a situation to be generated, and where space is available in the snoop queue in the P4 stage in response to snoop to be sent to the L1 D); g) DMA to L2 SRAM (e.g., where space is available in the DMA response queue in response to a situation to be generated, and where space is available in the snoop queue in the P4 stage in response to snoop to be sent to the L1 D in response to a DMA transaction); h) DMA to L1 D SRAM (e.g., where space is available in the DMA queue P4 stage, which is a situation where DMA transaction results are to be forwarded to the DMC); and i) read response to L1 D (e.g., for a read that hits the L2 cache or for a read to the L2 SRAM, read data can be stalled by the read response to L1 D: to prevent a stall backup of the entire pipeline caused by the read response to L1 D, a separate read response FIFO (not shown) can be included to queue a series of read responses, and the read response FIFO can be coupled to (e.g., shared by) each of the group pipes.

[0182] With respect to level 2 arbitration (S2 Arb), each requester (e.g., DMC 601, PMC 602, SE 603, MSMC 604, and CMMU 605) can have one or more transactions that are eligible for final arbitration and enter into the non-blocking RAU level 2 of pipeline 600 (e.g., its group pipe). In various examples, each transaction for each requester is arbitrated separately, or multiple transactions from each requester can be arbitrated generally.

[0183] RAU level 2 of pipeline 600 includes a set of arbiters, such as arbiters 641, 642, and 643. Arbiters 641, 642, and 643 are coupled to receive transactions from the respective outputs of arbiters 631, 632, and 633.

[0184] The second level of arbitration (e.g., RAU level 2) is a non-blocking section of the pipeline, such that each group pipe continues to determine a series of arbitration winners, such that no transaction can be stalled indefinitely. As described below, the combination of fixed and dynamic arbitration is arranged to prevent indefinite stalling.

[0185] A first arbitration contention can exist between requesters in a first group of two requester types, including streaming engine reads and including data loads and / or stores. The relative importance of a win for any of these contention transactions can be determined by evaluating the ill or beneficial effects of the first arbitration contention on the application. To selectively determine the relative importance, a user (e.g., a system designer) can program a configuration register (via a memory map and / or an extended control register) to load a bandwidth management counter with a value that indicates a relative arbitration priority between the first two requester types.

[0186] A second arbitration contention can exist between requesters in a second group of two requester types, including a first output port and a second output port, where the output ports are both output ports of the same streaming engine. In addition to having two streaming engines with separate ports as shown in example pipeline 600, other pipeline examples can include a single streaming engine that shares two ports among two or more streams. Because the UMC can not signal to receive the actual stream-to-port mapping of the SE, and because such mapping can change dynamically, a SE port 0-port 1 relative bandwidth management counter in a memory map register can be programmed by a user, such that (e.g., in response to the user programming) the UMC can determine a relative arbitration between the two ports.

[0187] A third arbitration contention can exist between requesters in a third group of two requester types, where the transactions from the requesters are DMA reads / writes. Such arbitration can be determined by using a counter to manage data traffic caused by the requested transactions.

[0188] Table 7 shows user ports that access three sets of counters to cause selected bias in arbitration results (e.g., so that a first application that provides real-time results can run uninterrupted and a second application that provides less important results is subject to more latency than the first application).

[0189] Table 7

[0190]

[0191] At the end of RAU stage 2, each of the group pipes has a respective unique winning transaction, each of which then forwards (e.g., in response to winning) to the next stage (e.g., P0 to P3 stage) of each of the group pipes.

[0192] With respect to the first four pipe stages (e.g., stages P0 to P3 that exist in each of the group pipes), stages P0 to P3 are non-suspend and non-block. The non-suspend design helps to avoid transaction suspension in stages P0 to P3 of pipeline 600. Each transaction admitted to stages P0 to P3 is processed by the stage in 1 or 2 cycles, and each such admitted transaction can have a guaranteed slot. Because arbitration has ensured sufficient bandwidth reserved in stages P0 to P3 (and downstream portions of pipeline 600 from there) to avoid transaction suspension prior to P0 (e.g., in RAU stages 1 and 2), each winning transaction that enters stage P0 (and any sub-transaction that can respectively result for each winning transaction) can then be subsequently processed by at least stages P1 to P3 without suspension.

[0193] Instance functionality of stage P0 (pipe stage 0) includes credit management and cache and SRAM functionality as described later herein.

[0194] Credit management functionality of stage P0 includes managing consumption of the reservation credits described herein with respect to S1 arbitration. As described below with reference to Table 8, appropriate sets of reservation credits are consumed in stage P0 and released in later stages. Consumption of various reservation credits in stage P0 is described later herein.

[0195] A read allocation command reservation credit is consumed for any read that can potentially create a miss to the MSMC. Because tag, MESI, or snoop RAM has not yet been evaluated in stage P0, a hit / miss evaluation result is not necessarily available here, and consumption of this credit is based on other factors. Other factors can include: 1) determining whether a line can be cached for reads and writes; 2) determining whether a line can potentially require a snoop transaction, e.g., where a line is marked as cacheable and sharable; 3) determining whether an address of a transaction points to an endpoint with different coherency requirements; and 4) determining whether one of the requesters (e.g., of an arbitrated transaction) is capable of producing a snoop transaction.

[0196] Write allocation command and data reservation credits are consumed for any write that can potentially write allocate and create a miss to the MSMC. Because tags or MESI RAM are not evaluated in stage P0, the hit / miss evaluation results can not be available at stage P0, so the consumption of this credit is based on other factors (such as the factors described above).

[0197] Write command credits are instance reservation credits that are consumed for any write that can potentially miss the cache, does not write allocate, and is to be issued as a write miss to the MSMC. Because tags or MESI RAM are not evaluated in stage P0, the hit / miss evaluation results can not be available at stage P0, and the consumption of this credit is based on other factors (such as the factors described above).

[0198] L1 D victim reservation credits are consumed for any L1 D victim that can potentially miss the cache, where the L1 D victim is to be issued to the MSMC due to a cache miss. Because tags or MESI RAM are not evaluated in stage P0, the hit / miss evaluation results can not be available at stage P0, and the consumption of this credit is based on other factors (such as the factors described above).

[0199] L2 victim reservation credits are consumed for any read or write that can potentially create a miss to the MSMC, such that a dirty line is to be evicted from the L2 cache. Because tags, MESI, or snoop RAM are not evaluated in stage P0, the hit / miss evaluation results can not be available at stage P0, and the consumption of this credit is based on other factors (such as the factors described above).

[0200] Snoop reservation credits are consumed for any read or write that can potentially create a snoop to the L1 D. Because snoop RAM is not evaluated in stage P0, the hit / miss evaluation results can not be available at stage P0, and the consumption of this credit is based on other factors (such as the factors described above).

[0201] DMA to L2 SRAM reservation credits are consumed for any DMA read that does not indicate a snoop to the L1 D and can be read from the L2 SRAM. Because snoop RAM is not evaluated in stage P0, the hit / miss evaluation results can not be available at stage P0, and the consumption of this credit is based on other factors (such as the factors described above).

[0202] DMA to L1 D SRAM: Reservation credits do not need to be consumed for this transaction, as space is available in the DMA queue P4 stage (e.g., without the need for a reservation station in the P4 exit FIFO) and because DMA transactions can be forwarded to the DMC. Forwarded DMA transactions can be without tag or snoop checking.

[0203] The L1D reservation credit read response is consumed for any read that can potentially read from the L2 cache or L2 SRAM and send data back to the DMC. Because the tag, MESI, or snoop RAM are not evaluated in stage P0, the hit / miss evaluation results can not be available at stage P0, and this credit consumption is based on other factors (as described above).

[0204] The credit management functionality of stage P0 includes managing cache and SRAM functionality. The P0 pipeline stage includes (or is coupled to) a tag access unit 651. The tag access unit is arranged to pre-process each of the read transactions to be sent to the L2 tag RAM, L2 MESI RAM, snoop shadow tag (L1D), victim shadow tag (L1D victim cache), and firewall.

[0205] Stage P1 (pipeline stage 1) includes cache and SRAM functionality. Stage P1 consumes a pipeline cycle while processing reads of the various cache-related RAMs listed above.

[0206] Stage P2 (pipeline stage 1) includes cache and SRAM functionality. The tag ECC 661 consumes a pipeline cycle while performing ECC detection and correction to verify data read from the various cache-related RAMs listed above (e.g., to correct soft errors caused in circuitry added by the pipeline 600), and while performing the initial portion of the hit / miss determination.

[0207] Stage P3 (pipeline stage 1) includes credit management functionality. The hit / miss results for both the L2 cache and the L1D shadow cache are determined by the hit / miss control 671, and some of the corresponding reservation credits are released here by the hit / miss control 671.

[0208] Some of the reservation credits released by hit / miss control 671 can include: a) read allocation command credits (e.g., in response to a read that hits the L2 cache, where the corresponding reservation credit is released because, for example, a miss cannot be generated and sent to the MSMC); b) write allocation command and date credits (e.g., in response to a write that hits the L2 cache, where the corresponding reservation credit is released because, for example, a write allocation miss can not be generated and sent to the MSMC); c) write command credits (e.g., in response to a write that hits the L2 cache, where the corresponding reservation credit is released because, for example, a write miss cannot be generated and sent to the MSMC); d) L1D victim (e.g., in response to an L1D victim that hits the L2 cache, where the corresponding reservation credit is released because, for example, a victim cannot be sent to the MSMC); e) L2 victim (e.g., in response to a read or write that hits the L2 cache, where the corresponding reservation credit is released because, for example, an L2 victim cannot be generated to the MSMC, and if a read or write misses the L2 cache but the line being replaced is not dirty, then the corresponding reservation credit is also released because, for example, an L2 victim can not be generated and sent to the MSMC); f) snoop (e.g., in response to a transaction that misses the L1D cache (including both the main cache and victim cache), where the corresponding reservation credit is released because, for example, a snoop cannot be generated to the DMC); g) DMA to L2 SRAM (e.g., in response to a transaction that hits the L1D cache (including both the main cache and victim cache), where the corresponding reservation credit is released because, for example, a snoop can be sent to the DMC); h) DMA to L1D SRAM (e.g., where the corresponding reservation credit is not released); and i) read response to L1D (e.g., the corresponding reservation credit).

[0209] Stage P3 (pipe stage 1) includes cache and SRAM functionality. Hit / miss control 671 continues the process of hit / miss evaluation and, in at least some cases, can generate a final result for both the L2 cache and the L1D snoop filter. In response to the final result for both the L2 cache and the L1D snoop filter, stage P3 can also perform initialization functions, such as setting up cache accesses for subsequent hits, L2 SRAM accesses, commands for misses, error status, and exception matters.

[0210] L2 RAM data store 672 is coupled to receive transactions from stage P3 and to forward data retrieved in response to transactions received from stage P3 to data ECC 673. Transactions received from hit / miss control 671 of stage P3 can bypass L2 RAM data store 672 by traversing an L2 VCT (level 2 victim resulting from an L2 cache miss) path to reach a cache miss 681 in stage P4, by traversing an SRAM bypass cache miss path to reach a cache miss 681 in stage P4, and by traversing an SRAM bypass snoop path to reach a snoop 682 in stage P4.

[0211] Stage P4 is the final portion of the full pipeline (e.g., stages P0 through P4, and pipeline 600): stage P4 is blocking, while stages P0 through P3 are non-blocking. Stage P4 includes FIFOs and other storage buffers that help isolate the front end of the pipeline from external interfaces, as well as external credits that are applied to those interfaces. Commands that enter stage P0 are guaranteed to be entries into exit FIFO entries in stage P4 (e.g., without being blocked), but the rate at which those stage P4 FIFOs retire FIFOs into transactions depends on the stages after P4 and external credits.

[0212] Transaction and reservation credit MSMCs (e.g., cache and miss) and DMCs (snoop, DMA to L1 DSRAM) sets are handled independently of the handling of reservation credits consumed and released for other kinds of transactions. For example, any output of stage P4 of the pipeline can be independently coupled to a selected input of a master arbiter for MSMC transactions 691 or to a selected input of a master arbiter for DMC transactions 692.

[0213] With respect to reservation credit management, all consumed reservation credits can be released in the P4 stage (so that reservation credits are recirculated to a pool of reservation credits) so that transactions can proceed to the next stage and eventually to an endpoint (e.g., MSMC or DMC).

[0214] While the P4 stage can be a blocking stage, in some conditions, a blocking transaction can not be allowed to block a non-blocking transaction. An example of such a blocking condition can be a case where a blocking read advance is not allowed due to the presence of insufficient reservation credits available for the Universal Memory Controller (UMC)-MSMC interface. In such a case, when the required reservation credits (non-blocking reservation credits) are present on the UMC-MSMC interface, a L1 D victim or a L2 victim will be allowed to issue. The determination of whether sufficient credits are available is managed by a state machine (not explicitly shown) that monitors the availability of external credits available from the UMC-MSMC interface, monitors the availability of external credits available on the DMA / snoop pipe stage (e.g., next stage), and arbitrates between different exit FIFOs of a group so that more reservation credits can be consumed than would otherwise be available to guarantee the use of only (internal) reservation credits.

[0215] The cache miss, snoop arbitration, and send stage is a common stage that receives transactions and forwards transactions received from all group pipes (e.g., the output of each group pipe). The cache miss, snoop arbitration, and send stage includes a master arbiter for MSMC transactions 691 and a master arbiter for DMC transactions 692. Transactions from any pipe designated for transmission to the MSMC can be arbitrated by the master arbiter for MSMC transactions 691 so that arbitration for such transactions is isolated and independent from arbitration for transactions from any pipe intended for the DMC. The cache miss, snoop arbitration, and send stage evaluates, based on transaction type, the type and number of external credits required to issue a particular transaction to an endpoint (MSMC or DMC) and arbitrates one transaction from a pipe that can be sent to an external device.

[0216] In the example pipeline 600, FIFO[1..N] 683 is a set of group pipe exit FIFOs in stage P4. Each of the exit FIFOs has a respective depth of reservation stations (e.g., “slots”) in which it can temporarily buffer a series of received transactions. The number of reservation stations in a particular exit FIFO determines the number of reservation credits available for a given FIFO. For each exit FIFO in FIFO[1..N] 683, there is a respective counter in counter[1..N] 609. The number of maximum reservation credits for a selected FIFO can be loaded into the respective reservation counter to initialize the reservation counter. Table 8 shows example transaction assignments and reservation credits for an associated pair of reservation counter and exit FIFO.

[0217] Table 8

[0218]

[0219] Each entry stored in a respective FIFO can be in one of four states: an unoccupied state, where the reservation counter value equals the start value; a reserved but unoccupied state, where the reservation counter value is less than the start value; an occupied (and reserved) state, where the reservation counter value is less than the start value; and a full state, where the reservation counter value has a value of zero.

[0220] Arbitration of transactions for storage in an exit FIFO is performed in response to reservation credit actions, which can "consume" reservation credits (e.g., in response to a number of reservation stations as indicated by a respective depth of the exit FIFO) or "release" reservation credits (e.g., reservation credits that have been previously consumed).

[0221] Consumption of reservation credits can occur in response to a reservation made for storage of a transaction entry in a particular exit FIFO. A reservation counter associated with the particular exit FIFO can be decremented in response to a consumed reservation credit, such that availability of open reservation stations in the particular exit FIFO can be tracked. At this point in the "reservation credit cycle," a transaction entry does not yet have to be pushed into a reservation station of the particular exit FIFO; consumption of a reservation credit indicates that a previously open reservation station has been reserved and is not available to accept a reservation (until released). Thus, a credit count is decremented in response to a respective consumption of a reservation credit.

[0222] Release of reservation credits can occur in response to a transaction entry being "popped" (e.g., exited) from a particular FIFO, such that a previously entered transaction entry is no longer stored in the FIFO. Thus, a reservation credit count in an associated reservation credit counter is incremented in response to a respective release of a reservation credit.

[0223] The pipeline 600 includes a blocking stage that allows a type of transaction with a lower priority to be held (e.g., temporarily paused) while allowing a type of transaction with a higher priority to advance in favor of the lower priority transaction type. Further, different transaction types can require different amounts of reservation credit, where an amount of reservation credit to be consumed can be determined in response to an amount of reservation credit associated with a particular type of transaction. In the example arbitration described later herein, a transaction is allowed to advance only when and if all required credit types have a counter value greater than zero (e.g., which indicates that the respective FIFO for the reservation counter is not in a full state).

[0224] In an example arbitration, the transaction enters RAU stage 2. The entering transaction is an instance transaction, where the transaction is a streaming engine (SE) coherent and cacheable read transaction with an endpoint outside the L2 cache controller. The type of entering transaction indicates that at least one of three actions will (e.g., will likely) be needed to satisfy the entering transaction. Determining which of the three actions to take can be determined in response to determining where and how to cache the address memory (e.g., indicated by the entering transaction).

[0225] The subsequent actions (e.g., if performed) will require a query to memory (e.g., tag RAM, or other cache management memory), resulting in an inability to determine a prediction of the final action to take at the time this transaction advances from the S2 arbitration (e.g., RAU stage 2) pipeline stage to the next pipeline stage (e.g., pipeline stage PO) (e.g., to the end of the current pipeline cycle). As a first potential action, a snoop L1 D will be performed if the line is cached in L1 D. Such a state can be determined by a cache hit in the shadow copy of the L1 D tag. As a second potential action, a cache inquiry will indicate that the line is a miss. As a third potential action, if the line is a miss, an L2 victim transaction will be performed, and space for the L2 victim will be allocated, and the line from the cache being replaced will be marked dirty.

[0226] An SE coherent and cacheable read transaction will 'win' arbitration and advance to the next pipeline stage if and only if the following reservation counters are greater than 0:

[0227] If (CREDIT_A > 0) and (CREDIT_C > 0) and (CREDIT_G > 0), then advance (1)

[0228] The reservation credit actions in RAU stage 2 include:

[0229] Consume credit CREDIT_G (decrement CREDIT_G counter) (2)

[0230] For potential snoop read of DMC,

[0231] Consume credit CREDIT_A (decrement CREDIT_A counter) (3)

[0232] For potential read miss of MSMC, and

[0233] Consume credit CREDIT_C (decrement CREDIT_C counter) (4)

[0234] Potential L2 victims for MSMC transactions. Thus, the reservation credits of FIFO[G], FIFO[A], and FIFO[C] have each been decremented. In the example, the credit counters A, C, and G are reservation credit counters and the credits consumed (or released) are reservation credits.

[0235] Table 9 shows example results of SE coherence and cacheable read transactions at pipe stage 3 (e.g., hit / miss control 671) that can be generated as a function of tag hit / miss results.

[0236] Table 9

[0237]

[0238] Depending on the results of the hit / miss check at pipe stage P3, one of the exit FIFOs will receive the generated transaction. If the transaction requires a snoop, then a snoop command is generated and pushed into FIFO G, and COUNTER G is not updated. If the transaction requires a cache miss, then a miss command is generated and pushed into FIFO A and COUNTER A is not updated. If the transaction requires an L2 victim, then a victim command is generated and pushed into FIFO C and COUNTER C is not updated.

[0239] Because pipe stage 3 is non-blocking, the transaction is advanced to pipe stage P4 for further processing. If the transaction advanced to the P4 stage requires a snoop to be generated and the P4 stage is able to advance the transaction to the "Master ARB for DMC transactions" pipe stage, then the credit COUNTER G is released (incremented). If the transaction advanced to the P4 stage requires a cache miss to be generated and the P4 stage is able to advance the transaction to the "Master ARB for MDMA transactions" pipe stage, then the credit COUNTER A is released (incremented). If the transaction requires an L2 victim to be generated and the P4 stage is able to advance the transaction to the "Master ARB for MDMA presentation" pipe stage, then the credit COUNTER C is released (incremented). At the end of processing at stage P4, each of the reservation credit counters G, A, and C have been incremented so that each of the reservation credits previously consumed in the RAU stage 2 have been released and the value of the respective counter has been restored to its respective starting value.

[0240] In a first example, a system includes a cache including a local memory including a set of cache lines to store data, and a multi-banked pipeline coupled to access the set of cache lines of the local memory, and the multi-banked pipeline includes a first bank of pipes configured to receive a first set of transaction requests to access the local memory from a first requestor, and a second bank of pipes configured to receive a second set of transaction requests to access the local memory from a second requestor. The second requestor is heterogeneous relative to the first requestor, and the first set of transaction requests are processed by the first bank of pipes while the second set of transaction requests are processed by the second bank of pipes.

[0241] The first bank of pipes can include a first bank of stall arbiters arranged to temporarily stall and reorder the first set of transaction requests in the first bank of pipes, and the second bank of pipes can include a second bank of stall arbiters arranged to temporarily stall and reorder the second set of transaction requests in the second bank of pipes.

[0242] The first bank of stall arbiters can be arranged to grant priority to non-stall transactions such that, in response to the granted priority, a stall of a first transaction remains at a stall stage of the first bank of pipes and a first non-stall transaction passes to a stage after the stall stage without remaining at the stall stage.

[0243] The first bank of stall arbiters can be arranged to grant priority in response to a value of a reservation credit pool of a type available to process one of the first set of transaction requests, and a reservation credit of the reservation credit pool initially indicates an amount of a reservation station of the first bank of pipes to process the one of the first set of transaction requests.

[0244] The system can further include a counter arranged to change the value of the reservation credit pool in response to a reservation credit granted by the first bank of stall arbiters to one of the first set of transaction requests. The counter can be arranged to restore the value of the reservation credit pool in response to a release of the reservation credit. The reservation credit can indicate availability of a reservation station. The reservation station can be a slot in an exit FIFO of the multi-banked pipeline.

[0245] The cache can be a second level cache, the local memory can be a second level memory, and the set of cache lines is a second level set of cache lines, and the system can further include a central processing unit (CPU) coupled to the second level cache and arranged to execute program instructions to manipulate data, and a first level cache including a local memory including a set of cache lines to store data.

[0246] One of the first set of transaction requests can include a first requester selected from one of a level 1 program cache (L1P), a level 1 data cache (L1D), a multi-core shared memory controller (MSMC), a memory mapping unit (MMU), and a streaming engine (SE), and wherein one of the second set of transaction requests can include a second requester different from the first requester.

[0247] One of the first set of transaction requests can include a first transaction type selected from one of a first level cache fetch, a first level cache load and / or store, a level 3 (L3) direct memory access (DMA) to a second level cache or the first level cache, an L3 snoop, an L3 CacheWarm, a page translation, streaming data from at least two ports, and a cache coherency / maintenance operation, and wherein one of the second set of transaction requests can include a second transaction type different from the first transaction type.

[0248] One of the first set of transaction requests can include a first destination selected from one of a level 2 (L2) static RAM (SRAM), a level 1 data cache (L1D) SRAM, a level 2 (L2) cache, a multi-core shared memory controller (MSMC) SRAM, a level 3 (L3) cache, and a memory addressable by a CPU other than L1, L2, and L3 cache memory, and wherein one of the second set of transaction requests can include a second destination different from the first destination.

[0249] The first level cache and the second level cache can maintain coherency in response to one of the first set of transaction requests including a first transaction type of a cache maintenance operation. The first set of pipelines can further include an electronic correction code (ECC) unit coupled between a first fabric of the first set of pipelines and a second fabric of the first set of pipelines.

[0250] In a second example, an apparatus comprising: a central processing unit (CPU) arranged to execute program instructions to manipulate data; a first level cache coupled to the CPU to temporarily store data in first level cache lines for manipulation by the CPU, wherein the first level cache includes first level local memory addressable by the CPU; and a second level cache coupled to the first level cache to temporarily store data in second level cache lines for manipulation by the CPU, wherein the second level cache includes second level local memory addressable by the CPU, wherein the second level cache includes a plurality of sets of pipelines including a first set of pipelines configured to receive a first set of transaction requests from a first requestor to access the second level local memory, wherein the second level cache includes a plurality of sets of pipelines including a second set of pipelines configured to receive a second set of transaction requests from a second requestor to access the second level local memory, wherein the first set of pipelines includes a first set of stall arbiters arranged to temporarily stall and reorder the first set of transaction requests in the first set of pipelines, and wherein the second set of pipelines includes a second set of stall arbiters arranged to temporarily stall and reorder the second set of transaction requests in the second set of pipelines, wherein the first set of stall arbiters are arranged to grant priority in response to a type of reservation credit available to process one of the first set of transaction requests, and wherein the reservation credit initially indicates an amount of reservation stations to process one of the first set of transaction requests. The apparatus can further include a counter arranged to change the reservation credit of one of the first set of transaction requests in response to a first set of pipeline clock.

[0251] The second requestor can be heterogeneous with respect to the first requestor, and wherein the first set of transaction requests are processed by the first set of pipelines while the second set of transaction requests are processed by the second set of pipelines.

[0252] In a third example, a method includes receiving, at a first set of pipelines of a plurality of sets of pipelines including a second set of pipelines coupled in parallel to a first set of pipelines, a first transaction request from a first requestor to access a local memory including a set of cache lines to store data, and receiving, at the first set of pipelines of the plurality of sets of pipelines, a second transaction request from a second requestor to access the local memory including the set of cache lines to store data, wherein the second requestor is heterogeneous with respect to the first requestor, wherein the first set of transaction requests is a first type of transaction request different from a second type of the second transaction request, and wherein the first and second transaction requests are processed concurrently by the first set of pipelines. The method can further include blocking the first transaction by a first set of blocking arbiters and granting priority to the second transaction by the first set of blocking arbiters, wherein the granting of priority is permitted in response to a comparison of a type of the first requestor to a type of the second requestor. The method can further include blocking the first transaction by the first set of blocking arbiters and granting priority to the second transaction by the first set of blocking arbiters, wherein the granting of priority is permitted in response to a comparison of a type of the first transaction to a type of the second transaction.

[0253] Modifications are possible in the described embodiments, and other embodiments are possible.

Claims

1. A system for memory operations, comprising: The cache contains: Local memory, which includes a set of cache lines for storing data, wherein the set of cache lines is arranged in a set of groups; The first extended local arbitration unit is configured to: Coupled to the first requester; Receive a set of the first group of transaction requests from the first requester; as well as Perform the first arbitration on the set of the first group of transaction requests; The second extended local arbitration unit is configured to: Coupled to a second requester that is different from the first requester; Receive a set of second transaction requests from the second requester; as well as Perform the first arbitration on the set of the second group of transaction requests; and Multiple sets of pipelines coupled to the first extended local arbitration unit, the second extended local arbitration unit, and the set of cache lines of the local memory, wherein the multiple sets of pipelines include: A first set of pipelines is configured to receive a set of first set of transaction requests from the first requester via a first extended local arbitration unit, wherein the first set of pipelines includes a first arbitrator configured to perform a second arbitration on the set of first set of transaction requests; and A second set of pipelines is configured to receive a set of second group transaction requests from the second requester via a second extended local arbitration unit, wherein the second set of pipelines includes a second arbitrator configured to perform a second arbitration on the set of second group transaction requests, and wherein the set of first group transaction requests is processed by the first set of pipelines and the set of second group transaction requests is processed by the second set of pipelines in parallel.

2. The system of claim 1, wherein the first arbitrator is configured to temporarily block and reorder the set of the first set of transaction requests in the first set of pipelines, and wherein the second arbitrator is configured to temporarily block and reorder the set of the second set of transaction requests in the second set of pipelines.

3. The system of claim 2, wherein the first arbitrator is configured to grant priority to non-blocking transactions such that, in response to the granted priority, a blocking first transaction remains at a blocking level of the first set of pipelines and a first non-blocking transaction is transmitted to a level after the blocking level without remaining at the blocking level.

4. The system of claim 2, wherein the first arbitrator is configured to grant priority in response to a value of a reservation credit pool of a type capable of processing one of the set of the first group of transaction requests, wherein the reservation credit in the reservation credit pool initially indicates the amount of reservation station of the first group of pipelines for processing one of the set of the first group of transaction requests.

5. The system of claim 4, further comprising a counter configured to change the value of the reservation credit pool in response to a reservation credit granted by the first arbitrator to one of the sets of the first group of transaction requests.

6. The system of claim 5, wherein the counter is configured to restore the value of the reservation credit pool in response to the release of the reservation credit.

7. The system of claim 6, wherein the booking credit indicates the availability of the booking station.

8. The system of claim 7, wherein the reservation station is a slot in the exit FIFO of the multiple sets of pipelines.

9. The system of claim 1, wherein the cache is a second-level cache, the local memory is a second-level memory, and the set of cache lines is a second-level set of cache lines, wherein the system further comprises: A central processing unit, coupled to the second-level cache and configured to execute program instructions to manipulate data; and The first-level cache includes local memory, which contains a set of cache lines for storing data.

10. The system of claim 9, wherein one of the first set of transaction requests includes a first requester selected from one of: a tier 1 program cache, a tier 1 data cache, a multi-core shared memory controller, a memory mapping unit, and a streaming engine, and wherein one of the second set of transaction requests includes a second requester, the second requester being heterogeneous relative to the first requester.

11. The system of claim 9, wherein one of the first set of transaction requests includes a first transaction type selected from one of the following: first-level cache fetch, first-level cache load and / or store, level 3 direct memory access to the second-level cache or the first-level cache, level 3 snooping, level 3 cachewarming, page translation, streaming data from at least two ports, and cache consistency / maintenance operations, and wherein one of the second set of transaction requests includes a second transaction type different from the first transaction type.

12. The system of claim 9, wherein one of the first set of transaction requests includes a first destination selected from one of: tier 2 static RAM, tier 1 data cache SRAM, tier 2 cache, multi-core shared memory controller SRAM, tier 3 cache, and memory addressable by the central processing unit other than tier 1, tier 2, and tier 3 cache memories, and wherein one of the second set of transaction requests includes a second destination different from the first destination.

13. The system of claim 9, wherein the first-level cache and the second-level cache maintain consistency in response to one of the set of first group of transaction requests of a first transaction type including cache maintenance operations.

14. The system of claim 1, wherein the first set of pipes further comprises an electronic correction code unit coupled between a first structure of the first set of pipes and a second structure of the first set of pipes.

15. A device for memory operations, comprising: Central processing unit, which is arranged to execute program instructions to manipulate data; A first-level cache, coupled to the central processing unit, temporarily stores data in a first-level cache line for manipulation by the central processing unit, wherein the first-level cache includes a first-level local memory addressable by the central processing unit. and A second-level cache, coupled to the first-level cache to temporarily store data in a second-level cache line for manipulation by the central processing unit, wherein the second-level cache includes a second-level local memory addressable by the central processing unit, wherein the second-level cache includes a first set of pipelines, the first set of pipelines including a first set of pipelines configured to receive a first set of transaction requests for access to the second-level local memory from a first requester, wherein the second-level cache includes a second set of pipelines, the second set of pipelines being different from the first set of pipelines and including a set of pipelines configured to receive a first set of transaction requests for access to the second-level local memory from a second requester. A second set of pipelines for a second set of transaction requests to be accessed in the second-level local memory, wherein the first set of pipelines includes a first set of blocking arbitrators arranged to temporarily block and reorder the first set of transaction requests in the first set of pipelines, and wherein the second set of pipelines includes a second set of blocking arbitrators arranged to temporarily block and reorder the second set of transaction requests in the second set of pipelines, wherein the first set of blocking arbitrators is arranged to grant priority in response to a type of reservation credit that can be used to process one of the first set of transaction requests, and wherein the reservation credit initially indicates the amount of reservation station used to process said one of the first set of transaction requests.

16. The device of claim 15, further comprising a counter arranged to change the reservation credit of one of the first set of transaction requests in response to a first set of pipeline clocks.

17. The device of claim 16, wherein the second requester is heterogeneous relative to the first requester, and wherein the first set of transaction requests is processed by the first set of pipelines while the second set of transaction requests is processed by the second set of pipelines.

18. A method for memory operations, comprising: A first local arbitrator receives a set of first transactions, the set of first transactions including a first transaction request from a first requester, the first transaction request accessing a local memory containing a set of cache lines for storing data; The first local arbitrator performs the first arbitration on the set of the first transactions; Subsequently, the set of the first transactions is provided to a first set of pipes in a plurality of pipes, the plurality of pipes including a second set of pipes connected in parallel with the first set of pipes; The second local arbitrator receives a set of second transactions, which includes second transaction requests from the second requester to access the local memory. The second local arbitrator performs a second arbitration on the set of the second transactions; and Subsequently, the set of the second transactions is provided to the first set of pipelines of the multiple sets of pipelines, wherein the local memory includes the set of cache lines for storing data, wherein the second requester is heterogeneous relative to the first requester, wherein the first transaction request is a first type of transaction request that is different from the second type of the second transaction request, and wherein the first and second transaction requests are processed in parallel by the first set of pipelines.

19. The method of claim 18, further comprising blocking the first transaction request via a first set of blocking arbitrators and granting priority to the second transaction request via the first set of blocking arbitrators, wherein the granting of priority is permitted in response to a comparison of the type of the first requester and the type of the second requester.

20. The method of claim 18, further comprising blocking the first transaction request via a first set of blocking arbitrators and granting priority to the second transaction request via the first set of blocking arbitrators, wherein the granting of priority is permitted in response to a comparison of the type of the first transaction request with the type of the second transaction request.

Images