Patent Description:
Memory latency and bandwidth are significant performance bottlenecks in many processing systems. These performance factors typically are impacted by memory cell access times and the propagation delays of signals traversing various interconnects within the memory. In conventional memory controller implementations, a worst-case approach is taken for scheduling memory accesses to a memory subsystem whereby the memory controller assumes fixed worst-case memory timing parameters that apply to the entire memory subsystem.

<CIT> discloses stacked-die memory systems and methods for training stacked-die memory systems. <CIT> discloses a method for accessing a memory device having pages by a memory interface that does not directly support page accesses. <CIT> discloses dynamic control of memory access speed. <CIT> discloses a mechanism for updating memory controller timing parameters during a frequency change.

According to the invention, there is provided an integrated circuit device according to claim <NUM> and a method according to claim <NUM>.

<FIG> illustrate example techniques for reducing latency and improving bandwidth and power efficiency of a memory subsystem of a processing system or other electronic device through the use of memory access scheduling based on region-specific memory timing parameters. Various factors, such as variations in the semiconductor fabrication process, device temperature, and aging effects, can cause the memory cell access times and signal propagation times to vary significantly for memory accesses to different regions of a memory, which becomes particularly pernicious when the supply voltage scales down to the transistor threshold voltage (Vth) level for the purposes of power reduction. In conventional systems, these performance variations are typically managed by selecting conservative timing parameters based on worst-case scenarios and using these same conservative timing parameters for each memory access, regardless of the region targeted by the memory access. In contrast, in some embodiments, a memory controller more efficiently schedules memory accesses by profiling one or more memory timing parameters for each region of multiple regions of a memory, saving the measured timing parameters to a timing data store and then scheduling memory accesses to the memory based on the profiled region-specific memory timing parameters associated with the regions targeted by the memory accesses. Thus, the memory controller can reduce latency and improve power efficiency of a memory subsystem by exploiting the performance variations among different regions of the memory such that the timing and sequencing of the memory accesses reflect the different memory timings exhibited by the different memory regions. The granularity of the profiled memory regions can include, for example, sets ofone or more cells,rows, banks, ranks, chips, memory modules (e.g., dual inline memory modules or "DIMMS"), channels, and the like.

Stacked-die, or three-dimensional (3D), dynamic random access memory (DRAM)-based memory subsystems often are considered for use as large on-chip caches. However, due to certain aspects of the DRAM architecture, due to die-to-die process variation, and due to the interconnect configurations resulting the stacked arrangement of the memory dies in a stacked-die memory, such memory subsystems often exhibit significant region-to-region variations in memory timing. This, in conjunction with ability to locally store memory timing information on a region-by-region basis makes stacked-die memory well suited for region-based memory access scheduling. Accordingly, example region-based memory access scheduling techniques are described herein in the example context of stacked-die DRAM memory. However, these techniques are not limited to this example context, but also are equally applicable to any variety of stacked or non-stacked memory architectures including, but not limited to, static random access memory (SRAM), ferroelectric RAM (F-RAM), magneto-resistive RAM (MRAM),Phase-Change RAM, resistive RAM, Flash memory, and the like.

<FIG> illustrates an example processing system <NUM> implementing region-based memory access scheduling in accordance with some embodiments. The processing system <NUM> can comprise any of a variety of processing systems, including a notebook or tablet computer, a desktop computer, a server, a network router, switch, or hub, a computing-enabled cellular phone, a personal digital assistant, a gaming console, and the like. The processing system <NUM> may be implemented on a single die or on multiple dies including a plurality of stacked die as shown later examples.

In the depicted example, the processing system <NUM> includes one or moreprocessors <NUM>, one or morememory controllers <NUM>, and a memory array <NUM>. The processor <NUM> includes one or more processor cores <NUM>, such as one or more central processing units (CPU), graphics processing units (GPU), digital signal processors (DSP), and the like. The processor <NUM> further includes an integrated northbridge <NUM>, an input/output (I/O) controller <NUM>, one or more levels of cache <NUM>, and the like. The northbridge <NUM> is connected to the memory controller <NUM> via host bus <NUM>. The host bus <NUM> can be implemented in accordance with any of a variety of conventional interconnect or bus architectures, such as a Peripheral Component Interconnect - Express (PCI-E) architecture, a HyperTransport architecture, a QuickPath Interconnect (QPI) architecture, and the like. Alternatively, host bus <NUM> can be implemented in accordance with a proprietary bus architecture. The I/O controller <NUM> can be connected to one or more external devices <NUM>, such as one or more external interfaces to display components, storage devices, input devices (e.g., a mouse or keyboard), and the like.

