Data corruption tracking for memory reliability

Abstract

For example, techniques are disclosed relating to improving memory reliability in the context of memory circuits with limited reliability characteristics. In some embodiments, a memory controller circuit is configured to communicate with the memory circuit via an interface that supports link error detection. The memory controller circuit may transmit a combination of data and parity for a first data block that causes the memory circuit to detect an uncorrectable write interface error based on the corruption indicator. Thus, a subsequent read of the location may result in an uncorrectable error indication. This may advantageously enable the memory controller circuit in some embodiments to propagate the corruption indicator as an uncorrectable error in the memory circuit without requiring additional tracking of the indicator by the memory circuit or memory controller.

Description

[Technical field]

[0001] The present disclosure relates generally to computer memory reliability, and more particularly to tracking corrupted data and logging data errors. [Background technology]

[0002] The reliability of data stored in memory is important in various computing contexts. In a data server context, various memory reliability features may be implemented, for example, using redundant storage / interfaces, extended ECC fields, etc. These techniques may not be appropriate in non-server contexts, for example, due to power consumption and circuit area considerations. However, improved memory reliability may still be desirable in these contexts. Data may pass through various circuits, for example, in a system-on-chip, and it may be difficult to track the state of corrupted data as it moves through the system. Additionally, memory errors and their sources may be difficult to track and log efficiently. [Brief description of the drawings]

[0003] [Figure 1] FIG. 1 is a generalized block diagram illustrating an exemplary memory system, according to some embodiments.

[0004] [Diagram 2] FIG. 2 is a block diagram illustrating an example memory controller circuit configured to force uncorrectable errors when writing to a memory circuit, in accordance with some embodiments.

[0005] [Diagram 3] FIG. 2 is a block diagram illustrating example memory circuitry configured to detect and correct correctable errors in accordance with some embodiments.

[0006] [Figure 4]FIG. 2 is a block diagram illustrating an example circuit of a system that can propagate a damage indicator according to some embodiments.

[0007] [Diagram 5] FIG. 2 is a block diagram illustrating a memory controller circuit including a demand scrub circuit, according to some embodiments.

[0008] [Figure 6] FIG. 2 is a block diagram illustrating an example memory cache controller configured to track uncorrectable and correctable errors in accordance with some embodiments.

[0009] [Figure 7] FIG. 2 is a generalized diagram illustrating an exemplary uncorrectable error logger data structure in accordance with some embodiments.

[0010] [Figure 8A] FIG. 2 is a generalized diagram illustrating an exemplary correctable error data structure in accordance with some embodiments.

[0011] [Figure 8B] 1 is a block diagram illustrating an example memory cache controller configured to output a first signal and a second signal, according to some embodiments.

[0012] [Figure 9] FIG. 4 is a flow diagram illustrating an example method for generating a signal based on tracked correctable errors, according to some embodiments.

[0013] [Figure 10] FIG. 4 is a flow diagram illustrating an example method for deallocating a correctable error tracker entry in accordance with some embodiments.

[0014] [Figure 11] 4 is a flow diagram illustrating another exemplary method according to some embodiments.

[0015] [Figure 12] 4 is a flow diagram illustrating another exemplary method according to some embodiments.

[0016] [Figure 13] FIG. 1 is a block diagram illustrating an exemplary computing device, according to some embodiments.

[0017] [Figure 14] FIG. 1 illustrates an exemplary application of the disclosed systems and devices, according to some embodiments.

[0018] [Figure 15] FIG. 1 is a block diagram illustrating an exemplary computer-readable medium for storing circuit design information, according to some embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0019] In disclosed embodiments discussed in detail below, the computing device is configured to track the corrupted state of data passing through various circuits (which may be referred to herein as corruption or "poison" indicators, which may indicate detected errors that are not correctable) and to record memory errors encountered.

[0020] In some embodiments, the memory controller forces an uncorrectable error when writing corrupted data to a memory circuit (e.g., DRAM) to maintain the corrupted status when later reading the same location from the memory circuit. This may enable tracking of corrupted data stored in memory and then retrieved without requiring dedicated memory cell fields or separate memory controller tracking structures. In general, the disclosed techniques may improve memory reliability with limited or negligible increases in area and power consumption.

[0021] In some embodiments, the memory is an LPDDR5 memory configured to detect both link and on-chip errors. The memory controller, in this context, may force write link error correction code (ECC) errors and maintain a dirty status.

[0022] In some embodiments, the memory circuit is configured to correct correctable on-chip errors and indicate to the memory controller that the correctable errors have been corrected, for example, via a Decoded Status Flags (DSF) interface. Note that a correctable error is a detected error where the error correction information (e.g., using an ECC mechanism) provides enough information to correct the error (as opposed to an uncorrectable error, which is detected but without enough information to make a correction). However, the memory circuit may correct the data in-flight and leave the incorrect data in the memory cell. Thus, in some embodiments, the demand scrub circuit is configured to initiate operations that cause internal read / correct / write operations in the memory circuit to correct the stored data. This can reduce the likelihood of further errors (e.g., a second bit flip in a memory that supports correction of single bit flips but not multiple bit flips) that make the data uncorrectable.

[0023] In some embodiments, the device is configured to track and record uncorrectable and correctable errors (e.g., via separate table structures) and can take different actions based on different error thresholds. In some embodiments, the device includes a memory cache and a memory cache controller, and the memory cache controller is configured to track the errors. In some embodiments, correctable and uncorrectable errors are also tracked at the source of the error (e.g., at a particular processor cluster and their cache). The memory cache controller can aggregate the error information and trigger various signals in response to certain thresholds. Various disclosed techniques can enable potential identification problems (e.g., a threshold count associated with a particular physical address can indicate a bad DRAM cell).

[0024] In various embodiments, the disclosed techniques may advantageously improve memory reliability in devices where server-grade memory reliability techniques are impractical. Memory System Overview

[0025] 1 is a block diagram illustrating an exemplary memory system, according to some embodiments. In the illustrated embodiment, system 100 includes a memory controller circuit 101 and multiple memory circuits 104-106 (note that in other embodiments, any of a variety of numbers of memory circuits may be implemented, and the memory circuits may include a variety of different numbers of banks per circuit). In the illustrated embodiment, memory controller circuit 101 is configured to communicate with memory circuit 104 via bus 108.

[0026] Memory control circuitry 101, in the illustrated embodiment, receives access requests 109 over multiple virtual channels 110. In some embodiments, the virtual channels carry different types of requests and have different quality of service requirements. Requests from a particular agent may be sent over a particular virtual channel, or an agent may be configured to send requests over multiple different virtual channels. In some embodiments, as discussed in more detail below, the virtual channels include a real-time channel, a low-latency channel, and a bulk (or best-effort) channel.

[0027] Memory controller circuitry 101, in the illustrated embodiment, includes queuing circuitry 102, arbitration circuitry 103, and priority tracking structure 111. In some embodiments, queuing circuitry 102 is configured to queue received requests. In some embodiments, arbitration circuitry 103 is configured to select which requests are granted access to a particular memory bank 107. In some embodiments, arbitration circuitry 103 is configured to use information in priority tracking structure 111 to determine which requests to grant.

[0028] In some embodiments, arbitration circuit 103 is configured to implement a category-based arbitration scheme. In some embodiments, each virtual channel is assigned a category value (e.g., C0-C3 in some embodiments, but other embodiments may implement any of a variety of numbers of categories). Arbitration circuit 103 may assign a category for each bank to each virtual channel. In some embodiments, each virtual channel starts with C3 for each bank, and arbitration circuit 103 is configured to prioritize C3 channels over other channels. A least-recently-used (LRU) scheme may be used to select among virtual channels having the same category for a bank. In some embodiments, certain low priority virtual channels are always given a certain low category, such as C1 or C0.

[0029] When a virtual channel wins arbitration and is granted access to a particular bank, in some embodiments, memory controller 101 decrements the category of that bank (e.g., from C3 to C2, or from C2 to C1). In some embodiments, when the virtual channel is reduced below a particular level (e.g., below C2) for each bank for which the virtual channel has a request, memory controller 101 is configured to increment all categories for that virtual channel by one level (e.g., from C2 to C3). Note that when "each" memory bank of a set of multiple memory banks is discussed herein, the techniques disclosed may apply to the set of memory banks, but not necessarily to all memory banks in a device or system. For example, other memory banks in the same device may be controlled by other memory controllers or devices.

[0030] In some embodiments, memory controller 101 also implements a credit system to grant a certain number of requests per virtual channel for a given read or write order, for example based on the requested or allocated bandwidth for different virtual channels, which may affect which virtual channels actually send requests to arbitration circuit 103 during a given order.

