Error Correction Code for Multi-Master Memory Controllers

Abstract

A device (200) includes a central processing unit (CPU) core (202) and a cache subsystem (206) coupled to the CPU core. The cache subsystem includes a memory configured to store a row of data and an error correction code (ECC) syndrome associated with the row of data (224), wherein the ECC syndrome is calculated based on the row of data and the ECC syndrome is a first type of ECC. The cache subsystem also includes a controller (222) configured to respond to a request from a master configured to implement a second type of ECC, the request being directed to the row of data, convert the first type of ECC syndrome of the row of data to a second type of ECC syndrome, and send a response to the master. The response includes the row of data and the second type of ECC syndrome associated with the row of data.

Description

Background Art

[0001] Some memory systems include a multi-level cache system in which hierarchies of memory (e.g., cache) provide different access speeds to cached data. A first level (L1) cache is tightly coupled to a central processing unit (CPU) core and provides relatively fast access to cached data for the CPU core. A second level (L2) cache is also coupled to the CPU core, and in some instances, the second level (L2) cache is larger than the L1 cache and therefore holds more data, although the L2 cache provides relatively slower access to cached data than the L1 cache. Additional memory levels in a hierarchy are possible. Summary of the invention

[0002] In some examples, a device includes a central processing unit (CPU) core and a cache subsystem coupled to the CPU core. The cache subsystem includes a memory configured to store a row of data and an error correction code (ECC) syndrome associated with the row of data, wherein the ECC syndrome is calculated based on the row of data and the ECC syndrome is a first type of ECC. The cache subsystem also includes a controller configured to respond to a request from a master configured to implement a second type of ECC, the request being directed to the row of data, convert the first type of ECC syndrome of the row of data to a second type of ECC syndrome, and send a response to the master. The response includes the row of data and the second type of ECC syndrome associated with the row of data.

[0003] In some examples, a method includes: calculating a single error correction, double error detection (SECDED) error correction code (ECC) syndrome for a row of data; storing the row of data and the SECDED ECC syndrome associated with the row of data in a memory; receiving, by a controller, a request from a master configured to implement single error detection (SED) ECC, the request being directed to the row of data: converting, by the controller, the SECDED ECC syndrome for the row of data to a SED ECC syndrome; and sending, by the controller, a response to the master, the response including the row of data and the SED ECC syndrome associated with the row of data.

[0004] In some examples, a second level (L2) cache subsystem includes a memory configured to store a row of data and an error correction code (ECC) syndrome associated with the row of data. The ECC syndrome is calculated based on the row of data, and the ECC syndrome is a single error correction, double error detection (SECDED) ECC syndrome. The L2 cache subsystem also includes a controller configured to, in response to a request from a master configured to implement single error correction (SED) ECC, the request being directed to the row of data, convert the SECDED ECC syndrome of the row of data to a SEDECC syndrome. The controller is also configured to send a response to the master, the response including the row of data and the SED ECC syndrome associated with the row of data.

[0005] In some examples, an apparatus includes a central processing unit (CPU) core and a cache subsystem coupled to the CPU core. The cache subsystem includes a first memory, a second memory, and a controller coupled to the first and second memories. The controller is configured to perform a series of clean transactions on the first memory and perform a functional transaction on the second memory. One of the clean transactions and the functional transaction are performed simultaneously.

[0006] In some examples, a method includes executing, by a controller, a series of error correction code (ECC) scrubbing transactions on a first memory; and executing, by the controller, a function transaction on a second memory. One of the ECC scrubbing transactions and the function transaction are executed simultaneously.

[0007] In some examples, a device includes a central processing unit (CPU) core and a cache subsystem coupled to the CPU core. The cache subsystem includes a first memory, a second memory, and a controller coupled to the first and second memories. The controller is configured to receive a transaction from a master, the transaction being directed to the first memory and including an address; recalculating an error correction code (ECC) for a row of data in the second memory associated with the address; determining that an uncorrectable error exists in the row of data in the second memory based on a comparison of the recalculated ECC of the row of data with a stored ECC; and in response to determining that an uncorrectable error exists in the row of data in the second memory, terminating the transaction without accessing the first memory.

[0008] In some examples, a method includes receiving, by a controller coupled to a first memory and a second memory, a transaction from a master. The transaction is directed to the first memory and includes an address. The method further includes: recalculating, by the controller, an error correction code (ECC) for a row of data in the second memory associated with the address; determining, by the controller, that an uncorrectable error exists in the row of data in the second memory based on a comparison of the recalculated ECC of the row of data with a stored ECC; and terminating the transaction without accessing the first memory in response to determining that an uncorrectable error exists in the row of data in the second memory. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] For a detailed description of various examples, reference will now be made to the accompanying drawings, in which:

[0010] Figure 1 A block diagram showing a multi-level cache system in some examples;

[0011] Figure 2 Another block diagram showing a multi-level cache system in some examples;

[0012] Figure 3 Another block diagram showing a multi-level cache system including a level 1 (L1) primary cache and a victim cache in some examples;

[0013] Figure 4 A flow chart showing a method for managing error correction codes (ECC) across various masters in some examples;

[0014] Figure 5 A block diagram showing a level 2 (L2) controller interfacing with grouped memory in some examples;

[0015] Figure 6 shows example configuration registers used in ECC cleanup transactions in some examples;

[0016] Figure 7 Example timeline showing ECC cleanup transactions in some instances;

[0017] Figure 8 A flow chart showing a method for performing an ECC cleanup transaction on a packet memory in some examples;

[0018] Fig. 9 shows an example L2 pipeline with premature transaction termination in the case of uncorrectable errors in some examples; and

[0019] Fig.10A flow chart showing a method of premature transaction termination in the event of an uncorrectable error in some examples. DETAILED DESCRIPTION