The processing components of system <NUM> are coupled to a memory subsystem comprised of the memory controller <NUM> and the memory array <NUM>. The memory array <NUM> may implement any variety of storage devices including, but not limited to, memory architectures such as dynamic random access memory (DRAM), static random access memory (SRAM), ferroelectric RAM (F-RAM) magneto-resistive RAM (MRAM) and the like. For the purposes of this disclosure, various embodiments are described in the context of DRAM arrays and DRAM memory controllers. In this example context, the memory array <NUM> comprises a plurality of DRAM arrays <NUM>. As described in detail below, the memory subsystem may be implemented as stacked-die memory devices and thus the DRAM arrays <NUM> may be implemented as, for example, separate memory die within the stacked-die memory.

In operation, the memory controller <NUM> services memory read and memory writerequests issued by the processing elements of the processing system <NUM>. To this end, thememory controller102 implements controller logic <NUM> for accessing the DRAM arrays <NUM> and for interfacing with the host bus <NUM>. In response to memory access requests, the controller logic <NUM> issues commands to the DRAM arrays <NUM>. In response to a read request for a corresponding address, the controller logic 108transmits signaling to the DRAM arrays <NUM> to read stored data at the addressed location. In response to a write request, the controller logic <NUM> transmits signaling to the DRAM arrays <NUM> to write data to the addressed location.

The correct operation of each memory transaction is predicated on the controller logic <NUM> adhering to certain memory timing parameters, such as the RAS precharge, or "tRP" timing parameter, which reflects the time needed between disabling access to one line of data and enabling access to another line of data. In implementation, some or all of the memory timing parameters may vary depending on the region of the memory array <NUM> being accessed. Accordingly, in some embodiments, the controller logic <NUM> is configured to buffer, reorder,or schedule memory requests based on region-specific memory timing parameters so as to improve performance and efficiency. To this end, the memory controller <NUM> also implements profiling logic <NUM> and a timing data store <NUM> to determine and store region-specific memory timing information. As described in more detail below with reference to <FIG> and <FIG>, in some embodiments, theprofiling logic <NUM> evaluates each memory region of a set of one or more memory regions of the memory array <NUM> to determine one or more memory timing parameters specific to that region. The memory timing information for the region then may be maintained in the timing data store <NUM>, which can comprise any of a variety of storage mechanisms, such as a memory array, a set of registers or a cache, a bloom filter, a content addressable memory (CAM), and the like. The granularity of the regions of the memory array <NUM> so analyzed can include, but is not limited to,cell-based regions, bank-based regions, row-based regions, channel-based regions, chip-based regions, memory-module-based regions, and the like, as well as combinations thereof.

In response to a trigger event, the profiling logic <NUM> initiates a test process to measure the corresponding memory timing parameters for each region of the applicable regions of the memory array <NUM>. This trigger event can include, for example, a power-on reset, a lapse of a timer, a command from the processor <NUM> or other controller, a sensed change in temperature that exceeds a threshold (and thereby indicating a likely temperature-induced change in the timing parameters),a trigger initiated during a dynamic voltage and frequency scaling (DVFS) operation,and the like. The test process can include, for example, repeatedly writing and subsequently accessing a test pattern to the corresponding region while varying the values for the applicable memory timing parameters. The timing parameters could be also updated byperforming a lookup to atable that maintainslatency values under different temperature or service times or stores representations of formulae that may be used to calculate the latency using temperature and service time as an input. When reliable minimum memory timing parameters are identified for the region via this test process, the profiling logic <NUM> can store data representative of these identified memory timing parameters to the timing data store <NUM>. In some embodiments, the timing data store <NUM> is implemented as a set of registers, cache, or CAM and the data is stored in a location associated with the region. In other embodiments, the timing data store <NUM> is implemented as a bloom filter or other compressed data structure, and this data is incorporated into the compressed data structure accordingly.

In the course of typical operation, the memory parameter timing information is accessible from the timing data store <NUM> by the controller logic <NUM>. In response to receiving a memory access request from the processor <NUM>, the controller logic <NUM> uses the address targeted by the memory access request to access the memory timing information associated with the region associated with the targeted address. With this region-specific memory timing information, the controller logic <NUM> canmanage the timing of memory commands sent to the memory array <NUM> according the stored memory timing parameters for a given region of memory so as to more efficiently schedule memory accesses. For example, when a memory read request is received by the memory controller <NUM>, the controller logic <NUM> identifies the region of memory to be accessed based on the address of the memory read request and then communicates with the profiling logic <NUM> and timing data store <NUM> to determine the memory timing parameters to that region. The controller logic then schedules and transmits commands to DRAM arrays <NUM> according to thestored timing parameters. As described in great detail below with reference to <FIG>, this command scheduling also includes ensuring there are no resource conflicts such as data bus collisions due to multiple accesses with different timings.

Significant variations in memory timing parametersare often encountered in stacked arrangement of memory dies. Memory controllers implementing region-based memory access scheduling techniques are able to exploit these variations to more efficiently schedule memory requests and are thus well-suited to stacked arrangements of memory die.