[0031] In various embodiments, a category-based arbitration scheme can provide fair access to a given bank among multiple virtual channels while cycling between banks to avoid delays associated with accessing the same bank in close succession.

[0032] The memory circuits 104-106, in the illustrated embodiment, each include a plurality of banks 107a-n. The memory circuits 104-106 may be implemented using any of a variety of suitable memory technologies. The memory circuits 104-106, for example, if implemented as dynamic random access memory (DRAM), may need to be periodically refreshed. Furthermore, since there may be a delay between successive accesses to different pages of the same bank, for example, it may be efficient to distribute access requests to different banks. Thus, generally speaking, the arbitration circuit 103 attempts to grant access to one of a set of banks that has not been accessed within a threshold time interval. Exemplary Overrides for Propagating Taint Indicators

[0033] FIG. 2 is a block diagram illustrating a memory controller circuit configured to force uncorrectable errors when writing to a memory circuit, according to some embodiments. In the illustrated embodiment, a computing system includes a memory controller circuit 101 and a memory circuit 104. Note that these circuits may be manufactured separately and connected during assembly of the computing device. The memory controller circuit 101 includes a control circuit 230. The memory circuit 103 includes a write link ECC check circuit 220, a circuit 250 configured to write data / parity combos for write link uncorrectable errors (UEs), a CE correction circuit 245, an error correction code (ECC) calculation circuit 255, and cells 260A-260N.

[0034] The write link ECC check 220, in the illustrated embodiment, includes circuitry configured to check the parity of write data transmitted from the memory controller 101. For example, the circuitry 220 may generate a parity value based on the received data and check that it matches the received parity value. As illustrated, the circuitry 220 may indicate whether the data transmitted over the link exhibits an uncorrectable error (UE), a correctable error (CE), or no error (NE). In the case of a correctable write link error, the CE correction circuitry 245 may correct the error. The circuitry 255 is configured to generate ECC information for the error-free data or data with a corrected CE and store the data and parity information in the memory cell 260. The elements 245 and 255 are illustrated using dashed lines and may be omitted in some embodiments. As shown, the memory circuit 104 is configured to store data and parity information in a given memory cell 260 (note that the data and parity information can be stored using sideband or in-line techniques, depending on the memory technology of the memory circuit 104).

[0035] Circuit 250, in the illustrated embodiment, is configured to handle uncorrectable errors on the write link. In particular, circuit 250 is configured to write a data parity combination to cell 260 that will result in a UE when the cell is later read (e.g., by an on-chip ECC check, discussed below with reference to FIG. 3). The data and parity values ​​may or may not match the actual data and parity received over the link from the memory controller circuit. The written data and parity values ​​may be vendor specific, and the original uncorrectable data may not be stored.

[0036] The control circuitry 230, in some embodiments, is configured to override the write link ECC and force an uncorrectable error in the corrupted data. For example, the control circuitry 230 may write a combination of data and parity over the link that intentionally causes the write link ECC check circuitry 220 to detect a UE. This may propagate a corrupted indicator of the data that will remain the next time a read to the location results in a UE. Note that the corrupted data may be corrupted in another circuit (e.g., a cache, a link between the processor and another element, etc.), and by tracking this corrupted data, improper use of the corrupted data can be avoided. In this scenario, the memory controller circuitry 101 may not care about the actual value of the corrupted data.

[0037] In other embodiments, control circuit 230 may override link ECC using other techniques. For example, rather than providing a data / parity combination that represents the UE, control circuit 230 may assert a signal indicating an override, and memory circuit 104 may write the data / parity combination to cell 260 in response to detecting the override signal.

[0038] 3 is a block diagram illustrating an exemplary read link and on-chip error detection circuitry in accordance with some embodiments. In the illustrated embodiment, memory controller 101 includes read link ECC check circuitry 315, and memory circuitry 104 includes CE correction circuitry 345 and check ECC circuitry 355.

[0039] In some embodiments, the read link ECC check circuit 325 is configured to generate and check parity information similar to the write link ECC check circuit 220. In some embodiments, on-chip errors or read link errors may be detected and reported by the read link ECC check circuit 325, as discussed in more detail below.

[0040] The check ECC circuit 355, in the illustrated embodiment, is configured to read the data and parity information of the memory cell, generate a parity value based on the data, and verify that the parity values ​​match. The CE correction circuit 345, in the illustrated embodiment, is configured to correct the CE detected by the circuit 355. The UE may be reported via a decode status flag (DSF), which may be transmitted via the same interface as the link parity information. In some embodiments, the decode status flag allows the memory circuit 104 to indicate whether or not it detected an error in the memory cell. Thus, the memory circuit 104 may indicate a corrected CE, UE, or no error via the DSF for a given location. It should be noted that various elements of the device (e.g., SoC components) may detect and correct CE in a similar manner.

[0041] For a reading UE, memory controller circuit 101 may mark the data as dirty. Similarly, the UE may be detected in various circuits of the device and may result in a dirty indication for the data in circuits that support such indication. In the case of a CE, memory controller circuit 101 may trigger a demand scrub operation, as discussed in more detail below with reference to FIG. 5.

[0042] It should be noted that the various error detection and correction techniques discussed herein are included for purposes of illustration, but are not intended to limit the scope of the present disclosure. In other embodiments, any of a variety of suitable ECC or parity schemes may be implemented. Generally speaking, in the context of an ECC scheme that supports correction of a CE having up to N incorrect bits, errors on more than N bits may correspond to the UE. Similarly, while separate parity and data lines are shown, in other embodiments, any of a variety of suitable link interfaces may be implemented, and these fields may share an interface.

[0043] Note that in some cases, the memory circuit 104 may be the original source of the uncorrectable error that caused the taint indicator in the memory controller 101. This may raise the question of whether the taint indicator is propagated upon rewriting of data to a known bad cell. If this is a soft error or a transient memory error, the tainted uncorrectable error may be propagated when the data is rewritten to the cell. If this is a hard or persistent memory circuit error, there are two possibilities. First, a rewrite to the cell may still store a data / parity combination corresponding to an uncorrectable error, and propagation of the taint indicator is safe. Second, the cell may end up storing a data / parity combination corresponding to a correctable error, and thus not propagate a taint indication when the cell is read. In this scenario, since an error in the memory circuit 104 caused the taint indication in the first place, the overall error problem may be addressed by software, and may have been signaled by the memory controller circuit 101 when generating the original taint indication. Additionally, hard memory failures may also be detected during a zeroing operation, in which all zeros are written to a memory location. Either detection technique may allow the operating system to take a page offline to avoid further errors due to, for example, hard or persistent memory errors. If the operating system is fairly pessimistic when taking a page offline in response to an uncorrectable error, it may be highly unlikely that a memory-initiated uncorrectable error will cause a failure that propagates a tainted indicator. Example of contamination indicator propagation

[0044] It should be noted that while overriding the link ECC is one example of a corruption indicator propagation, the corruption indicator may be propagated throughout various circuit elements and operations, as discussed in more detail below.

[0045] 4 is a block diagram illustrating an example circuit, e.g., within an SoC, configured to propagate tainted indications. In the illustrated example, the system includes a memory controller 101, a memory circuit 104, a memory cache controller 410, a fabric 420, and an agent 440.

[0046] The various agents, memory cache controller 410, and memory controller circuitry 101 communicate via fabric 420. In some embodiments, the fabric may include a field (e.g., a bit) for a dirty indicator in the data transmitted over the fabric. This may enable the circuitry to propagate the dirty indicator through the fabric. In other embodiments, fabric 420 may not include a dedicated field for the dirty indicator, but the various circuitry may encode the dirty indicator in the data transmitted over the fabric for decoding by the receiving circuitry.

[0047] The memory cache controller 410 may control a memory cache, which may be the cache furthest from one or more processors in a cache / memory hierarchy (e.g., there may be one or more lower level L1, L2, L3 caches, etc.). The memory cache (not shown) may be configured to write evicted data to the memory circuit 104 and read data from the memory circuit 104 for cache misses. The memory cache controller 410 may be configured to detect corrupted data in the memory cache and mark the data as dirty. The memory cache controller 410 may also be configured to maintain a dirty indicator for data corrupted elsewhere before being stored in the memory cache.

[0048] The memory controller 101 may also generate a taint indicator for the data based on a match between the address of the data and a channel address mask. This may allow for deliberate insertion of various types of errors, for example for debug purposes, where errors (including CE and UE) may be injected when receiving data from the memory or writing data to the memory. The masking may allow for triggering on a range of addresses. This may be important for testing, considering that CE is fairly rare and UE is even rarer. Thus, the injection of errors may facilitate testing of various memory reliability features.

