Internal error checking and correction (ECC) with extra system bits

A memory subsystem includes a data bus to couple a memory controller to one or more memory devices. The memory controller and one or more memory devices transfer data for memory access operations. The data transfer includes the transfer of data bits and associated check bits over a transfer cycle burst. The memory devices include internal error checking and correction (ECC) separate from the system ECC managed by the memory controller. With a 2N transfer cycle for 2{circumflex over ( )}N data bits for a memory device, the memory devices can provide up to 2N memory locations for N+1 internal check bits, which can leave up to (2N minus (N+1)) extra bits to be used by the system for more robust ECC.

CLAIM OF PRIORITY

This application is a U.S. National Phase application under 35 U.S.C. § 371 of International Application No. PCT/US17/30695, filed May 2, 2017, entitled “INTERNAL ERROR CHECKING AND CORRECTION (ECC) WITH EXTRA SYSTEM BITS”, which in turn is based on U.S. 62/330,338, entitled, “INTERNAL ERROR CHECKING AND CORRECTION (ECC) WITH EXTRA SYSTEM BITS”, the entire contents of which are incorporated herein by reference. The present application claims the benefit of priority of these applications.

FIELD

The descriptions are generally related to memory devices, and more particular descriptions are related to error checking and correction within memory systems.

Portions of the disclosure of this patent document may contain material that is subject to copyright protection. The copyright owner has no objection to the reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. The copyright notice applies to all data as described below, and in the accompanying drawings hereto, as well as to any software described below: Copyright © 2016, 2017, Intel Corporation, All Rights Reserved.

BACKGROUND

Memory devices continue to be an essential part of electronic devices and computer systems. Memory densities continue to increase as feature geometries shrink, but scaling to smaller geometries continues to increase the number of errors in memories. One technique for addressing memory errors is to employ ECC (error checking and correction, which may also be referred to as error correction coding). Traditionally a memory controller performs error detection and correction, including generating check bits to send with data, which the memory device stores on a write operation and returns on a read operation. When the memory controller performs the error correction, the memory controller and memory devices exchange the ECC bits or check bits, which increases the bandwidth of the data bus (e.g., increase a channel from 64 bits or signal lines to 72, or from 32 bits or signal lines to 36). Increasing numbers of ECC bits would be needed to continue to meet RAS (reliability, accessibility, and serviceability) expectations in modern memory subsystems, which suggests increasing the data bus width with more signal lines to accommodate additional ECC bits needed to perform higher levels of error correction. However, increasing the bus width increases costs and consumes additional power.

Descriptions of certain details and implementations follow, including a description of the figures, which may depict some or all of the embodiments described below, as well as discussing other potential embodiments or implementations of the inventive concepts presented herein.

DETAILED DESCRIPTION

As described herein, the application of error checking and correction (ECC) can scale per channel without increasing the overhead required for the application of ECC. The scaling of the ECC allows providing more check bits to apply a higher level of ECC without increasing the channel width. In one embodiment, higher levels of ECC can be provided without increasing the percentage of total bandwidth used for check bits relative to traditional ECC approaches. There is a logarithmic relationship between the number of bits required to provide ECC and the number of bits being protected by ECC. For example, if B+1 check bits are used for single error correction (SEC) for 2{circumflex over ( )}B data bits (for example, 8 check bits for 128 (2{circumflex over ( )}7) data bits), twice as many data bits (2{circumflex over ( )}(B+1) data bits) can be protected with SEC with B+2 check bits (for example, 9 check bits for 256 data bits).

It will be understood that ECC is also commonly used as an acronym for error correction coding or error correction codes. Error correction codes refer to the codes used to perform computations. Error correction coding may be used interchangeably with error checking and correction, where error checking and correction refers to the process of using one or more codes to generate check bits, or using check bits to verify the validity of data, or a combination. Error checking and correction is to be understood in an expansive sense of checking for and potentially correcting detected errors, and ECC can be generally understood to refer to error checking and correction.

ECC operations can be performed in accordance with an ECC algorithm, referring to a series or sequence of consecutive operations to perform ECC. An ECC algorithm includes computations to generate ECC bits or use the bits to determine the validity of data or a combination. Typically, ECC logic performs ECC operations. The ECC logic can include ECC circuitry that performs computations. ECC bits or check bits refer to the ECC code for validating data or a codeword. Typical ECC operations include a series of XOR (exclusive OR) operations on a codeword with corresponding ECC bits to generate an expected result.

A traditional approach to data transfer in memory systems is to send 128 data bits in a burst of 8 transfer cycles (or burst length 8 (BL8)). It will be understood that 8 check bits can be transferred one per transfer cycle or unit interval (UI) of the memory access transaction. In a configuration where, for example, 16×4 memory devices are coupled in parallel, each device may contribute 64 bits of a total 512 data bits, with two extra devices being used to provide an additional 64 bits of ECC and system metadata, for a total of 576 bits transferred between a host and the group of memory devices. Increasing to BL16 would provide for 128 data bits from each ×4 memory device, which is twice the traditional 64 bits, which can reduce the number of devices required on a channel from 16+2 to 8+1 for the same number of bits. However, by reducing the number of memory devices in half, extra ECC or metadata or a combination of ECC and metadata would be needed to provide the same level of ECC protection, such as being able to recover from a full device failure.

It will be understood that more robust ECC operations require additional system bits, which cannot be provided in the traditional scenario without increasing the overhead to include another memory device (in the implementation described above, there would be 8+2 memory devices). As such, a memory controller can generate more check bits to transmit with the data bits on a write operation, and receive the check bits back on a read operation. However, with a traditional approach, the added overhead of the extra device and the additional 64 bits in the BL16 implementation is more than is necessary to provide similar ECC protection as in the case of 16+2 memory devices for BL8.

In one embodiment, the memory devices are capable of performing on-die or internal ECC, where the memory device itself includes ECC logic to perform ECC at the memory device separate from the ECC managed by the memory controller. On-die ECC refers to ECC operations where the memory device itself generates and stores check bits for write data, and applies the check bits to correct data prior to sending the data to the memory controller for read data. Thus, there is a distinction between ECC where the memory controller generates and checks the check bits, and where the memory device itself performs the checking. It will be understood that where a memory device performs internal or on-die ECC, the memory controller does not have visibility into the internal check bits, and may not even know if an error was corrected.

In one embodiment, a memory device applies internal ECC with 9 bits for 256 data bits. The closest binary number larger than 9 is 16, which means the memory device can provide or allocate 16 bits for ECC information, and only needs 9. In one embodiment, the memory device can provide access to the memory controller to up to the 7 extra bits for system ECC information or metadata or a combination. While the example of 9 bits for 256, and 16 bits is provided, in general the memory device can provide up to (2N minus (N+1)) extra bits based on a 2N transfer cycle for 2{circumflex over ( )}N data bits within the memory device, based on the memory device using or allocating 2N memory locations for N+1 internal check bits for on-die ECC. It will be understood that the approach may be generally applicable to a system in which N is greater than 1.

Thus, in one embodiment a system enables the use of extra system bits in memory access operations for memory devices with on-memory or on-die ECC. Extra system bits refer to bits that can be stored in a memory device and exchanged with a memory controller for purposes of operation of the hardware platform. The exchange of data can occur with either a read memory access operation or a write memory access operation. The exchange for a read operation can refer to an operation where a memory device fetches and transmits data to a memory controller in response to a read access request. The exchange of data can also refer to a write operation where the memory controller provides data to the memory device to store in its memory array(s).

System-level bits can be understood as data bits used as metadata within the hardware components of a system (e.g., the hardware platform) to control or enhance, or both, the operations of the hardware components. In one embodiment, system-level bits are not controlled by the host operating system (OS), and may not even be visible to the host OS that provides a software platform for the execution of applications in a general purpose operation of a computing device. In one embodiment, the exchange and use of the system-level bits described is limited to operation of the memory subsystem.

In one embodiment, in addition to on-die ECC, a memory device can store additional system bits, which can be accessed by the memory controller to perform platform-level system operations. In one embodiment, the memory controller can access the system bits but not the internal ECC bits. In one embodiment, the memory device protects the system ECC bits from corruption by applying the on-die ECC bits to both the data bits and the system ECC bits. In one embodiment, the memory device does not perform internal ECC operations on the extra system bits. In an alternate embodiment, the memory can perform internal ECC operations on the extra system bits. In one embodiment, the system architecture provides for up to 2 system bits per 64 data bits, where some exchanges may include 1 extra system bit, and other exchanges may include 2 extra system bits. In one embodiment, the system bit exchange occurs on a separate data signal line or separate lane from the data bus. In one embodiment, system bit exchange on a separate lane is provided with slower signals than the data signals. Thus, a system bit exchange can span multiple UIs instead of sending a data bit in every UI of an access transaction. In one embodiment, the system bit exchange occurs in a separate UI after a typical data transaction burst length (e.g., a 17th UI after 16 UIs of data transfer for the read/write transaction for a BL16 implementation).

FIG. 1is a block diagram of an embodiment of a system with memory that exchanges extra system bits with traditional ECC bits. System100includes a processor and elements of a memory subsystem in a computing device. Processor110represents a processing unit of a computing platform that may execute an operating system (OS) and applications, which can collectively be referred to as the host or the user of the memory. The OS and applications execute operations that result in memory accesses. Processor110can include one or more separate processors. Each separate processor can include a single processing unit, a multicore processing unit, or a combination. The processing unit can be a primary processor such as a CPU (central processing unit), a peripheral processor such as a GPU (graphics processing unit), or a combination. Memory accesses may also be initiated by devices such as a network controller or hard disk controller. Such devices can be integrated with the processor in some systems or attached to the processer via a bus (e.g., PCI express), or a combination. System100can be implemented as an SOC (system on a chip), or be implemented with standalone components.

Reference to memory devices can apply to different memory types. Memory devices often refers to volatile memory technologies. Volatile memory is memory whose state (and therefore the data stored on it) is indeterminate if power is interrupted to the device. Nonvolatile memory refers to memory whose state is determinate even if power is interrupted to the device. Dynamic volatile memory requires refreshing the data stored in the device to maintain state. One example of dynamic volatile memory includes DRAM (dynamic random access memory), or some variant such as synchronous DRAM (SDRAM). A memory subsystem as described herein may be compatible with a number of memory technologies, such as DDR3 (double data rate version 3, original release by JEDEC (Joint Electronic Device Engineering Council) on Jun. 27, 2007, currently on release 21), DDR4 (DDR version 4, initial specification published in September 2012 by JEDEC), DDR4E (DDR version 4, extended, currently in discussion by JEDEC), LPDDR3 (low power DDR version 3, JESD209-3B, August 2013 by JEDEC), LPDDR4 (low power DDR version 4, JESD209-4, originally published by JEDEC in August 2014), WIO2 (Wide I/O 2 (WideIO2), JESD229-2, originally published by JEDEC in August 2014), HBM (high bandwidth memory DRAM, JESD235, originally published by JEDEC in October 2013), DDR5 (DDR version 5, currently in discussion by JEDEC), LPDDR5 (currently in discussion by JEDEC), HBM2 (HBM version 2), currently in discussion by JEDEC), or others or combinations of memory technologies, and technologies based on derivatives or extensions of such specifications.