<FIG> illustrates an exploded perspective view of an example implementation of the processing system <NUM> as a stacked-die processing system 200in accordance with some embodiments. In the depicted example, the stacked-die processing system <NUM> includes a plurality of dies, such as dies <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> (collectively referred to herein as "dies <NUM>-<NUM>"), stacked in the illustrated vertical arrangement and interconnected via through silicon vias (TSVs) <NUM>. In the illustrated example, stacked memory dies <NUM>, <NUM>, <NUM>, and <NUM> implement the memory cell circuitry <NUM> that forms the DRAM arrays <NUM> (<FIG>) of the memory array <NUM> (<FIG>). The dies <NUM>-<NUM> thus are referred to herein as "memory dies. " While described in the example context of DRAM, the memory cell circuitry <NUM> may implement any variety of memory architectures including, but not limited to, DRAM, static random access memory (SRAM), read-only memory (ROM), flash memory ferroelectric RAM (F-RAM), magneto-resistive RAM (MRAM) and the like.

The die <NUM> implements the processing components of the processor <NUM> as described above, including one or more processor cores <NUM> and <NUM> and a cache <NUM>, and is thus referred to herein as the "processor die <NUM>". The die <NUM> implements the memory controller <NUM>, which includes the profiling logic <NUM>. The memory controller <NUM> implements hardwired logic for accessing the memory circuitry of stacked die <NUM>-<NUM> as well as interfacing to the die <NUM> to service read and write memory access requests. The dies <NUM> and <NUM> also can include any of a variety of peripheral devices such as northbridges, southbridges, input/output controllers, network interfaces, and the like. The dies <NUM> and <NUM> thus are referred to herein as "logic dies.

The timing data store <NUM> may be implemented as a cache, CAM, bloom filter, or register set on a logic die of the stacked-die processing system <NUM>. To illustrate, the timing data store <NUM> may be implemented as non-volatile memory (e.g., flash memory) on die <NUM> along with the other components of the memory controller <NUM> to facilitate timely access to the memory timing information by the profiling logic and controller logic <NUM> of the memory controller <NUM>. In other embodiments, stacked-die processing system <NUM> can take advantage of the sizeable storage capacity of the memory array <NUM> by implementing the timing data store <NUM> in the memory cell circuitry <NUM> of one or more of the memory dies. In yet other embodiments, the timing data store <NUM> may be implemented using both logic die and memory die. To illustrate, the timing data store <NUM> may be implemented as a small cache on a logic die and a larger cache on a memory die, with the small cache storing the memory timing information for the most recently accessed regions of memory and larger cache storing the memory timing information for all of the memory regions.

In some embodiments, the components of the processor <NUM> and the memory controller 102may be partitioned in other combinations across multiple dies or implemented on single die. To illustrate, the memory controller <NUM> and the processor <NUM> may be implemented on the samedie. As another example, the processor <NUM> may be implemented on one die, the controller logic <NUM> (<FIG>) and the memory interface <NUM> (<FIG>) implemented on a second die, and the profiling logic <NUM> and timing data storeimplemented on a third die.

Stacked memory subsystems typically employ a separate logic layer to implement the memory controller and related logic functions so that a different semiconductor fabrication process can be used to fabricate the logic dies <NUM> than that used to fabricate the memory layers <NUM>-<NUM>. Accordingly, the vertical die stack of processing system <NUM> may be fabricated using any of a variety of 3D integrated circuit fabrication processes. In one approach, the die <NUM>-<NUM> each are implemented as a separate substrate (e.g., bulk silicon) with active devices and one or more metal routing layers formed at an active surface. This approach can include a wafer-on-wafer process whereby a wafer comprising a matrix of dice is fabricated and thinned, and TSVs are etched through the bulk silicon. Multiple wafers are then stacked to achieve the illustrated layer configuration (e.g., a stack of four wafers comprising memory circuitry die for the three memory layers and a wafer comprising the logic die for a logic layer), aligned, and then joined via thermocompression. The resulting stacked wafer set is singulated to separate the individual 3D IC devices.

In a die-on-die process, the wafer implementing each corresponding layer is first singulated, and then the die are separately stacked and joined to fabricate the 3D IC devices. In a die-on-wafer approach, wafers for one or more layers are singulated to generate the die for one or more layers, and these die are then aligned and bonded to the corresponding die areas of another wafer, which is then singulated to produce the individual 3D IC devices. One benefit of fabricating the die <NUM>-<NUM> on separate wafers is that a different fabrication process can be used to fabricate the logic layers (die <NUM>-<NUM>) than that used to fabricate the memory die (die <NUM>-<NUM>). Thus, a fabrication process that provides improved performance and lower power consumption may be used to fabricate dies <NUM> and <NUM> (and thus provide faster and lower-power interface logic and circuitry for the memory controller <NUM> and profiler <NUM>), whereas a fabrication process that provides improved cell density and improved leakage control may be used to fabricate the dies <NUM>-<NUM> (and thus provide more dense, lower-leakage bitcells for the stacked memory).