[0049] The memory controller 101 may also include a write queue field for tracking the tainted indicator. The memory controller 101 may perform various operations on the queued accesses to improve efficiency. For example, the memory controller 101 may transfer write data for the same location from a write queue to a read queue entry to avoid accessing the memory circuit 104 for a read. As another example, the memory controller 101 may merge accesses to improve efficiency, avoid hazards (e.g., WAW, WARAW, etc.), or both. In some embodiments, the memory controller circuit 101 is configured to properly maintain the tainted indicator through such operations.

[0050] Agent 440 may be a variety of circuits, such as a processor, a graphics processor, an I / O controller, etc. Agent 440 may also generate or maintain taint indicators for the data it processes.

[0051] Consider the following example paths that data may take through the system: A data block may be flagged as dirty by memory cache controller 410 based on an error in the memory cache. A dirty indicator may be communicated to memory controller 101 via fabric 420 along with the write of the data to memory. Memory controller 101 may combine the dirty indicator with any dirty indicators generated due to a channel address mask (e.g., by indicating dirty if any dirty indicator is set). Memory controller 101 may propagate the dirty indicator along with the write data to the write queue circuitry. For any write-read transfer from a write queue entry to a read queue, memory controller 101 may similarly propagate the dirty indicator. For any access merge operation, memory controller 101 may similarly propagate any dirty indicators for the merged data to the merged operation. A write link override may result in data corresponding to an uncorrectable error being stored in a memory cell. When later read, the memory controller circuit 101 can mark the data as corrupted in response to detecting the DSF value for an uncorrectable error, and the corrupt indicator can be propagated to various circuits in the system.

[0052] Relative to memory controller circuits that maintain dedicated information regarding which memory cells are dirty, or dedicated fields within the memory cells to track this information, the disclosed techniques can advantageously reduce area and power consumption within a memory cache controller while accurately propagating the dirty indicators. LPDDR5 Memory Overview and Limitations

[0053] It should be noted that the various techniques discussed herein may be particularly relevant in the context of LPDDR5 memory circuits, but similar techniques may be used for various memory technologies. In general, LPDDR5 memory can provide good performance for various applications (e.g., mobile devices) with relatively low power consumption. This memory technology and these applications may not incorporate various memory reliability features implemented in other contexts, such as server applications that incorporate extensive redundancy and ECC functions. The following discussion presents some LPDDR5 features that may be relevant to the present disclosure.

[0054] The fifth generation of LPDDR (Low-Power Double Data Rate) SDRAM technology was first released in the first half of 2019. It inherits the previous generation LPDDR4 / 4X 4 / 4 X and offers speeds of up to 6400Mbps (1.5 times faster). In addition, by implementing several power-saving developments, LPDDR5 can reduce power by up to 20% over the previous generation. LPDDR5 can provide link ECC schemes, scalable clocking architecture, multiple frequency-set points (FSP), decision feedback equalization (DFE) to mitigate inter-symbol interference (ISI), write X function, flexible bank architecture, and inline on-chip ECC. LPDDR5 systems typically do not offer server-level reliability features such as single-device data correction (SDDC), memory mirroring and redundancy, demand scrubbing, patrol scrubbing, data corruption, redundant links, clock and power monitoring / redundancy / failover, CE isolation, online sparing with automatic failover, double device data correction (DDDC), etc. Exemplary Demand Scrub Circuit

[0055] In some embodiments, memory circuit 104 is configured to detect correctable errors in memory cell data and correct the errors before providing read data to memory controller 101. However, the erroneous data may remain uncorrected in the memory cells. The likelihood of uncorrectable errors for such data may increase. For example, if the system is configured to correct single bit errors but is unable to correct multiple bit errors (or, more generally, unable to correct errors above a threshold number of bit errors), data that already exhibits correctable errors may be more likely to be further corrupted to exhibit uncorrectable errors.

[0056] Thus, in some embodiments, memory controller circuit 101 is configured to perform demand scrubbing to cause memory circuit 104 to correct data stored in memory cells. Memory circuit 104 may support one or more types of write operations to efficiently perform the corrections.

[0057] 5 is a block diagram illustrating an exemplary demand scrub circuit, according to some embodiments. In the illustrated embodiment, memory controller 101 includes a demand scrub circuit 510, which includes a snoop circuit 520 and a corrective CE circuit 530. The remaining elements of FIG. 5 may be configured as described above for similarly numbered elements of the previous figures.

[0058] The demand scrub circuit 510, in the illustrated embodiment, is configured to detect corrected errors from the memory circuit 104 and trigger the memory circuit 104 to correct the errors. Specifically, in the illustrated embodiment, the snoop circuit 510 is configured to snoop (monitor) the DSF status of the read operation performed by the memory controller 101. When the memory circuit 104 detects and corrects a CE, the DSF associated with the data indicates that the CE has been corrected. The DSF is one example of an encoding that may be used for LPDDR5, but is not intended to limit the scope of the present disclosure. In general, the snoop circuit may utilize any of a variety of suitable fields to determine when the memory circuit 104 has corrected an error in a memory cell without updating the memory cell to a corrected value. In some embodiments, the snoop circuit 520 collects a DRAM channel address corresponding to each detected CE.

[0059] In response to detecting a CE, snoop circuit 520 notifies correction CE circuit 530, which triggers an internal correction within memory circuit 104. In the illustrated example, the trigger is a fully masked partial write to the location that exhibited a CE, which results in an internal read / correct / write to that memory cell within memory circuit 104 (without changing the correct value of the data). In general, memory circuit 104 can support commands such as a fully masked partial write operation, which indicates to read a location, correct the CE at that location, and write the corrected value back to the location.

[0060] The disclosed techniques may allow for simplification of memory circuits 104 relative to memory circuits with built-in scrubbing while still providing demand scrubbing functionality in some scenarios.

[0061] In some embodiments, multiple demand scrub corrections of the same location may indicate a faulty memory cell, and the operating system may take the corresponding page offline. However, in the case of a transient or soft error, the demand scrub techniques discussed herein can reduce the rate at which CEs in memory circuit cells become UEs.

[0062] The demand scrub function may be programmable, for example, to disable demand scrubbing. In some embodiments, demand scrubbing may not be performed in one or more modes in which DSF is disabled. In some embodiments, the status of demand scrubbing may be locked so that it cannot be changed after boot.

[0063] Note that demand scrub operations may be arbitrated with other access operations by memory controller circuit 101. In some embodiments, demand scrub operations may have a relatively lower quality of service (QoS) level or class than one or more other types of traffic, thereby reducing or avoiding interference with QoS for that traffic. In some circumstances, demand scrub operations may be forgone. In some embodiments, the snoop circuitry may track information about multiple CEs at a time, but may only allow a threshold number of demand scrub operations to be in-flight at a given time (e.g., one).

[0064] In some embodiments, the demand scrub circuitry 510 may include a transfer progress counter that accumulates over time and increase the priority of the demand scrub operation when the transfer progress counter reaches a threshold.

[0065] In some embodiments, the demand scrubbing circuitry 510 includes a timeout timer that starts when a demand scrub write is placed in the write queue and can force write ordering when the timeout timer reaches a threshold. The demand scrubbing circuitry 510 can also disable demand scrubbing in response to certain operating conditions, such as the write queue already having a threshold number of valid entries.

[0066] In some embodiments, the data associated with a demand scrub write is not software accessible (e.g., the data is read, corrected, and written internally to the memory circuit 104). In some embodiments, the demand scrub operation is not controlled by software, but is fully hardware controlled (e.g., the snoop circuit 520 and the correction CE circuit 530 may operate according to a finite state machine).

[0067] In some embodiments, the demand scrub circuit 510 is configured to record demand scrub operations. For example, the demand scrub circuit 510 may include software accessible configuration registers that indicate a count of DSFs with CE status (which may be maintained independently for different lanes), a count of successfully completed demand scrub writes, and a count of deferred demand scrub writes. These counters may be zeroed on reset, by software, or both. In some embodiments, the counters are only available in a debug mode of operation. As used herein, the term "software" refers broadly to program instructions executed by one or more processors, and includes user applications, firmware, operating systems, and the like. Exemplary Error Tracking Techniques

[0068] 6 is a block diagram illustrating an exemplary memory cache controller configured to track and record correctable and uncorrectable errors and output software visible signaling, according to some embodiments. In the illustrated embodiment, the memory cache controller 410 includes an uncorrectable error (UE) logger 610 and a correctable error (CE) tracker 620.

[0069] The UE logger 610, in the illustrated embodiment, is configured to log detected memory errors and track certain information (e.g., physical address, error source, client identifier, etc., discussed in more detail below). In the illustrated embodiment, the UE logger 610 is specifically configured to log detected uncorrectable memory errors. In some embodiments, the UE logger 610 tracks the source of the uncorrectable errors. In some embodiments, the UE logger 610 does not aggregate addresses and is not content addressable.

