Fully dynamic post-package repair

Abstract

The memory controller includes a command queue, an arbiter, and a controller. In response to a repair signal for migrating data from a faulty region of the memory to a buffer, the controller generates at least one command to perform a post-package repair operation of the faulty region and migrates data from the buffer to an alternate region of the memory. The controller migrates data to and from the buffer by providing migration read requests and migration write requests to the command queue, respectively. The arbiter uses multiple arbitration rules for both read and write migration requests and read and write access requests.

Description

[Technical Field]

[0001] The present disclosure relates generally to data processing systems, and more particularly to data processing systems having highly reliable memory. [Background technology]

[0002] Modern dynamic random-access memory (DRAM) is used in most personal computer systems and servers today due to its low cost, high density, and random access time. Due to its small size, DRAM memory cells are susceptible to soft errors. Soft errors are data errors caused by the occurrence of random electrical events, such as alpha particles passing through a capacitor or electromagnetic interference. Therefore, soft errors do not reflect any fundamental error or defect in the circuit configuration. Instead, memory cells occasionally contain circuit defects that worsen over time until a memory cell or set of adjacent memory cells fails; these circuit defects are known as "hard errors." Traditionally, DRAMs are tested at the factory to detect hard errors, which are corrected by replacing failing rows or columns with redundant rows or columns. However, detecting and correcting memory cells that become defective after manufacturing is more difficult. Memory systems are typically tested for hard errors during power-up, and portions of memory with hard errors are removed from the system memory map. However, if a hard error occurs after startup, running programs may crash, causing inconvenience to the user or even loss of data.

[0003] To correct hard errors that occur after factory testing, the Joint Electron Devices Engineering Council (JEDEC) adopted a feature known as post-package repair. Post-package repair was first adopted in the double data rate version four (DDR4) specification. Post-package repair allows affected memory chips to replace defective rows with replacement rows. There are two types of post-package repair: a "soft" post-package repair uses a replacement row for the defective row while the chip is powered up, but the replacement is lost when the chip is powered down. A "hard" post-package repair permanently substitutes a replacement row for the defective row.

[0004] Before invoking the post-package repair sequence, the host processor must migrate data from the faulty row to other memory. The actual post-package repair operation requires all banks to be in a precharged state to prevent any operations from occurring. To prevent unintended post-package repair programming, double data rate, version 5 (DDR5) memory is protected by a read-modify-write guard key to prevent both hard and soft post-package repair operations from being initiated. The soft post-package repair sequence takes approximately 1 millisecond (ms), while the hard post-package repair operation takes approximately 200 ms due to the reprogramming of fuses in the memory device. After the hard post-package repair sequence completes, the host processor must migrate data back to memory before beginning reads and writes to the memory. Due to the length of time this operation and software intervention takes, significant latency is added to pending memory accesses of running programs, which can cause other system issues, such as forcing server nodes offline. [Brief explanation of the drawings]

[0005] [Figure 1] FIG. 1 is a block diagram of a data processing system according to some embodiments. [Figure 2] FIG. 1 is a block diagram of a memory controller according to some embodiments. [Figure 3] 3 is a block diagram of the dynamic post-package repair circuit of FIG. 2 according to some embodiments. [Figure 4] 3 is a flowchart of operations performed by the dynamic post-package repair circuit of FIG. 2 according to some embodiments. [Figure 5] 1 is a flowchart of a post-package repair routine according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0006] In the following description, the use of the same reference numerals in different figures indicates similar items or the presence or absence of identical counterparts. Unless otherwise stated, the word "coupled" and its related verb forms include both direct and indirect electrical connections by means known in the art, and unless otherwise stated, any description of a direct connection also refers to alternative embodiments using a suitable form of indirect electrical connection.

[0007] The memory controller includes a command queue, an arbiter, and a controller. In response to a repair signal for migrating data from a faulty region of the memory to a buffer, the controller generates at least one command to perform a post-package repair operation of the faulty region and migrates the data from the buffer to an alternate region of the memory. The controller migrates data to / from the buffer by providing migration read requests and migration write requests to the command queue, respectively. The arbiter uses multiple arbitration rules for both read and write migration requests and read and write access requests.