In addition to, or alternatively to, volatile memory, in one embodiment, reference to memory devices can refer to a nonvolatile memory device whose state is determinate even if power is interrupted to the device. In one embodiment, the nonvolatile memory device is a block addressable memory device, such as NAND or NOR technologies. Thus, a memory device can also include a future generation nonvolatile devices, such as a three dimensional crosspoint memory device, other byte addressable nonvolatile memory devices, or memory devices that use chalcogenide phase change material (e.g., chalcogenide glass). In one embodiment, the memory device can be or include multi-threshold level NAND flash memory, NOR flash memory, single or multi-level phase change memory (PCM) or phase change memory with a switch (PCMS), a resistive memory, nanowire memory, ferroelectric transistor random access memory (FeTRAM), magnetoresistive random access memory (MRAM) memory that incorporates memristor technology, or spin transfer torque (STT)-MRAM, or a combination of any of the above, or other memory.

Descriptions herein referring to a “RAM” or “RAM device” can apply to any memory device that allows random access, whether volatile or nonvolatile. Descriptions referring to a “DRAM” or a “DRAM device” can refer to a volatile random access memory device. The memory device or DRAM can refer to the die itself, to a packaged memory product that includes one or more dies, or both. In one embodiment, a system with volatile memory that needs to be refreshed can also include nonvolatile memory.

Memory controller120represents one or more memory controller circuits or devices for system100. Memory controller120represents control logic that generates memory access commands in response to the execution of operations by processor110. Memory controller120accesses one or more memory devices140. Memory devices140can be DRAM devices in accordance with any referred to above. In one embodiment, memory devices140are organized and managed as different channels, where each channel couples to buses and signal lines that couple to multiple memory devices in parallel. Each channel is independently operable. Thus, each channel is independently accessed and controlled, and the timing, data transfer, command and address exchanges, and other operations are separate for each channel. As used herein, coupling can refer to an electrical coupling, communicative coupling, physical coupling, or a combination of these. Physical coupling can include direct contact. Electrical coupling includes an interface or interconnection that allows electrical flow between components, or allows signaling between components, or both. Communicative coupling includes connections, including wired or wireless, that enable components to exchange data.

In one embodiment, settings for each channel are controlled by separate mode registers or other register settings. In one embodiment, each memory controller120manages a separate memory channel, although system100can be configured to have multiple channels managed by a single controller, or to have multiple controllers on a single channel. In one embodiment, memory controller120is part of host processor110, such as logic implemented on the same die or implemented in the same package space as the processor.

Memory controller120includes I/O interface logic122to couple to a memory bus, such as a memory channel as referred to above. I/O interface logic122(as well as I/O interface logic142of memory device140) can include pins, pads, connectors, signal lines, traces, or wires, or other hardware to connect the devices, or a combination of these. I/O interface logic122can include a hardware interface. As illustrated, I/O interface logic122includes at least drivers/transceivers for signal lines. Commonly, wires within an integrated circuit interface couple with a pad, pin, or connector to interface signal lines or traces or other wires between devices. I/O interface logic122can include drivers, receivers, transceivers, or termination, or other circuitry or combinations of circuitry to exchange signals on the signal lines between the devices. The exchange of signals includes at least one of transmit or receive. While shown as coupling I/O122from memory controller120to I/O142of memory device140, it will be understood that in an implementation of system100where groups of memory devices140are accessed in parallel, multiple memory devices can include I/O interfaces to the same interface of memory controller120. In an implementation of system100including one or more memory modules170, I/O142can include interface hardware of the memory module in addition to interface hardware on the memory device itself. Other memory controllers120will include separate interfaces to other memory devices140.

The bus between memory controller120and memory devices140can be implemented as multiple signal lines coupling memory controller120to memory devices140. The bus may typically include at least clock (CLK)132, command/address (CMD)134, and write data (DQ) and read DQ136, and zero or more other signal lines138. In one embodiment, a bus or connection between memory controller120and memory can be referred to as a memory bus. The signal lines for CMD can be referred to as a “C/A bus” (or ADD/CMD bus, or some other designation indicating the transfer of commands (C or CMD) and address (A or ADD) information) and the signal lines for write and read DQ can be referred to as a “data bus.” In one embodiment, independent channels have different clock signals, C/A buses, data buses, and other signal lines. Thus, system100can be considered to have multiple “buses,” in the sense that an independent interface path can be considered a separate bus. It will be understood that in addition to the lines explicitly shown, a bus can include at least one of strobe signaling lines, alert lines, auxiliary lines, or other signal lines, or a combination. It will also be understood that serial bus technologies can be used for the connection between memory controller120and memory devices140. An example of a serial bus technology is 8B10B encoding and transmission of high-speed data with embedded clock over a single differential pair of signals in each direction. In one embodiment, CMD134represents signal lines shared in parallel with multiple memory devices. In one embodiment, multiple memory devices share encoding command signal lines of CMD134, and each has a separate chip select (CS_n) signal line to select individual memory devices.

It will be understood that in the example of system100, the bus between memory controller120and memory devices140includes a subsidiary command bus CMD134and a subsidiary bus to carry the write and read data, DQ136. In one embodiment, the data bus can include bidirectional lines for read data and for write/command data. In another embodiment, the subsidiary bus DQ136can include unidirectional write signal lines for write and data from the host to memory, and can include unidirectional lines for read data from the memory to the host. In accordance with the chosen memory technology and system design, other signals138may accompany a bus or sub bus, such as strobe lines DQS. Based on design of system100, or implementation if a design supports multiple implementations, the data bus can have more or less bandwidth per memory device140. For example, the data bus can support memory devices that have either a ×32 interface, a ×16 interface, a ×8 interface, or other interface. The convention “×W,” where W is an integer that refers to an interface size or width of the interface of memory device140, which represents a number of signal lines to exchange data with memory controller120. The interface size of the memory devices is a controlling factor on how many memory devices can be used concurrently per channel in system100or coupled in parallel to the same signal lines. In one embodiment, high bandwidth memory devices, wide interface devices, or stacked memory configurations, or combinations, can enable wider interfaces, such as a ×128 interface, a ×256 interface, a ×512 interface, a ×1024 interface, or other data bus interface width.

In one embodiment, memory devices140and memory controller120exchange data over the data bus in a burst, or a sequence of consecutive data transfers. The burst corresponds to a number of transfer cycles, which is related to a bus frequency. In one embodiment, the transfer cycle can be a whole clock cycle for transfers occurring on a same clock or strobe signal edge (e.g., on the rising edge). In one embodiment, every clock cycle, referring to a cycle of the system clock, is separated into multiple unit intervals (UIs), where each UI is a transfer cycle. For example, double data rate transfers trigger on both edges of the clock signal (e.g., rising and falling). A burst can last for a configured number of UIs, which can be a configuration stored in a register, or triggered on the fly. For example, a sequence of eight consecutive transfer periods can be considered a burst length 8 (BL8), and each memory device140can transfer data on each UI. Thus, a ×8 memory device operating on BL8 can transfer 64 bits of data (8 data signal lines times 8 data bits transferred per line over the burst). It will be understood that this simple example is merely an illustration and is not limiting.

Memory devices140represent memory resources for system100. In one embodiment, each memory device140is a separate memory die. In one embodiment, each memory device140can interface with multiple (e.g., 2) channels per device or die. Each memory device140includes I/O interface logic142, which has a bandwidth determined by the implementation of the device (e.g., ×16 or ×8 or some other interface bandwidth). I/O interface logic142enables the memory devices to interface with memory controller120. I/O interface logic142can include a hardware interface, and can be in accordance with I/O122of memory controller, but at the memory device end. In one embodiment, multiple memory devices140are connected in parallel to the same command and data buses. In another embodiment, multiple memory devices140are connected in parallel to the same command bus, and are connected to different data buses. For example, system100can be configured with multiple memory devices140coupled in parallel, with each memory device responding to a command, and accessing memory resources160internal to each. For a Write operation, an individual memory device140can write a portion of the overall data word, and for a Read operation, an individual memory device140can fetch a portion of the overall data word. As non-limiting examples, a specific memory device can provide or receive, respectively, 8 bits of a 128-bit data word for a Read or Write transaction, or 4 bits or 8 bits or 16 bits (depending on whether it is a ×4 or a ×8 or a ×16 device) of a 256-bit data word. The remaining bits of the word will be provided or received by other memory devices in parallel.

In one embodiment, memory devices140are disposed directly on a motherboard or host system platform (e.g., a PCB (printed circuit board) on which processor110is disposed) of a computing device. In one embodiment, memory devices140can be organized into memory modules170. In one embodiment, memory modules170represent dual inline memory modules (DIMMs). In one embodiment, memory modules170represent other organization of multiple memory devices to share at least a portion of access or control circuitry, which can be a separate circuit, a separate device, or a separate board from the host system platform. Memory modules170can include multiple memory devices140, and the memory modules can include support for multiple separate channels to the included memory devices disposed on them. In another embodiment, memory devices140may be incorporated into the same package as memory controller120, such as by techniques such as multi-chip-module (MCM), package-on-package, through-silicon VIA (TSV), or other techniques or combinations. Similarly, in one embodiment, multiple memory devices140may be incorporated into memory modules170, which themselves may be incorporated into the same package as memory controller120. It will be appreciated that for these and other embodiments, memory controller120may be part of host processor110.

Memory devices140each include memory resources160. Memory resources160represent individual arrays of memory locations or storage locations for data. Typically memory resources160are managed as rows of data, accessed via wordline (rows) and bitline (individual bits within a row) control. Memory resources160can be organized as separate channels, ranks, and banks of memory. Channels may refer to independent control paths to storage locations within memory devices140. Ranks may refer to common locations across multiple memory devices (e.g., same row addresses within different devices). Banks may refer to arrays of memory locations within a memory device140. In one embodiment, banks of memory are divided into sub-banks with at least a portion of shared circuitry (e.g., drivers, signal lines, control logic) for the sub-banks. It will be understood that channels, ranks, banks, sub-banks, bank groups, or other organizations of the memory locations, and combinations of the organizations, can overlap in their application to physical resources. For example, the same physical memory locations can be accessed over a specific channel as a specific bank, which can also belong to a rank. Thus, the organization of memory resources will be understood in an inclusive, rather than exclusive, manner.

In one embodiment, memory devices140include one or more registers144. Register144represents one or more storage devices or storage locations that provide configuration or settings for the operation of the memory device. In one embodiment, register144can provide a storage location for memory device140to store data for access by memory controller120as part of a control or management operation. In one embodiment, register144includes one or more Mode Registers. In one embodiment, register144includes one or more multipurpose registers. The configuration of locations within register144can configure memory device140to operate in different “mode,” where command information can trigger different operations within memory device140based on the mode. Additionally or in the alternative, different modes can also trigger different operation from address information or other signal lines depending on the mode. Settings of register144can indicate configuration for I/O settings (e.g., timing, termination or ODT (on-die termination)146, driver configuration, or other I/O settings).

In one embodiment, memory device140includes ODT146as part of the interface hardware associated with I/O142. ODT146can be configured as mentioned above, and provide settings for impedance to be applied to the interface to specified signal lines. In one embodiment, ODT146is applied to DQ signal lines. In one embodiment, ODT146is applied to command signal lines. In one embodiment, ODT146is applied to address signal lines. In one embodiment, ODT146can be applied to any combination of the preceding. The ODT settings can be changed based on whether a memory device is a selected target of an access operation or a non-target device. ODT146settings can affect the timing and reflections of signaling on the terminated lines. Careful control over ODT146can enable higher-speed operation with improved matching of applied impedance and loading. ODT146can be applied to specific signal lines of I/O interface142,122, and is not necessarily applied to all signal lines.