[0070] CE tracker 620, in the illustrated embodiment, is configured to record detected memory errors and track certain information (e.g., physical address, count of errors at that address, client identifier, etc.). In the illustrated embodiment, CE tracker 620 is specifically configured to record detected correctable memory errors. In some embodiments, CE tracker 620 implements a count field that indicates the number of correctable errors that have occurred that correspond to a given physical address. In some embodiments, CE tracker 620 aggregates addresses and is content addressable.

[0071] In the illustrated embodiment, the memory cache controller 410 is configured to generate software visible signal(s). These signals can inform the tracker / logger content software that a threshold on content has been met, or can generally indicate to the software that a particular action may need to be taken (e.g., clear an entry, mark data as tainted, take a page offline, etc.).

[0072] It should be noted that in other embodiments, devices may implement the disclosed record / trace circuitry elsewhere, in addition to or instead of the memory cache controller 410. However, tracking in the memory cache controller 410 may be particularly advantageous because the memory cache controller may operate using physical memory channel addresses. This information may not be available to other circuits, and thus tracking in the memory cache controller can provide detailed information to software without the need to transmit this information to other circuit elements.

[0073] In general, the disclosed tracking structure can advantageously provide software with a variety of useful information not available in conventional implementations, enabling the software to take appropriate corrective action when an error is detected.

[0074] 7 is a diagram illustrating an example UE logger data structure configured to log uncorrectable memory errors, according to some embodiments. In the illustrated embodiment, the example UE logger data structure 610 includes a valid field, a physical address field, a client identifier field, and an error source field.

[0075] In the illustrated embodiment, the valid field indicates whether the data entry is valid. In some embodiments, all entries in the UE logger data structure 610 are initially set to invalid.

[0076] In the illustrated embodiment, the physical address field contains memory address information for a data entry that allows the data bus to access a particular storage cell of the memory. This information can be particularly useful when a memory cell is the source of an error.

[0077] In the illustrated embodiment, the client identifier field identifies the client circuit within the SoC that previously accessed the data. For example, this field may indicate the fabric identifier of the client with respect to the communications fabric.

[0078] In the illustrated embodiment, the error source field includes address information for the data entry that identifies the source of the memory error. Non-limiting example error sources that may be encoded include a UE from a DRAM read, a memory cache read data having an uncorrectable error (based on an error check or a dirty indicator), or snoop response dirty data (e.g., when a snoop to another cache determines that the other cache controls the location and has marked the data as dirty).

[0079] In some embodiments, when there are no free entries in the UE logger and a UE is detected, an overflow signal (e.g., a bit) is asserted. In some embodiments, the overflow bit may be sticky and persistent until cleared (e.g., via a write-1-to-clear operation). Software may initiate corrective action based on the overflow signal to mitigate corruption risks associated with not being able to log subsequent UEs.

[0080] In some embodiments, after the software reads an entry from the UE logger data structure 610, it may invalidate the entry, for example via a write-1-to-clear operation.

[0081] 8A is a diagram illustrating an example CE tracker data structure configured to track correctable memory errors, according to some embodiments. In the illustrated embodiment, the example CE tracker data structure 620 includes a valid field, a physical address field, a client identifier field, and a count field.

[0082] The valid, physical address, and client identifier fields may track information similar to that described above in the context of the UE logger data structure 610. In some embodiments, the CE tracker 620 utilizes a content addressable memory (CAM) structure in which at least a portion of the physical address is used as a tag to determine if there is a hit on a valid entry and to increment the count, as discussed below with reference to FIG.

[0083] In the illustrated embodiment, the count field indicates the number of correctable errors detected for the respective physical address in the interval since the entry was last cleared.

[0084] 8B is a block diagram illustrating an example memory cache controller configured to track CE errors and output a signal based on a particular threshold being met or exceeded. In the illustrated embodiment, the memory cache controller 410 includes a CE tracker 620 and outputs a first signal corresponding to a valid occupancy threshold and a second signal corresponding to a count threshold.

[0085] In the illustrated embodiment, the control circuitry is configured to assert a signal indicative of a valid occupancy threshold when the number of valid entries in CE tracker 620 meets the threshold. Note that "meeting" a threshold may correspond to equaling the threshold or exceeding the threshold (e.g., having a value one step greater or less than the threshold) in different implementations.

[0086] In the illustrated embodiment, the control circuitry is configured to assert a signal indicative of the count threshold when the count field of a particular physical address in CE tracker 620 reaches a value that satisfies the count threshold.

[0087] Based on these signals, the software can take various corrective actions, such as stopping a particular activity when a valid occupancy threshold is met, or accessing one or more CE tracker entries when a count threshold is met. Exemplary Techniques for Allocating and Deallocating CE Tracker Entries

[0088] 9 is a flow diagram illustrating an exemplary method for allocating a new CE. The method illustrated in FIG. 9 may be used with, among other things, any of the computer circuits, systems, devices, elements, or components disclosed herein. In various embodiments, some of the illustrated method elements may be performed simultaneously, in a different order than that illustrated, or may be omitted. Additional method elements may be performed as desired.

[0089] At 910, in the illustrated embodiment, a control circuit (eg, of memory cache controller 410) receives the new CE.

[0090] At 920, in the illustrated embodiment, the control circuitry determines whether the new CE is a hit or a miss in the CE tracker. If it is a hit, flow continues to 950; if it is a miss, flow continues to 930.

[0091] At 930, in the illustrated embodiment, in the event of a miss in the CE tracker, the control circuit allocates an entry in the CE tracker for the new CE and initializes its count (eg, to 1 or a default value).

[0092] At 940, in the illustrated embodiment, the control circuitry determines whether the occupancy threshold is met (e.g., if the number of valid entries in the CE tracker meets the occupancy threshold after allocating the entries at 930). If so, the control circuitry asserts a signal indicating that the valid occupancy threshold has been met.

[0093] In some embodiments, in response to the signal, the software may take a snapshot of the visible valid entries and clear the entries to clear space in the CE tracker. In some embodiments, when there are no free entries in the CE tracker, new CEs may not be tracked. Note that in some situations, an entry may not be software visible. For example, the control circuitry may only allow software to access all or a portion of an entry after one of the disclosed thresholds has been hit.

[0094] At 950, in the illustrated embodiment, for a hit in the CE tracker, the control circuitry increments the count value for the hit entry and updates the client identifier of that entry to the most recent client associated with the error. In other embodiments, the client identifier field may track multiple client identifiers, and the control circuitry may add the most recent client identifier to the list of identifiers.

[0095] At 960, in the illustrated embodiment, the control circuitry determines whether the count threshold has been met due to the increment at 950. If so, the control circuitry asserts a signal indicating that the count threshold has been met. In some embodiments, such a signal can alert software to a potentially bad DRAM cell, allowing the software to take various actions, such as off-lining the page that contains the cell.

[0096] 10 is a flow diagram illustrating an exemplary method for deallocating a CE tracker entry. The method illustrated in FIG. 10 may be used with, among other things, any of the computer circuits, systems, devices, elements, or components disclosed herein. In various embodiments, some of the illustrated method elements may be performed simultaneously, in a different order than that illustrated, or may be omitted. Additional method elements may be performed as desired.

[0097] At 1010, in the illustrated embodiment, the control circuitry determines whether the CE tracker is accessible by the software. If so, flow proceeds to 1020. If not, the control circuitry may take no further action.

[0098] At 1020, in the illustrated embodiment, upon verifying that the CE tracker is accessible by the software, the control circuitry reads one or more entries. In some embodiments, a protocol is initiated to take a snapshot of all visible valid entries in the CE tracker structure.

[0099] At 1030, in the illustrated embodiment, the control circuitry determines whether to deallocate one or more entries in the CE tracker. In some embodiments, the deallocation is performed by software, for example, using a write-1-to-clear mechanism.

[0100] In some embodiments, the deallocation of one or more entries in the CE tracker is at the discretion of the software. The software has the option of not deallocating an entry. According to some embodiments, the software can move the CE tracker information to another data structure to make space available in the CE tracker. This can be useful, for example, in situations where there are a significant number of unique CE addresses or if a threshold is reduced. Exemplary Methods

[0101] 11 is a flow diagram illustrating an exemplary method for tracking corrupted data, according to some embodiments. The method illustrated in FIG. 11 may be used with, among other things, any of the computer circuits, systems, devices, elements, or components disclosed herein. In various embodiments, some of the illustrated method elements may be performed simultaneously, in a different order than that illustrated, or may be omitted. Additional method elements may be performed as desired.