In another approach, the layers <NUM>-<NUM> are fabricated using a monolithic 3D fabrication process whereby a single substrate is used and each die layer is formed on a preceding die layer using a layer transfer process, such as an ion-cut process. The stacked memory device also may be fabricated using a combination of techniques. For example, logic layers (dies204 and <NUM>) may be fabricated using a monolithic 3D technique, the memory layers (dies <NUM>-<NUM>) may be fabricated using a die-on-die or wafer-on-wafer technique, or vice versa, and the resulting logic layer stack and memory layer stack then may be bonded together and then to bonded to the interposer substrate.

Although the processing system <NUM> and the processing system <NUM> each implement a single instance of memory controller <NUM>, in other embodiments multiple memory controllers may be implemented in order to increase system performance, with each memory controller controlling separate portions of system memory. Each of the multiple memory controllersmay implementseparate instances of the region-based memory access scheduling techniques described herein.

<FIG> is a diagram illustrating an exploded perspective view of an example implementation of the processing system <NUM> as a stacked-die processing system <NUM> with multiple memory controllers in accordance with some embodiments. In the depicted example, the stacked-die processing system 300is configured in a side-split arrangement that includes a die <NUM> and a vertically-stacked memory subsystem comprised of dies <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> (collectively, "dies <NUM>-<NUM>"). The die <NUM> implements the components of the processor <NUM>, including one or more processor cores <NUM> and <NUM>, a cache <NUM>, and the like. In the illustrated example, dies <NUM>-<NUM> implement the memory cell circuitry <NUM> of thememory array <NUM> (<FIG>). A host bus <NUM> connects the die <NUM> and the die <NUM>. The die <NUM> implements two memory controllers <NUM> and <NUM> (embodiments of the memory controller <NUM>, <FIG>) as well as profiling logic <NUM> and profiling logic <NUM> (embodiments of the profiling logic <NUM>, <FIG>). Each of the memory controllers <NUM> and <NUM> controlcorresponding independent portions of the attached memory arrays in order increase memory bandwidth and throughput. The profiling logic <NUM> operates to maintain memory timing information for the regions of the memory array <NUM> served by the memory controller <NUM> and the profiling logic <NUM> operates to maintain memory timing information for the regions of the memory array <NUM> served by the memory controller <NUM>.

The depicted processing system <NUM> may be implemented with a variety packaging techniques. In some embodiments, memory subsystem implemented as dies <NUM>-<NUM> may be implemented as a separate vertical stack, horizontally disposed on the surface of an interposer along with die <NUM>. In this embodiment, the host bus <NUM> can include conductors implemented in themetal layers of the interposer. In another embodiment, the processor die <NUM> and the stack of dies <NUM>-<NUM> may be contained in separate integrated circuit (IC)packages. In such implementations, the IC packages may be placed on a circuit board or similar substrate and the host bus <NUM> implemented using conductors of the circuit board, including pads, pins, traces, vias, solder bumps and the like.

<FIG> is a diagram illustrating a more detailed implementation of the memory controller <NUM> in accordance with some embodiments. In the depicted example, the memory controller <NUM> includes a host interface <NUM>, an arbiter <NUM>, profiling logic <NUM> (corresponding to the profiling logic <NUM>, <FIG>), a timing data store <NUM> (corresponding to the timing data store <NUM>, <FIG>), a command (CMD) input queue <NUM>, a write queue <NUM>, a read queue <NUM>, a scheduler <NUM>, and a physical interface (PHY) <NUM>. The arbiter, queues <NUM>, <NUM>, and <NUM>, and the scheduler <NUM> together form the controller logic <NUM> (<FIG>). A host bus <NUM> couples thehost interface <NUM> to the processor <NUM> (<FIG>), wherebythe host interface404 receives and buffers signaling representative of memory accessrequests transmitted over the host bus <NUM> to the memory controller <NUM>. The host interface also transmits memory access request responses to the processor <NUM> via the host bus402. The arbiter <NUM> receives memory access requests from the host interface <NUM> and from the profiling logic <NUM>, and resolves conflicts for the command input queue <NUM> and the write queue <NUM>, which buffer multiple commands and memory write requests, respectively. These commands and write requests are stored in-order but may be selected and executed on out-of-order to improve performance. The read queue <NUM> buffers responses to memory read requests, prior to being selected by the arbiter <NUM> for transmission to the host interface <NUM>.