[0008] The data processing system includes a memory access agent, a data fabric, a memory, and a memory controller. The memory controller receives read access requests and write access requests from the memory access agent via the data fabric. The memory controller uses a plurality of arbitration rules to select from among the read access requests and the write access requests to send to the memory. In response to a repair signal, the memory controller migrates data from a faulty region of the memory to a buffer, generates at least one command to perform a post-package repair operation on the faulty region, and migrates data from the buffer to an alternate region of the memory by providing a migration read request and a migration write request, respectively. The memory controller uses a plurality of arbitration rules for both the migration read request and the migration write request and the read access request and the write access request.

[0009] The method includes selecting a request from among the read access requests and write access requests in the command queue using a plurality of arbitration rules. A corresponding memory command is provided in response to the selection. In response to the repair signal, data is migrated from a faulty region of the memory to a buffer, at least one command is generated to perform a post-package repair operation on the faulty region, and the data from the buffer is migrated to an alternate region of the memory. Migrating data to and from the buffer includes providing migration read requests and migration write requests to the command queue, respectively. The plurality of arbitration rules are used for both the read migration requests and write migration requests and the read access requests and write access requests.

[0010] 1 is a block diagram of an accelerated processing unit (APU) 100 and memory system 130 known in the prior art. APU 100 is an integrated circuit suitable for use as a processor in a host data processing system and generally includes a central processing unit (CPU) core complex 110, a graphics core 120, a set of display engines 122, a memory management hub 140, a data fabric 125, a set of peripheral controllers 160, a set of peripheral bus controllers 170, and a system management unit (SMU) 180.

[0011] CPU core complex 110 includes CPU core 112 and CPU core 114. In this example, CPU core complex 110 includes two CPU cores, but in other embodiments, CPU core complex 110 may include any number of CPU cores. Each of CPU cores 112 and 114 is bidirectionally connected to a system management network (SMN) that forms a control fabric and to data fabric 125, and is capable of providing memory access requests to data fabric 125. Each of CPU cores 112 and 114 may be a single core, or may be a core complex having two or more single cores that share certain resources, such as a cache.

[0012] Graphics core 120 is a high-performance graphics processing unit (GPU) capable of executing graphics operations such as vertex processing, fragment processing, shading, and texture blending in a highly integrated and parallel manner. Graphics core 120 is bidirectionally connected to SMN and data fabric 125 and can provide memory access requests to data fabric 125. In this regard, APU 100 may support either a unified memory architecture in which CPU core complex 110 and graphics core 120 share the same memory space, or a memory architecture in which CPU core complex 110 and graphics core 120 share a portion of the memory space, while graphics core 120 also uses private graphics memory that is not accessible by CPU core complex 110.

[0013] Display engine 122 renders and rasterizes objects generated by graphics core 120 for display on a monitor. Graphics core 120 and display engine 122 are typically bidirectionally connected to memory management hub 140 for uniform translation to appropriate addresses in memory system 130, which in turn is bidirectionally connected to data fabric 125 for generating such memory accesses and receiving read data returned from the memory system.

[0014] Data fabric 125 includes a crossbar switch for routing memory access requests and responses between any memory accessing agent and memory management hub 140. The data fabric also includes a system memory map defined by the basic input / output system (BIOS) and buffers for each virtual connection to determine where to send memory accesses based on the system configuration.

[0015] Peripheral controllers 160 include a universal serial bus (USB) controller 162 and a Serial Advanced Technology Attachment (SATA) interface controller 164, each of which is bidirectionally connected to a system hub 166 and an SMN bus. These two controllers are merely exemplary of peripheral controllers that may be used in APU 100.

[0016] Peripheral bus controller 170 includes a system controller or "Southbridge" (SB) 172 and a Peripheral Component Interconnect Express (PCIe) controller 174, each of which is bidirectionally connected to an input / output (I / O) hub 176 and the SMN bus. I / O hub 176 is also bidirectionally connected to system hub 166 and data fabric 125. Thus, for example, a CPU core can program registers in USB controller 162, SATA interface controller 164, SB 172, or PCIe controller 174 through accesses routed by data fabric 125 through I / O hub 176. Software and firmware for APU 100 is stored in a system data drive or system BIOS memory (not shown), which may be any of a variety of non-volatile memory types, such as read-only memory (ROM), flash, electrically erasable programmable ROM (EEPROM), etc. Generally, the BIOS memory is accessed via a PCIe bus, and the system data drives are accessed via a SATA interface.