[0102] At 1110, in the illustrated embodiment, the memory controller circuit communicates with the memory circuit via an interface. The memory circuit may implement both link error correction and on-die error correction. In some embodiments, the memory circuit supports interface error detection (e.g., write link ECC) that results in the writing of a combination of data and parity to a target memory location for a detected uncorrectable write interface error, which combination corresponds to the uncorrectable error.

[0103] At 1120, in the illustrated embodiment, the memory controller circuit arbitrates between requests to access the memory circuit from the request agent circuit, including a first request to write first data to a first location within the memory circuit.

[0104] At 1130, in the illustrated embodiment, the memory controller circuitry maintains corruption indicators for the data block, including a first corruption indicator indicating that the first data has been determined to be corrupted. In some embodiments, one of the agent circuits is configured to generate the first corruption indicator, for example, based on the detected UE.

[0105] In some embodiments, a device including a memory controller circuit is configured to maintain the corruption indicator through multiple operations including any combination of the following operations: propagating the corruption indicator after merging one or more requests to resolve a hazard, propagating the corruption indicator for a write-read transfer operation from a write queue, converting the corruption indicator to a forced uncorrectable write interface error, communicating the corruption indicator to the memory controller circuit by a memory cache controller circuit, and propagating the corruption indicator determined based on an address mask.

[0106] At 1140, in the illustrated embodiment, the memory controller circuit transmits a combination of data and parity for the first data block that causes the memory circuit to detect an uncorrectable write interface error.

[0107] At 1150, in the illustrated embodiment, the memory controller circuit reads the memory location following the write for the first request and generates a corruption indicator of the read data in response to a report of an uncorrectable error from the memory circuit for the read data.

[0108] In some embodiments, the demand scrub circuit is configured to detect corrected errors indicated by the memory circuit, where incorrect data is still stored in memory cells of the memory circuit, and in response to detecting the corrected errors, initiate a demand scrub write operation to the memory circuit that causes an internal read, error correction of the correctable errors, and writing of the corrected data to the memory circuit. In some embodiments, the write operation is a fully masked partial write operation to the DRAM addresses where the corrected errors were detected. In some embodiments, the demand scrub circuit is configured to record in one or more software accessible registers the number of correctable errors detected and the number of successful demand scrub writes. In some embodiments, the detection of the corrected errors is based on a decoding status flag reported by the memory circuit that indicates whether the provided data has no errors, has correctable errors, or has uncorrectable errors.

[0109] In some embodiments, the memory circuit includes error circuitry configured for a write operation to verify parity information of error-free write data and to correct detected correctable errors associated with the interface, and in some embodiments, the memory circuit includes error circuitry configured for a read operation to correct detected errors associated with the read location and to report detected uncorrectable errors associated with the read location via the interface.

[0110] 12 is a flow diagram illustrating an exemplary method for tracking the number of detected correctable errors, according to some embodiments. The method illustrated in FIG. 12 may be used with, among other things, any of the computer circuits, systems, devices, elements, or components disclosed herein. In various embodiments, some of the illustrated method elements may be performed simultaneously, in a different order than that illustrated, or may be omitted. Additional method elements may be performed as desired.

[0111] At 1210, the illustrated embodiment caches data manipulated by one or more processors in a memory cache.

[0112] At 1220, in the illustrated embodiment, the number of detected correctable errors associated with a plurality of respective locations is tracked using a plurality of tracking circuit entries.

[0113] At 1230, in the illustrated embodiment, in response to detecting the number of correctable errors for a particular location, a signal is generated to one or more processors identifying the particular location.

[0114] In some embodiments, a signal identifying a particular location is asserted to indicate that a count threshold has been hit, which can alert software that there is a page potentially with bad DRAM that may be close to failing.

[0115] In some embodiments, an alert signal is generated in response to the number of valid entries in the tracking circuit entry meeting or exceeding an occupancy threshold. In some embodiments, in response to meeting or exceeding an occupancy threshold, software is enabled to access one or more tracking circuit entries.

[0116] In some embodiments, in response to software signaling, one or more of the tracking circuit entries may be de-allocated.

[0117] In some embodiments, the multiple circuit entries include a respective client identifier field that indicates a client associated with a given correctable error. In some embodiments, a detected UE associated with multiple respective locations of data is tracked using multiple UE tracking circuit entries.

[0118] In some embodiments, a UE tracking circuit entry includes a source field that identifies a source of a given UE. In some embodiments, the source field is configured to encode a source that includes at least a source of a memory error, a memory cache error, and a snoop response. In some embodiments, multiple UE tracking circuit entries are untagged and multiple tracking circuit entries are tagged with at least a portion of an address for a given location.

[0119] In some embodiments, the device is configured to maintain a corruption indicator for the data block, the corruption indicator indicating that the data block has been determined to be corrupted. Exemplary Devices

[0120] 13, a block diagram illustrating an exemplary embodiment of device 1300 is shown. In some embodiments, elements of device 1300 may be included within a system-on-chip. In some embodiments, device 1300 may be included in a mobile device that may be battery powered. Thus, power consumption by device 1300 may be an important design consideration. In the illustrated embodiment, device 1300 includes fabric 1310, compute complex 1320, input / output (I / O) bridge 1350, cache / memory controller 1345, graphics unit 13135, and display unit 1365. In some embodiments, in addition to or instead of the illustrated components, device 1300 may include other components (not shown), such as video processor encoders and decoders, image processing or recognition elements, computer vision elements, etc.

[0121] Fabric 1310 may include various interconnects, buses, MUXes, controllers, etc., and may be configured to facilitate communication between various elements of device 1300. In some embodiments, portions of fabric 1310 may be configured to implement a variety of different communication protocols. In other embodiments, fabric 1310 may implement a single communication protocol, and elements coupled to fabric 1310 may internally convert from one communication protocol to other communication protocols.

[0122] In the illustrated embodiment, compute complex 1320 includes bus interface unit (BIU) 1325, cache 1330, and cores 1335 and 1340. In various embodiments, compute complex 1320 may include various numbers of processors, processor cores, and caches. For example, compute complex 1320 may include one, two, or four processor cores, or any other suitable number. In one embodiment, cache 1330 is a set associative L2 cache. In some embodiments, cores 1335 and 1340 may include internal instruction and / or data caches. In some embodiments, a coherency unit (not shown) in fabric 1310, cache 1330, or elsewhere in device 1300 may be configured to maintain coherency between various caches of device 1300. BIU 1325 may be configured to manage communications between compute complex 1320 and other elements of device 1300. A processor core, such as core 1335 and core 1340, may be configured to execute instructions of a particular instruction set architecture (ISA), which may include operating system instructions and user application instructions.

[0123] Cache / memory controller 1345 may be configured to manage the transfer of data between fabric 1310 and one or more caches and / or memories. For example, cache / memory controller 1345 may be coupled to an L3 cache, which may in turn be coupled to system memory. In other embodiments, cache / memory controller 1345 may be directly coupled to memory. In some embodiments, cache / memory controller 1345 may include one or more internal caches.

[0124] As used herein, the term "coupled" can refer to one or more connections between elements, and the coupling may include intervening elements. For example, in FIG. 13, graphics unit 1375 may be described as "coupled" to memory via fabric 1310 and cache / memory controller 1345. In contrast, in the illustrated embodiment of FIG. 13, graphics unit 1375 is "directly coupled" to fabric 1310, as there are no intervening elements.

[0125] The graphics unit 1375 may include one or more processors, such as one or more graphics processing units (GPUs). The graphics unit 1375 may receive graphics-oriented instructions, such as, for example, OPENGL®, Metal, or DIRECT3D® instructions. The graphics unit 1375 may execute specialized GPU instructions or perform other operations based on the received graphics-oriented instructions. The graphics unit 1375 may generally be configured to process large blocks of data in parallel and may build images in a frame buffer for output to a display, which may be included in the device or may be a separate device. The graphics unit 1375 may include transform, lighting, triangle, and rendering engines in one or more graphics processing pipelines. The graphics unit 1375 may output pixel information for a display image. In various embodiments, the graphics unit 1375 may include programmable shader circuitry that may include highly parallel execution cores configured to execute graphics programs, which may include pixel tasks, vertex tasks, and computation tasks (which may or may not be graphics-related).

[0126] The display unit 1365 may be configured to read data from the frame buffer and provide a stream of pixel values ​​for display. The display unit 1365, in some embodiments, may be configured as a display pipeline. In addition, the display unit 1365 may be configured to blend multiple frames to generate an output frame. Furthermore, the display unit 1365 may include one or more interfaces (e.g., MIPI or embedded display port (eDP)) for coupling to a user display (e.g., a touch screen or an external display).