Memory device140includes controller150, which represents control logic within the memory device to control internal operations within the memory device. For example, controller150decodes commands sent by memory controller120and generates internal operations to execute or satisfy the commands. Controller150can be referred to as an internal controller, and is separate from memory controller120of the host. Controller150can determine what mode is selected based on register144, and configure the internal execution of operations for access to memory resources160or other operations based on the selected mode. Controller150generates control signals to control the routing of bits within memory device140to provide a proper interface for the selected mode and direct a command to the proper memory locations or addresses. Controller150includes command logic152, which can decode command encoding received on command and address signal lines. Thus, command logic152can be or include a command decoder. With command logic152, memory device can identify commands and generate internal operations to execute requested commands.

Referring again to memory controller120, memory controller120includes scheduler130, which represents logic or circuitry to generate and order transactions to send to memory device140. From one perspective, the primary function of memory controller120could be said to schedule memory access and other transactions to memory device140. Such scheduling can include generating the transactions themselves to implement the requests for data by processor110and to maintain integrity of the data (e.g., such as with commands related to refresh). Transactions can include one or more commands, and result in the transfer of commands or data or both over one or multiple timing cycles such as clock cycles or unit intervals. Transactions can be for access such as read or write or related commands or a combination, and other transactions can include memory management commands for configuration, settings, data integrity, or other commands or a combination.

Memory controller120typically includes logic to allow selection and ordering of transactions to improve performance of system100. Thus, memory controller120can select which of the outstanding transactions should be sent to memory device140in which order, which is typically achieved with logic much more complex that a simple first-in first-out algorithm. Memory controller120manages the transmission of the transactions to memory device140, and manages the timing associated with the transaction. In one embodiment, transactions have deterministic timing, which can be managed by memory controller120and used in determining how to schedule the transactions.

Referring again to memory controller120, memory controller120includes command (CMD) logic124, which represents logic or circuitry to generate commands to send to memory devices140. The generation of the commands can refer to the command prior to scheduling, or the preparation of queued commands ready to be sent. Generally, the signaling in memory subsystems includes address information within or accompanying the command to indicate or select one or more memory locations where the memory devices should execute the command. In response to scheduling of transactions for memory device140, memory controller120can issue commands via I/O122to cause memory device140to execute the commands. In one embodiment, controller150of memory device140receives and decodes command and address information received via I/O142from memory controller120. Based on the received command and address information, controller150can control the timing of operations of the logic and circuitry within memory device140to execute the commands. Controller150is responsible for compliance with standards or specifications within memory device140, such as timing and signaling requirements. Memory controller120can implement compliance with standards or specifications by access scheduling and control.

In one embodiment, memory controller120includes refresh (REF) logic126. Refresh logic126can be used for memory resources that are volatile and need to be refreshed to retain a deterministic state. In one embodiment, refresh logic126indicates a location for refresh, and a type of refresh to perform. Refresh logic126can trigger self-refresh within memory device140, or execute external refreshes which can be referred to as auto refresh commands) by sending refresh commands, or a combination. In one embodiment, controller150within memory device140includes refresh logic154to apply refresh within memory device140. In one embodiment, refresh logic154generates internal operations to perform refresh in accordance with an external refresh received from memory controller120. Refresh logic154can determine if a refresh is directed to memory device140, and what memory resources160to refresh in response to the command.

In one embodiment, memory controller includes ECC logic170to manage error checking and correction in memory accesses of system100. ECC logic170can include ECC hardware that performs ECC computations and stores results. In one embodiment, memory device140includes internal ECC managed by ECC logic180. ECC logic180can include ECC hardware that performs ECC computations and stores results. ECC logic170of memory controller120manages system wide ECC, and can detect and correct errors across multiple different memory resources in parallel (e.g., multiple memory devices140). ECC logic170can generate check bits that it will send to memory device140for storage with a write operation, and which will be returned with a read operation. Many techniques for system wide ECC are known, and can include ECC logic170managing memory resources in a way to spread errors across multiple resources. By spreading errors across multiple resources, memory controller120can recover data even in the event of one or more failures in memory device140. Memory failures are generally categorized as either soft errors or soft failures, which are transient bit errors typically resulting from random environmental conditions, or hard errors or hard failures, which are non-transient bit errors occurring as a result of a hardware failure. As described herein, system ECC can be improved by scaling up the protection level on a channel by channel basis.

ECC logic180of memory device140manages one or more errors occurring in the memory resources160. The use of ECC within memory device140may be referred to as internal ECC or on-die ECC, or internal on-die ECC. In general, internal ECC refers to ECC implemented within memory device140, without command or management of the ECC operations by memory controller120or the host. With internal ECC, in response to a write request, ECC logic180generates ECC bits to store with the data sent by memory controller120. In response to a read request, ECC logic180checks and corrects an error in the data prior to presenting the data to memory controller120to satisfy the request. In one embodiment, SEC data provided from memory device140via operations of ECC logic180is indistinguishable at memory controller120from data with no errors.

In one embodiment, system100has extra system bits available for ECC or other system functions, or a combination. In one embodiment, memory controller120can provide extra system bits to memory device140, and the same extra bits can be returned by the memory device in response to a read request. In one embodiment, ECC logic180covers the additional system bits via the same ECC code182or other ECC mechanism used to protect the integrity of the data bits. In one embodiment, memory devices140provide extra system bits to memory controller120, which can include bits exchanged during UI transfers for internal ECC bits, where there are more UI transfers for internal ECC bits than there are internal ECC bits to transfer. In one embodiment, memory controller120can write the extra bits as additional commands or controls for memory devices140, and memory devices140can return internal ECC information with the extra system bits.

In one embodiment, one or more memory devices140includes an additional signal line (in addition to the DQ signal lines or the memory bus interface, e.g., ×4, ×8, or other). Such an implementation can be referred to as having an additional lane or out of band signal to transfer the extra system bits. In one embodiment, the memory device does not include an additional signal line to transfer the additional system bits, but transfers with another transfer cycle. A transfer cycle refers to a period of time based on a clock or timing signal. The transfer cycle can be referred to as a unit interval (UI). Memory transfers commonly occur over the DQ signal lines over a burst of N UIs, such an 8 cycle or UI burst length or burst length of 8 (BL8), or a 16 UI burst length (BL16). In one embodiment, system100could employ a BL16 for transferring data, followed by a single UI transfer for the extra system bits on the DQ signal lines. In one embodiment, system100could employ a BL16 for transferring data and ECC and extra system bits without an additional UI.

FIG. 2Ais a block diagram of an embodiment of a system in which a memory device and memory controller exchange extra bits in addition to ECC check bits. System202represents a memory subsystem, and provides an example of a system that can be in accordance with system100ofFIG. 1.

Host210represents a central processor or SOC, which executes the primary control functions of system202. Host210includes processor hardware (not specifically shown). Host210includes memory controller212, which can be hardware separate from the processor hardware, or integrated as a module onto the host processor. Host210includes ECC engine214, which can be implemented as hardware within memory controller212, or as hardware separate from memory controller212. In an implementation where ECC engine214operates on hardware outside memory controller212, the ECC engine will coordinate ECC operations with the transfer and receipt of data by memory controller212. In system202, ECC can be provided on a hardware platform level, and lower than a level that is controlled by a host OS. Thus, in one embodiment, ECC operations within system202occur at the level of host hardware, and there is not software executed by or controlled by the host operating system that controls the ECC.

In one embodiment, ECC engine214includes check bit generator216and error correction logic218. Check bit generator216generates check bits for data sent to memory220. In one embodiment, check bit generator216includes hardware to perform XOR operations on data to generate the check bits. Error correction logic218computes the same or a complementary computation on received data and compares the results to the received check bits. In one embodiment, error correction logic218includes hardware to perform XOR operations on data to perform error checking, including comparing against received check bits.

Memory220includes a controller or processor hardware to direct the operations of the memory device. The control hardware can execution command execution logic222to perform operations in response to commands from host210. For example, in response to a write command, command execution logic222can control operations to store transferred data (not explicitly shown) along with write ECC242into memory array230. As another example, in response to a read command, command execution logic222can control operations to fetch read data (not explicitly shown) along with read ECC244from memory array230. In the ideal scenario, read ECC244will match write ECC242for the same memory address space. Array230can include any type of memory structure consistent with the application of ECC, and can store data232and ECC234. ECC234represents check bits that corresponds with user data bits of data232. In one embodiment, ECC234is stored together with the data. In one embodiment, ECC234is stored in a separate memory chip from where data232is stored.

In one embodiment, memory220includes internal ECC224, which can include logic executed by the internal controller or on separate hardware, or a combination. Internal ECC224enables memory220to generate and apply check bits within the memory, independent ECC check bits provided by host210. In one embodiment, internal ECC bits are stored within memory array230. Thus, array230may store two types of ECC bits: check bits for internal ECC and check bits for system ECC. While shown as two types of ECC check bits, it will be understood that internal ECC and system ECC are separate, and in general the check bits and ECC operations of one are not related to the check bits and ECC operations of the other. In one embodiment, with parallel memory devices, only one will store both system check bits and internal check bits, while all may store internal check bits. With internal ECC234, memory220can perform separate error checking and correction on data received from host210, and prior to sending fetched data back to host210.

In one embodiment, system bits246represent additional bits exchanged between ECC engine214and memory220. System bits246provide an example of extra bits in accordance with any embodiment described herein. System bits246can provide additional information for ECC or other purposes. In one embodiment, system bits246represent other system metadata used by host210. In one embodiment, host210and memory220exchange system bits246in extra UIs provided by an excess of UIs that are more than what is needed to transfer write ECC242and read ECC244. The additional UIs are provided to transfer extra bits that memory220can store with additional memory locations available beyond what is needed for internal ECC operations. For example, the excess UIs can be the result of additional signal lines distributed among parallel memory devices, which provides UIs in addition to those used to transfer the data bits and check bits associated with the data. In one embodiment, the excess UIs can be the result of an extended command operation, such as by defining an access operation (e.g., read or write) to include UIs more than what are necessary to transfer the data and associated check bits.

It will be understood that ECC engine214provides ECC operations for memory controller212. Memory controller212includes a hardware I/O interface to couple memory220, which can include a data bus and command bus and other signals. Transceiver212A represents transmit and receive circuitry within memory controller212to send and receive, respectively, data to and from memory220. Transceiver220A represents transmit and receive circuitry within memory220to send and receive, respectively, data to and from memory controller212. Memory controller212sends data for write transactions, where a transaction includes sending a command and a burst operation to transmit data related to the command. Memory controller212receives data for read transactions. On the other side, memory220receives data for write transactions and sends data for read transactions.

In one embodiment, memory220provides internal ECC for 2{circumflex over ( )}N data bits protected by least N+1 check bits. In one embodiment, the memory device has 2N memory locations for the N+1 internal check, and can use the additional memory locations for system bits.

FIG. 2Bis a block diagram of an embodiment of internal error checking and correction circuitry for a memory device. System204is one example of a memory subsystem in accordance with system100ofFIG. 1. Host252includes a memory controller or equivalent or alternative circuit or component that manages access to memory254. In one embodiment, the memory controller is integrated on a processor chip (e.g., iMC). Host252performs external ECC on data read from and written to memory254.