The scheduler <NUM> selects memory access requests from queues <NUM> and <NUM> and translates those requests into DRAM command sequences. In some embodiments, the scheduler420 implements aset of algorithms and heuristics for reordering queued memory access requests. These algorithms and heuristics may consider DRAM structure such as banks, rows and columns, as well as region-specific memory timing parameters in order to generate a schedule of access to the memory array <NUM> (<FIG>) via the PHY <NUM>. By re-ordering the memory requests, the scheduler <NUM> can reduce latency and improve bandwidth of the memory subsystem.

Each DRAM operationgenerates different demands and claims on various DRAM resources such as the internal banks, address lines and data lines. When creating a schedule of memory access requests, the scheduler <NUM> takes into account potential resource conflicts and ensures that the required resources are available at the appropriate time. In addition to considering resource constraints, the scheduler 420also generates a schedule that conforms to the DRAM timing constraints and timing parameters in order to ensure correct operation. Examples of DRAM timing parameters considered by the scheduler <NUM> include, but are not limited to: the row to column command delay (tRCD) parameter, the time between column command and data out (tCL) parameter, the time between column commands (tCCD) parameter, the precharge time (tRP) parameter, and the minimum row open time (tRAS) parameter.

In conventional systems, these memory timing parameters are typically loaded into the memory controller and applied for scheduling memory access requests without specific regard to the region of memory being accessed. However, as described above, the memory controller <NUM>, in some embodiments, considers the memory timing parameters on a region-by-region basis when scheduling memory access requests. To this end, the profiling logic <NUM> implements logic to test and measure one or more of the memory timing parameters for each region of a set of regions of the memory array <NUM>. For a DRAM implementation, DRAM timing parameters measured may include, but are not limited to tRCD(row to column command delay), tCL (time between column command and data out), tCCD (time between column commands), tRP (precharge time), tRAS (minimum row open time), tFAW (multi-bank activation window), tWTR (time between read and write), tWR (write recovery time), and the like. For arrays utilizing memory technologies other than DRAM, the timing information may include other timing parameters as appropriate for those types of memory. The profilinglogic410 may accomplish measurement of timing parameters by generating sequences of memory read and memory write commands and observing the results while varying the parameter being tested. In the depicted example, the profiling logic <NUM> generates sequences of commands and sends them to the arbiter <NUM> to be eventually placed into the queues <NUM> and <NUM>. In other embodiments, the memory controller <NUM> may implement separate queues for the testing sequences generated by the profilinglogic410. The regions of the memory array <NUM> may be cell-based, row-based, bank-based, rank-based, chip-based, and the like. Moreover, the profiling logic <NUM> may maintain different levels of region granularity. For example, the profiling logic <NUM> may determine DRAM timing parameters that apply to each row of one bank, but determine DRAM timing parameters on a sub-regions of another bank (e.g., based on a row-by-row basis for the other bank). In such instances, a sub-region is a smaller unit of granularity compared to the corresponding region (e.g., a sub-region of a bank region could be a row, a sub-region of a row region could be a bit cell or a subset of the bit cells of the row, etc.) Moreover, the granularity of the memory region may depend on the memory timing parameters. For example, the profiling logic <NUM> may track the tRP parameters on a bank-by-bank basis while tracking the tRCD parameters on a row-by-row basis.

The region-by-region timing parameter analysis may be triggered by any of a variety of trigger events. For example, the profiling logic <NUM> may include one or more static or configurable trigger timers to initiate periodic reevaluation. As another example, the trigger events can include certain system events or signaling directed by other system components, such as reevaluation signaling initiated by an operating system, hypervisor, basic input output system (BIOS), firmware or a combination thereof. To illustrate, at system boot-up the BIOS may direct the profiling logic 410to perform an initial set of measurements early in the boot process and then periodically at some pre-determined interval. In another example, detection of a correctable or uncorrectable memory error may cause the operating system or hypervisor to trigger the profiling logic <NUM>. As circuit operation often is influenced by temperature, the profiling logic <NUM> may use a temperature threshold or a temperature change threshold trigger to initiate reevaluation of the memory timing parameters.

The timing data store412 receives and stores the DRAM timing parameters generated by the profiling logic <NUM> so as to be subsequently accessible by scheduler <NUM>. In some embodiments, this timing information may be stored as the actual value of the parameter. For example, the tRP parameter stored for a given row may be the actual number of cycles required to recharge the given row. Alternatively, the timing information may be categorized into several levels or bins, and an indication of the bin number is stored. For example the tRPparameter could be classified into <NUM> levels or bins, such as:<=<NUM> cycles; <NUM>-<NUM> cycles; <NUM>-<NUM> cycles;and <NUM>-<NUM> cycles.