[0017] SMU 180 is a local controller that controls the operation of resources on APU 100 and synchronizes communication between them. SMU 180 manages the power-up sequencing of the various processors on APU 100 and controls multiple off-chip devices via reset, enable, and other signals. SMU 180 includes one or more clock sources (not shown), such as a phase-locked loop (PLL), to provide clock signals to each of the components of APU 100. SMU 180 also manages power for the various processors and other functional blocks and can receive measured power consumption values ​​from CPU cores 112 and 114 and graphics core 120 to determine appropriate power states.

[0018] Memory management hub 140 and its associated physical interfaces (PHYs) 151 and 152 are integrated with APU 100 in this embodiment. Memory management hub 140 includes memory channels 141 and 142 and power engine 149. Memory channel 141 includes host interface 145, memory channel controller 143, and physical interface 147. Host interface 145 bidirectionally connects memory channel controller 143 to data fabric 125 via a serial presence detect (SDP) link. Physical interface 147 bidirectionally connects memory channel controller 143 to PHY 151 and, in the exemplary embodiment, conforms to the DDR PHY Interface (DFI) specification. Memory channel 142 includes host interface 146, memory channel controller 144, and physical interface 148. Host interface 146 bidirectionally connects memory channel controller 144 to data fabric 125 via another SDP. Physical interface 148 bidirectionally connects memory channel controller 144 to PHY 152 and conforms to the DFI specification. Power engine 149 is bidirectionally connected to SMU 180 via the SMN bus, to PHYs 151 and 152 via APBs, and to memory channel controllers 143 and 144. PHY 151 has a bidirectional connection to memory channel 131. PHY 152 has a bidirectional connection to memory channel 133.

[0019] Memory management hub 140 embodies a memory controller with two memory channel controllers and uses shared power engine 149 to control the operation of both memory channel controller 143 and memory channel controller 144 in a manner described further below. Each of memory channels 141 and 142 can connect to cutting-edge DDR memory, such as DDR version five (DDR5), DDR version 4 (DDR4), low power DDR4 (LPDDR4), graphics DDR version 5 (GDDR5), and high bandwidth memory (HBM), and can be adapted for future memory technologies. These memories provide high bus bandwidth and high-speed operation. At the same time, they offer low-power modes to conserve power for battery-powered applications such as laptop computers, as well as built-in thermal monitoring.

[0020] Memory system 130 includes memory channel 131 and memory channel 133. Memory channel 131 includes a set of dual inline memory modules (DIMMs) connected to DDRx bus 132, which in this example includes DIMMs 134, 136, and 138, which correspond to separate ranks. Similarly, memory channel 133 includes a set of DIMMs connected to DDRx bus 129, including representative DIMMs 135, 137, and 139.

[0021] The APU 100 acts as the central processing unit (CPU) of the host data processing system and provides various buses and interfaces useful in modern computer systems, including two double data rate (DDRx) memory channels, a PCIe root complex for connection to a PCIe link, a USB controller for connection to a USB network, and an interface to a SATA mass storage device.

[0022] The APU 100 also implements various system monitoring and power saving functions. One system monitoring function in particular is thermal monitoring. For example, if the APU 100 gets too hot, the SMU 180 can reduce the frequency and voltage of the CPU cores 112, 114 and / or the graphics core 120. If the APU 100 gets too hot, it can shut down completely. Thermal events can also be received from external sensors by the SMU 180 via the SMN bus, and the SMU 180 can reduce the clock frequency and / or power supply voltage accordingly.

[0023] Figure 2 is a block diagram of a memory controller 200 suitable for use in an APU such as Figure 1. Memory controller 200 generally includes a memory channel controller 210 and a power controller 250. Memory channel controller 210 generally includes an interface 212, a memory interface queue 214, a command queue 220, an address generator 222, a content addressable memory (CAM) 224, replay control logic 231 including a replay queue 230, refresh control logic 232, a timing block 234, a page table 236, an arbiter 238, an error correction code (ECC) check circuit 242, an ECC generation block 244, a data buffer 246, and refresh logic 247.