System204illustrates write path260in memory254, which represents a path for data and ECC check bits and extra bits268written from host252to memory254. Host252provides data and other bits to memory254for writing to the memory array(s). In one embodiment, data and ECC bits262includes system ECC bits from the memory controller to write in memory254. In one embodiment, memory254generates check bits264with check bit generator282to store with the data in memory. In one embodiment, check bits264cover both the data bits (e.g., the user data or the data generated by operation of the OS) and the system ECC bits. Check bits264can enable memory254to correct an error that might occur in the writing to and reading from the memory array(s). Data and ECC bits262and check bits264can be included as code word in266, which is written to the memory resources. It will be understood that check bits264represent internal check bits within the memory device. In one embodiment, there is no write path to check bits264from host252. In one embodiment, there is a write path to check bits264only for purposes of testing the code matrix of memory254. In one embodiment, host252sends extra bits268for storing in memory254. Extra bits268can include additional ECC information or system metadata or a combination. In one embodiment, extra bits268can be protected by check bits264. In one embodiment, extra bits268are not covered by internal ECC. Memory254has more space allocated for internal check bits264than needed to store the internal check bits, and memory254stores extra bits268with internal check bits264in the extra space.

Read path270represents a path for data read from memory254to host252. In one embodiment, at least certain hardware components of write path260and read path270are the same hardware. In one embodiment, memory254fetches code word out272in response to a Read command from host252. The code word can include data and system ECC274and check bits276. Data and ECC bits274and check bits276can correspond, respectively, to data and ECC bits262and check bits264written in write path260, if the address location bits of the write and read commands are the same. Similarly, memory254can provide extra bits298to host252, such as data bits stored with check bits276. If extra bits268are covered by internal ECC, extra bits298will be covered by the internal ECC operations of read path270. It will be understood that error correction in read path270can include the application of an XOR (exclusive OR) tree (e.g., a sequence of XOR circuits) to a corresponding H matrix to detect errors and selectively correct errors (in the case of a single bit error). As is understood in the art, an H matrix refers to a hamming code parity-check matrix that shows how linear combinations of digits of the codeword equal zero. Thus, the H matrix rows identify the coefficients of parity check equations that must be satisfied for a component or digit to be part of a codeword. In one embodiment, memory254includes syndrome decode284, which enables the memory to apply check bits276to data and ECC bits274to detect errors in the read data. Syndrome decode284can generate syndrome278for use in generating appropriate error information for the read data. Data and ECC bits274can also be forwarded to error correction288for correction of a detected error.

As is understood in the art, an H matrix refers to a hamming code parity-check matrix that shows how linear combinations of digits of the code word equal zero. In one embodiment, the ECC includes XORing ECC check bits with an identical version generated as the syndrome, which results in zeros. Thus, the H matrix rows can identify the coefficients of parity check equations that must be satisfied for a component or digit to be part of a code word. In one embodiment, memory254includes syndrome generator284to generate an error vector or syndrome278. In one embodiment, check bit generator282and syndrome generator284are fully specified by a corresponding H matrix for the memory device.

In one embodiment, syndrome generator284passes syndrome278to syndrome decode286, which enables the memory to apply check bits276to data274to detect errors in the read data. Syndrome decode286can check syndrome278against an ECC code vector or code matrix stored in memory254. Data274can also be forwarded to error correction288for correction of a detected error.

In one embodiment, if there are no errors in the read data (e.g., zero syndrome278), syndrome decode286can pass the data to host252as no error292. In one embodiment, if there is a single bit error (e.g., non-zero syndrome278that matches one of the columns of the H matrix), syndrome decode286can generate a CE (corrected error) signal with error location290, which is a corrected error indication to error correction logic288. Error correction288can apply the corrected error to the specified location in data274to generate corrected data296for writing to host252. In one embodiment, if there are multiple errors in the read data (e.g., non-zero syndrome278that does not match any of the columns in a corresponding H matrix), syndrome decode286generates DUE (detected uncorrected error)294, which indicates a detected, uncorrected error. DUE294can indicate a multibit error that memory254was not able to correct by internal ECC.

In one embodiment, syndrome decode286applies separate functions for the following conditions. In the case of a zero syndrome, syndrome decode286can pass no error data292to host252. In the case of a non-zero syndrome that matches one of the columns of the H-matrix, the ECC engine can flip or toggle the corresponding bit to create a corrected error signal (CE). Error correction288can perform the actual data correction by changing the identified bit290. In one embodiment, in the case of a non-zero syndrome that does not match any column, syndrome decode sends the erroneous data to host252. Corrected data296sent from error correction logic288is sent when a corresponding code is found in the matrix. In one embodiment, syndrome decode286identifies data as DUE294.

In one embodiment, the error correction logic of read path270generates one or more bits that are transmitted to a register or controller on a memory module. In one embodiment, the controller can send information as extra bits to host252in additional UIs provided by extending the burst length. In one embodiment, memory254only sends no error data292or corrected data296and system check bits to host252. The extra bit can be based on the value of DUE294, or based on whether or not an error correction was performed.

FIGS. 3A-3Dare table representations of embodiments of storage and exchange of extra system bits. Diagrams302,304,306, and308illustrate different options for storing internal ECC and extra system bits.

Referring to diagram302ofFIG. 3A, the system includes ½ K (512 bits) pages, and each operation operates on 64 bits of data per page. It will be understood that while ½ K pages are illustrated, 1 K page size or other page sizes could be used. Furthermore, the same principles can be applied with respect to additional system bits whether the number of bits is 64 bits per page, or some other number of bits, and whether the number of bits accessed per operation is 128 bits or some other number of bits. In one embodiment, the different pages are accessed from different memory arrays. For example, a memory die can include two sides, with 64 bits of access to both sides. The access can be from one or multiple banks.

In diagram302, there are 8 memory locations for internal ECC and extra bits for the 128 bits illustrated, and the memory device stores all 8 ECC and extra bits in a single page. The memory device spreads the data across the two pages. Thus, Page A includes 64 bits of data plus 8 bits allocated for internal ECC or ECC plus system bits. Page B includes 64 bits of data, and no ECC bits. In one embodiment, the memory device stores extra system bits in a location not shown, which can be in addition to the data bits and ECC bits illustrated. In one embodiment, the extra system bits can be stored in two separate pages or in a single page, and/or the memory array from which the data bits are read or to which the data bits are written. Data310represents 128 bits of data with associated 8 bits of ECC bits or ECC and extra system bits. It will be understood that while 8 bits of ECC and extra bits are illustrated for 128 bits of data, the amounts of data can vary; for example,FIG. 3Dillustrates a similar diagram where four pages of memory are illustrated.

Referring to diagram304ofFIG. 3B, the memory device reads or write 128 bits of data over two ½ K pages. The 128 bits of data are spread over two pages, and the ECC data bits are also spread over the two pages, with each page storing 4 ECC bits. Thus, Page A includes 64 bits of data plus 4 bits allocated for internal ECC or ECC plus system bits. Page B also includes 64 bits of data plus 4 bits allocated for internal ECC or ECC plus system bits. In one embodiment, in the first option the memory device also stores and exchanges 4 additional system bits per 128 data bits. In alternative embodiments, other numbers of extra system bits can be used. The additional system bits can be stored with the ECC bits, or stored separately. Even if the ECC bits are spread across two pages, in one embodiment, the memory device can store the extra system bits in a single page or across the two pages. Data320represents 128 bits of data with associated 8 bits of ECC bits or ECC and extra system bits. While data320may be similar to data310with 128 bits of data and 8 ECC bits, data320is stored differently.

Referring to diagram306ofFIG. 3C, the memory device stores all data bits and all ECC bits in a single page. Thus, Page A includes 128 bits of data plus 8 bits allocated to internal ECC or ECC plus system bits. In one embodiment, the memory device stores additional system bits with Page A. It will be understood that such an option would require additional access/prefetch circuitry, which would increase memory die size and consume more power. Data330represents 128 bits of data with associated 8 bits of ECC bits or ECC and extra system bits, all from a single page.

In diagram308, there are a total of 256 bits from four pages, which may be in accordance with an embodiment described herein. Diagrams302,304, and306can be understood to be in accordance with diagram308in various embodiments. Diagram308illustrates one example of how 256 data bits and associated ECC and system bits can be allocated in accordance with diagram302. Alternate embodiments of diagram308can be in accordance with diagram304or diagram306. As illustrated, there are 8 memory locations for internal ECC and extra bits for each of 64 bits pages, and the memory device stores 8 ECC and extra bits in one page and 8 ECC and extra bits in another page, while two pages are not allocated memory space for ECC and extra bits. The memory device spreads the data across the four pages. Thus, Page A includes 64 bits of data plus 8 bits allocated for internal ECC or ECC plus system bits. Page B includes 64 bits of data, and no ECC bits. Page C includes 64 bits of data plus 8 bits allocated for internal ECC or ECC plus system bits. Page D includes 64 bits of data, and no ECC bits. The allocation of ECC bits among the pages can be provided in any manner, such as in Pages A and B, with none in Pages C and D, or another configuration. In one embodiment, the memory device stores extra system bits across Pages A and C with the internal ECC bits. Data340represents 256 bits of data with associated 16 bits of ECC and extra system bits.

Consider one embodiment of a memory device with a ×4 interface. In one embodiment, for a read, the memory device can prefetch data and transfer 128 bits to the memory controller with BL16 over two interfaces (4*2*16=128). In one embodiment, for a write, the memory controller can transfer the data to the memory device with BL16 in similar fashion. Extra system bits can be transferred either in a separate lane or in a separate UI. The data can be stored in accordance with any of diagrams302,304,306, or308, and similarly prefetched for reads.

FIGS. 4A-4Dare embodiments of tabular data that represent an exchange of error checking and correction bits between a host and a memory that exchanges extra system bits with error checking and correction information. In accordance with what is described herein, extra bits can be provided by memory devices over an extended burst. As illustrated in diagram410ofFIG. 4A, diagram420ofFIG. 4B, and diagram430ofFIG. 4C, the memory device can provide one or more additional bits over an extra lane or extra data signal line. Such a signal line can be routed from the memory device to a controller on a memory module, or coupled to logic circuits on a memory module to interface with the associated memory controller. For example, if multiple memory devices provide one or more bits of data over an additional signal line, the lines may be multiplexed and selected to provide the appropriate data to the memory controller. As illustrated in diagram440ofFIG. 4D, the memory device can alternatively provide one or more additional bits in a UI of one of the standard signal lines of the data interface, which can be referred to as transmitting inline. The inline transmission occurs on an additional UI or extra burst cycle. In an embodiment where different memory devices in parallel transmit one of the multiple bits, each device could transmit its allocated extra bit only in the UI and signal line assigned to it. In one embodiment, multiplexing logic can select the appropriate signal to send to the memory controller.

Referring to diagram410, user data interface414illustrates DQ[3:0], which represent the 4 lanes of a ×4 interface memory device or DRAM. It will be understood that a different interface size could be used. As illustrated, the DRAM operates on a data burst412of BL16, to transfer 64 bits over user data interface414. In one embodiment, the DRAM also transfers on a fifth signal line or fifth data lane ECC interface416, which provides an extra system bit. The extra system bit is illustrated as e0. In one embodiment, the additional signal line, DQ4/E operates on a slower transfer speed than DQ[3:0]. Thus, the system could require 16 DQ UI for a single bit transfer for e0 over the extra data lane. In one embodiment, DQ4/E has the same speed interface as DQ[3:0], and simply repeats the transfer for multiple UI to transfer e0.

Referring to diagram420, user data interface424illustrates DQ[3:0], which represent the 4 lanes of a ×4 interface memory device or DRAM. It will be understood that a different interface size could be used. As illustrated, the DRAM operates on a data burst422of BL16, to transfer 64 bits over user data interface424. In one embodiment, the DRAM also transfers on a fifth signal line or fifth data lane ECC interface426, which provides extra system bits. The extra system bits are illustrated as e0 and e1. In one embodiment, the additional signal line, DQ4/E operates on a slower transfer speed than DQ[3:0]. Thus, the system could require 8 DQ UI for a single extra bit transfer over the extra data lane. In one embodiment, DQ4/E has the same speed interface as DQ[3:0], and simply repeats the transfer for multiple UI to transfer e0 and e1. In one embodiment, if more than one extra bit is assigned per 64 bits of data, the memory device and memory controller can exchange the extra bits as follows: e0 during UI[0:7] on DQ4/E, and e1 during UI[8:15] on DQ4/E.