The timing data store412may be implemented by any number of storage mechanisms, including but not limited to bloom filters, content addressable memory (CAMs), caches, registers and the like. The storage mechanism may be chosen based on the size and number of stored parameters in order to reduce storage space. In some embodiments, the timing data store412 may implement different types of storage (bloom filters, CAM arrays and such) for each timing parameter tracked by the profiling logic410. To illustrate, a bloom filter may be used to store a binned tRP value as described above. One bloom filter is implemented for each tRP bin. Bloom filter <NUM> represents bin <NUM>, bloom filter <NUM> represents bin <NUM> and so on. In operation, the profiling logic <NUM> determines that the tRP for say, row <NUM>, is classified into the second bin. The profilinglogic <NUM> sends the row number and bin number to the timing data store412. The timing data store412 enters the index of row <NUM> into the second tRPbloom filter. Later in subsequent operations, the scheduler <NUM> may consult the timing data store <NUM> to determine the tRP for row <NUM>. It sends the row number (<NUM>) and an indication of the requested parameter (tRP) to timing data store <NUM>. The timing data store <NUM> consults the tRP bloom filters, and returns the tRP bin for row <NUM> back to the scheduler <NUM>.

With the region-by-region memory timing parameters identified and stored in the timing data store <NUM>, the scheduler <NUM> may utilize the stored region-based memory timing parameters to more optimally schedule memory access requests based on the regions they target. Thus, in response to receiving a memory access request to a target address, the scheduler <NUM> accesses from the timing data store <NUM> the DRAM timing parameters associated with the region containing the target address, and uses the accessed DRAM timing parameters rather than (or in addition to) memory-wide timing parameters to generate more optimized memory access schedules. For example, the tRCD (the row to column command delay) timing parameter is a fundamental portion of the overall latency of a DRAM read operation. tRCD represents the minimum delay required between an `activation row' DRAM command and the subsequent `column read' DRAM command. Supposefor a given banktRDC is <NUM> cycles for some rows and is <NUM> cycles for other faster rows. A conventional memory controller would use the most conservative timing oftRCD=<NUM> for all rows. In contrast, the present invention having stored data representative of tRCD for each row in the timing data store <NUM>, allows the scheduler <NUM> to utilizetRCD=<NUM> for the faster rows, thus reducing by one cycle the latency of a DRAM read operation to those rows. The profiling logic <NUM> implements logic to test and measure one or more of the memory timing parameters for each region of a set of regions of the memory array <NUM>.

<FIG> is a flow diagram illustrating a method <NUM> of profiling a memory performance parameter on a region-by-region basisin accordance with some embodiments. For ease of illustration, the method <NUM> is described in the example context of the memory controller block <NUM> as shown in <FIG>, and for determining the tCL memory timing parameter as specified for DRAM architectures. A similar process may be implemented to measure other memory timing parameters, such as tRCD, tCCD, tRP, and tRAS, tFAW, tWTR, and tWRparameters.

At block <NUM>, the profiling logic <NUM> initiates the region-by-region memory profiling in response to a trigger event, such as an interval timeout or other system event as described earlier. At block <NUM>, the profiling logic <NUM> selects a DRAM row bufferof a DRAM array <NUM> (<FIG>) to be tested and sets thetCLparameter for the selected DRAM row buffer to the maximum value. At block <NUM>, the profiling logic <NUM> selects afirst test data patternto be used to verify that the rowbuffer functions correctly at a given tCL value. The data test patterns may include any number of well-known test patterns used to detect memory errors such as `all ones', `all zeros', `alternating ones and zeros', 'walking ones' and the like. The data test patterns may further includepatterns specifically designed for the particular implementation of DRAM array <NUM>. At block <NUM>, the profiling logic <NUM> generates a memory write request to an address corresponding to the row buffer under test. The write request is transmitted to the scheduler <NUM> (<FIG>) via the write queue414(<FIG>) and the arbiter <NUM> (<FIG>). At block <NUM>, the profiling logic <NUM> generates a memory read request to the same address under the set tCL value. The read request is similarly transmitted to the scheduler <NUM> via the read queue <NUM> (<FIG>). At block <NUM>, the profiling logic <NUM> compares the data read back from the row buffer to the test pattern. If the data read back does not match, at block <NUM> the profiling logic <NUM> stores the last known good tCL in the timing data store <NUM>. As noted above, the timing data store <NUM> may be implemented as a bloom filter in order to reduce storage requirements. Otherwise, if the data read back matches, testing proceeds to block <NUM>, whereupon the test process loops back and selects the next test pattern. The process of blocks <NUM>-<NUM> repeats with each selected test pattern until the last pattern is tested (block <NUM>). If all test patterns have passed, at block 520the profiling logic <NUM> selects the next lower value for the tCLparameter and the process of blocks <NUM>-<NUM> is repeated for the this value for the tCL parameter. This process continues until a failing value for thetCLparameter has been detected at block <NUM>, at which point the last known good tCL value is stored as the row-specific tCL parameter for the row under test at block <NUM>. Thus, at the completion of the method <NUM>, the timing data store <NUM> has been updated with the fastest tCL value for the particular row under test. Although the method measures tCL for one row buffer for ease of illustration, in practice the method <NUM> would be repeated to measure tCL for any number of memory regions. Accordingly, the method <NUM> may be repeated for the next row under test, and so forth, until the fastest tCL value has been identified and stored for each of the rows of a portion of the entirety of the memory array <NUM>.