[0020] Figure 1 A block diagram of a system 100 is shown in some examples. The example system 100 includes multiple CPU cores 102a to 102n. Each CPU core 102a to 102n is coupled to a private L1 cache 104a to 104n and a private L2 cache 106a to 106n. The L2 cache 106a to 106n is in turn coupled to a shared third level (L3) cache 108 and a shared main memory 110 (e.g., a double data rate (DDR) random access memory (RAM)). In other examples, a single CPU core 102 is coupled to the L1 cache 104, the L2 cache 106, the L3 cache 108, and the main memory 110.

[0021] In some examples, the CPU cores 102a to 102n include register files, integer arithmetic logic units, integer multipliers, and program flow control units. In one example, the L1 cache 104a to 104n associated with each CPU core 102a to 102n includes a separate first-level program cache (L1P) and a first-level data cache (L1D). The L2 cache 106a to 106n is a combined instruction / data cache that stores both instructions and data. In some examples, the CPU core 102a and its associated L1 cache 104a and L2 cache 106a are formed on a single integrated circuit.

[0022] The CPU cores 102a to 102n operate under program control to perform data processing operations on data. Instructions are fetched before being decoded and executed. Figure 1 In the example of , the L1P of the L1 cache 104a to 104n stores instructions used by the CPU cores 102a to 102n. The CPU core 102 first attempts to access any instructions from the L1P of the L1 cache 104. The L1D of the L1 cache 104 stores data used by the CPU core 102. The CPU core 102 first attempts to access any required data from the L1 cache 104. The two L1 caches 104 (L1P and L1D) are supported by the L2 cache 106 as a unified cache. In the case of a cache miss in the L1 cache 104, the requested instruction or data 106 is sought from the L2 cache. If the requested instruction or data is stored in the L2 cache 106, it is provided to the requesting L1 cache 104 to provide to the CPU core 102. The requested instruction or data is provided to both the requesting cache and the CPU core 102 at the same time to speed up use.

[0023] The unified L2 cache 106 is further coupled to a level 3 (L3) cache 108. Figure 1 In the example of , the third level (L3) cache 108 is shared by the L2 caches 106a-106n. The L3 cache 108 is in turn coupled to the main memory 110. As will be described below, the memory controller facilitates communication between each of the CPU core 102, the L1 cache 104, the L2 cache 106, the L3 cache 108, and the main memory 110. The memory controller(s) handle memory-centric functions such as cacheability determination, cache coherency enforcement, error detection and correction, address translation, etc. In Figure 1 In some examples, the CPU cores 102 are part of a multiprocessor system, and thus the memory controller also handles data transfers between the CPU cores 102 and maintains cache coherence between the CPU cores 102. In other examples, the system 100 includes only a single CPU core 102 along with its associated L1 cache 104 and L2 cache 106.

[0024] Figure 2 A block diagram of a system 200 in the examples described herein is shown. Certain elements of the system 200 are similar to those described above with respect to Figure 1 2, but are shown in greater detail. For example, CPU core 202 is similar to CPU core 102 described above. L1 cache 104 subsystem described above is depicted as L1D 204 and L1P 205. L2 cache 106 described above is shown here as L2 cache subsystem 206. L3 cache 208 is similar to L3 cache 108 described above. System 200 also includes a stream engine 210 coupled to L2 cache subsystem 206. System 200 also includes a memory management unit (MMU) 207 coupled to L2 cache subsystem 206.

[0025] The L2 cache subsystem 206 includes an L2 tag ram 212, an L2 coherent (e.g., MESI) data memory 214, a shadow L1 tag ram 216, and an L1 coherent (e.g., MESI) data memory 218. Each of the blocks 212, 214, 216, 218 is alternatively referred to as a memory or RAM. The L2 cache subsystem 206 also includes a tag ram error correction code (ECC) data memory 220. In an example, the ECC data memory 220 maintains ECC data for each of the memories 212, 214, 216, 218.

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

[0027] exist Figure 2 In the example of , L2 SRAM is depicted as four memory banks 224a to 224d. However, in other examples, L2 SRAM includes more or fewer memory banks, including being implemented as a single memory bank. L2 SRAM 224 is used as L2 cache and is alternatively referred to herein as L2 cache 224.

[0028] L2 tag ram 212 contains a list of physical addresses whose contents (e.g., data or program instructions) have been cached to L2 cache 224. In an example, an address translator translates a virtual address into a physical address. In one example, an address translator generates a physical address directly from a virtual address. For example, the lower n bits of the virtual address are used as the least significant n bits of the physical address, wherein the most significant bit of the physical address (higher than the lower n bits) is generated based on a set of tables configured in the main memory. In this example, L2 cache 224 can use a physical address for addressing. In some examples, a hit / miss indicator from a tag ram 212 search is stored.

[0029] L2 MESI memory 214 maintains coherent data to implement full MESI coherency with L2 SRAM 224, external shared memory, and data cached into L2 cache from elsewhere in system 200. The functionality of system 200 coherency is described below.

[0030] The L2 cache subsystem 206 also shadows the L1D tags in the L1D shadow tag ram 216 and the L1D MESI memory 218. The tag ram ECC data 220 provides error detection and correction for the tag memory and also for one or both of the L2 MESI memory 214 and the L1D MESI memory 218. The L2 cache controller 222 generally controls the operation of the L2 cache subsystem 206, including handling coherency operations within the L2 cache subsystem 206 and between other components of the system 200.

[0031] Figure 3 A block diagram of a system 300 is shown that demonstrates various features of cache coherence implemented in examples of the present description. The system 300 contains the same features as described above with respect to Figure 1 and 2 For example, CPU core 302 is similar to CPU cores 102 , 202 . Figure 3 Also included is an L1 cache subsystem 304, an L2 cache subsystem 306, and an L3 cache subsystem 308. The L1 cache subsystem 304 includes an L1 controller 310 coupled to an L1 SRAM 312. The L1 controller 310 is also coupled to an L1 primary cache 314 and an L1 victim cache 316, which will be described below. In some examples, the L1 primary cache 314 and the L1 victim cache 316 implement the functionality of the L1D 204 and / or the L1P 205.

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