[0127] I / O bridge 1350 may include various elements configured to implement, for example, Universal Serial Bus (USB) communications, security, audio, and / or low power always-on functionality. I / O bridge 1350 may also include interfaces such as, for example, Pulse Width Modulation (PWM), General Purpose Input / Output (GPIO), Serial Peripheral Interface (SPI), and Inter-Integrated Circuit (I2C). Various types of peripherals and devices may be coupled to device 1300 via I / O bridge 1350.

[0128] In some embodiments, device 1300 includes a network interface circuit (not explicitly shown) that may be connected to fabric 1310 or I / O bridge 1350. The network interface circuit may be configured to communicate over various networks, which may be wired, wireless, or both. For example, the network interface circuit may be configured to communicate over a wired local area network, a wireless local area network (e.g., via WiFi), or a wide area network (e.g., the Internet or a virtual private network). In some embodiments, the network interface circuit is configured to communicate over one or more cellular networks using one or more radio access technologies. In some embodiments, the network interface circuit is configured to communicate using device-to-device communication (e.g., Bluetooth or WiFi Direct), or the like. In various embodiments, the network interface circuit may provide device 1300 with connectivity to various types of other devices and networks.

[0129] Various elements of FIG. 13 may utilize the disclosed techniques. For example, memory cache controller 410, memory controller circuit 101, or both may be included in element 1345. Fabric 1310 may support corruption indicators. Various agent circuits, such as graphics unit 1375, compute complex 1320, etc., may detect data corruption and propagate corruption indicators. The disclosed techniques may advantageously improve memory reliability in various embodiments. Example Applications

[0130] Referring now to Figure 14, various types of systems are shown that may include any of the circuits, devices, or systems described above. Systems or devices 1400 that incorporate or otherwise utilize one or more of the techniques described herein may be utilized in a wide range of areas. For example, the systems or devices 1400 may be utilized as part of the hardware of a system such as a desktop computer 1410, a laptop computer 1420, a tablet computer 1430, a cellular or mobile phone 1440, or a television 1450 (or a set-top box coupled to a television).

[0131] Similarly, the disclosed elements may be utilized in a wearable device 1460 such as a smartwatch or health monitoring device. A smartwatch may implement a variety of different functions in many embodiments, e.g., access to email, cellular service, calendar, health monitoring, etc. A wearable device may also be designed to perform only health monitoring functions, such as monitoring a user's vital signs, performing epidemiological functions such as contact tracing, providing communications to emergency medical services, etc. Other types of devices are also contemplated, including devices worn around the neck, devices implantable in the human body, glasses or helmets designed to provide computer-generated reality experiences such as those based on augmented and / or virtual reality, etc.

[0132] The system or device 1400 may also be used in various other contexts. For example, the system or device 1400 may be utilized in the context of a server computer system, such as a dedicated server or shared hardware running cloud-based services 14130. Additionally, the system or device 1400 may be implemented in a wide range of dedicated everyday devices, including devices 1480 commonly found in the home, such as refrigerators, thermostats, security cameras, etc. The interconnection of such devices is often referred to as the "Internet of Things" (IoT). Elements may also be implemented in various forms of transportation. For example, the system or device 1400 may be used in the control systems, guidance systems, entertainment systems, etc. of various types of vehicles 1490.

[0133] 14 are merely examples and are not intended to limit potential future applications of the disclosed systems or devices. Other example applications include, but are not limited to, portable gaming devices, music players, data storage devices, unmanned aerial vehicles, etc. Exemplary Computer-Readable Medium

[0134] The present disclosure has described various exemplary circuits in more detail above. The present disclosure is intended to cover not only embodiments including such circuits, but also computer-readable storage media including design information specifying such circuits. Accordingly, the present disclosure is intended to support claims that cover not only apparatus including the disclosed circuits, but also storage media specifying the circuits in a format recognized by a manufacturing system configured to generate hardware (e.g., integrated circuits) including the disclosed circuits. Claims to such storage media are intended to cover entities that, for example, generate circuit designs but do not themselves manufacture the designs.

[0135] 15 is a block diagram illustrating an exemplary non-transitory computer-readable storage medium for storing circuit design information, according to some embodiments. In the illustrated embodiment, a semiconductor manufacturing system 1520 is configured to process design information 1515 stored in the non-transitory computer-readable medium 1510 and to manufacture an integrated circuit 1530 based on the design information 1515.

[0136] The non-transitory computer readable storage medium 1510 may include any of a variety of suitable types of memory or storage devices. The non-transitory computer readable storage medium 1510 may be an installation medium, such as a CD-ROM, a floppy disk or tape device, a computer system memory or random access memory such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, non-volatile memory such as flash, magnetic media, such as a hard drive, or optical storage device, registers, or other similar types of memory elements. The non-transitory computer readable storage medium 1510 may also include other types of non-transitory memory, or combinations thereof. The non-transitory computer readable storage medium 1510 may include two or more memory media that may be in different locations, such as different computer systems connected over a network.

[0137] The design information 1515 may be specified using any of a variety of suitable computer languages, including, but not limited to, hardware description languages ​​such as VHDL, Verilog, SystemC, SystemVerilog, RHDL, M, MyHDL, etc. The design information 1515 may be usable by semiconductor manufacturing systems 1520 to manufacture at least a portion of the integrated circuit 1530. The format of the design information 1515 may be recognized by at least one semiconductor manufacturing system 1520. In some embodiments, the design information 1515 may also include one or more cell libraries that specify the synthesis, layout, or both of the integrated circuit 1530. In some embodiments, the design information is specified, in whole or in part, in the form of a netlist that specifies the cell library elements and their connectivity. The design information 1515, alone, may or may not include information sufficient for the manufacture of a corresponding integrated circuit. For example, the design information 1515 may specify the circuit elements to be manufactured, but not their physical layout. In this case, the design information 1515 may need to be combined with layout information to actually manufacture the specified circuit.

[0138] The integrated circuit 1530 may, in various embodiments, include one or more custom macrocells, such as memory, analog, or mixed-signal circuits. In such cases, the design information 1515 may include information related to the included macrocells. Such information may include, but is not limited to, a schematic capture database, mask design data, behavioral models, and device or transistor level netlists. As used herein, mask design data may be formatted according to Graphics Data System (GDSII), or any other suitable format.

[0139] Semiconductor fabrication system 1520 may include any of a variety of suitable elements configured to fabricate integrated circuits. This may include, for example, elements for depositing semiconductor material (e.g., on a wafer, which may include masking) and removing material, changing the shape of deposited material, modifying material (e.g., by doping the material or by changing the dielectric constant using ultraviolet treatment), etc. Semiconductor fabrication system 1520 may also be configured to perform various tests of the fabricated circuits for correct operation.

[0140] In various embodiments, the integrated circuit 1530 is configured to operate according to a circuit design specified by the design information 1515, which may include performing any of the functions described herein. For example, the integrated circuit 1530 may include any of the various elements shown in Figures 1-8 or 13. Furthermore, the integrated circuit 1530 may be configured to perform various functions described herein in conjunction with other components. Furthermore, the functions described herein may be performed by multiple connected integrated circuits.

[0141] As used herein, phrases of the form "design information specifying a design of a circuit configured to..." do not imply that the subject circuit must be fabricated in order for the requirement to be satisfied. Rather, the phrase indicates that the design information describes a circuit that includes components that are configured or specified to perform a specified action when manufactured. ***

[0142] The present disclosure includes references to "one embodiment" or groupings of "embodiments" (e.g., "some embodiments" or "various embodiments"). Embodiments are different implementations or examples of the disclosed concepts. References to "one embodiment," "one embodiment," "particular embodiment," etc. do not necessarily refer to the same embodiment. Numerous possible embodiments, including those specifically disclosed, are contemplated, as well as modifications or alternatives that are within the spirit or scope of the present disclosure.

[0143] This disclosure may discuss potential advantages that may result from the disclosed embodiments. Not all implementations of these embodiments necessarily exhibit any or all of the potential advantages. Whether advantages are realized for a particular implementation depends on many factors, some of which are outside the scope of this disclosure. Indeed, there are many reasons why an implementation within the scope of the claims may not exhibit some or all of any disclosed advantages. For example, a particular implementation may include other circuitry outside the scope of this disclosure that, in conjunction with one of the disclosed embodiments, negates or reduces one or more of the disclosed advantages. Furthermore, suboptimal design practices of a particular implementation (e.g., implementation techniques or tools) may also negate or reduce the disclosed advantages. Even assuming skilled execution, realization of advantages may still depend on other factors, such as the environmental conditions in which the implementation is deployed. For example, inputs provided to a particular implementation may prevent one or more of the problems addressed in this disclosure from occurring on a particular occasion, such that the benefits of the solution may not be realized. Given the existence of factors external to the present disclosure that may arise, it is expressly intended that any potential advantages described herein should not be construed as claim limitations that must be met in order to demonstrate infringement. Rather, the identification of such potential advantages is intended to illustrate the type or types of improvement available to a designer having the benefit of the present disclosure. The fact that such advantages are permissibly described (e.g., a statement that a particular advantage "may result") is not intended to convey any doubt as to whether such advantage may actually be realized, but rather is intended to recognize the technological reality that realization of such advantages often depends on additional factors.