With the memory timing parameters identified for a given region and stored in the timing data store <NUM>, the scheduler <NUM> may utilize the stored region-based memory timing parameters to more optimally schedule memory access requests. The resulting improvement in memory latency and bandwidth may be better understood by examining a timing diagram for a DRM 'read' operation.

<FIG> is a timing diagram illustrating an exampleuse of profiled region-based memory timing parameters by the memory controller <NUM> (<FIG>) to schedule memory access requests so as to improve memory latency. For ease of illustration, the scheduling and timing of a DRAM read operation is shown, using the profiled values tRCD and tCL, however the memory controller may use any one of, or a combination of profiled DRAM timing parameters to schedule commands accordingly. The overall latency of a read operation for a previously unopened row is the sum of tRCD and tCL timing parameters. tRCD represents the minimum delay required between an `activate row' DRAM command and the subsequent `column read' DRAM command. tCL represents the minimum delay between the `column read' command and the availability of the first word of data being returned.

<FIG> compares the timing for two separate DRAM read operations, the first read operation is for location 'X' and the second is for location 'Y'. The profiling logic <NUM> (<FIG>) is assumed to have previously measured and stored the tRCD and tCLtiming parameters for various memory regions including DRAM rows 'X' and 'Y' used in the example, whereby for row 'X' the tRCD parameter is set to <NUM> cycles (tRCDx=<NUM>) and the tCL parameter is set to <NUM> cycles (tCLx=<NUM>) and for row 'Y' the tRCD parameter is set to <NUM> cycles (tRCDY=<NUM>) and the tCL parameter is set to <NUM> cycles (tCLY=<NUM>).