[0033] Cache coherence is a technique that allows data and program caches and different requestors (including requestors without cache) to determine the most recent data value for a given address in memory. Cache coherence enables this coherent data value to be accurately reflected to observers present in the system 300 (e.g., a cache or requestor that issues a command to read a given memory location). Certain instances of the present description refer to example MESI coherence schemes in which cache lines are set to one of four cache coherence states: modified, exclusive, shared, or invalid. Other instances of the present description refer to subsets of the MESI coherence scheme, while still other instances include more coherence states than the MESI coherence scheme. Regardless of the coherence scheme, the cache coherence state for a given cache line is stored in, for example, the L2MESI memory 214 described above.

[0034] A cache line having a modified cache coherence state indicates that the value in the cache line is modified relative to the main memory (e.g., DDR 110), and the value in the cache line is exclusively held in the current cache (e.g., L2 cache 324). The modified cache coherence state also indicates that the value in the cache line is not explicitly present or is invalid in any other cache (e.g., L1 or L3 cache).

[0035] A cache line having an exclusive cache coherence state indicates that the value in the cache line has not been modified relative to the main memory (e.g., DDR 110), but the value in the cache line is exclusively held in the current cache (e.g., L2 cache 324). An exclusive cache coherence state also indicates that the value in the cache line is not explicitly present or valid in any other cache (e.g., L1 or L3 cache).

[0036] A cache line having a shared cache coherency state indicates that the value in the cache line is unmodified relative to main memory (e.g., DDR 110). A shared cache state also indicates that the value in the cache line may exist in multiple caches (e.g., caches other than L2 cache 324).

[0037] A cache line having an invalid cache coherency state indicates that any values ​​in the cache line are to be considered not present in the cache (eg, L2 cache 324).

[0038] The examples described herein utilize hardware techniques, control logic, and / or state information to implement a consistency system. Each observer may issue a read request to a memory location marked as shareable—and some observers may be able to issue a write request. Specifically, the cache may also issue a snoop request to it, requesting to read, return, or even update its cache state, depending on the type of snoop operation. In the example multi-level cache hierarchy described above, the L2 cache subsystem 306 is configured to send and receive snoop operations. The L1 cache subsystem 304 receives snoop operations, but does not send snoop operations. The L3 cache subsystem 308 sends snoop operations, but does not receive snoop operations. In the examples described herein, the L2 cache controller 320 maintains state information (e.g., in the form of hardware buffers, memory, and logic) to also track the state of the consistency cache lines present in both the L1 primary cache 314 and the L1 victim cache 316. Tracking the state of the consistency cache lines enables the implementation of a consistency hardware cache system.

[0039] Examples of this description refer to various types of coherency transactions, including read transactions, write transactions, snoop transactions, victim transactions, and cache maintenance operations (CMOs). These transactions are sometimes referred to as read, write, snoop, victim, and CMO, respectively.

[0040] A read returns the current value of a given address, whether the value is stored at an endpoint (e.g., DDR 110) or in a cache in the consistency system 300. A write updates the current value of a given address and invalidates other copies of the given address stored in caches in the consistency system 300. A snoop reads or invalidates a copy of data stored in a cache (or both reads and invalidates the data). A snoop starts from a numerically higher level of the hierarchy to a cache at the next numerically lower level of the hierarchy (e.g., from L2 controller 320 to L1 controller 310), and can propagate further to even lower levels of the hierarchy as needed. A victim starts from a numerically lower level cache in the hierarchy to the next numerically higher level in the cache hierarchy (e.g., from L1 controller 310 to L2 controller 320) or from a primary cache at a given level to a victim cache at the same level. A victim transfers the modified data to the next level of the hierarchy and / or to a victim cache. In some cases, the victim is propagated further to numerically higher levels of the cache hierarchy (e.g., if L2 controller 310 sends the victim to L2 controller 320 for an address in DDR 110, and the line does not exist in L2 cache 324, then L2 controller 320 forwards the victim to L3 controller 309). Finally, CM0 causes an action to be performed in one cache for a given address.

[0041] Still reference Figure 3 In one example, the L1 primary cache 314 is a direct-mapped cache that services read and write hits and snoops. The L1 primary cache 314 also keeps track of cache coherence state information (e.g., MESI state) for its cache lines. In an example, the L1 primary cache 314 is a read-allocate cache. Therefore, writes that miss the L1 primary cache 314 are sent to the L2 cache subsystem 306 without allocating space in the L1 primary cache 314. In the example of a direct-mapped L1 primary cache 314, when a new allocation occurs in the L1 primary cache 314, the current line in the group is moved to the L1 victim cache 316, regardless of whether the line is clean (e.g., unmodified) or dirty (e.g., modified).

[0042] In an example, the L1 victim cache 316 is a fully associative cache that holds cache lines that are removed from the L1 primary cache 314, for example, due to replacement. The L1 victim cache 316 holds both clean and dirty lines. The L1 victim cache 316 services read and write hits and snoops. The L1 victim cache 316 also keeps track of cache coherence state information (e.g., MESI state) for its cache lines. When a cache line in a modified state is replaced from the L1 victim cache 316, the cache line is sent to the L2 cache subsystem 306 as a victim.

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

[0044] Still reference Figure 3 In some examples, the L2 controller 320 described herein combines both local coherence (e.g., handling requests that are endpointed to its local L2 SRAM 322) and external coherence (e.g., handling requests that are endpointed to external memory such as L3 SRAM (not shown for simplicity) or DDR 110). An endpoint refers to a memory target such as L2 SRAM 322 or DDR 110 that resides at a specific location on the chip, is directly acted upon by a single controller and / or interface, and can be cached at various levels of the coherent cache hierarchy, such as Figure 3A master (eg, a hardware component, circuit, or the like) is a requesting program that issues read and write accesses to an endpoint. In some instances, the master stores the results of these read and write accesses in a cache, but the master does not necessarily store such results in a cache.