[0024] Interface 212 has a first bidirectional connection to data fabric 125 via an external bus and has an output. In memory controller 200, this external bus conforms to an extensible interface labeled "AXI4." Interface 212 translates memory access requests from a first clock domain known as the FCLK (or MEMCLK) domain to a second clock domain internal to memory controller 200 known as the UCLK domain. Similarly, memory interface queue 214 provides memory accesses from the UCLK domain to the DFICLK domain associated with the DFI interface.

[0025] Address generator 222 decodes addresses in memory access requests received from data fabric 125 via the AXI4 bus. Memory access requests include access addresses in the physical address space expressed in a normalized format. Address generator 222 converts the normalized addresses into a format that can be used to address actual memory devices in memory system 130 and to efficiently schedule associated accesses. This format includes a region identifier that associates the memory access request with a particular rank, row address, column address, bank address, and bank group. At startup, the system BIOS interrogates the memory devices in memory system 130 to determine their size and configuration and programs a set of configuration registers associated with address generator 222. Address generator 222 uses the configuration stored in the configuration registers to convert the normalized addresses into the appropriate format. Command queue 220 is a queue of memory access requests received from memory access agents in APU 100, such as CPU cores 112 and 114 and graphics core 120. Command queue 220 stores address fields decoded by address generator 222 and other address information that allows arbiter 238 to efficiently select memory accesses, including access type and quality of service (QoS) identifiers. CAM 224 contains information for enforcing ordering rules, such as write after write (WAW) and read after write (RAW) ordering rules.

[0026] An error correction code (ECC) generation block 244 determines the ECC for the write data sent to the memory. An ECC check circuit 242 checks the received ECC against the incoming ECC.

[0027] Replay queue 230 is a temporary queue for storing memory accesses selected by arbiter 238 awaiting responses, such as address and command parity responses. Replay control logic 231 accesses ECC check circuitry 242 to determine whether the returned ECC is correct or indicates an error. Replay control logic 231 initiates and controls a replay sequence in which accesses are replayed in the event of a parity or ECC error in any of these cycles. Replayed commands are placed in memory interface queue 214.

[0028] The refresh control logic 232 includes state machines for various power-down, refresh, and termination resistor (ZQ) calibration cycles that are generated separately from normal read and write memory access requests received from memory access agents. For example, when a memory rank is in precharge power-down, the refresh control logic must be periodically activated to perform refresh cycles. The refresh control logic 232 periodically generates refresh commands in response to defined conditions to prevent data errors caused by charge leakage from the storage capacitors of memory cells in the DRAM chip. The refresh control logic 232 includes an activation counter 248, which in this embodiment has a counter for each memory region that counts the rolling number of activation commands sent to the memory region via the memory channel. The memory region is a memory bank in some embodiments and a memory sub-bank in other embodiments, as described further below. Furthermore, the refresh control logic 232 periodically calibrates the ZQ to prevent on-die termination resistor mismatches due to thermal changes in the system.

[0029] Arbiter 238 is bidirectionally connected to command queue 220 and is the heart of memory channel controller 210, increasing efficiency through intelligent scheduling of accesses to improve memory bus utilization. Arbiter 238 uses timing block 234 to enforce the proper timing relationships by determining whether a particular access in command queue 220 is eligible for issue based on DRAM timing parameters. For example, each DRAM may have a "t RC A timing block 234 maintains a set of counters that determine eligibility based on this and other timing parameters defined in the JEDEC specification, and is bidirectionally connected to replay queue 230. A page table 236 maintains state information about active pages in each bank and rank of the memory channel for arbiter 238, and is bidirectionally connected to replay queue 230.

[0030] In response to a write memory access request received from interface 212, ECC generation block 244 calculates an ECC according to the write data. Data buffer 246 stores the write data and ECC for the received memory access request. The data buffer outputs the combined write data / ECC to memory interface queue 214 when arbiter 238 selects the corresponding write access for dispatch to the memory channel.