Referring to diagram430, user data interface434illustrates DQ[3:0], which represent the 4 lanes of a ×4 interface memory device or DRAM. It will be understood that a different interface size could be used. As illustrated, the DRAM operates on a data burst432of BL16, to transfer 64 bits over user data interface434. In one embodiment, the DRAM also transfers on a fifth signal line or fifth data lane ECC interface436, which provides extra system bits. The extra system bits are illustrated as e[0:6]. In one embodiment, the additional signal line, DQ4/E operates on a slower transfer speed than DQ[3:0]. Thus, the system could require 2 DQ UI for a single extra bit transfer over the extra data lane. In one embodiment, DQ4/E has the same speed interface as DQ[3:0], and simply repeats the transfer for multiple UI to transfer the extra bits. In one embodiment, the memory device and memory controller can exchange the extra bits as follows: e0 during UI[0:1] on DQ4/E, e1 during UI[2:3] on DQ4/E, e2 during UI[4:5] on DQ4/E, e3 during UI[6:7] on DQ4/E, e4 during UI[8:9] on DQ4/E, e5 during UI[10:11] on DQ4/E, and e6 during UI[12:13] on DQ4/E. It will be observed that no extra bit is shown transferred on UI[14:15], referring to an embodiment where only 7 extra bits are available. In an alternate embodiment, the memory device and memory controller can exchange data on DQ4/E during UI[14:15].

Referring to diagram440, user data interface444illustrates DQ[3:0], which represent the 4 lanes of a ×4 interface memory device or DRAM. It will be understood that a different interface size could be used. In contrast to diagrams410,420, and430described above, which illustrate an additional lane for transferring extra bits, in diagram440the memory device and memory controller can exchange extra bits on additional UIs. As illustrated, the DRAM operates on a data burst442of BL18 for ECC transactions. In one embodiment, the memory device may be configured to transfer over BL16 for non-ECC transactions, and configured to transfer over BL18 for ECC-based transactions. As illustrated, UI[16] and UI[17] are identified as ECC UIs552, because they are additional transfer cycles on which extra bits can be transferred. In one embodiment, only 7 extra bits are available, and so there is no e7. Thus, UI[17] may have extra slot454where no bit is transferred on DQ3. In an alternate embodiment, the memory device and memory controller can exchange data on DQ3 during UI[17].

In general forFIGS. 4A-4D, the representations of the transmission of one or more extra bits can be applied by one or more memory devices of a group. In one embodiment, a memory controller connects to multiple memory devices in parallel, such as the memory devices of a DIMM. When multiple memory devices are coupled in parallel, in one embodiment, one or more of the memory devices provides extra bits on one or more additional UIs, and one or more other memory devices does not. For example, consider the example provided above of a memory subsystem with 9 DRAM devices and a 40 bit channel or an interface that provides data over 40 signal lines. Nine DRAM devices that have ×4 interfaces equals 36 signal lines for data and single bit error ECC data, leaving 4 signal lines for additional data. In one embodiment, one or more memory devices couple to the additional signal lines. If fewer than 4 device coupled to the lines, the signal lines could be multiplexed to one or more signal lines of the memory devices. In one embodiment, where 9 DRAM devices are used, 5 devices can provide ×4 interfaces (20 bits) plus another 4 devices that provide ×5 interfaces (20 bits) such as those illustrated inFIGS. 4A-4C. Alternatively, additional data transfer UIs could be used, or additional UI data transfers from the DRAM devices could be buffered (for example in a DIMM register) and transmitted over 40 signal lines. It will be understood that these examples are merely for illustration and are not limiting.

FIGS. 5A-5Care block diagrams of embodiments of mapping extra system bits to memory bits. Referring to mapping510ofFIG. 5A, 128 bits of data can include 64 bits from two separate sources or from a single page. In one embodiment, D0 and D1 represent separate memory devices or memory dies that exchange a chunk of the overall data. In one embodiment, 4 extra system bits516can be added per 128 data bits512(e.g., two bits to each of two pages), in addition to ECC bits514. Thus, the number of ECC and system bits can be 8 ECC bits per 128 data bits, with 4 extra bits provided by different devices. With the additional system bits, there may be 12 bits per 128 data bits, with 8 ECC bits and 4 extra bits. Mapping510provides an example of a mapping for two devices, and additional devices can be added, some of which may not map to extra bits, and some of which may map to extra bits that are not shown.

Referring to mapping520ofFIG. 5B, four ×4 devices have four 64b chunks for 256b of data. D[0:4] include 256 bits of data, each having 64 bits from four separate sources or from one or multiple pages. In one embodiment, 8 extra system bits526can be added per 256 data bits522, in addition to ECC bits524. Thus, the number of ECC and system bits can be 8 ECC bits for data bits, with up to 8 extra bits. With the additional system bits, there may be 16 bits per 256 data bits, with 8 ECC bits and 8 extra bits. In one embodiment, one or more of bits526shown as extra bits is an additional ECC bit.

Referring to mapping530ofFIG. 5C, four ×4 devices have four 64b chunks for 256b of data. D[0:4] include 256 bits of data, each having 64 bits from four separate sources or from one or multiple pages. In one embodiment, 7 extra system bits536can be added per 256 data bits532, in addition to ECC bits534. Thus, the number of ECC and system bits can be 9 ECC bits for the 256 data bits, with up to 7 extra bits. With the additional system bits, there may be 16 bits per 256 data bits, with 9 ECC bits534and 7 extra bits536. Mapping530can be considered a more specific case of mapping520, where one of extra bits526provides the ninth ECC bit ECC8. In one embodiment, not all extra bits are used. For example, mapping530illustrates e[0:3] associated, respectively, with D[0:3], and three extra bits being reserved (RFU, or reserved for future use). In one embodiment, the various memory devices provide one extra bit per 64 bit chunk. In an alternative embodiment, alternating between transferring one and two additional bits per page of data can use up all 7 extra bits. In one embodiment, D[0:3] represent only the memory devices that map to extra bits and will exchange extra bits with the memory controller. Other memory devices will provide the remaining data bits for a page, and an additional device can provide the ECC bits. In such a case where an additional memory device provides the ECC bits, it will be understood that ECC8 can be provided as an extra bit, either from one or more of the data memory devices, or from the ECC memory device.

FIG. 6Ais a block diagram of an embodiment of a system with a register for DRAM devices that provide extra system bits for system ECC in accordance with any embodiment described herein. System602illustrates one embodiment of a system with memory devices that share a control bus (C/A (command/address) bus612) and a data bus (data bus614). The shared C/A bus can be shared among DRAM devices620on the same channel. As illustrated, system602includes two channels, and thus includes C/A bus612[0] and C/A bus612[1]. Similarly, system602includes data bus614[0] and data bus614[1]. DRAM devices620can be individually accessed with device specific commands, and can be accessed in parallel with parallel commands. In one embodiment, DRAM devices620represent memory devices on a DIMM. It will be understood that different implementations can have different numbers of DRAM devices (either more or fewer).

Register610represents a controller for system602, or a controller for a memory module or DIMM represented by system602. It will be understood that the controller represented by register610is different from a host controller or memory controller (not specifically shown) of a computing device in which system602is incorporated. Likewise, the controller of register610is different from an on-chip or on-die controller that is included on the DRAM devices620. In one embodiment, register610is a registered clock driver (which can also be referred to as a registering clock driver). The registered clock driver receives information from the host (such as a memory controller) and buffers the signals from the host to the various DRAM devices620. If all DRAM devices620were directly connected to host630, the loading on the signal lines would degrade high speed signaling capability. By buffering the input signals from the host, host630only sees the load of register610, which can then control the timing and signaling to the DRAM devices620. In one embodiment, register610is a controller on a DIMM to control signaling to the various memory devices.

Register610includes interface circuitry to couple to host630and to DRAM devices620. While not shown in specific detail, the hardware interface can include drivers, impedance termination circuitry, and logic to control operation of the drivers and impedance termination. The interfaces can include circuitry such as interfaces described below with respect to an interface between a DRAM device and a memory controller of host630. The interface circuitry can provide interfaces to various buses described with respect to system100.

The interface circuitry enables coupling to DRAM devices620over data bus614. In one embodiment, the interface circuitry enables coupling to DRAM devices620over C/A bus612. In one embodiment, register610has independent command ports for separate channels. In one embodiment, register610has independent data ports for separate channels. Separate and independent channels, channel 0 and channel 1, can enable the parallel communication of data on two different data buses614[0] and614[1], which can collectively be referred to as data buses614. In one embodiment, all memory devices620in system602share the same data bus614. Separate channels can enable the parallel communication of commands on two different command buses612[0] and612[1], which can collectively be referred to as C/A buses612. In one embodiment, all memory devices620in system602share the same C/A bus. In one embodiment, memory devices620are coupled to parallel C/A buses612and data buses614for purposes of signaling and loading. While two channels are illustrated, in one embodiment, more channels can be provided in system602. While not specifically shown, in addition to being coupled to host630, system602can include a connection to nonvolatile storage (not shown).

In one embodiment, host630provides commands and address information through a C/A bus connection to register610(not specifically shown). In one embodiment, host630directly couples to DRAM devices620through C/A buses612. In one embodiment, register610functions as a C/A register, and register610can forward commands from the host to the DRAM devices. C/A buses612are typically unilateral buses to carry command and address information to all DRAM devices in a channel. Thus, the bus can be a multi-drop bus.

In response to one or more memory access commands on the C/A bus, DRAM devices620execute operations requested, which can include writing data or reading data. For a write, host630provides the data to write to the specified address over data bus614. In system602, multiple DRAM devices620in parallel on a channel will write a portion of the read data. For example, the DRAM devices may have a ×4 or ×8 interface, and write the number of bits per transfer cycle of a burst length in accordance with the interface. For a read, DRAM devices620provide the data to host630over data bus614. In one embodiment, system602includes a common bidirectional data bus614, where register610can connect to each DRAM device with a number of bits equal to the interface width, with a matched strobe pair. In one embodiment, data buses614are terminated at either end of the bus segment to avoid signal reflections.

When ECC is applied in system602, data buses614enable the exchange of both user data and ECC check bits. As illustrated, data632represents the user data and ECC bits634represent the check bits to protect data632. In accordance with what is described herein, in one embodiment, data buses614enable the providing of extra bits636, which represent bits sent in UIs that can be used for ECC bits. Internally, DRAM devices620can exchange extra bits636based on an allocation of bits or memory spaces for internal ECC which is in excess of what is needed for the number of ECC bits used to provide internal ECC for the number of data bits stored in the DRAM devices. The number of data bits stored and fetched for memory operations can be in excess of the number of data bits each DRAM device620will contribute data632. For example, DRAM devices620may operate on 256 bits of data internally, with 9 internal check bits used for ECC, and each device will contribute a 64 bit chunk to each memory access operation (either by storing 64 bits for a write or outputting 64 bits for a read). As one specific example, if SEC is the level of ECC applied, a certain number of internal check bits separate from ECC bits634will be required to perform SEC within the DRAM devices. DRAM devices620can provide unused, allocated ECC address space for additional system bits represented by extra bits636. Extra bits636can enable host630to provide ECC protection beyond SEC, such as enabling recovery from a whole device failure.