[0045] Soft errors occurring in memory are one reason for failure of various applications. These soft errors occur due to random radiation flipping bits in the memory. In some instances, one or more parity bits are stored with the data to detect such errors.

[0046] Error correction codes (ECC) are used as a measure to protect memory from transient and permanent faults that occur during functional operation. The ability to protect against such faults and to continue operating in the presence of such faults is referred to as "safety" or "functional safety". In the examples described herein, various components of the above system implement different levels of ECC protection, including zero protection, single error detection (SED) and single error correction, double error detection (SECDED).

[0047] In the examples described herein, functionality associated with various ECC processes, determinations, methods, etc., is generally attributed to L2 controller 222 (and / or Figure 3 However, it should be understood that in some examples, the L2 controller 222 is combined with the L2 controller 320. Figure 2 Other blocks in the ECC memory (e.g., ECC check block 226 and ECC data memory 220) perform such functions, which in at least some cases include Figures 1 to 3 The ECC syndromes of the various memories described as part of the L2 cache subsystem.

[0048] In the above Figures 1 to 3 The various different memories present in the systems described in have different functional safety requirements, and the various masters present in those systems are configured to provide different levels of ECC protection. This described example addresses the complexity of maintaining sufficient functional safety throughout the system to meet, for example, the failure-in-time (FIT) rate specified by product requirements.

[0049] In particular, the L2 controller 222 provides several safety solutions, including maintaining ECC for its grouped SRAM memories 224a-224d, maintaining the required ECC for data-carrying transactions across interfaces to other entities outside the L2 cache subsystem 206, and translating ECC across heterogeneous interfaces to entities outside the L2 cache subsystem 206. The L2 controller 222 is also configured to implement various cleanup transactions to maintain and update ECC-protected memories (e.g., to correct soft errors that occur in those memories).

[0050] The L2 controller 222 receives multiple transaction types from various masters, including L1D 204, L1P 205, SE 210, MMU 207, and L3 208. In addition, in an example, L2 SRAM 224, which is used as both a directly addressable memory and a data backup for the L2 cache, is parity protected with a SECDED ECC syndrome for each 32 bytes of data. There are multiple transaction types that contain both data and SECDED ECC syndromes. For example, write transactions, read responses, and snoop responses all contain data and SECDED ECC syndromes, and these transactions may result in updating the L2 SRAM 224.

[0051] In some cases, partial updates to the L2 SRAM 224 use a "read-modify-write" operation to maintain the integrity of the SECDED ECC syndrome, such as by correcting a single soft error in the stored data and generating an updated SECDED ECC syndrome based on the corrected data. In other cases, an entire row write or entire row response is optimized, where a read-modify-write operation is unnecessary and one or more complete 32-byte data values ​​can be directly updated using the accompanying SECDED ECC syndrome. In other cases, parity protection information is converted to convert the ECC syndrome from SECDED to SED before returning a read response to the initiating master. In the following example, the L2 controller 222 maintains SECDED parity protection on its L2 SRAM 224 while also managing individual master requirements for parity protection, particularly for masters utilizing SED parity protection.

[0052] As further described below, the L2 controller 222, which manages the different ECC requirements of different masters, enables multiple different masters to access a common set of L2 SRAM 224 (e.g., which is itself protected using a SECDED ECC scheme) managed by the L2 controller 224. Thus, a different topology of masters interfaces to the same shared L2 SRAM 224 while benefiting from the relatively stronger SECDED protection in the L2 SRAM 224, while enabling each master to manage its own memory at different security levels where permitted or desired.

[0053] In some examples, the L2 controller 222 is configured to maintain SECDED parity for the memories 212, 214, 216, 218 (e.g., via the ECC block 220) in addition to the SECDED parity for the L2 SRAM 224. In various examples, it is assumed that at least some of the masters to which the L2 cache subsystem 206 is coupled employ SED parity protection instead of the SECDED protection employed by the L2 cache subsystem 206. In one example, the L1P 205, the SE 210, and the MMU 207 employ SED protection instead of SECDED protection. The L2 controller 222 is configured to convert the SECDED ECC syndromes to SED ECC syndromes when returning read response data to these masters.

[0054] Figure 4 A flow diagram of a method 400 is shown in some examples. The method 400 involves the L2 controller 222 managing and translating ECC across heterogeneous interfaces to entities outside of the L2 cache subsystem 206.

[0055] The method 400 begins in block 402 where the L2 controller 222 calculates a SECDED ECC syndrome for a row of data. The method 400 continues in block 404 where the L2 controller 222 stores the row of data and the SECDED ECC syndrome associated with the row of data in a memory, such as the L2 SRAM 224.

[0056] The method 400 proceeds to block 406 where the L2 controller 222 receives a request from a master configured to implement SED ECC (e.g., one of the L1P 205, SE 210, and MMU 207 described above). In this example, the request is directed to a line of data stored in the L2 SRAM 224 by the L2 controller 222 using the SECDED ECC syndrome.

[0057] Before the L2 controller 222 responds to the request, the method 400 continues to block 408, where the L2 controller 222 converts the SECDED ECC syndrome of the data row to a SED ECC syndrome. Next, the method 400 proceeds to block 410, where the L2 controller 222 sends a response to the master including the data row and the SED ECC syndrome associated with the data row (e.g., the SED ECC syndrome to which the initial SECDED ECC syndrome was converted).

[0058] In an example, when the SECDED ECC syndrome of the data row is converted to SED ECC, the L2 controller 222 is configured in a step to recalculate the SECDED ECC syndrome of the data row (e.g., based on the current data in the L2 SRAM 224). In this example, the L2 controller 222 then determines that there is a single error in the data row based on a comparison of the recalculated SECDED ECC syndrome and the SECDED ECC syndrome associated with the data row (e.g., stored in the ECC block 220). Due to the detection of a single error that is correctable when protected with the SECDED ECC syndrome, the L2 controller 222 is configured to overwrite the data row in the memory with a corrected data row in which the single error is corrected. Finally, the L2 controller 222 is configured to calculate the SED ECC syndrome based on the corrected data row, and then send a response to the master. In an example, the response to the master including the associated SED ECC syndrome is transmitted in a single bus transaction. Thus, the L2 controller 222 is configured to not only manage ECC across heterogeneous interfaces, but also to correct errors as part of a transaction.

[0059] In another example, the L2 controller 222 determines that there are more than one error in the row of data based on a comparison of the recalculated SECDED ECC syndrome and the SECDED ECC syndrome associated with the row of data (e.g., stored in the ECC block 220). Due to the detection of a double error (or larger error) that is detectable but uncorrectable when protected by the SECDED ECC syndrome, the L2 controller 222 is configured to generate an interrupt to the requesting master to signal the error in the requested data. In some cases, the L2 controller 222 does not have visibility into how a particular master will handle the error interrupt, but the requesting master is therefore able to determine (e.g., based on the safety criticality of the transaction) how to handle the error interrupt.

[0060] As described above, in some examples, the L2 controller 222 is configured to communicate with a grouped memory structure (eg, Figure 2 The four memory banks of the L2 SRAM 224 shown in FIG. Figure 5 Another view of this structure 500 is shown, which includes common L2 control logic 502 coupled to four grouped L2 SRAM blocks 506a-506d through four parallel pipelines 504a-504d. Figure 5In the example of , the access to L2 SRAM 506 includes 256b of data + 10b of ECC syndrome, such as SECDED syndrome. For the purposes of the following examples, L2 control logic 502 and L2 controller 222 are functionally similar, just as grouped L2 SRAM 506 and L2 SRAM 224 are functionally similar. This described example utilizes parallel pipeline 504 access to grouped L2 SRAM 506 to improve the efficiency of performing ECC scrubbing operations on L2 SRAM 506. ECC scrubbing operations are further described below, but generally refer to periodic correction and / or detection of soft errors in L2 SRAM 506. Particularly for safety-critical applications, this periodic error correction and / or detection increases the functionality of the overall system in such applications.

[0061] As described, the L2 controller 502 utilizes the grouped nature of the L2 SRAM 506 and parallel pipelines 504 to independently perform ECC scrubbing operations on each pipeline, which reduces the performance loss of the entire system (e.g., from interrupt transactions) by performing scrubbing operations on individual pipelines. This also reduces performance dependencies on other pipelines. For example, any pipeline that is not currently participating in an ECC scrubbing operation can operate on a functional transaction, which reduces the impact of scrubber operations on other critical mission-mode applications.

[0062] Figure 6 Registers 600 in certain examples are shown. In these examples, the scrubber logic operating on each pipeline is configured by two control registers 600, L2EDCFG (e.g., scrubber control register) and L2EDTST (e.g., test control register). In some examples, these control registers 600 are written by configuration code prior to program execution and remain valid until a subsequent update to the control registers occurs.

[0063] The cleaner control register generally controls the frequency of the cleaning operation. In this example, the SCEN (e.g., enable) field of the cleaner control register is an enable bit. When SCEN is asserted, the cleaning operation occurs according to the values ​​of SCDELAY and BTDELAY, which will be further described below. When SCEN is deasserted, the cleaning operation does not occur.

[0064] The BTDELAY (eg, burst delay) field controls the delay between consecutive cleanup bursts. In some instances, the integer value captured in the burst delay field represents a single clock cycle of delay. Cleanup bursts are described below.

[0065] The SCDELAY (e.g., Cycle Delay) field controls the delay between the end of one cleanup cycle and the start of the next cleanup cycle. In one example, in functional mode, the integer value captured in the Cycle Delay field represents 1024 delay clock cycles (but other scaling multipliers are within the scope of the description herein). In another example, in test mode (described further below), the integer value captured in the Cycle Delay field represents a single delay clock cycle. The cleanup cycles are described below.

[0066] The test control register controls the test mode of the scrubber logic and enables programmatic, selective scrubbing of specific regions or addresses of the L2SRAM 506. The SCTST (e.g., test enable) field of the test control register controls the test mode of the scrubbing process. Although the SCEN field described above keeps the scrubbing process generally enabled, if SCEN is asserted, then SCTST being asserted will cause the scrubber logic to enter test mode.

[0067] The SCADDR (eg, test address) field specifies the starting address in L2 SRAM 506 for the next test mode scrubbing cycle.

[0068] The SCCOUNT (eg, test count) field controls the number of scrubbing accesses that will occur during the next scrubbing cycle.

[0069] See above for clean access, clean burst, and clean cycle. Further references Figure 7 To describe these concepts, Figure 7 An example timeline 700 showing ECC scrubbing operations in some examples.

[0070] A cleanup access is the smallest granularity of cleanup that occurs and consists of a read-modify-write of a single address in the L2 SRAM 506. In an example, if there is a single-bit error (e.g., detectable and correctable by a SECDED ECC syndrome stored at a location in the L2 SRAM 506), then the cleanup access only modifies the data at the given address. If the cleanup access does not detect an error, then no operation needs to be performed. However, if a two-bit error is detected in the L2 SRAM 506 (e.g., detectable by a SECDED ECC syndrome stored at a location in the L2 SRAM 506 but not correctable by it), then an interrupt representing the error is generated and the write operation is not performed. As above, although the L2 controller 222 does not have visibility into how a particular master will handle an error interrupt, the L2 controller 222 provides knowledge of the error to the master, and the master can determine (e.g., based on the safety criticality of the transaction) how to handle the error interrupt.

[0071] A cleanup burst is a series of consecutive cleanup accesses that occur consecutively (e.g., without pauses or delays between cleanup accesses). The delay between cleanup bursts (e.g., the time between the last cleanup access of a cleanup burst and the first cleanup access of a subsequent cleanup burst) is software programmable and controlled by the burst delay (e.g., BTDELAY) cleanup controller control register field described above. In some examples, the number of cleanup accesses per cleanup burst is fixed (e.g., in Figure 7 In one example, 4 cleanup accesses per cleanup burst), while in other examples, the number of cleanup accesses per cleanup burst is fixed to a different value, or is configurable (e.g., with an additional control register field).

[0072] Finally, a scrubbing cycle is the most granular scrubbing that occurs and consists of multiple scrubbing bursts that occur regularly, where the delay between bursts can be programmed using the burst delay (e.g., BTDELAY) scrubber control register field described above. In one example, a complete scrubbing cycle results in the entire contents of the bank of L2 SRAM 506 being scrubbed. The delay between the end of a complete scrubbing cycle and the start of the next scrubbing cycle (e.g., the time between the last scrubbing access of the last scrubbing burst of a scrubbing cycle and the first scrubbing access of the first scrubbing burst of the subsequent scrubbing cycle) is software programmable and controlled by the cycle delay (e.g., SCDELAY) scrubber control register field described above.

[0073] In one example, the L2 SRAM 506 cleaner is implemented with several finite state machines (e.g., implemented in the L2 controller 222 or the pipeline 504 itself). These state machines interact with each other during the functional mode and the test mode. In an example, the cleaner logic is replicated across all four pipelines 504, thereby resulting in a parallel cleaner implementation scheme that allows each pipeline 504 to operate independently of the other pipelines 504. Therefore, when one pipeline 504 requests and starts a cleaning cycle, the other pipelines 504 are still processing functional transactions. In one example, the cleaner control register and the test control register control the pipelines 504 in a global manner. When being globally controlled, it is impossible for one pipeline 504 to be in a test mode and another pipeline 504 to be in a functional mode. Similarly, when being globally controlled, cleaning in the functional mode is enabled or disabled for all pipelines 504.

[0074] In response to the enable field of the clean control register (e.g., SCEN) being asserted and the test enable field of the test control register (e.g., SCTST) being deasserted, the cleanser state machine (e.g., implemented in pipeline 504) operates in functional mode. In one example, a countdown timer is thus started and counts down until a threshold is reached (e.g., after SCDELAY*1,024 clock cycles have elapsed).

[0075] Once the countdown is complete (e.g., the countdown timer reaches a threshold), the cleaner state machine requests a cleanup burst. Before the cleanup burst can begin, the associated L2 pipeline 504 must refresh all existing functional transactions. Therefore, the cleaner state machine also asserts a pause request signal to the L2 controller 502, which prevents new transactions from winning arbitration and entering the pipeline 504. Once the issued transaction is completed, the pipeline is considered a refresh transaction, and a confirmation signal is issued to the cleaner state machine by the L2 controller 502. In response to the refresh confirmation signal being asserted, the cleaner state machine starts the first cleanup burst (e.g., a series of cleanup transactions). In an example, the cleaner state machine presents the address and the cleanup access request to the control logic of the L2 SRAM 506, which causes a given address to undergo a cleanup access to detect and correct any one-bit error at the location, as described above.

[0076] In some examples, when the various pipelines 504 begin operating with the same functional delay, and therefore begin their first scrubbing cycles at approximately the same time, the scrubbing operations of the pipelines are decoupled over time. For example, the pipeline 504 stall mechanism described above will take a different number of cycles for the various pipelines 504. Furthermore, scrubbing operations are performed more or less quickly on various banks of the L2 SRAM 506, further increasing the variability in the time at which each pipeline 504 processes a scrubbing transaction or a functional transaction.

[0077] In response to the enable field (e.g., SCEN) of the cleanup control register being asserted, when the test enable field (e.g., SCTST) of the test control register is also asserted, the cleaner state machine (e.g., implemented in pipeline 504) operates in test mode. The operation of the cleaner state machine in test mode is similar to that in functional mode, as described above, but with the following differences. In one example, although the countdown timer is still utilized, the loop delay field is not scaled (e.g., not multiplied by 1024 as in the above example), which results in a faster cleanup burst due to less time between cleanup cycles. In addition, unlike starting the cleanup cycle at the beginning (e.g., address 0) of the L2 SRAM 506, the start address of the cleanup cycle is given by the test address (e.g., SCADDR) field of the test control register in test mode. In addition, instead of cleaning the entire memory bank of the L2 SRAM 506, the total number of cleanup accesses is given by the test count (e.g., SCCOUNT) field of the test control register. The test mode improves debugging and testing of various aspects of the L2 SRAM 506 scrubbing operations described herein.

[0078] Figure 8 A flow chart of a method 800 for performing ECC cleanup transactions on a grouped memory in some examples is shown. The method 800 begins at block 802, where the L2 controller 502 performs a series of ECC cleanup transactions on a first memory (e.g., L2 SRAM 506a). As described above, in some examples, the L2 controller 502 operates in conjunction with a state machine in a pipeline 504 to perform ECC cleanup transactions on the L2 SRAM 506. The method 800 also includes, in block 804, the L2 controller 502 performing a functional transaction (e.g., not an ECC cleanup transaction) on a second memory (e.g., L2 SRAM 506b) while performing an ECC cleanup transaction on the first memory. Therefore, since any pipeline 504 that is not currently participating in an ECC cleanup operation is able to operate on a functional transaction, the overall performance dependency on the ECC cleanup operation is reduced. This reduces the impact of the scrubber operation on other critical mission mode applications of the system.

[0079] As described above, different system components implement different levels of protection, ranging from zero protection to SED protection to SECDED protection. Regardless of the protection employed, when a particular transaction encounters an uncorrectable error, an interrupt is generated for a system-level response to the error (e.g., by a controlling master). Generating an interrupt is preferred because, at least in some cases, the initiating master will not receive notification of the uncorrectable error in the form of a response status. In the example described herein, the L2 controller 222 continues to process a functional (e.g., task mode) transaction even after detecting an uncorrectable error associated with the transaction because the L2 controller 222 does not necessarily have enough system-level information to know whether the detected uncorrectable error is a critical error or a non-critical error.

[0080] This described example improves the performance of the L2 controller 222 in the presence of uncorrectable errors. In particular, processing transactions that encounter uncorrectable errors is simplified while reducing power consumption and latency when processing these transactions.

[0081] As described below, the L2 controller 222 is configured to terminate the processing of a transaction early in response to detecting an uncorrectable error. Early termination of a transaction for which an associated uncorrectable error has been detected also enables the L2 controller 222 to provide an earlier response (e.g., an error interrupt) to the initiating master, thereby further reducing latency. Early termination of a transaction for which an associated uncorrectable error has been detected also enables the L2 controller 222 to avoid memory accesses (e.g., accesses to the L2 SRAM 224 that would otherwise be caused by the transaction), which reduces power consumption.

[0082] Steering Fig. 9 , a block diagram of an L2 pipeline 900 in some examples is shown. As shown, the L2 pipeline 900 is a multi-stage pipeline where memory access occurs in stage P0 (902), ECC detection and correction occurs in stage P1 (904), various cache logic occurs in stage P2 (906), and L2 SRAM 224 access occurs in stage P3 (908).

[0083] In particular, the L2 controller 222 is configured to receive transactions from the master. The transaction is directed to, for example, the L2 SRAM 224 and includes an address. In the example, in stage P0 (902), the L2 controller 222 accesses one or more of the L2 tag memory 212, the L2 coherence memory 214, and the L1 shadow tag memory 216 based on the address of the transaction. As described above, the L2 controller 222 is configured to maintain SECDED parity for the memories 212, 214, 216, 218 (e.g., through the ECC block 220) in addition to maintaining SECDED parity for the L2 SRAM 224.

[0084] Thus, in stage P1 (904), the L2 controller 222 is configured to recalculate an error correction code (ECC) for a row of data (e.g., tag data in L2 tag memory 212, coherency data in L2 coherency memory 214, or shadow tag data in L1 shadow tag memory 216) associated with an address of the transaction. The L2 controller 22 is configured to determine that an uncorrectable error exists in one (or more) of the tag data, coherency data, or shadow tag data based on a comparison of the recalculated ECC for the row of data with a stored ECC (e.g., in ECC block 220). In response to determining that an uncorrectable error exists in one (or more) of the tag data, coherency data, or shadow tag data, the L2 controller 222 is configured to terminate the transaction early without accessing the first memory, as shown in block 907.

[0085] In addition, when the L2 controller 222 detects an uncorrectable error as described above, the logic in stage P2 (906) releases the address lock, which enables the L2 controller 222 to continue processing transactions after the transaction in which the uncorrectable error was detected. In addition, when the L2 controller 222 detects an uncorrectable error as described above, the logic in stage P2 (906) blocks access to the L2 SRAM 224 in stage P3 (908), which reduces power consumption.

[0086] Fig.10 A flow chart of a method 1000 for premature transaction termination in the event of an uncorrectable error in some examples is shown. The method 1000 begins at block 1002, where the L2 controller 222 receives a transaction from a master. The transaction is directed to a first memory (e.g., L2 SRAM 224) and includes an address. The method 1000 continues at block 1004, where the L2 controller 222 recalculates an ECC for a row of data in a second memory (e.g., tag data in L2 tag memory 212, coherency data in L2 coherency memory 214, or shadow tag data in L1 shadow tag memory 216) associated with the transaction address.

[0087] The method 1000 then continues in block 1006, where the L2 controller 222 determines that an uncorrectable error exists in the row of data in the second memory based on a comparison of the recalculated ECC for the row of data with the stored ECC (e.g., in the ECC block 220). In response to determining that an uncorrectable error exists in the row of data in the second memory, the method 1000 continues in block 1008, where the L2 controller 222 terminates the transaction early without accessing the first memory (e.g., the L2 SRAM 224). As described above, in addition to terminating the transaction early, the method may also include the L2 controller generating a response (e.g., an interrupt) to the master indicating the presence of the uncorrectable error.

[0088] In the preceding description and claims, the terms "including" and "comprising" are used in an open-ended fashion, and thus mean "including, but not limited to,." Furthermore, the term "couple" or "couples" means an indirect or direct connection. Thus, if a first device is coupled to a second device, the connection may be through a direct connection or an indirect connection via other devices and connections. Similarly, a device coupled between a first component or location and a second component or location may be through a direct connection or through an indirect connection via other devices and connections. An element or feature "configured to" perform a task or function may be configured (e.g., programmed and / or structurally designed) by a manufacturer at the time of manufacture to perform the function and / or may be configurable (or reconfigurable) by a user after manufacture to perform the function and / or other additional or alternative functions. Configuration may be by firmware and / or software programming of the device, by the construction and / or layout of the hardware components and interconnections of the device, or a combination thereof. Likewise, the use of the phrase "ground" or the like in the foregoing description includes base ground, ground, floating ground, virtual ground, digital ground, common ground, and / or any other form of ground connection that may be applicable or suitable for the teachings of this description. Unless otherwise stated, a value preceded by "about," "approximately," or "substantially" means + / - 10 percent of the value.

[0089] The above description illustrates the principles and various embodiments of this description. Once the above description is fully understood, numerous changes and modifications will become apparent to those skilled in the art. The appended claims include all such changes and modifications.

Claims

1. A device comprising: Central Processing Unit (CPU) core; and A cache subsystem coupled to the CPU core, the cache subsystem comprising: a memory configured to store a row of data and a first error correction code (ECC) syndrome associated with the row of data, wherein the first ECC syndrome is calculated based on the row of data, wherein the first ECC syndrome is a first type ECC; and a controller coupled to the memory and configured to respond to a request from a master configured to implement a second type of ECC different from the first type of ECC, the request being directed to the row of data: converting the first ECC syndrome of the data row into a second ECC syndrome of the second type ECC; and A response is sent to the master, the response including the data row and the second ECC syndrome associated with the data row.

2. The apparatus of claim 1 , wherein when the controller converts the first ECC syndrome of the data row to the second ECC, the controller is further configured to: Determining a third ECC syndrome of the data row; determining whether an error exists in the row of data based on a comparison of the third ECC syndrome associated with the row of data and the first ECC syndrome; and When the error is determined to exist: determining a corrected data row in which the error is corrected; overwriting the row of data in the memory with the corrected row of data; and The second ECC syndrome is calculated based on the corrected data row.

3. The apparatus of claim 1, wherein the response including the second ECC syndrome is transmitted from the cache subsystem to the master in a single bus transaction.

4. The apparatus of claim 1 , wherein the controller is further configured to, in response to the request: Determining a third ECC syndrome of the data row; determining, based on a comparison of the third ECC syndrome associated with the row of data with the first ECC, whether there are more errors in the row of data than can be corrected based on the first type of ECC; and When it is determined that there are more errors in the row of data than can be corrected based on the first type of ECC, an interrupt is generated.

5. The apparatus of claim 1, wherein the first type ECC comprises a single error correction, double error detection (SECDED) ECC, and the second type ECC comprises a single error detection (SED) ECC.

6. The apparatus of claim 1, wherein: The master is a first master; The controller is coupled to a set of masters, the set of masters comprising a first subset of masters associated with the first type of ECC and a second subset of masters associated with the second type of ECC; and The controller is configured to convert the first ECC syndrome to the second ECC syndrome and send the response including the second ECC syndrome based on the first master being in the second subset of masters.

7. The apparatus of claim 6, wherein the second subset of masters comprises at least one of: a memory management unit, a stream engine, or a level 1 cache.

8. The apparatus of claim 1, wherein: The memory is a first memory; The controller includes a second memory from the group consisting of: a tag memory, a coherent memory, and a shadow tag memory; The data row is associated with an entry in the second memory; The controller is configured to convert the first ECC syndrome to the second ECC syndrome and send the response including the second ECC syndrome based on the entry in the second memory having fewer errors than can be corrected based on the first type of ECC.

9. The apparatus of claim 8, wherein the controller is configured to terminate the request based on the entry in the second memory having more errors than can be corrected based on the first type of ECC.

10. A method comprising: Calculating a single error correction, double error correction detection (SECDED) error correction code (ECC) syndrome for a data row; storing the row of data and the SECDED ECC syndrome associated with the row of data in a memory; receiving, by a controller, a request from a master configured to implement single error detection (SED) ECC, the request being directed to the row of data: converting, by the controller, the SECDED ECC syndrome of the data row into a SED ECC syndrome; and The controller sends a response to the master, the response including the data row and the SED ECC syndrome associated with the data row.

11. The method according to claim 10, wherein: Converting the first SECDED ECC syndrome of the data row into the SED ECC syndrome further comprises: determining a second SECDED ECC syndrome of the data row; determining whether an error exists in the row of data based on a comparison of the second SECDED ECC syndrome associated with the row of data and the first SECDED ECC syndrome; and When the error is determined to exist: determining a corrected data row in which the error is corrected; overwriting the row of data in the memory with the corrected row of data; and The SED ECC syndrome is calculated based on the corrected data row.

12. The method of claim 10, further comprising transmitting the response including the SEDECC syndrome to the master in a single bus transaction.

13. The method of claim 10, wherein: The SECDED ECC syndrome is a first SECDED ECC syndrome; and The method further comprises, in response to receiving the request: determining a second SECDED ECC syndrome of the data row; determining whether more errors than can be corrected exist in the row of data based on a comparison of the second SECDED ECC syndrome associated with the row of data and the first SECDED ECC syndrome; and When it is determined that there are more errors in the data row than can be corrected, an interrupt is generated.

14. The method of claim 10, further comprising determining whether to perform the conversion of the SECDED ECC syndrome to the SED ECC syndrome based on whether the master is in a first set of masters coupled to the controller and associated with a SED ECC type or in a second set of masters coupled to the controller and associated with a SECDED ECC type.

15. The method of claim 10, further comprising determining whether to perform converting the SECDED ECC syndromes to the SED ECC syndromes based on whether the master includes at least one of: a memory management unit, a streaming engine, or a level 1 cache.

16. The method of claim 10, wherein: The memory is a first memory; The row of data is associated with an entry in a second memory; and The method also includes determining whether to perform converting the SECDED ECC syndrome to the SED ECC syndrome based on whether the entry has fewer errors than can be corrected.

17. A level 2 (L2) cache subsystem comprising: a memory configured to store a row of data and a single error correction, double error detection (SECDED) error correction code (ECC) syndrome associated with the row of data, wherein the SECDED ECC syndrome is calculated based on the row of data; and a controller coupled to the memory and configured to respond to a request from a master configured to implement single error detection (SED) ECC, the request being directed to the row of data: Converting the SECDED ECC syndrome of the data row into a SED ECC syndrome; and A response is sent to the master, the response including the data row and the SEDECC syndrome associated with the data row.

18. The L2 cache subsystem of claim 17, wherein: The SECDED ECC syndrome is a first SECDED ECC syndrome; and When the controller converts the first SECDED ECC syndrome of the data row into the SEDECC, the controller is further configured to: determining a second SECDED ECC syndrome of the data row; determining whether an error exists in the row of data based on a comparison of the second SECDED ECC syndrome associated with the row of data and the first SECDED ECC syndrome; as well as When the error is determined to exist: determining a corrected data row in which the error is corrected; overwriting the row of data in the memory with the corrected row of data; and The SED ECC syndrome is calculated based on the corrected data row.

19. The L2 cache subsystem of claim 17, wherein the response including the SEDECC syndrome is transmitted from the cache subsystem to the master in a single bus transaction.

20. The L2 cache subsystem of claim 17, wherein: The SED ECC syndrome is a first SED ECC syndrome; and The controller is further configured to, in response to the request: determining a second SECDED ECC syndrome of the data row; determining whether more errors than can be corrected exist in the row of data based on a comparison of the second SECDED ECC syndrome associated with the row of data and the first SECDED ECC syndrome; and When it is determined that there are more errors in the data row than can be corrected, an interrupt is generated.

Images