[0031] Power controller 250 generally includes an interface 252 to an advanced extensible interface 254, labeled "AXI," and a power engine 260. Interface 252 has a first bidirectional connection to the SMN and has an output. APB interface 254 has an input connected to the output of interface 252 and an output for connecting to the PHY via the APB. Power engine 260 has an input connected to the output of interface 252 and an output connected to the input of memory interface queue 214. Power engine 260 includes a set of configuration registers 262, a dynamic post-package repair circuit 264, labeled "DPPR CKT," a self-refresh controller 266, labeled "SELFRE / PE," and a reliable read / write timing engine 268, labeled "RRW / TE." Configuration registers 262 are programmed via the AXI bus and store configuration information for controlling the operation of various blocks within memory controller 200. Accordingly, configuration registers 262 have outputs connected to these blocks that are not shown in detail in FIG. 2. Self-refresh controller 266 is an engine that allows for manual generation of refreshes in addition to the automatic generation of refreshes by refresh control logic 232. Reliable read / write timing engine 268 provides a continuous stream of memory accesses to memory or I / O devices for purposes such as DDR interface maximum read latency (MRL) training and loopback testing.

[0032] The memory channel controller 210 includes circuitry that enables it to select memory accesses for dispatch to the associated memory channel. To make the desired arbitration decisions, the address generator 222 decodes address information into pre-decoded information, including rank, row address, column address, bank address, and bank group within the memory system, and the command queue 220 stores the pre-decoded information. The configuration registers 262 store configuration information for determining how the address generator 222 decodes the received address information. The arbiter 238 uses the decoded address information, timing eligibility information indicated by the timing block 234, and active page information indicated by the page table 236 to efficiently schedule memory accesses while adhering to other criteria, such as quality of service (QoS) requirements. For example, the arbiter 238 implements prioritization of accesses to open pages and hides overhead accesses to one bank by interleaving them with read and write accesses to another bank to avoid the overhead of precharge and activation commands required to change memory pages. In particular, during normal operation, the arbiter 238 typically keeps pages open in different banks until they need to be precharged before selecting a different page. In some embodiments, the arbiter 238 determines eligibility for command selection based on at least the respective values ​​of the activation counters 248 for the target memory regions of each command.

[0033] (Dynamic Post-Package Repair) 3 is a block diagram of dynamic post-package repair circuit 264 of FIG. 2, according to some embodiments. Dynamic post-package repair circuit 264 includes controller 310 and buffer 320. Controller 310 has four ports, including a first port for receiving signals from the SMN bus (as shown in FIG. 1) or from a port of data fabric 125, a second port connected to command queue 220, a third port connected to data buffer 246, and a fourth port (described further below).

[0034] The first port includes inputs for receiving a first signal labeled "START_DPPR" and a second signal labeled "FAIL ROW ADDRESS." Controller 310 receives the START_DPPR signal and, in response, performs a post-package repair operation on a region of memory (e.g., a row of DRAM chips on DIMM 134 of FIG. 1) having a base address indicated by the FAIL ROW ADDRESS signal. In the example shown in FIG. 3, the region is a row of DRAM chips on DIMM 134. In other embodiments, the region may be a column, a group of columns, a row, a group of rows, etc. In various embodiments, hardware circuitry within controller 310, software running on controller 310, or some combination of the two, can dynamically detect the need to perform a post-package repair. For example, this may be necessary because a memory scrubber may detect a large number of correctable errors, indicating that memory cells on a particular row of memory are likely to fail, as described in U.S. Patent No. 10,042,700. Another example is for memory controller 200 to replay read accesses to a particular row of memory a sufficient number of times to determine that there is an actual uncorrectable error.

[0035] A second port carries signals from controller 310 to command queue 220. The second port includes a command signal labeled "COM" and an address signal labeled "ADD." Controller 310 uses the COM and ADD signals to specify migration read and migration write commands, both of which are described more fully below.

[0036] A third port communicates signals between controller 310 and data buffer 246. The third port includes an input, labeled "RDDATA," for receiving read data received from data buffer 246 and an output, labeled "WRDATA," for providing write data to data buffer 246. Controller 310 uses the RDDATA signal to receive migration data for storage in buffer 320 in response to a migration read command and uses the WRDATA signal to send migration data for storage in external DRAM in conjunction with a migration write command. These operations are described more fully below.