For example, in one embodiment, DRAM devices620provide for 2N memory locations for internal ECC bits. If only N+1 check bits are needed for ECC, there are 2N minus (N+1) slots theoretically available for additional information. Host630and DRAM devices620exchange extra bits636for the DRAM devices to store and then provide the extra bits.

System602illustrates register610and DRAM devices620in a configuration similar to a DIMM layout. However, in one embodiment, register610can represent or be replaced with other hardware interface logic to couple a multi-device package of memory to host630. For example, certain multichip packages can include multiple DRAM dies within the device package. The DRAM dies can be stacked, or otherwise packaged together. In one embodiment, such a package includes a high bandwidth memory device. In a multichip package implementation, the application of ECC can be provided in accordance with what is described herein.

FIG. 6Bis a block diagram of an embodiment of a DIMM with ×4 DRAM devices that provide extra system bits for system ECC over a longer burst length. System604provides one example of a DIMM system in accordance with system602ofFIG. 6A. More specifically, system604illustrates an embodiment of DIMM640, with two channels of DRAM devices. Each channel includes 9 DRAM devices, DRAM[0:8], which have ×4 data bus interfaces.

Host660provides a command to either channel 0, CH[0], or channel 1, CH[1] over a command and address bus (not specifically shown). In one embodiment, the C/A bus goes through register650on DIMM640, and commands are forwarded to the DRAM devices over C/A buses642, with C/A bus642[0] for CH[0], and C/A bus642[1] for CH[1]. Data for read and write transactions is exchanged over data buses644, with data bus644[0] for CH[0], and data bus644[1] for CH[1]. In one embodiment, a multiple DRAM devices provide one extra bit per 64b chunk of data. As illustrated, DRAM[0], DRAM[2], DRAM[4], and DRAM[6] per channel provide an additional bit, and are illustrated as being D×4+1, or a ×4 interface for data, plus one additional signal line to transfer an extra bit. It will be understood that the implementation illustrated is merely one example, and any different DRAM device can be selected to provide an additional bit. In one embodiment, register650can select a DRAM device to provide the extra bit, and those choose a DRAM device to select the extra bit based on an LSB (least significant bit) of a CAS (column address strobe) command. In response to such a command, the DRAM device selected for providing the extra bit can drive the bit on the interface for read and read the bit from the interface for write.

As illustrated in system604, data buses644have a burst of BL16, in one embodiment. In one embodiment, with BL16 and 9 DRAM devices where 5 devices have ×4 interfaces and 4 devices have ×5 interfaces, the channel can have a physical bandwidth of 40 bits or signal lines, times 16 transfer cycles can provide up to 640 data bits. In one embodiment, all ×4 interfaces transfer data for the entire BL16 cycle for 36*16=576 bits, and each of the additional interfaces selectively drives either 1 or two extra bits. The 576 bits are the 512 data bits plus the 64 system ECC bits. System604illustrates 7 system bits, which totals 583 bits exchanged, and the 7 system bits are exchanged over one or more of the additional interface signal lines over the 16 transfer cycles. In one embodiment, the DRAM devices illustrated as D×4 have a fifth interface signal line, and could be configured as D×4+1, but the additional interface signal line is not connected.

FIG. 7is a block diagram of an embodiment of a system in which a memory device and memory controller exchange extra bits with a data access transaction. System700provides an example of a system in accordance with an embodiment of system604ofFIG. 6B. Memory controller710represents a control circuit of the host to provide management of memory access to memory devices730and750. Memory controller710is illustrated to include ECC engine712, which represents logic including circuitry to perform ECC functions for system700. I/O714represents the hardware interface elements and software control logic to drive the hardware to exchange or send and receive data with memory devices730and750.

Memory devices730are illustrated with I/O732, which represents hardware interface elements and software control logic to drive the hardware to exchange data with memory controller710. Similarly, memory devices760are illustrated with I/O752, which represents hardware interface elements and software control logic to drive the hardware to exchange data with memory controller710. As illustrated, both memory devices730and memory devices750include hardware interfaces to four data bus signal lines. Each device has D[0:3], which will connect to different signal lines of a total data bus.

In one embodiment, memory controller710is capable of coupling to memory730and memory750in parallel via a data bus, which can exchange data722and system ECC724. In one embodiment, memory controller can exchange extra bits726with selected memory devices, and specifically with memory devices750. In one embodiment, memory devices730include interface D[4], but it is not connected, and only D[0:3] are connected for the exchange of data722and system ECC724. In one embodiment, memory devices750are connected for the exchange of data722and system ECC724with D[0:3], and also include D[4] connected for the exchange of extra bits726, in accordance with any embodiment described herein.

As a specific example, consider that memory controller710exchanges 512 data bits722with 64 system ECC bits724, and either 4 or 7 extra bits726. In one embodiment, each of four memory devices730exchanges 64 data bits, and a fifth memory device730exchanges the 64 ECC bits. In one embodiment, upon receiving data for write through I/O732, memory devices730perform internal ECC operations with internal ECC734, which generates internal check bits. Thus, memory devices730store data742, which may be the system ECC bits for the ECC device in one embodiment, and internal ECC bits744generated by and for use by internal ECC734. For read, internal ECC734reads internal ECC bits744and applies ECC operations before sending the data to memory controller710.

Continuing with the example, in one embodiment, each of four memory devices750exchanges 64 data bits, and exchanges extra bits726. In one embodiment, each memory device750contributes one extra system bit for 4 extra bits726. In one embodiment, memory devices750each contribute at least one extra system bit, and alternately contribute 2 extra system bits for a total of 7 extra bits726. Other numbers of extra bits can be used, including more than 7 extra bits in alternative embodiments. The storage of extra bits can be in accordance with any embodiment described herein, which allows for more than 7 extra system bits to be stored. The transfer of extra bits can be in accordance with any embodiment described herein, which allows for more than 7 extra system bits to be exchanged. In one embodiment, upon receiving data for write through I/O752, memory devices760perform internal ECC operations with internal ECC754, which generates internal check bits. Thus, memory devices750store data742and internal ECC bits746generated by and for use by internal ECC754. For read, internal ECC754reads internal ECC bits746and applies ECC operations before sending the data to memory controller710.

FIG. 8is a flow diagram of an embodiment of a process for applying on-memory error checking and correction with extra system bits. Process800illustrates a flow for data access and internal ECC with extra system bits. Process800provides one example of a flow in accordance with any internal ECC architecture with extra system bits. Process800provides an example of an implementation of providing extra system bits with additional UIs in accordance with what is described herein.

The process illustrated can be a process performed by a memory subsystem in accordance with any embodiment described herein. More specifically, process800illustrates operations for a memory controller and associated memory device. The system generates a data access request, such as a read or write request,802. In one embodiment, the memory controller sends the request for data access, including system ECC bits and extra system bits to accompany the access request,804.

For a write access type corresponding to a write request,806WRITE branch, in one embodiment, the memory controller sends extra system bits with the write data and system ECC bits, which the memory device receives,808. In one embodiment, the memory device generates internal ECC bits for the write data and system ECC bits,810, and applies the extra system bits in accordance with a configuration of the memory device. In one embodiment, the memory device generates internal ECC bits for both the write data and system ECC bits, and not the extra system bits. In one embodiment, the memory device performs internal ECC on the extra system bits. The memory device stores the write data and the ECC bits,812. In one embodiment, the memory device also stores the internal ECC bits and extra system bits in accordance with an embodiment of bit mappings as described herein, or a different mapping of ECC bits or extra system bits.

For a read access type corresponding to a read request,806READ branch, in one embodiment, the memory device fetches the read data and system ECC bits, and the internal ECC bits associated with the data,814. In one embodiment, the memory device performs internal ECC on the data with internal check bits,816. The memory device returns the data to the memory controller, which can include system ECC bits and extra system bits,818.

FIG. 9is a flow diagram of an embodiment of a process for providing extra system bits for error checking and correction. Process900illustrates a flow for data access to multiple parallel memory devices. Process900provides one example of a flow in accordance with an implementation of providing extra system bits with additional UIs in accordance with what is described herein. In one embodiment, process900implements process800for each memory device.

The process illustrated can be a process performed by a memory subsystem in accordance with any embodiment described herein. More specifically, process900illustrates operations for a memory controller and associated memory device. The system generates a data access request, such as a read or write request,902.

For a write request,904WRITE branch, the memory controller computes ECC check bits to send with the write data,906. The memory controller sends the write data and associated system ECC bits to multiple memory devices in parallel,908, such as to a memory module or multichip device. In one embodiment, the memory controller sends extra system bits to a selected one or more of the parallel memory devices. The memory devices receive the write data and associated system ECC bits to store,910. In one embodiment, the memory devices perform internal ECC and store the data, the system ECC bits, and the internal ECC bits,912. In one embodiment, the memory devices perform internal ECC and store the data, system ECC bits, and internal ECC bits and extra system bits,914.

For a read request,904READ branch, in one embodiment, the memory device fetches the data, which can include system ECC bits, and associated internal ECC bits,916. In one embodiment, the memory device performs internal ECC operations prior to sending the read data,918, which can correct errors in the data prior to sending it to the memory controller. In one embodiment, the memory device sends the checked/corrected read data and associated system ECC bits to the memory controller,920. One or more of the memory device can also send one or more extra system bits in accordance with what is described herein,922. In one embodiment, the memory controller performs system level ECC with the system ECC bits and read data from multiple memory devices, including extra system bits,924.

FIG. 10is a block diagram of an embodiment of a computing system in which error checking and correction with extra system bits can be implemented. System1000represents a computing device in accordance with any embodiment described herein, and can be a laptop computer, a desktop computer, a tablet computer, a server, a gaming or entertainment control system, a scanner, copier, printer, routing or switching device, embedded computing device, a smartphone, a wearable device, an internet-of-things device or other electronic device.

System1000includes processor1010, which provides processing, operation management, and execution of instructions for system1000. Processor1010can include any type of microprocessor, central processing unit (CPU), graphics processing unit (GPU), processing core, or other processing hardware to provide processing for system1000, or a combination of processors. Processor1010controls the overall operation of system1000, and can be or include, one or more programmable general-purpose or special-purpose microprocessors, digital signal processors (DSPs), programmable controllers, application specific integrated circuits (ASICs), programmable logic devices (PLDs), or the like, or a combination of such devices.

In one embodiment, system1000includes interface1012coupled to processor1010, which can represent a higher speed interface or a high throughput interface for system components that needs higher bandwidth connections, such as memory subsystem1020or graphics interface components1040. Interface1012can represent a “north bridge” circuit, which can be a standalone component or integrated onto a processor die. Where present, graphics interface1040interfaces to graphics components for providing a visual display to a user of system1000. In one embodiment, graphics interface1040can drive a high definition (HD) display that provides an output to a user. High definition can refer to a display having a pixel density of approximately 100 PPI (pixels per inch) or greater, and can include formats such as full HD (e.g., 1080p), retina displays, 4K (ultra high definition or UHD), or others. In one embodiment, the display can include a touchscreen display. In one embodiment, graphics interface1040generates a display based on data stored in memory1030or based on operations executed by processor1010or both. In one embodiment, graphics interface1040generates a display based on data stored in memory1030or based on operations executed by processor1010or both.

