Abstract: Memory controller concepts are disclosed in which hardware resources of a memory controller can be re-used or re-configured to accommodate various different memory configurations. The memory configuration may be stored in mode register bits (228), settable by a host or operating system. By re-configuring or reallocating certain resources of a memory controller, for example command logic blocks (A, B, C, D in FIG. 1A), a single controller design can be used to interface efficiently with a variety of different memory components. Command logic blocks that support N×M memory ranks, for example, can be reconfigured to support N ranks and M threads for multi-threaded memories (FIG. 1A). Data buffer (232, 254) depth can be extended by reconfiguring the buffers responsive to the mode register bits (228). Request buffers can be shared across command logic blocks, for example to increase the request buffer depth (FIG. 3A). Unused circuits can be powered down to save power consumption (FIG. 4A).

Abstract: A multi-channel memory controller (110, 600) may be dynamically re-architected to schedule low and high-latency memory access requests differently (FIG. 12) in order to make more efficient use of memory resources and improve overall performance. Data may be duplicated or “cloned” in a clone area (612) of one or more channels of a multi-channel or module threaded memory (610), the clone area being reserved by the memory controller. Cloning information is stored in a clone mapping table 620, preferably reflecting memory channel locations, including clone locations, per memory address range. An operating system may request a selected number of channels for cloning, see (622), based on application latency requirements or sensitivity, by storing the request in the clone mapping table. Coarse granularity access requests also may be dynamically scheduled across one or more first-available channels of the multi-channel or module threaded memory (1504) in a modified controller (1500).