[0037] A fourth port communicates signals between controller 310 and buffer 320. The fourth port includes an output labeled "OFFSET" for providing an address signal and a bidirectional input / output port labeled "DATA" for communicating signals. The OFFSET signal indicates the offset in buffer 320 of the data element being read from or written to buffer 320. The DATA signal communicates data being read from or written to buffer 320. Buffer 320 is large enough to store data from an entire row of DRAM being migrated from a defective physical row to an alternate physical row mapped to the address of the defective physical row. In a specific example, the DRAM is a byte-eight (x8) DRAM that stores 1K of data (1024 bits) per row, and buffer 320 is capable of storing all 1024 bits. It should be apparent that buffer 320 may be of varying sizes to support different memory widths, burst lengths, etc. In other embodiments, only a single 64-bit buffer can be used to migrate data between a defective row and another unused row in the memory system, and then, once post-package repair is complete, migrate data between the unused row and a replacement row mapped to the defective row, but this operation requires twice the memory access operations.

[0038] Generally, in response to a repair signal, e.g., START_DPPR, for migrating data from a faulty row of memory to the buffer 320, the dynamic post-package repair circuit 264 generates at least one command as a COM signal to perform a post-package repair operation for the faulty row, and migrates the data of the faulty row from the buffer 320 to an alternate row of memory mapped to the faulty row.

[0039] According to various embodiments disclosed herein, the controller 310 migrates data to and from the buffer 320 by providing migration read requests and migration write requests, respectively, to the command queue 220. Mitigation read requests and mitigation write requests are similar to regular reads and writes, except that the dynamic post-package repair circuit 264 is the destination for read data received from the external DRAM and the source for write data provided to an alternate row in the external DRAM. In this manner, the dynamic post-package repair circuit 264 offloads system software from data migration tasks. Furthermore, the memory controller 200 processes migration reads and migration writes using the same priority rules described above as regular reads and writes do. This operation allows reads and writes from other memory accessing agents to proceed toward completion while the post-package repair is being processed, avoiding a significant increase in latency.

[0040] FIG. 4 illustrates a flowchart 400 of operations performed by the dynamic post-package repair circuit 264 of FIG. 2 , according to some embodiments. The process begins at box 410. For example, an external agent such as the SMU 180 or a CPU core acting as a basic input / output system (BIOS) service processor may initiate the DPPR process by providing a START_DPPR signal. In another example, the memory controller 200 itself may track ECC errors for a region, e.g., a row, and generate the START_DPPR signal internally. In some cases, the memory controller 200 may detect and track ECC errors during normal read and write operations. In other cases, the memory controller 200 may detect and track ECC errors during background scrubbing. In yet another case, the memory controller 200 may detect and track an unacceptably high number of ECC errors for a region, i.e., the number of correctable errors exceeds a threshold, during background scrubbing by polling its error register using the DDR5 memory's automatic error check and scrub (ECS) feature. In either case, a large number of ECC errors for a row indicates that other memory cells along the row may also be beginning to fail, making the errors uncorrectable, allowing memory controller 200 to aggressively perform DPPR.

[0041] In box 420, the OFFSET for the affected region is set to 0 and the flow continues to subflow 430.

[0042] In subflow 430, data at an OFFSET from the FAIL ROW ADDRESS is read from the corresponding DRAM in action box 431. Decision box 432 determines whether there was an ECC error in the read cycle. If there was an ECC error, flow continues to decision box 433, which determines whether the error was correctable, e.g., a single error in a single-error-correcting ECC system. If the error was correctable, the data is corrected in action box 434, and flow continues to action box 437. If the data was not correctable, flow continues to action box 435. In action box 435, memory controller 200 takes one or more subsequent corrective actions. The subsequent corrective actions could be, for example, reporting the error to the BIOS, poisoning the row, a combination of the two, etc. To poison the row, memory controller 200 stores poison metadata in buffer 320, which poisons the line if the data is later written back to the row in memory. The process then proceeds to decision box 438. As shown in memory controller 200 of FIG. 2, boxes 432 through 435 are performed by ECC check circuit 242. In action box 437, the data is stored at an offset from the base in buffer 320, and flow proceeds to decision box 438. In decision box 438, OFFSET is compared to (n-1). If the offset is not equal to (n-1), flow proceeds to action box 439, where OFFSET is incremented (i.e., OFFSET = OFFSET + 1), and flow returns to action box 431. If OFFSET is equal to (n-1), flow proceeds to action box 440.

[0043] Action box 440 executes the post-package repair sequence of FIG. 5, which is described in more detail below.

[0044] In action box 450, data is written, one element at a time, from buffer 320 to the alternate row that is mapped to the address of the failed row. The procedure ends in box 460.