Memory subsystem1020represents the main memory of system1000, and provides storage for code to be executed by processor1010, or data values to be used in executing a routine. Memory subsystem1020can include one or more memory devices1030such as read-only memory (ROM), flash memory, one or more varieties of random access memory (RAM) such as DRAM, or other memory devices, or a combination of such devices. Memory1030stores and hosts, among other things, operating system (OS)1032to provide a software platform for execution of instructions in system1000. Additionally, applications1034can execute on the software platform of OS1032from memory1030. Applications1034represent programs that have their own operational logic to perform execution of one or more functions. Processes1036represent agents or routines that provide auxiliary functions to OS1032or one or more applications1034or a combination. OS1032, applications1034, and processes1036provide software logic to provide functions for system1000. In one embodiment, memory subsystem1020includes memory controller1022, which is a memory controller to generate and issue commands to memory1030. It will be understood that memory controller1022could be a physical part of processor1010or a physical part of interface1012. For example, memory controller1022can be an integrated memory controller, integrated onto a circuit with processor1010.

In one embodiment, system1000includes interface1014, which can be coupled to interface1012. Interface1014can be a lower speed interface than interface1012. In one embodiment, interface1014can be a “south bridge” circuit, which can include standalone components and integrated circuitry. In one embodiment, multiple user interface components or peripheral components, or both, couple to interface1014. Network interface1050provides system1000the ability to communicate with remote devices (e.g., servers or other computing devices) over one or more networks. Network interface1050can include an Ethernet adapter, wireless interconnection components, cellular network interconnection components, USB (universal serial bus), or other wired or wireless standards-based or proprietary interfaces. Network interface1050can exchange data with a remote device, which can include sending data stored in memory or receiving data to be stored in memory.

In one embodiment, system1000includes one or more input/output (I/O) interface(s)1060. I/O interface1060can include one or more interface components through which a user interacts with system1000(e.g., audio, alphanumeric, tactile/touch, or other interfacing). Peripheral interface1070can include any hardware interface not specifically mentioned above. Peripherals refer generally to devices that connect dependently to system1000. A dependent connection is one where system1000provides the software platform or hardware platform or both on which operation executes, and with which a user interacts.

In one embodiment, system1000includes storage subsystem1080to store data in a nonvolatile manner. In one embodiment, in certain system implementations, at least certain components of storage1080can overlap with components of memory subsystem1020. Storage subsystem1080includes storage device(s)1084, which can be or include any conventional medium for storing large amounts of data in a nonvolatile manner, such as one or more magnetic, solid state, or optical based disks, or a combination. Storage1084holds code or instructions and data1086in a persistent state (i.e., the value is retained despite interruption of power to system1000). Storage1084can be generically considered to be a “memory,” although memory1030is typically the executing or operating memory to provide instructions to processor1010. Whereas storage1084is nonvolatile, memory1030can include volatile memory (i.e., the value or state of the data is indeterminate if power is interrupted to system1000). In one embodiment, storage subsystem1080includes controller1082to interface with storage1084. In one embodiment controller1082is a physical part of interface1014or processor1010, or can include circuits or logic in both processor1010and interface1014.

Power source1002provides power to the components of system1000. More specifically, power source1002typically interfaces to one or multiple power supplies1004in system1002to provide power to the components of system1000. In one embodiment, power supply1004includes an AC to DC (alternating current to direct current) adapter to plug into a wall outlet. Such AC power can be renewable energy (e.g., solar power) power source1002. In one embodiment, power source1002includes a DC power source, such as an external AC to DC converter. In one embodiment, power source1002or power supply1004includes wireless charging hardware to charge via proximity to a charging field. In one embodiment, power source1002can include an internal battery or fuel cell source.

In one embodiment, memory subsystem1020includes ECC1090, which can be an implementation of internal ECC with extra system bits in accordance with any embodiment described herein. ECC1090is shown as a separate element, but represents internal ECC in memory devices1030and system level ECC in memory controller1022. The internal ECC generates internal ECC bits for internal ECC, and can correct an error in read data prior to sending it to memory controller1022. ECC1090in accordance with an embodiment herein additionally allows memory controller1022and memory1030to exchange extra system bits. In one embodiment, system1000is a server device. In one embodiment in a server device, system1000can be one of multiple systems combined together in a server configuration. For example, the server can be implemented as a blade server combined with other blade servers in a chassis system.

FIG. 11is a block diagram of an embodiment of a mobile device in which error checking and correction with extra system bits can be implemented. Device1100represents a mobile computing device, such as a computing tablet, a mobile phone or smartphone, a wireless-enabled e-reader, wearable computing device, an internet-of-things device or other mobile device, or an embedded computing device. It will be understood that certain of the components are shown generally, and not all components of such a device are shown in device1100.

Device1100includes processor1110, which performs the primary processing operations of device1100. Processor1110can include one or more physical devices, such as microprocessors, application processors, microcontrollers, programmable logic devices, or other processing means. The processing operations performed by processor1110include the execution of an operating platform or operating system on which applications and device functions are executed. The processing operations include operations related to I/O (input/output) with a human user or with other devices, operations related to power management, operations related to connecting device1100to another device, or a combination. The processing operations can also include operations related to audio I/O, display I/O, or other interfacing, or a combination. Processor1110can execute data stored in memory. Processor1110can write or edit data stored in memory.

In one embodiment, system1100includes one or more sensors1112. Sensors1112represent embedded sensors or interfaces to external sensors, or a combination. Sensors1112enable system1100to monitor or detect one or more conditions of an environment or a device in which system1100is implemented. Sensors1112can include environmental sensors (such as temperature sensors, motion detectors, light detectors, cameras, chemical sensors (e.g., carbon monoxide, carbon dioxide, or other chemical sensors)), pressure sensors, accelerometers, gyroscopes, medical or physiology sensors (e.g., biosensors, heart rate monitors, or other sensors to detect physiological attributes), or other sensors, or a combination. Sensors1112can also include sensors for biometric systems such as fingerprint recognition systems, face detection or recognition systems, or other systems that detect or recognize user features. Sensors1112should be understood broadly, and not limiting on the many different types of sensors that could be implemented with system1100. In one embodiment, one or more sensors1112couples to processor1110via a frontend circuit integrated with processor1110. In one embodiment, one or more sensors1112couples to processor1110via another component of system1100.

In one embodiment, device1100includes audio subsystem1120, which represents hardware (e.g., audio hardware and audio circuits) and software (e.g., drivers, codecs) components associated with providing audio functions to the computing device. Audio functions can include speaker or headphone output, as well as microphone input. Devices for such functions can be integrated into device1100, or connected to device1100. In one embodiment, a user interacts with device1100by providing audio commands that are received and processed by processor1110.

Display subsystem1130represents hardware (e.g., display devices) and software components (e.g., drivers) that provide a visual display for presentation to a user. In one embodiment, the display includes tactile components or touchscreen elements for a user to interact with the computing device. Display subsystem1130includes display interface1132, which includes the particular screen or hardware device used to provide a display to a user. In one embodiment, display interface1132includes logic separate from processor1110(such as a graphics processor) to perform at least some processing related to the display. In one embodiment, display subsystem1130includes a touchscreen device that provides both output and input to a user. In one embodiment, display subsystem1130includes a high definition (HD) display that provides an output to a user. High definition can refer to a display having a pixel density of approximately 100 PPI (pixels per inch) or greater, and can include formats such as full HD (e.g., 1080p), retina displays, 4K (ultra high definition or UHD), or others. In one embodiment, display subsystem includes a touchscreen display. In one embodiment, display subsystem1130generates display information based on data stored in memory or based on operations executed by processor1110or both.

I/O controller1140represents hardware devices and software components related to interaction with a user. I/O controller1140can operate to manage hardware that is part of audio subsystem1120, or display subsystem1130, or both. Additionally, I/O controller1140illustrates a connection point for additional devices that connect to device1100through which a user might interact with the system. For example, devices that can be attached to device1100might include microphone devices, speaker or stereo systems, video systems or other display device, keyboard or keypad devices, or other I/O devices for use with specific applications such as card readers or other devices.

As mentioned above, I/O controller1140can interact with audio subsystem1120or display subsystem1130or both. For example, input through a microphone or other audio device can provide input or commands for one or more applications or functions of device1100. Additionally, audio output can be provided instead of or in addition to display output. In another example, if display subsystem includes a touchscreen, the display device also acts as an input device, which can be at least partially managed by I/O controller1140. There can also be additional buttons or switches on device1100to provide I/O functions managed by I/O controller1140.

In one embodiment, I/O controller1140manages devices such as accelerometers, cameras, light sensors or other environmental sensors, gyroscopes, global positioning system (GPS), or other hardware that can be included in device1100, or sensors1112. The input can be part of direct user interaction, as well as providing environmental input to the system to influence its operations (such as filtering for noise, adjusting displays for brightness detection, applying a flash for a camera, or other features).

In one embodiment, device1100includes power management1150that manages battery power usage, charging of the battery, and features related to power saving operation. Power management1150manages power from power source1152, which provides power to the components of system1100. In one embodiment, power source1152includes an AC to DC (alternating current to direct current) adapter to plug into a wall outlet. Such AC power can be renewable energy (e.g., solar power, motion based power). In one embodiment, power source1152includes only DC power, which can be provided by a DC power source, such as an external AC to DC converter. In one embodiment, power source1152includes wireless charging hardware to charge via proximity to a charging field. In one embodiment, power source1152can include an internal battery or fuel cell source.

Memory subsystem1160includes memory device(s)1162for storing information in device1100. Memory subsystem1160can include nonvolatile (state does not change if power to the memory device is interrupted) or volatile (state is indeterminate if power to the memory device is interrupted) memory devices, or a combination. Memory1160can store application data, user data, music, photos, documents, or other data, as well as system data (whether long-term or temporary) related to the execution of the applications and functions of system1100. In one embodiment, memory subsystem1160includes memory controller1164(which could also be considered part of the control of system1100, and could potentially be considered part of processor1110). Memory controller1164includes a scheduler to generate and issue commands to control access to memory device1162.

Connectivity1170includes hardware devices (e.g., wireless or wired connectors and communication hardware, or a combination of wired and wireless hardware) and software components (e.g., drivers, protocol stacks) to enable device1100to communicate with external devices. The external device could be separate devices, such as other computing devices, wireless access points or base stations, as well as peripherals such as headsets, printers, or other devices. In one embodiment, system1100exchanges data with an external device for storage in memory or for display on a display device. The exchanged data can include data to be stored in memory, or data already stored in memory, to read, write, or edit data.

Connectivity1170can include multiple different types of connectivity. To generalize, device1100is illustrated with cellular connectivity1172and wireless connectivity1174. Cellular connectivity1172refers generally to cellular network connectivity provided by wireless carriers, such as provided via GSM (global system for mobile communications) or variations or derivatives, CDMA (code division multiple access) or variations or derivatives, TDM (time division multiplexing) or variations or derivatives, LTE (long term evolution—also referred to as “4G”), or other cellular service standards. Wireless connectivity1174refers to wireless connectivity that is not cellular, and can include personal area networks (such as Bluetooth), local area networks (such as WiFi), or wide area networks (such as WiMax), or other wireless communication, or a combination. Wireless communication refers to transfer of data through the use of modulated electromagnetic radiation through a non-solid medium. Wired communication occurs through a solid communication medium.

Peripheral connections1180include hardware interfaces and connectors, as well as software components (e.g., drivers, protocol stacks) to make peripheral connections. It will be understood that device1100could both be a peripheral device (“to”1182) to other computing devices, as well as have peripheral devices (“from”1184) connected to it. Device1100commonly has a “docking” connector to connect to other computing devices for purposes such as managing (e.g., downloading, uploading, changing, synchronizing) content on device1100. Additionally, a docking connector can allow device1100to connect to certain peripherals that allow device1100to control content output, for example, to audiovisual or other systems.