[0144] Unless otherwise stated, the embodiments are non-limiting. That is, the disclosed embodiments are not intended to limit the scope of the claims made based on this disclosure, even if only a single example is described with respect to a particular feature. The disclosed embodiments are intended to be illustrative, not limiting, unless otherwise stated in the disclosure. The above description is intended to enable claims that cover not only the disclosed embodiments, but also alternatives, modifications, and equivalents that will be apparent to those skilled in the art having the benefit of this disclosure.

[0145] For example, features of the present application may be combined in any suitable manner. Accordingly, new claims may be formulated during prosecution of this application (or an application claiming priority to this application) for any such combination of features. In particular, with reference to the appended claims, features from dependent claims may be combined with features of other dependent claims, including claims that are dependent on other independent claims, as appropriate. Similarly, features from each independent claim may be combined as appropriate.

[0146] Thus, the accompanying dependent claims may each be drafted to be dependent on a single other claim, although additional dependencies are also contemplated. Any combination of features in the dependent claims consistent with this disclosure is contemplated and may be claimed in this or another application. In summary, combinations are not limited to those specifically recited in the accompanying claims.

[0147] Where appropriate, it is contemplated that a claim drafted in one format or statutory type (e.g., apparatus) is also intended to support a corresponding claim in another format or statutory type (e.g., method). ***

[0148] Because this disclosure is a legal document, various terms and phrases may be subject to administrative and judicial interpretation. The definitions provided in the following paragraphs, as well as throughout this disclosure, are hereby publicly advised to be used in interpreting any claims made based on this disclosure.

[0149] Reference to a singular item (i.e., a noun or noun phrase preceded by "a," "an," or "the") is intended to mean "one or more" unless the context clearly indicates otherwise. Thus, a reference to an "item" in a claim does not exclude additional instances of the item without the context requiring otherwise. A "plurality" of an item refers to a set of two or more items.

[0150] The word "may" is used herein in a permissive sense (i.e., having the possibility, being able to) and not in an obligatory sense (i.e., not required).

[0151] The terms "comprising" and "including" and their forms are open ended and mean "including, but not limited to."

[0152] When the term "or" is used in this disclosure in reference to a list of alternatives, it will generally be understood to be used in an inclusive sense unless the context clearly indicates otherwise. Thus, a list of "x or y" is equivalent to "x or y, or both," and thus encompasses 1) x but not y, 2) y but not x, and 3) both x and y. On the other hand, the phrase "either x or y, but not both" makes it clear that "or" is used in an exclusive sense.

[0153] The enumeration of "w, x, y, z, or any combination thereof," or "at least one of ... w, x, y, and z" is intended to cover all possibilities including a single element up to the total number of elements in the set. For example, for the set [w, x, y, z], these expressions cover any single element of the set (e.g., w but not x, y, or z), any two elements (e.g., w and x but not y or z), any three elements (e.g., w, x, and y but not z), and all four elements. Thus, the phrase "at least one of ... w, x, y, and z" refers to at least one element of the set [w, x, y, z], thereby covering all possible combinations in this list of elements. This phrase should not be interpreted as requiring that there be at least one instance of w, at least one instance of x, at least one instance of y, and at least one instance of z.

[0154] In this disclosure, various "labels" may precede a noun or noun phrase. Unless the context clearly indicates otherwise, the various labels used for a feature (e.g., "first circuit," "second circuit," "particular circuit," "given circuit," etc.) refer to different instances of the feature. Furthermore, when applied to features, the labels "first," "second," and "third" do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) unless otherwise specified.

[0155] As used herein, the phrase "based on" is used to describe one or more factors that influence the determination. This term does not exclude the possibility that additional factors may influence the decision. That is, the decision may be based only on the specified factors or based on the specified factors as well as other unspecified factors. Consider the phrase "determining A based on B." This phrase specifies that B is a factor that is used to determine A or that influences the determination of A. This phrase does not exclude that the determination of A may also be based on some other factor, such as C. This phrase is intended to cover embodiments in which A is determined solely based on B. As used herein, the phrase "based on" is synonymous with the phrase "based at least in part on."

[0156] The phrases "in response to" and "in response to" recite one or more factors that trigger an effect. This phrase does not exclude the possibility that additional factors may affect or otherwise trigger the effect, either together with the particular factor or independent of the specified factor. That is, the effect may be in response only to these factors or to the specified factors as well as other unspecified factors. Consider the phrase "performing A in response to B." By this phrase, B is a factor that triggers the execution of A or triggers a particular outcome for A. This phrase does not exclude that the execution of A may also be in response to other factors, such as C. This phrase also does not exclude that the execution of A may be in response to both B and C. This phrase is intended to cover embodiments in which A is performed only in response to B. As used herein, the phrase "in response to" is synonymous with the phrase "at least partially in response to." Similarly, the phrase "in response to" is synonymous with the phrase "at least partially in response to." ***

[0157] Within this disclosure, various entities (which may be variously referred to as "units," "circuits," other components, etc.) may be described or claimed as being "configured" to perform one or more tasks or operations. The phrase "entity" configured to perform one or more tasks is used herein to refer to structures (i.e., physical things). More specifically, the phrase is used to indicate that the structure is arranged to perform one or more tasks during operation. A structure may be said to be "configured to perform" some task even if the structure is not currently operating. Thus, an entity described or explained as being "configured" to perform some task refers to a physical thing, such as a device, a circuit, a system having a processor unit and a memory that stores executable program instructions to perform the task. The phrase is not used herein to refer to intangible things.

[0158] In some cases, various units / circuits / components may be described herein as performing a set of tasks or operations, and even if not specifically described, it will be understood that those entities are "configured to" perform those tasks / operations.

[0159] The term "configured to" is not intended to mean "configurable to." For example, an unprogrammed FPGA is not considered to be "configured" to perform a particular function. However, this unprogrammed FPGA may be "configurable" to perform that function. After appropriate programming, the FPGA can then be said to be "configured" to perform a particular function.

[0160] For purposes of filing a U.S. patent application based on this disclosure, reciting a claim as a structure "configured to" perform one or more tasks is not expressly intended to invoke 35 U.S.C. §112(f) for that claim element. If an applicant wishes to invoke 35 U.S.C. §112(f) during prosecution of a U.S. patent application based on this disclosure, it would be to recite a claim element using "means for [performing a function]."

[0161] Various "circuits" may be described in this disclosure. These circuits or "circuitry" constitute hardware including various types of circuit elements such as combinational logic, clocked storage devices (e.g., flip-flops, registers, latches, etc.), finite state machines, memories (e.g., random access memory, embedded dynamic random access memory), programmable logic arrays, etc. Circuits may be custom designed or obtained from standard libraries. In various implementations, circuitry may include digital components, analog components, or a combination of both, as appropriate. Certain types of circuits may be generally referred to as "units" (e.g., decoding units, arithmetic logic units (ALUs), functional units, memory management units (MMUs), etc.). Such units may also be referred to as circuits or circuitry.

[0162] The disclosed circuits / units / components and other elements shown in the drawings and described herein include hardware elements such as those described in the preceding paragraphs. Often, the internal arrangement of hardware elements within a particular circuit may be specified by describing the function of that circuit. For example, a particular "decode unit" may be described as performing the function of "processing the opcode of an instruction and routing the instruction to one or more of a plurality of functional units," meaning that the decode unit is "configured" to perform this function. Description of this function is sufficient to suggest to one skilled in the computer arts a set of possible configurations of the circuit.