[0045] FIG. 5 is a flowchart 500 of a post-package repair subflow according to some embodiments. While the data processing system of FIG. 1 uses DDR5 DRAM, DDR5 is merely an example, and a corresponding flow according to the operations described herein may be used for different DRAMs that also support post-package repair. The flow begins at box 510. In action box 520, memory controller 200 precharges all banks of the affected memory chips and enables them to update their mode registers. In action box 530, memory controller 200 disables data bus inversion (DBI) mode and cyclic redundancy check (CRC) mode for the affected DRAMs by writing to specific mode register bits as defined by the relevant standard. In action box 540, memory controller 200 transitions the affected memory chips into post-package repair mode by setting one or more mode register bits defined by the relevant standard. Between action boxes 530 and 540, note that some DRAMs require an extended unlock sequence before post-package repair can be enabled to prevent random software errors from causing unexpected post-package repair operations. In action box 550, the affected DRAMs perform post-package repair operations. In action box 560, memory controller 200 causes the affected memory chips to exit post-package repair mode by clearing the associated mode register bit(s). In action box 570, flow returns to the main flow shown in flowchart 400, specifically action box 450.

[0046] Thus far, a system for dynamic post-package repair by a memory controller has been described. In this system, the memory controller, and in particular the dynamic post-package repair circuitry, migrates data from the failed row to a buffer 320. This is done by using mitigation read commands (to store the data in a buffer, such as an on-chip buffer) and mitigation write commands (to rewrite the data to an alternate row mapped to the address of the failed row) that are provided to a command queue for arbitration using the same arbitration rules as normal read and write requests. Thus, the memory controller performs the post-package repair operation in hardware, and does so without sacrificing efficiency or significantly increasing latency by allowing an arbiter to schedule migration read and migration write requests along with normal read and write requests.

[0047] The data processing system 600 of FIG. 6 , or any portion thereof, may be described or represented by a computer-accessible data structure in the form of a database or other data structure that can be read by a program and used directly or indirectly to fabricate an integrated circuit. For example, the data structure may be a behavioral or register transfer level (RTL) description of hardware functionality in a high-level design language (HDL) such as Verilog or VHDL. The description may be read by a synthesis tool that can synthesize the description to generate a netlist that includes a list of gates from a synthesis library. The netlist comprises a set of gates that also represent the functionality of the hardware comprising the integrated circuit. The netlist may then be placed and routed to generate a data set that describes the geometric shapes to be applied to a mask. The mask may then be used in various semiconductor manufacturing processes to fabricate the integrated circuit. Alternatively, the database on the computer-accessible storage medium may be a netlist (with or without a synthesis library) or a data set, or Graphic Data System (GDS) II data, if desired.

[0048] While specific embodiments have been described, various modifications to these embodiments will be apparent to those skilled in the art. Various versions of DDR memory that support post-package repair may be used, such as DDR4, DDR5, and LPDDR4. The buffer used to temporarily store the data to be migrated may be located on-chip in the memory controller or in a separate, unused row in the system memory. The actual post-package repair command sequence varies between DRAM versions and manufacturers and may include an extra unlock cycle due to the persistence of the post-package repair operation. In the illustrated embodiment, the unit of repair is the row, but in other embodiments, the unit may be a different size. The number of rows available for repair varies between manufacturers and may be based on rows for each bank group, for example. The specific arbitration rules common between normal read and normal write requests and migration read and migration write requests vary between embodiments and memory controller designs. In some embodiments, the set of common arbitration rules between normal read and normal write requests and migration read and migration write requests is less than the entire set of arbitration rules used with either type of request. In various embodiments, a memory controller interfacing to a memory that supports full dynamic post-package repair may perform only soft post-package repair, only hard post-package repair, or both. Furthermore, while the exemplary embodiments are disclosed in the context of an APU, the techniques are also useful for memory controllers used in servers and other high-end computing products.

[0049] Therefore, it is intended that the appended claims cover all modifications of the disclosed embodiments that fall within the scope of the disclosed embodiments.

Claims

1. A memory controller, A command queue; an arbiter coupled to the command queue; a controller that, in response to a repair signal for migrating data from a faulty area of ​​memory to a buffer, generates at least one command to perform a post-package repair operation for the faulty area and migrates the data from the buffer to an alternate area of ​​the memory; The controller provides migration read access requests and migration write access requests to the command queue; the arbiter uses the same arbitration rules for both the migration read access requests and the migration write access requests and for normal read and normal write access requests; Memory controller.