In addition to a proprietary docking connector or other proprietary connection hardware, device1100can make peripheral connections1180via common or standards-based connectors. Common types can include a Universal Serial Bus (USB) connector (which can include any of a number of different hardware interfaces), DisplayPort including MiniDisplayPort (MDP), High Definition Multimedia Interface (HDMI), Firewire, or other type.

In one embodiment, memory subsystem1160includes ECC1190, which can be an implementation of internal ECC with extra system bits in accordance with any embodiment described herein. ECC1190is shown as a separate element, but represents internal ECC in memory devices1162and system level ECC in memory controller1164. The internal ECC generates internal ECC bits for internal ECC, and can correct an error in read data prior to sending it to memory controller1164. ECC1190in accordance with an embodiment herein additionally allows memory controller1164and memory1162to exchange extra system bits. In one embodiment, system1100is a server device. In one embodiment in a server device, system1100can be one of multiple systems combined together in a server configuration. For example, the server can be implemented as a blade server combined with other blade servers in a chassis system.

In one aspect, a dynamic random access memory (DRAM) device includes: a memory array with addressable memory locations; an internal error checking and correction (ECC) circuit to perform internal ECC, including to generate and apply check bits within the DRAM device, wherein the memory array is to provide 2N memory locations for N+1 internal check bits for internal ECC of 2{circumflex over ( )}N data bits, where N is an integer greater than 1; and a hardware input/output interface to couple to a memory controller, wherein the input/output interface is to provide access to one or more of the (2N minus (N+1)) memory locations to the memory controller as extra bits for system ECC information, wherein the system ECC information is separate from the internal ECC.

In one embodiment, N is 8. In one embodiment, the memory array is to provide the 16 memory locations over four cachelines, wherein the four cachelines include one extra bit. In one embodiment, the memory array is to provide the 16 memory locations over four cachelines, wherein at least one of the four cachelines includes two extra bits. In one embodiment, the internal ECC circuit is to perform single bit error (SBE) correction independent of system ECC managed by the memory controller. In one embodiment, the input/output interface is to exchange data bits with the memory controller in connection with a memory access operation, wherein the extra bits are exchanged at a slower bit rate than the data bits. In one embodiment, the input/output interface is to couple in parallel with M additional DRAM devices over a data bus to the memory controller, where M is an integer greater than 1, and wherein the DRAM devices are to exchange a portion of the 2{circumflex over ( )}N data bits to the memory controller over a 2N transfer cycle burst. In one embodiment, M is 8 for nine total DRAM devices. In one embodiment, the data bus comprises a 40 bit channel, with 4 DRAM devices having a ×5 data bus interface, and 5 DRAM devices having a ×4 data bus interface. In one embodiment, the DRAM devices with the ×5 data bus interface are to exchange data bits on four of the five signal lines of the ×5 interface, and to exchange the extra bits on the fifth signal line. In one embodiment, the data bus comprises a 36 bit channel, wherein the transfer cycle burst includes at least an extra cycle burst to transfer the extra bits. In one embodiment, the memory devices comprise memory devices on a dual inline memory module (DIMM). In one embodiment, the DRAM device comprises one of multiple DRAM dies in a multichip memory package. In one embodiment, the DRAM device comprises a DRAM device compatible with a double data rate (DDR) standard.

In one aspect, a system includes: a data bus of signal lines; a memory controller coupled to the data bus; and one or more dynamic random access memory (DRAM) devices coupled to the memory controller via the data bus, the DRAM devices in accordance with any DRAM device in the previous two paragraphs. In one embodiment, the system further comprising one or more of a multicore processor coupled to the memory controller; a network adapter coupled to exchange data between the DRAM devices and a remote network location; a display communicatively coupled to a processor; or a battery to provide power to the system.

In one aspect, a method for error management in a dynamic random access memory (DRAM) device includes: performing internal error checking and correction (ECC), including generating and applying check bits within the DRAM device; providing 2N memory locations for N+1 internal check bits for internal ECC of 2{circumflex over ( )}N data bits, where N is an integer greater than 1; and providing access to one or more of the (2N minus (N+1)) memory locations to a memory controller as extra bits for system ECC information, wherein the system ECC information is separate from the internal ECC. The method can be in accordance with any embodiment of a DRAM device as set forth above.

In one aspect, an apparatus comprises means for performing operations to execute a method in accordance with the preceding method for error management. In one aspect, an article of manufacture comprising a computer readable storage medium having content stored thereon, which when accessed provides instructions to cause a computer device to perform operations to execute a method in accordance with the preceding method for error management.

In one aspect, a memory controller includes: a hardware input/output interface to couple to one or more memory devices over a data bus; transmit circuitry to transmit to the one or more memory devices for a write operation, 2{circumflex over ( )}N data bits and at least N+1 check bits over a 2N transfer cycle burst, where N is an integer greater than 1; and receive circuitry to receive from the one or more memory devices for a read operation, 2{circumflex over ( )}N data bits and at least N+1 check bits over a 2N transfer cycle burst.

In one embodiment, N is 8. In one embodiment, the number of memory devices comprises 8. In one embodiment, the receive circuitry is to receive 2N check bits. In one embodiment, the 2N check bits include (N+1) check bits generated by the memory controller for ECC (error checking and correction) of the 2{circumflex over ( )}N data bits, and up to (2N minus (N+1)) extra check bits generated based on internal ECC on the memory devices. In one embodiment, the one or more memory devices comprise memory devices on a dual inline memory module (DIMM). In one embodiment, the data bus comprises a 36 bit channel. In one embodiment, the one or more memory devices comprise a single memory device package with multiple DRAM dies. In one embodiment, the one or more memory devices comprise memory devices compliant with a double data rate (DDR) standard.

In one aspect, a method for accessing a memory includes: transmitting to one or more memory devices for a write operation, 2{circumflex over ( )}N data bits and at least N+1 check bits over a 2N transfer cycle burst, where N is an integer greater than 1; and receiving from the one or more memory devices for a read operation, 2{circumflex over ( )}N data bits and at least N+1 check bits over a 2N transfer cycle burst.

In one embodiment, N is 8. In one embodiment, the number of memory devices comprises 8. In one embodiment, receiving comprises receiving 2N check bits. In one embodiment, the 2N check bits include (N+1) check bits generated by the memory controller for ECC (error checking and correction) of the 2{circumflex over ( )}N data bits, and up to (2N minus (N+1)) extra check bits generated based on internal ECC on the memory devices. In one embodiment, the one or more memory devices comprise memory devices on a dual inline memory module (DIMM). In one embodiment, the data bus comprises a 36 bit channel. In one embodiment, the one or more memory devices comprise a single memory device package with multiple DRAM dies. In one embodiment, the one or more memory devices comprise memory devices compliant with a double data rate (DDR) standard.

In one aspect, an apparatus comprises means for performing operations to execute a method in accordance with the preceding method for accessing a memory. In one aspect, an article of manufacture comprising a computer readable storage medium having content stored thereon, which when accessed provides instructions to cause a computer device to perform operations to execute a method in accordance with the preceding method for accessing a memory.

In one aspect, a dynamic random access memory (DRAM) chip includes: a hardware input/output interface to couple in parallel with M−1 additional memory devices over a data bus to a memory controller, where M is an integer greater than 1; receive circuitry to receive from the memory controller for a write operation, (2{circumflex over ( )}N)/M data bits over a 2N transfer cycle burst, and to receive at least one of at least N+1 check bits; and transmit circuitry to transmit to the memory controller for a write operation, (2{circumflex over ( )}N)M data bits over a 2N transfer cycle burst, and to transmit at least one of at least N+1 check bits.

In one embodiment, N is 8. In one embodiment, M is 8. In one embodiment, transmitting comprises transmitting 2N check bits. In one embodiment, further comprising: an internal ECC (error checking and correction) circuit within the DRAM chip to perform ECC operations, including to generate internal check bits for error correction within the DRAM chip prior to the sending of data to the memory controller; wherein the 2N check bits include (N+1) check bits generated by the memory controller for ECC of the 2{circumflex over ( )}N data bits, and at least one extra check bit generated by the internal ECC circuit. In one embodiment, the memory devices comprise memory devices on a dual inline memory module (DIMM). In one embodiment, the data bus comprises a 36 bit channel. In one embodiment, the DRAM chip comprises one of multiple DRAM dies in a multichip memory package. In one embodiment, the DRAM chip comprises a DRAM device compliant with a double data rate (DDR) standard.

In one aspect, a method for interfacing with a memory controller includes: receiving from a memory controller for a write operation, (2{circumflex over ( )}N) divided by M data bits over a 2N transfer cycle burst, and to receive at least one of at least N+1 check bits; and transmitting to the memory controller for a write operation, (2{circumflex over ( )}N) times M data bits over a 2N transfer cycle burst, and to transmit at least one of at least N+1 check bits.

In one embodiment, N is 8. In one embodiment, M is 8. In one embodiment, the transmit circuitry is to transmit 2N check bits. In one embodiment, further comprising: an internal ECC (error checking and correction) circuit within the DRAM chip to perform ECC operations, including to generate internal check bits for error correction within the DRAM chip prior to the sending of data to the memory controller; wherein the 2N check bits include (N+1) check bits generated by the memory controller for ECC of the 2{circumflex over ( )}N data bits, and at least one extra check bit generated by the internal ECC circuit. In one embodiment, the memory devices comprise memory devices on a dual inline memory module (DIMM). In one embodiment, the data bus comprises a 36 bit channel. In one embodiment, the DRAM chip comprises one of multiple DRAM dies in a multichip memory package. In one embodiment, the DRAM chip comprises a DRAM device compliant with a double data rate (DDR) standard.

In one aspect, an apparatus comprises means for performing operations to execute a method in accordance with the preceding method for accessing a memory. In one aspect, an article of manufacture comprising a computer readable storage medium having content stored thereon, which when accessed provides instructions to cause a computer device to perform operations to execute a method in accordance with the preceding method for accessing a memory.

In one aspect, a system includes: a data bus of signal lines; a memory controller coupled to the data bus; and one or more dynamic random access memory (DRAM) devices coupled to the memory controller via the data bus; wherein the memory controller and DRAM devices are to exchange 2{circumflex over ( )}N data bits and at least N+1 check bits over a 2N transfer cycle burst for memory access operations, where N is an integer greater than 1.

In one embodiment, N is 8. In one embodiment, the memory controller and DRAM devices are to exchange 2N check bits. In one embodiment, the one or more DRAM devices further comprising: an internal ECC (error checking and correction) circuit within the DRAM devices to perform ECC operations, including to generate internal check bits for error correction within the DRAM devices prior to the sending of data to the memory controller; wherein the 2N check bits include (N+1) check bits generated by the memory controller for ECC of the 2{circumflex over ( )}N data bits, and up to (2N minus (N+1)) extra check bits generated by the internal ECC circuits of the DRAM devices. In one embodiment, the DRAM devices comprise memory devices on a dual inline memory module (DIMM). In one embodiment, the one or more DRAM devices comprise DRAM devices compliant with a double data rate (DDR) standard. In one embodiment, further comprising one or more of a multicore processor coupled to the memory controller; a network adapter coupled to exchange data between the DRAM devices and a remote network location; a display communicatively coupled to a processor; or a battery to provide power to the system.

Besides what is described herein, various modifications can be made to the disclosed embodiments and implementations of the invention without departing from their scope. Therefore, the illustrations and examples herein should be construed in an illustrative, and not a restrictive sense. The scope of the invention should be measured solely by reference to the claims that follow.