At clock cycle T<NUM>, the memory controller <NUM> issues an `activate row' command <NUM> to row X of the memory array <NUM> (<FIG>). Six cycles later at clock cycle T<NUM>, the memory controller <NUM> issues a `column read' command <NUM> using the profiled value of tRCDx=<NUM> for row 'X'. Next, using the profiled value of tCLx=<NUM> for row 'X' the memory controller waits six cycles for the memory data <NUM> to be returned at clock cycle T<NUM>. Thus the total read latency for location X is <NUM> cycles. Contemporaneously at clock cycle T<NUM>, the memory controller <NUM> issues an `activate row' command <NUM> for row Y. Using the profiled valuetRCDy=<NUM> for row 'Y', the memory controller <NUM> issues a `column read' command <NUM> four cycles later at clock cycle T<NUM>. Next, using the profiled value of tCLy=<NUM> for row 'Y', the memory controller <NUM> waits five cycles for the memory data <NUM> to be returned at clock cycle T<NUM>, for a total of <NUM> cycles of latency.

If the memory controller <NUM> were to use the conventional worst-case timing parameters across the entire memory, the tRCD parameter for the entire memory would have been set to <NUM> and thus the 'Read' command <NUM> would not have been issued until <NUM> cycles after the `activate row' command <NUM>. Likewise, the memory controller <NUM> would have also assumed that the memory data <NUM> would not be returned until <NUM> cycles after the `column read' command <NUM> was issued. However, by using profiling logic <NUM> to exploit the variations in the tRCD and tCL timing parameters on a row-by-row basis, the memory controller <NUM> is able to issue the `column read' command <NUM> to row Y two cycles earlier and access the resulting memory data <NUM> one cycle earlier, thereby reducing the latency of the memory data610 returned for the 'read'command608 to row Y by three cycles, and thereby increasing the overall processing performance of the system.

In some embodiments, the apparatus and techniques described above are implemented in a system comprising one or more integrated circuit (IC) devices (also referred to as integrated circuit packages or microchips), such as the processing systems of <FIG>. Electronic design automation (EDA) and computer aided design (CAD) software tools may be used in the design and fabrication of these IC devices. These design tools typically are represented as one or more software programs. The one or more software programs comprise code executable by a computer system to manipulate the computer system to operate on code representative of circuitry of one or more IC devices so as to perform at least a portion of a process to design or adapt a manufacturing system to fabricate the circuitry. This code can include instructions, data, or a combination of instructions and data. The software instructions representing a design tool or fabrication tool typically are stored in a computer readable storage medium accessible to the computing system. Likewise, the code representative of one or more phases of the design or fabrication of an IC device may be stored in and accessed from the same computer readable storage medium or a different computer readable storage medium.

Such storage media can include, but is not limited to, optical media (e.g., compact disc (CD), digital versatile disc (DVD), Blu-Ray disc), magnetic media (e.g., floppy disc , magnetic tape, or magnetic hard drive), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or Flash memory), or microelectromechanical systems (MEMS)-based storage media.

<FIG>is a flow diagram illustrating an example method700 for the design and fabrication of an IC device implementing one or more aspects described above. As noted above, the code generated for each of the following processes is stored or otherwise embodied in computer readable storage media for access and use by the corresponding design tool or fabrication tool.

At block702 a functional specification for the IC device is generated. The functional specification (often referred to as a micro architecture specification (MAS)) may be represented by any of a variety of programming languages or modeling languages, including C, C++, SystemC, Simulink, or MATLAB.

At block704, the functional specification is used to generate hardware description code representative of the hardware of the IC device. In some embodiments, the hardware description code is represented using at least one Hardware Description Language (HDL), which comprises any of a variety of computer languages, specification languages, or modeling languages for the formal description and design of the circuits of the IC device. The generated HDL code typically represents the operation of the circuits of the IC device, the design and organization of the circuits, and tests to verify correct operation of the IC device through simulation. Examples of HDL include Analog HDL (AHDL), Verilog HDL, SystemVerilog HDL, and VHDL. For IC devices implementing synchronized digital circuits, the hardware descriptor code may include register transfer level (RTL) code to provide an abstract representation of the operations of the synchronous digital circuits. For other types of circuitry, the hardware descriptor code may include behavior-level code to provide an abstract representation of the circuitry's operation. The HDL model represented by the hardware description code typically is subjected to one or more rounds of simulation and debugging to pass design verification.

After verifying the design represented by the hardware description code, at block706 a synthesis tool is used to synthesize the hardware description code to generate code representing or defining an initial physical implementation of the circuitry of the IC device. In some embodiments, the synthesis tool generates one or more netlists comprising circuit device instances (e.g., gates, transistors, resistors, capacitors, inductors, diodes, etc.) and the nets, or connections, between the circuit device instances. Alternatively, all or a portion of a netlist can be generated manually without the use of a synthesis tool. As with the hardware description code, the netlists may be subjected to one or more test and verification processes before a final set of one or more netlists is generated.

Alternatively, a schematic editor tool can be used to draft a schematic of circuitry of the IC device and a schematic capture tool then may be used to capture the resulting circuit diagram and to generate one or more netlists (stored on a computer readable media) representing the components and connectivity of the circuit diagram. The captured circuit diagram may then be subjected to one or more rounds of simulation for testing and verification.

At block708, one or more EDA tools use the netlists produced at block706 to generate code representing the physical layout of the circuitry of the IC device. This process can include, for example, a placement tool using the netlists to determine or fix the location of each element of the circuitry of the IC device. Further, a routing tool builds on the placement process to add and route the wires needed to connect the circuit elements in accordance with the netlist(s). The resulting code represents a three-dimensional model of the IC device. The code may be represented in a database file format, such as, for example, the Graphic Database System II (GDSII) format. Data in this format typically represents geometric shapes, text labels, and other information about the circuit layout in hierarchical form.

At block710, the physical layout code (e.g., GDSII code) is provided to a manufacturing facility, which uses the physical layout code to configure or otherwise adapt fabrication tools of the manufacturing facility (e.g., through mask works) to fabricate the IC device. That is, the physical layout code may be programmed into one or more computer systems, which may then control, in whole or part, the operation of the tools of the manufacturing facility or the manufacturing operations performed therein.

However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the present invention as set forth in the claims below.

Claim 1:
An integrated circuit, IC, device comprising:
a stacked-die memory device comprising:
a set of stacked memory dies (<NUM>, <NUM>, <NUM>, <NUM>; <NUM>, <NUM>, <NUM>, <NUM>) providing a memory having a plurality of regions, each region comprising one of a cell-based region, a bank-based region, and a row-based region; and
a set of one or more logic dies (<NUM>, <NUM>; <NUM>, <NUM>) electrically coupled to the stacked memory dies, the set of one or more logic dies comprising:
a processor (<NUM>); and
a memory controller (<NUM>; <NUM>, <NUM>) to schedule memory accesses to regions of the memory based on identified memory timing parameters specific to the regions, characterized in that the memory controller comprises:
profiling logic (<NUM>, <NUM>, <NUM>, <NUM>) to identify one or more memory timing parameters for at least one region of the memory, wherein the profiling logic is configured to:
measure a type of memory timing parameter of a plurality of types of memory timing parameters for each sub-region of a plurality of sub-regions of each region; and
identify the fastest measured memory timing parameter corresponding to each measured type of memory timing parameter of the sub-regions as a memory timing parameter for each corresponding type of memory timing parameter for each region.