2. the failure region comprises a first row, and the replacement region comprises a second row mapped to an address of the first row; The memory controller of claim 1 .

3. the command queue receives the normal read access requests and the normal write access requests from a plurality of memory access agents; The memory controller of claim 1 .

4. the memory controller poisons the faulty region if any of the migration read access requests causes an uncorrectable error; The memory controller of claim 1 .

5. the memory controller generates the repair signal in response to detecting a number of correctable errors exceeding a threshold during normal read and normal write operations; The memory controller of claim 1 .

6. the memory controller generating the repair signal in response to polling a memory configured to detect a number of correctable errors during read and write operations that exceeds a threshold; The memory controller of claim 1 .

7. the memory controller corrects the error in the data by storing the corrected data in the buffer if any of the migration read requests causes a correctable error; The memory controller of claim 1 .

8. 1. A data processing system comprising: a memory access agent; Data Fabric and Memory and a memory controller that receives read access requests and write access requests from the memory access agents via the data fabric and selects from among the read access requests and the write access requests to be sent to the memory using a plurality of arbitration rules; the memory controller migrates data from a faulty region of the memory to a buffer in response to a repair signal, generates at least one command to perform a post-package repair operation on the faulty region, and migrates the data from the buffer to an alternate region of the memory by providing a migration read request and a migration write request, respectively; the memory controller uses the plurality of arbitration rules for both the migration read request and the migration write request, and the read access request and the write access request. Data processing system.

9. The memory controller A command queue; an arbiter that uses the plurality of arbitration rules to select from among the read access requests and the write access requests in the command queue to provide a corresponding memory command; a controller that, in response to the repair signal for migrating the data from the faulty area of ​​the memory to the buffer, generates the at least one command to cause the memory to perform the post-package repair operation for the faulty area and migrates the data from the buffer to the replacement area of ​​the memory; the controller migrates the data to the buffer by providing the migration read request to the command queue and migrates the data from the buffer by providing a migration write request to the command queue; the arbiter uses the plurality of arbitration rules for both the migration read requests and the migration write requests and the read access requests and the write access requests.

9. The data processing system of claim 8.

10. the command queue receives the read access requests and the write access requests from a plurality of memory access agents; 10. The data processing system of claim 9.

11. the command queue, the arbiter, the controller, and the buffer are combined on a single semiconductor chip; 10. The data processing system of claim 9.

12. the memory controller providing an error signal to a basic input / output system (BIOS) if any of the migration read requests causes an uncorrectable error.

10. The data processing system of claim 9.

13. the memory controller corrects the error in the data by storing the corrected data in the buffer if any of the migration read requests causes a correctable error; 10. The data processing system of claim 9.

14. the data fabric includes a background scrubber that activates the repair signal in response to detecting a number of correctable errors in the failure domain that exceeds a threshold.

14. The data processing system of claim 13.

15. the failure region comprises a first row, and the replacement region comprises a second row mapped to an address of the first row; 9. The data processing system of claim 8.

16. 1. A method comprising: selecting a request from among the read and write access requests in the command queue using a plurality of arbitration rules; In response to said selecting, providing a corresponding memory command; Depending on the repair signal, moving data from a faulty region of memory to a buffer; generating at least one command to perform a post-package repair operation on the faulty region; migrating the data from the buffer to an alternate area of ​​the memory, wherein migrating the data to the buffer includes providing a migration read request to the command queue and migrating the data from the buffer includes providing a migration write request to the command queue; and using the plurality of arbitration rules for both the migration read request and the migration write request, and the read access request and the write access request. method.

17. the failure region comprises a first row, and the replacement region comprises a second row mapped to an address of the first row; 17. The method of claim 16.

18. receiving the read access requests and the write access requests from a plurality of memory access agents; 17. The method of claim 16.

19. providing an error signal to a basic input / output system (BIOS) if any of the migration read requests generates an uncorrectable error.

17. The method of claim 16.

20. correcting errors in said data; the correcting includes storing corrected data in the buffer if any of the migration read requests causes a correctable error.

17. The method of claim 16.

Images