[0163] In various embodiments, as discussed in the previous paragraph, circuits, units, and other elements may be defined by the functions or operations they are configured to perform. The arrangement of such circuits / units / components relative to one another and the way in which they interact will ultimately generate a microarchitectural definition of the hardware that is fabricated in an integrated circuit or programmed into an FPGA to form the physical implementation of the microarchitectural definition. Thus, a microarchitectural definition is recognized by those skilled in the art as a structure from which many physical implementations may be derived, all of which belong to the broader structure described by the microarchitectural definition. That is, a person skilled in the art presented with a microarchitectural definition provided in accordance with this disclosure may, without undue experimentation, use ordinary skill to implement the structure by coding the description of the circuit / unit / component into a hardware description language (HDL), such as Verilog or VHDL. HDL descriptions are often expressed in a manner that appears to be functional. However, to those skilled in the art, this HDL description is the method used to translate the structure of the circuit, unit, or component into the next level of implementation details. Such HDL descriptions may take the form of behavioral level code (typically not synthesizable), register transfer language (RTL) code (typically synthesizable, as opposed to behavioral level code), or structural code (e.g., a netlist specifying logic gates and their connections). The HDL description may be synthesized against a library of cells designed for a given integrated circuit manufacturing technology, and modified for timing, power, and other reasons, resulting in a final design database that can be sent to a foundry to generate masks and ultimately manufacture the integrated circuit. Some hardware circuits, or portions thereof, may also be custom designed in a schematic editor and incorporated into the integrated circuit design along with the synthesized circuit. The integrated circuit may further include transistors and other circuit elements (e.g., passive elements such as capacitors, resistors, inductors, etc.), as well as interconnects between the transistors and the circuit elements.Some embodiments may implement multiple integrated circuits connected together to realize the hardware circuit, and / or some embodiments may use discrete elements. Alternatively, the HDL design may be integrated into and implemented in a programmable logic array, such as a field programmable gate array (FPGA). This decoupling between the design of a group of circuits and the subsequent low-level implementation of those circuits typically results in a scenario where the circuit or logic designer does not specify any particular set of structures for the low-level implementation other than describing how the circuit is structured, since this process is performed at a different stage in the circuit implementation process.

[0164] The fact that many different low-level combinations of circuit elements can be used to implement the same specification for a circuit results in numerous equivalent structures for that circuit. As noted above, these low-level circuit implementations may vary depending on changes in manufacturing technology, the foundry selected to manufacture the integrated circuit, the libraries of cells provided for a particular project, etc. In many cases, the choices made by different design tools or methods to generate these different implementations may be arbitrary.

[0165] Furthermore, for a given embodiment, it is common for a single implementation of a particular functional specification of a circuit to include a large number of devices (e.g., millions of transistors). This absolute amount of information therefore makes it impractical to exhaustively enumerate the low-level structures used to implement a single embodiment, let alone the vast amount of equivalent possible implementations. For this reason, this disclosure describes the structure of a circuit using functional abbreviations used in the industry.

Claims

1. An apparatus comprising: one or more agent circuits; a memory controller circuit, the memory controller circuit comprising: communicating with a memory circuit via an interface, the memory circuit supporting error detection for the interface that results in the writing of a combination of data and parity to a target memory location for a detected uncorrectable write interface error, the combination corresponding to a non-correctable error; arbitrating between requests to access the memory circuit from requesting agent circuits, the requesting agent circuit including a first request to write first data to a first location within the memory circuit; maintaining a corruption indicator for the data block, the corruption indicator including a first corruption indicator indicating that the first data has been determined to be corrupt; transmitting a combination of data and parity for the first data block over the interface that causes the memory circuit to detect an uncorrectable write interface error; an apparatus configured to read the memory location following the write for the first request, and in response to a report of an uncorrectable error from the memory circuit for the read data, generate a corruption indicator for the read data.

2. The apparatus of claim 1 , wherein one of the agent circuits is configured to generate the first damage indicator.

3. Propagating the corruption indicator after merging one or more requirements to resolve the hazard; and Propagating a corruption indicator for a write-to-read transfer operation from the write queue; and 10. The apparatus of claim 1, configured to maintain the corruption indicator through multiple operations, including converting the corruption indicator to a forced uncorrectable write interface error.

4. The plurality of operations include: communicating a corruption indicator to said memory controller circuit by a memory cache controller circuit; and propagating the corruption indicator based on the address mask.

5. The memory controller circuit includes: detecting a corrected error indicated by the memory circuit having incorrect data still stored in a memory cell of the memory circuit; initiating a demand scrub write operation to the memory circuit in response to detecting the corrected error, causing an internal read, error correction of the correctable error, and writing of the corrected data to the memory circuit; The apparatus of claim 1 , further comprising a demand scrub circuit configured to:

6. 6. The apparatus of claim 5, wherein the write operation is a full masked partial write operation to the DRAM address where the corrected error was detected.

7. The demand scrub circuitry stores in one or more software accessible registers: the number of correctable errors detected; and The apparatus of claim 5 , configured to record a number of successful demand scrub writes.

8. 6. The apparatus of claim 5, wherein the detection of the corrected errors is based on a decoding status flag reported by the memory circuit that indicates whether the provided data has no errors, has correctable errors, or has uncorrectable errors.

9. The apparatus of claim 1 , wherein the memory circuitry implements both link error correction and on-die error correction.

10. The memory circuit further includes: For a write operation, Check the parity information of the written data for errors, correcting a detected correctable error associated with the interface; For a read operation, correcting the detected errors associated with said read locations; 2. The apparatus of claim 1, further comprising an error circuit configured to report detected uncorrectable errors associated with the read location via the interface.

11. The memory circuit; a central processing unit configured to access the memory circuit through the memory controller circuit; The apparatus of claim 1 , further comprising: a network interface circuit.

12. 1. A method comprising: communicating with a memory circuit via an interface, by a memory controller circuit, the memory circuit supporting error detection for the interface that results in writing a combination of data and parity to a target memory location for a detected uncorrectable write interface error, the combination corresponding to a non-correctable error; arbitrating, by the memory controller circuit, between requests to access the memory circuit from requesting agent circuits, the requesting agent circuit including a first request to write first data to a first location within the memory circuit; maintaining corruption indicators for the data block, the corruption indicator including a first corruption indicator indicating that the first data has been determined to be corrupted by the memory controller circuit; transmitting, by the memory controller circuit, a combination of data and parity for the first data block over the interface, the combination causing the memory circuit to detect an uncorrectable write interface error; following the write for the first request, the memory controller circuitry reads the memory location and in response to a report of an uncorrectable error from the memory circuitry for the read data, generates a corruption indicator for the read data.

13. and maintaining, by an apparatus including the memory controller circuit, a corruption indicator through a plurality of operations, the plurality of operations comprising: Propagating the corruption indicator after merging one or more requirements to resolve the hazard; and Propagating a corruption indicator for a write-to-read transfer operation from the write queue; and and converting the corruption indicator to a forced uncorrectable write interface error.

14. detecting, by a demand scrub circuit, a corrected error indicated by said memory circuit having incorrect data still stored in a memory cell of said memory circuit; 13. The method of claim 12, further comprising: in response to detecting a corrected error, the demand scrub circuitry initiates a demand scrub write operation to the memory circuit that causes an internal read, error correction of the correctable error, and writing of the corrected data to the memory circuit.

15. 15. The method of claim 14, wherein the write operation is a full masked partial write operation to the DRAM address where the corrected error was detected.

16. A circuit comprising: one or more agent circuits; and a memory controller circuit; The memory controller circuit includes: communicating with a memory circuit via an interface, the memory circuit supporting error detection for the interface that results in the writing of a combination of data and parity to a target memory location for a detected uncorrectable write interface error, the combination corresponding to a non-correctable error; receiving a request to access the memory circuit from a requesting agent circuit, the request including a first request to write first data to a first location within the memory circuit; maintaining a corruption indicator for the data block, the corruption indicator including a first corruption indicator indicating that the first data has been determined to be corrupt; transmitting a combination of data and parity for the first data block over the interface that causes the memory circuit to detect an uncorrectable write interface error; a circuit configured to read the memory location following the write for the first request, and to generate a corruption indicator for the read data in response to a report of an uncorrectable error from the memory circuit for the read data.

17. The circuit of claim 16 , wherein one of the agent circuits is configured to generate the first corruption indicator.

18. The circuit is configured to maintain the failure indicator through a plurality of operations, the plurality of operations comprising: Propagating the corruption indicator after merging one or more requirements to resolve the hazard; and Propagating a corruption indicator for a write-to-read transfer operation from the write queue; and converting the corruption indicator to a forced uncorrectable write interface error; communicating a corruption indicator to said memory controller circuit by a memory cache controller circuit; and propagating the corruption indicator based on the address mask.

19. The memory controller circuit includes: Detecting corrected errors indicated by said memory circuit in which incorrect data is still stored in memory cells of said memory circuit. initiating a demand scrub write operation to the memory circuit in response to detecting the corrected error, causing an internal read, error correction of the correctable error, and writing the corrected data to the memory circuit; 20. The circuit of claim 16, comprising a demand scrub circuit configured to:

20. 20. The circuit of claim 19, wherein detection of the corrected errors is based on a decoding status flag reported by the memory circuit that indicates whether the provided data has no errors, has correctable errors, or has uncorrectable errors.

Images