Patent Application
20250104758
Dynamic random access memory (DRAM) cells require periodic refreshing to raise the voltage in each cell back to a full charge state in order to prevent data loss due to normal voltage leakage. The refresh rate required for memory cells may be temperature dependent as increased temperature causes increased voltage leakage. Currently, technical specifications for volatile memory devices allow for all bank refresh (ABR) in which all memory cells in all banks of the memory are refreshed at the same time, and per bank refresh (PBR) in which memory cells in each bank of memory are refreshed. The frequency and ways in which memory cells are refreshed may impact device performance due to unavailability of the memory during refresh or increased congestion on the command/address bus during refresh. As the operating temperature of a memory increases, the potential impacts on performance may increase.
Various aspects include methods and memory controllers for implementing multi bank refresh commands that provide flexibility in managing the refresh requirements of DRAM memory. Various aspects may include methods of performing multi-memory bank refreshes of volatile memory devices performed by a memory controller. Such aspect methods may include selecting a number of memory banks to refresh in a multi-bank memory refresh cycle, selecting a first memory bank to refresh in the multi-bank refresh cycle, and applying a multi-bank of memory refresh command to a memory device, in which the multi-bank of memory refresh command may encode the number of memory banks to be refreshed, and the first memory bank to refresh. In some aspects, the multi-bank of memory refresh command may encode the number of memory banks to be refreshed in z bits, in which z is an integer, and the multi-bank of memory refresh command is completed in m clock cycles, in which m is an integer. In some aspects, z equals 3 and m equals 2.
Some aspects may further include selecting one of a plurality of different patterns of memory bank refreshing sequences, in which the multi-bank of memory refresh command also may encode the pattern for refreshing particular memory banks. In some aspects, selecting one of a plurality of different patterns of memory bank refreshing sequences may include selecting one of an incremental pattern, a pairwise pattern based on pairs of memory banks specified for the memory device, a step of N pattern, or a diagonal pattern based on the pairs of memory banks specified for the memory device. In some aspects, N equals 2.
Further aspects include methods of implementing a multi-bank memory refresh command on a memory device. Such aspect methods may include recognizing a multi-bank memory refresh command based on signals applied to command and address pins over a number m of clock cycles, in which m is an integer, identifying a number of memory banks to be refreshed based on the signals applied to the command and address pins over the m clock cycles, identifying a first memory bank to be refreshed based on the signals applied to the command and address pins over at least one clock cycle, and refreshing the identified number of memory banks within the memory device starting from the identified first memory bank. In some aspects, m equals 2. In some aspects, the multi-bank of memory refresh command may encode the number of memory banks to be refreshed in z bits, in which z is an integer. In some aspects, z equals 3.
Some aspects may further include identifying a pattern for refreshing particular memory banks based on the signals applied to the command and address pins over at least one clock cycle, and refreshing the identified number of memory banks within the memory device according to the pattern for refreshing particular memory starting from the identified first memory bank. Some aspects may further include selecting a next memory bank for refreshing according to the identified pattern for refreshing particular memory banks, determining whether the selected memory bank has already been refreshed, refreshing the selected memory bank in response to determining that the selected memory bank has not already been refreshed, and selecting a next memory bank for refreshing in response to determining that the selected memory bank has already been refreshed.
Some aspects may further include determining whether the identified number of memory banks have been refreshed, selecting the next memory bank for refreshing in response to determining that the identified number of memory banks have not yet been refreshed, and ending the multi-bank memory refresh in response to determining that the identified number of memory banks have been refreshed.
Further aspects include a computing device including a memory and a memory controller configured to perform operations of any of the methods summarized above. Further aspects include a computing device having means for accomplishing functions of any of the methods summarized above. Further aspects include a non-transitory processor-readable storage medium having stored thereon processor-executable software instructions configured to cause a processor and/or processing system to perform operations of any of the methods summarized above.
The accompanying drawings, which are incorporated herein and constitute part of this specification, illustrate example embodiments of various embodiments, and together with the general description given above and the detailed description given below, serve to explain the features of the claims.
Various embodiments will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. References made to particular examples and implementations are for illustrative purposes, and are not intended to limit the scope of the claims.
Various embodiments include methods, and computing devices implementing such methods of multi bank refresh of DRAM memory devices according to flexible refresh commands that provide flexibility in identifying which banks of memory are refreshed and the sequences in which identified banks are refreshed. Various embodiments include defining a multi-bank refresh command that enables a memory controller to choose the number of memory banks and the desired memory banks in volatile memory devices, such as but not limited to double data rate (DDR) and low power double data rate (LPDDR) memory devices. Various embodiments may enable the memory controller to specify the number of memory banks to be refreshed, the starting bank number, and the pattern of memory banks to be refreshed following the starting bank. Various embodiments may help to minimize performance loss by enabling the memory controller to issue refreshes to multiple idle banks. Various embodiments may be applicable to a variety of volatile memory device technologies.
The term “computing device” is used herein to refer to stationary computing devices including personal computers, desktop computers, all-in-one computers, workstations, super computers, mainframe computers, embedded computers (such as in vehicles and other larger systems), computing systems within or configured for use in vehicles, servers, multimedia computers, and game consoles. The terms “computing device” and “mobile computing device” are used interchangeably herein to refer to any one or all of cellular telephones, smartphones, personal or mobile multi-media players, personal data assistants (PDA's), laptop computers, tablet computers, convertible laptops/tablets (2-in-1 computers), smartbooks, ultrabooks, netbooks, palm-top computers, wireless electronic mail receivers, multimedia Internet enabled cellular telephones, mobile gaming consoles, wireless gaming controllers, and similar personal electronic devices that include a memory, and a programmable processor.
The term “processing system” is used herein to refer to one more processors, including multi-core processors, that are organized and configured to perform various computing functions. Various embodiment methods may be implemented in one or more of multiple processors within a vehicle processing system as described herein.
The term “system on chip” (SoC) is used herein to refer to a single integrated circuit (IC) chip that contains multiple processors, memory and supporting resources, which may form a processing system integrated on a single substrate. A SoC may contain circuitry for digital, analog, mixed-signal, and radio-frequency functions. A single SoC processing system also may include any number of general-purpose or specialized processors (e.g., network processors, digital signal processors, modem processors, video processors, etc.), memory blocks (e.g., ROM, RAM, Flash, etc.), and resources (e.g., timers, voltage regulators, oscillators, etc.). For example, an SoC processing system may include an applications processor that operates as the SoC's main processor, a central processing unit (CPU), a microprocessor unit (MPU), an arithmetic logic unit (ALU), etc. SoC processing systems also may include software for controlling integrated resources and processors, as well as for controlling peripheral devices.
The term “system in a package” (SIP) may be used herein to refer to a single module or package that contains a processing system including multiple resources, computational units, cores, or processors on two or more IC chips, substrates, or SoCs. For example, a SIP processing system may include a single substrate on which multiple IC chips or semiconductor dies are stacked vertically. Similarly, the SIP processing system may include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor dies are packaged into a unifying substrate. A SIP processing system also may include multiple independent SOCs coupled together via high-speed communication circuitry and packaged in close proximity, such as on a single motherboard, in a single UE, or in a single CPU device. The proximity of the SoCs facilitates high-speed communications and the sharing of memory and resources.
Volatile memory cells, such as MDRAM, DDR and LPDDR memory cells, require periodic refreshes that recharge cells to the full charge state to prevent data loss due to voltage leakage. Current JEDEC specifications mandate refreshes to all the memory banks in a time interval (referred to herein as “tREFI”). LPDDR specifications currently only allow two types of refresh commands; all bank refresh (ABR) and per bank refresh (PBR) commands. Under some circumstances, these two refresh command options can lead to either performance degradation or increased command and address (CA) bus congestion, respectively. At higher refresh rates, these limitations may be exacerbated.
All bank refresh commands refresh all banks at once, thus stalling traffic for a time interval (“tRFCab”) that is longer than the time interval (“tRFCpb”) of a per bank refresh command. As a result, all bank refresh reduces command and address bus congestion but can lead to performance degradation of up to 30-40%.
Per bank refresh refreshes only two banks at a time. Subsequent per bank refresh commands can be sent out by the memory controller after the time interval between two per bank refreshes to different banks. As a result, per bank refresh reduces performance degradation but increases command and address bus congestion.
Also, for some refresh rates, such as for 4×/8× that is important for high temperature applications, such as in automobile computing systems, it might not be possible to schedule all 8 Per Bank Refresh commands in the time interval tREFI. This could lead to performance degradation due to the need to force all bank refresh commands.
Various embodiments solve some of the limitations in current JEDEC specifications for memory bank refresh by providing a flexible multi bank refresh command that provides flexibility to minimize both performance degradation and command and address bus congestion. The multi bank refresh commands of various embodiments provide the memory controller with flexibility to choose the number of memory banks and the desired banks in volatile memory devices (e.g., DDR/LPDDR memory devices) to be refreshed in any given refresh cycle. The flexible refresh command of various embodiments may enable DRAM controllers to incorporate smart refresh algorithms that can be responsive to the nature of the workload of the processing system and memory at any given instant. Some embodiments include a defined multi bank refresh command using an existing reserved for future use (RFU) command of the current JEDEC Low Power Double Data Rate specification, which is applicable to past and future DDRx/LPDDRx specifications. Such embodiments use a number of bits available in the RFU command for each DDR/LPDDR generation to define the number of memory banks to be refreshed, a starting bank number, and a pattern of memory banks to be refreshed in sequence following the starting memory bank. Various embodiments may enable the memory controller to minimize performance loss by issuing refreshes to multiple idle memory banks, and reducing command and address bus congestion by issuing fewer refresh commands per time interval for completing refreshes to all memory banks as mandated by the specification. This solution is applicable for all volatile memory specs.
Various embodiments may be particularly advantageous in high temperature applications, such as in computing devices deployed in automobiles. For example, DDR memory has to increase the memory refresh rate when temperature of the DDR memory increases to certain levels in order to maintain integrity of data stored in the DDR memory. Increasing the memory refresh rate reduces read/write bandwidth and increases latency for the DDR memory.
Various embodiments improve the operation of computing and processing devices in a variety of application by enabling refresh to be scheduled in a manner consistent with executing operations by providing flexibility for a memory controller to choose the number of memory banks to be refreshed and/or choose which banks to be refreshed. Various embodiments may reduce memory performance degradation and command and address bus congestion by providing flexibility that enables smart refresh scheduling. The refresh schema of various embodiments may be of particular benefit in applications requiring high refresh rates, such as in high temperature environments such as experienced in automotive computing devices. Further, the proposed commands of various embodiments may be scalable across volatile memory specifications, and may be modified to meet different memory configurations and needs.
A computing device 10 processing system 12 may include a variety of different types of processors 14 and processor cores, such as one or more general purpose processors, a central processing unit (CPU), a digital signal processor (DSP), a graphics processing unit (GPU), an accelerated processing unit (APU), a secure processing unit (SPU), a subsystem processor of specific components of the computing device, such as an image processor for a camera subsystem or a display processor for a display, an auxiliary processor, a single-core processor, a multicore processor, a controller, and a microcontroller. A processing system 12 may further embody other hardware and hardware combinations, such as a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), other programmable logic device, discrete gate logic, transistor logic, performance monitoring hardware, watchdog hardware, and time references. Integrated circuits may be configured such that the components of the integrated circuit reside on a single piece of semiconductor material, such as silicon.
A computing device 10 may include more than one SoC processing systems 12, thereby increasing the number of processors 14 and processor cores. The computing device 10 may also include processors 14 of a processing system that are not associated with an SoC 12. The processors 14 may each be configured for specific purposes that may be the same as or different from other processors 14 of the computing device 10. One or more of the processors 14 and processor cores of the same or different configurations may be grouped together. A group of processors 14 or processor cores may be referred to as a multi-processor cluster.
The memories 16, 36 of the SoC 12 may be a volatile or non-volatile memory configured for storing data and processor-executable code for access by the processor 14. The computing device 10 and/or SoC 12 may include one or more memories 16, 36 configured for various purposes. One or more memories 16, 36 may include volatile memories such as random access memory (RAM) or main memory, including dynamic RAM (DRAM), or cache memory. These memories 16, 36 may be configured to temporarily hold a limited amount of data received from a data sensor or subsystem, data and/or processor-executable code instructions that are requested from a non-volatile memory 16, 24, loaded to the memories 16 from the non-volatile memory 16, 24 in anticipation of future access based on a variety of factors, and/or intermediary processing data and/or processor-executable code instructions produced by the processor 14 and temporarily stored for future quick access without being stored in non-volatile memory 16, 24. The memory interface 34 and the memory 36 may work in unison to allow the computing device 10 to load and retrieve data and processor-executable code on the memory 36.
The storage memory interface 20 and the storage memory 24 may work in unison to allow the computing device 10 to store data and processor-executable code on a non-volatile storage medium. The storage memory 24 may be configured much like an embodiment of the memory 16 in which the storage memory 24 may store the data or processor-executable code for access by one or more of the processors 14. The storage memory 24, being non-volatile, may retain the information after the power of the computing device 10 has been shut off. When the power is turned back on and the computing device 10 reboots, the information stored on the storage memory 24 may be available to the computing device 10. The storage memory interface 20 may control access to the storage memory 24 and allow the processor 14 to read data from and write data to the storage memory 24.
The power manager 28 may be configured to control power states of one or more power rails (not shown) for power delivery to the components of the SoC 12. In some embodiments, the power manager 28 may be configured to control amounts of power provided to the components of the SoC 12. For example, the power manager 28 may be configured to control connections between components of the SoC 12 and the power rails. As another example, the power manager 28 may be configured to control amounts of power on the power rails connected to the components of the SoC 12. The power manager 28 may be configured as a power management integrated circuit (power management ICs or PMIC).
A clock controller 30 may be configured to control clock signals transmitted to the components of the SoC 12. For example, the clock controller 30 may gate a component of the SoC 12 by disconnecting the component of the SoC 12 from a clock signal and may ungate the component of the SoC 12 by connecting the component of the SoC 12 to the clock signal.
A peripheral device interface 38 may enable components of the SoC 12, such as the processor 14 and/or the memory 16, to communicate with a peripheral device 40. The peripheral device interface 38 may provide and manage physical and logical connections between the components of the SoC 12 and the peripheral device 40. The peripheral device interface 38 may also manage communication between the components of the SoC 12 and the peripheral device 40, such as by directing and/or allowing communications between transmitter and receiver pairs of the components of the SoC 12 and the peripheral device 40 for a communication. The communications may include transmission of memory access commands, addresses, data, interrupt signals, state signals, etc. A peripheral device 40 may be any component of the computing device 10 separate from the SoC 12, such as a processor, a memory, a subsystem, etc. In some embodiments, the peripheral device interface 38 may include a PCIe root complex and may enable PCIe protocol communication between the components of the SoC 12 and the peripheral device 40.
The interconnect 32 may be a communication fabric, such as a communication bus including a number of lines (i.e., conductors), configured to communicatively connect the components of the SoC 12. The interconnect 32 may transmit signals between the components of the SoC 12. In some embodiments, the interconnect 32 may be configured to control signals between the components of the SoC 12 by controlling timing and/or transmission paths of the signals.
Some or all of the components of the computing device 10 and/or the SoC 12 may be arranged differently and/or combined while still serving the functions of the various embodiments. The computing device 10 may not be limited to one of each of the components, and multiple instances of each component may be included in various configurations of the computing device
The processors 204a-204n (e.g., a CPU, GPU, an NPU, etc.) may be configured to execute program instructions including reading and/or writing to the memory devices 212a, 212b. Memory access commands may be generated and sent by the processors 204a-204n for implementing the read and/or write instructions at the memory devices 212a, 212b.
The memory controller 206 may receive the memory access commands from any number and combination of the processors 204a-204n. The memory access commands may include information for implementing the read and/or write instructions at the memory devices 212a, 212b. Such information may include virtual and/or physical addresses of the memory devices 212a, 212b at which to implement the read and/or write instructions. The memory controller 206 may identify addresses of locations at the memory devices 212a, 212b corresponding to the addresses of the memory access commands and direct the memory access commands to the locations. In some embodiments, the addresses of the locations at the memory devices 212a, 212b may be identified by mapping or converting the addresses of the memory access commands to addresses of the locations using an algorithm and/or a mapping table, such as a mapping table stored at a translation lookaside buffer. The memory controller 206 may send the memory access commands, addresses of the locations at the memory devices 212a, 212b, and/or signals for activating the components of the memory devices 212a, 212b for the corresponding locations. In some embodiments, the memory controller 206 may be separate from the processors 204a-204n. In some embodiments, one or more memory controllers 206 may be integral to one or more of the processors 204a-204n.
In addition to providing an interface for the processors 204a-204n for read and write operations, the memory controller 206 may also be configured to control operations to refresh the memory banks 216 to maintain data stored in memory cells. By controlling read and write operations, the memory controller 206 may have or maintain information on the locations in memory, including memory banks, that are currently storing data, currently involved in read and/or write operations, and currently idle or being access infrequently. With this information available, the memory controller 206 can initiate memory refresh cycles on memory banks that are not currently engaged in supporting an ongoing process using a multi-bank memory refresh command according to various embodiments.
The physical layer 208 may receive the memory access commands, addresses of the locations at the memory devices 212a, 212b, and/or signals for activating the components of the memory devices 212a, 212b for the corresponding locations from the memory controller 206. The physical layer 208 may send the memory access commands, addresses of the locations at the memory devices 212a, 212b, and/or signals for activating the components of the memory devices 212a, 212b for the corresponding locations along with other signals via n lines in the communication bus 210, in which n is an integer value. The communication bus 210 may include various lines 218, 220, 222, 224, 226, 228, 230 coupled to pins on the memory devices 212a, 212b. In the illustrated example, the physical layer 208 may send signals for the memory access commands including: data signals via one or more data buses 218a, 218b; data clock signals via one or more data clock lines 220a, 220b; read strobe clock signals via one or more read strobe clock lines 222a, 222b; memory access commands and addresses of the locations signals via n lines in one or more command and address buses 224a, 224b, clock signals via one or more clock lines 226a, 226b; chip select signals via one or more chip select buses 228a, 228b; and/or reset signals via a reset line 230.
Depending on the addresses of the locations at the memory devices 212a, 212b, the physical layer 208 may send the signals via specific combinations of the sub-buses and lines 218, 220, 222, 224, 226, 228, 230 to each memory device interface 214. The interface 214 may interpret and/or send the signals to one or more memory banks 216 to which of the interface 214 is communicatively connected. For example, chip select signals on line 228 may be interpreted by and indicate to the interface 214 on which of the memory devices 212a, 212b to activate the communicatively connected memory banks 216 and/or implement the memory access commands at the communicatively connected memory banks 216.
In various embodiments, the memory controller 206 may cause the memory physical layer 208 to provide signals to the interface 214 via a number n of command and address bus lines 224 in combination with clock systems via line 226 to identify memory banks to be refreshed. For example, the command and address bus lines 224 may connect and provide signals to pins CA0, CA1, CA2 and CA3 of the memory device 212a as described in more detail herein. As described with reference to
In some embodiments, the addresses of the locations at the memory devices 212a, 212b may be within a rank of one or more memory devices 212a, 212b. As referred to herein, a rank may include a memory space across multiple memory banks 216a, 216b of one memory device 212a, 212b for which at least two memory banks 216a, 216b are associated with different partial channels. For example, for a DDR dual in-line memory module (DIMM), memory devices 212a, 212b located on opposite sides of the DIMM may be part of different ranks. In some embodiments, the addresses of the locations at the memory devices 212a, 212b may be within a logical rank of multiple memory devices 212a, 212b. As referred to herein, a logical rank may include a memory space across multiple memory banks 216a, 216b of multiple memory devices 212a, 212b for which the memory banks 216a, 216b of two memory devices 212a, 212b are associated with different partial channels. For example, for a DDR DIMM, memory devices 212a, 212b located on opposite sides of the DIMM may be part of a logical rank. In some embodiments, two memory devices 212a, 212b of a logical rank may be communicatively connected to the same sub-buses and lines 218a, 218b, 220a, 220b, 222a, 222b, 224a, 224b, 226a, 226b, 228a, 228b, 230.
Various embodiments may be implemented by introducing new signaling commands for volatile memory devices (e.g., DDR and LPDDR memory devices) for controlling the refresh of memory banks in a multi-bank format that provides memory controllers with flexibility for specifying refresh of selected memory banks. In some embodiments, the memory controller may generate a refresh command that identifies a memory bank to begin refreshing and the number of memory banks to be refreshed. To provide further flexibility, in some embodiments the memory controller may generate a refresh command that identifies a memory bank to begin refreshing, the number of memory banks to be refreshed and a pattern in which memory banks are to be refreshed from the starting bank. Some embodiments may include a new multi-bank refresh command structure that encodes information identifying the memory bank to begin refreshing and the number of memory banks to be refreshed. Some embodiments may include a new multi-bank refresh command structure that encodes information identifying the memory bank to begin refreshing, the number of memory banks to be refreshed, and the pattern in which memory banks are to be refreshed from the starting bank.
A non-limiting example of a representative command structure and non-limiting examples of bit pattern translation tables according to a non-limiting embodiment are illustrated in
Referring to
The command structure illustrated in the example table 300 identifies signals of high (H) or low (L) voltage that are applied to the volatile memory device command pins CA0, CA1, CA2 and CA3 of the memory device interface (e.g., 214) on two consecutive clock cycles (CS) on the rising (R1 or R2) edge or falling (F1 or F2) that of the clock signal to identify that it is a multi-bank refresh command. The example table 300 shows signals that identify the number of memory banks to be refreshed in one multi-bank refresh cycle, and the identity of the memory bank at which the multi-bank refresh process should begin. The example table 300 is for an embodiment in which the memory controller can also identify a pattern in which memory banks are refreshed, and thus also shows signals that identify the type of multi-bank refresh pattern that should be implemented (i.e., incremental, pairwise, step of N or diagonal as described herein).
As illustrated in table 300, a memory controller 206 and memory physical layer 208 may issue a multi-bank refresh command using the command and address lines 224 connected to the DDR command pins CA0, CA1, CA2 and CA3 by applying high voltage (H) to the CA0, CA1, and CA2 pins while applying low voltage (L) to the CA3 command pin on the rising edge of a first clock signal (i.e., as CS goes high), followed by applying low voltage to the CA0 and CA2 pins and maintaining high voltage on the CA1 pin on the falling edge of the first clock signal (i.e., as CS voltage drops to any voltage below high indicated by “x”).
As part of this example multi-bank refresh command structure, the voltage (H or L) applied to the CA0, CA1 and CA3 on specific portions of two clock cycles provides three bits of information (referred to in the figures as “nB0”, “nB1” and “nB2”) used to specify the number of memory banks to be refreshed. In other words, in this non-limiting example, the number of bits z used to encode the number of memory banks to be refreshed as shown in
As part of this example multi-bank refresh command structure, the voltage (H or L) applied to the CA2 and CA3 pins on the rising edge of the second clock signal provides two bits of information (with the voltage/bit values referred to in the figures as “mREF1” and “mREF0”) useful for identifying the pattern in which memory banks are to be refreshed. As noted above, in some embodiments, the multi-bank refresh command structure may not include information or bits for identifying a pattern for refreshing banks, in which case memory banks may be refreshed in a default pattern (such as incremental) from the starting memory bank for the identified number of memory banks.
In the non-limiting embodiment illustrated in
As part of this example multi-bank refresh command structure, the voltage (H or L) applied to the CA0, CA1, CA2 and CA3 pins on the falling edge of the second clock signal provides four bits of information (with the voltage/bit values referred to in the figures as “BA0”, “BA1”, “BG0” and “BG1”) useful for identifying the number of the memory bank at which refreshing should start. Table 306 in
Turning to how the non-limiting signals described above would be acted upon by the memory device side, the interface 214 would recognize the applied signals as indicating a multi-bank refresh command, and use the values/voltage states applied on the command pins to determine the number of memory banks to refresh, the pattern to be followed in refreshing banks, and the memory bank at which the refresh cycle should begin. In the embodiment multi-bank refresh command structure illustrated in Table 300 of
Again,
The example multi-bank refresh command 306 illustrated in
The general format of the multi-bank refresh command 306 illustrated in
The implementation of multi-bank refreshing according to the non-limiting embodiment illustrated in
Referring to the non-limiting examples illustrated in Table 400, if the pattern of memory banks to be refreshed is set to “increment” (i.e., mREF1=0 and mREF0=0 per
If the pattern of memory banks to be refreshed is set to “pair” (i.e., mREF1=0 and mREF0=1 per
If the pattern of memory banks to be refreshed is set to “step of N” in which N=2 (i.e., mREF1=1 and mREF0=0 per
Referring to
The benefit of a multi-bank memory refresh command can be appreciated with reference to
In block 1102, the memory controller may determine when and which memory banks require refresh as part of the normal operations of managing dynamic memory. This may include identifying those memory banks that have not been refreshed within a period of time that depends on temperature and other factors such that voltage decay could lead to loss of data. As part of the operations in block 1102, the memory controller may also select one of multiple memories coupled to and controlled by the memory controller.
In block 1104, the memory controller may select particular memory banks for refresh. In this operation, the memory controller may also select memory banks that should remain available for write and read operations during that memory refresh cycle. The particular memory banks selected for refresh may depend upon factors such as the operating temperature (which may determine how frequently memory banks must be refreshed), current read and write operations being performed in various memory banks, and other operational considerations.
In some instances, depending on current read and write operations and memory banks currently in use or recently refreshed, it may not be efficient to refresh all of the memory banks selected in block 1104 in a single multi-bank refresh command. Therefore, in block 1106, the memory controller may select a number of memory banks to refresh using a multi-memory bank refresh command in a given memory refresh interval (tREFI). Selection of the number of memory banks to be refreshed in a given multi-bank refresh command may depend on how many memory banks will require refreshing within the next refresh cycle, distribution of the memory banks requiring refresh, a pattern of refreshing (determined in block 1108) suitable for efficiently refreshing at least some of the memory banks in one cycle, and operational considerations, such as the rate at which memory banks are being written and read. In some instances, the operations in block 1106 need not be performed because the selection of memory banks to refresh using a single multi-bank refresh command in block 1104 also identifies the number of memory banks to refresh using the command.
In block 1108, the memory controller may select a pattern for refreshing particular memory banks. The memory controller may select from among various refresh patterns supported by the multi-bank memory refresh commands implemented on the memory device. For example, in the embodiment illustrated in
In block 1110, the memory controller may select a first memory bank to refresh in a multi-bank refresh cycle. The selection of the first memory banks to refresh may depend upon the pattern of memory refresh selected as well as other considerations.
In block 1112, the memory controller may generate a multibank memory refresh command that specifies the number of memory banks to refresh in the multi-bank refresh cycle (as determined in block 1106), the pattern of refreshing of memory banks (such as selected in block 1108) and identify the first memory bank two refresh parentheses such as selected in block 1110). In generating the multi-bank refresh command, the memory controller may encode this information into digital or signal formats similar to those illustrated in
In block 1114, the memory controller may cause the memory physical layer (e.g., 208) to apply the corresponding voltage levels to the command and address pins on the selected memory device, thereby causing the memory device to implement the multi-bank refresh.
The operations in the method 1100 may be performed repeatedly or periodically to refresh memory banks in selected memory devices, particularly when multi-bank memory refresh methods are suitable to current operating conditions or may improve performance of the computing device.
In block 1202, the memory device interface may monitor command and address pins for memory commands.
In block 1204, the memory device interface may recognize a multi-bank memory refresh command based on the signals that are applied to the command and address pins over two clock cycles. Non-limiting examples of signal patterns that could be used for a multi-bank memory refresh commands are described with reference to
In block 1212, the memory device interface (or another component of the memory device) may select the next memory bank to be refreshed based on the identified first memory bank to be refreshed (e.g., determined in block 1210). At the start of a multi-bank memory refresh cycle, the memory device interface may select the first memory bank to be refreshed that was identified in the received multi-bank memory refresh command. Thereafter, the memory device interface may select the next memory bank to refresh based on the identified pattern for refreshing particular memory banks (e.g., determined in block 1208).
In determination block 1214, the memory device interface (or other complement) may determine whether the selected memory bank has already been refreshed within a threshold amount of time, and thus does not require refreshing in the current refresh cycle.
In response to determining that the selected memory bank has already been refreshed (i.e., determination block 214=“Yes”), the memory device interface may again select the next memory bank for refreshing in block 1212, thereby skipping a memory bank that does not require refreshing.
In response to determining that the selected memory bank has not already been refreshed (i.e., determination block 1214=“No”), the memory device may refresh that selected memory bank in block 1216.
In determination block 1218, the memory device interface may determine whether there are more memory banks to refresh in the current multi-bank memory refresh cycle. This determination may be based on the identified number of memory banks to be refreshed in the given cycle (e.g., determined in block 1206) and the number of memory banks that have been refreshed in the given cycle.
In response to determining that there are more memory banks to refresh (i.e., determination block 1218=“Yes”), the memory device interface may select the next memory bank for refreshing in block 1212 as described. In other words, if the memory device interface determines that the identified number of memory banks have not yet been refreshed, the memory device interface may continue the multi-bank memory refresh process by selecting the next memory bank to be refreshed in block 1212.
In response to determining that all memory banks have been refreshed in the givens multi-bank memory refresh cycle (i.e., determination block 1218=“No”), the memory device interface may return to monitoring the command and address pins for further commands in block 1202 as described. In other words, if the memory device interface determines that the identified number of memory banks have been refreshed, the memory device interface may end the multi-bank memory refresh cycle and begin monitoring command and address pins for the next memory device command.
A computing device suitable for implementing various embodiments (including, but not limited to, embodiments described above with reference to
The mobile computing device 1300 may have one or more radio signal transceivers 1308 (e.g., Peanut, Bluetooth, ZigBee, Wi-Fi, RF radio) and antennae 1310, for sending and receiving communications, coupled to each other and/or to the processor 1302. The transceivers 1308 and antennae 1310 may be used with the above-mentioned circuitry to implement the various wireless transmission protocol stacks and interfaces. The mobile computing device 1300 may include a cellular network wireless modem chip 1316 that enables communication via a cellular network and is coupled to the processor.
The mobile computing device 1300 may include a peripheral device connection interface 1318 coupled to the processor 1302. The peripheral device connection interface 1318 may be singularly configured to accept one type of connection, or may be configured to accept various types of physical and communication connections, common or proprietary, such as Universal Serial Bus (USB), FireWire, Thunderbolt, or PCIe. The peripheral device connection interface 1318 may also be coupled to a similarly configured peripheral device connection port (not shown).
The mobile computing device 1300 may also include speakers 1314 for providing audio outputs. The mobile computing device 1300 may also include a housing 1320, constructed of a plastic, metal, or a combination of materials, for containing all or some of the components described herein. The mobile computing device 1300 may include a power source 1322 coupled to the processor 1302, such as a disposable or rechargeable battery. The rechargeable battery may also be coupled to the peripheral device connection port to receive a charging current from a source external to the mobile computing device 1300. The mobile computing device 1300 may also include a physical button 1324 for receiving user inputs. The mobile computing device 1300 may also include a power button 1326 for turning the mobile computing device 1300 on and off.
An example computing device suitable for implementing various embodiments (including, but not limited to, embodiments described above with reference to
Methods and devices for implementing such methods in accordance with the various embodiments (including, but not limited to, embodiments described above with reference to
The vehicle computing system 1504 may be coupled to and configured to control drive control components 1506a, navigation components 1506b, and one or more sensors 1506c of the vehicle system 1500. The processor 1504a may be configured with processor-executable instructions to control maneuvering, navigation, and/or other operations of the vehicle, including operations of various embodiments, including gathering and analyzing real-world vehicle run data gathered from the sensors 1506c. The input module 1504c may receive sensor data from one or more vehicle sensors 1506c as well as electronic signals from other components, including the drive control components 1506a and the navigation components 1506b. The output module 1504d may communicate with or activate various components of the embedded vehicle computing system 1500, including drive control components 1506a, navigation components 1506b, and vehicle sensor(s) 1506c.
The vehicle computing system 1504 may be coupled to drive control components 1506a to control various elements of the vehicle related to maneuvering and navigation of the vehicle, such as the engine, motors, throttles, steering elements, braking or deceleration elements, and the like. The drive control components 1506a may also include components that control other devices of the vehicle, including interior environment controls (e.g., air conditioning and heating), external and/or interior lighting, interior and/or exterior informational displays (which may include a display screen or other devices to display information), safety devices (e.g., haptic devices, audible alarms, etc.), and other similar devices.
The vehicle computing system 1504 may be coupled to navigation components 1506b, and may receive data from the navigation components 1506b and be configured to use such data to determine the present position and orientation of the vehicle, as well as an appropriate course toward a destination. The navigation components 1506b may include or be coupled to a Global Navigation Satellite System (GNSS) receiver system (e.g., one or more Global Positioning System (GPS) receivers) enabling the embedded vehicle computing system 1000 to determine its current position using GNSS signals. Through control of the drive control elements 1506a, the processor 1504a may control the vehicle to navigate and maneuver.
The vehicle computing system 1504 may be coupled to one or more sensors 1506c. The sensor(s) 1506c may be configured to provide a variety of data to the processing system 1504a.
While the vehicle computing system 1504 is described as including separate components, in some embodiments some or all of the components (e.g., processing system 1504a, memory controller 1504b, memories 1504c, input module 1504d, and output module 1504e) may be integrated in a single device or module, such as an SIP or SoC processing system. For example, an SoC processing device may be configured for use in vehicles and configured with processor-executable instructions to perform operations of navigation and collision avoidance.
Implementation examples are described in the following paragraphs. While some of the following implementation examples are described in terms of example systems, devices, or methods, further example implementations may include: the example systems or devices discussed in the following paragraphs implemented as a method executing operations of the example systems or devices; the example systems, devices, or methods discussed in the following paragraphs implemented by a computing device including one or more memory controllers and one or more memory devices configured to perform operations of the example systems, devices, or methods; the example systems, devices, or methods discussed in the following paragraphs implemented by a computing device including one or more memory devices and means for performing functions of the example methods; and the example systems, devices, or methods discussed in the following paragraphs implemented as a non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a processor of a memory controller or memory device to perform the operations of the example systems, devices, or methods.
Example 1. A method of performing multi-memory bank refreshes of volatile memory devices performed by a memory controller, including: selecting a number of memory banks to refresh in a multi-bank memory refresh cycle; selecting a first memory bank to refresh in the multi-bank refresh cycle; and applying a multi-bank of memory refresh command to a memory device, in which the multi-bank of memory refresh command encodes the number of memory banks to be refreshed, and the first memory bank to refresh.
Example 2. The method of example 1, in which: the multi-bank of memory refresh command encodes the number of memory banks to be refreshed in z bits, in which z is an integer; and the multi-bank of memory refresh command is completed in m clock cycles, in which m is an integer.
Example 3. The method of example 2, in which z equals 3 and m equals 2.
Example 4. The method of any of examples 1-3, further including selecting one of a plurality of different patterns of memory bank refreshing sequences, in which the multi-bank of memory refresh command also encodes the pattern for refreshing particular memory banks . . .
Example 5. The method of example 4, in which selecting one of a plurality of different patterns of memory bank refreshing sequences includes selecting one of an incremental pattern, a pairwise pattern based on pairs of memory banks specified for the memory device, a step of N pattern, or a diagonal pattern based on the pairs of memory banks specified for the memory device.
Example 6. The method of example 5, in which in N equals 2.
Example 7. A method of implementing a multi-bank memory refresh command on a memory device, including: recognizing a multi-bank memory refresh command based on signals applied to command and address pins over a number m of clock cycles, in which m is an integer; identifying a number of memory banks to be refreshed based on the signals applied to the command and address pins over the m clock cycles; identifying a first memory bank to be refreshed based on the signals applied to the command and address pins over at least one clock cycle; and refreshing the identified number of memory banks within the memory device starting from the identified first memory bank.
Example 8. The method of example 7, in which m equals 2.
Example 9. The method of either of examples 7 or 8, in which the multi-bank of memory refresh command encodes the number of memory banks to be refreshed in bits, in which
is an integer.
Example 10. The method of example 9, in which z equals 3.
Example 11. The method of any of examples 7-10, further including: identifying a pattern for refreshing particular memory banks based on the signals applied to the command and address pins over at least one clock cycle; and refreshing the identified number of memory banks within the memory device according to the pattern for refreshing particular memory starting from the identified first memory bank.
Example 12. The method of example 11, further including: selecting a next memory bank for refreshing according to the identified pattern for refreshing particular memory banks; determining whether the selected memory bank has already been refreshed; refreshing the selected memory bank in response to determining that the selected memory bank has not already been refreshed; and selecting a next memory bank for refreshing in response to determining that the selected memory bank has already been refreshed.
Example 13. The method of example 7, further including: determining whether the identified number of memory banks have been refreshed; selecting the next memory bank for refreshing in response to determining that the identified number of memory banks have not yet been refreshed; and ending the multi-bank memory refresh in response to determining that the identified number of memory banks have been refreshed.
Computer program code or “program code” for execution on a programmable processor for carrying out operations of the various embodiments may be written in a high level programming language such as C, C++, C#, Smalltalk, Java, JavaScript, Visual Basic, a Structured Query Language (e.g., Transact-SQL), Perl, or in various other programming languages. Program code or programs stored on a computer readable storage medium as used in this application may refer to machine language code (such as object code) whose format is understandable by a processor.
The foregoing method descriptions and the process flow diagrams are provided merely as illustrative examples and are not intended to require or imply that the operations of the various embodiments must be performed in the order presented. As will be appreciated by one of skill in the art the order of operations in the foregoing embodiments may be performed in any order. Words such as “thereafter,” “then,” “next,” etc. are not intended to limit the order of the operations; these words are simply used to guide the reader through the description of the methods. Further, any reference to claim elements in the singular, for example, using the articles “a,” “an” or “the” is not to be construed as limiting the element to the singular.
The various illustrative logical blocks, modules, circuits, and algorithm operations described in connection with the various embodiments may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and operations have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the claims.
The hardware used to implement the various illustrative logics, logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but, in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuitry that is specific to a given function.
In one or more embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable medium or a non-transitory processor-readable medium. The operations of a method or algorithm disclosed herein may be embodied in a processor-executable software module that may reside on a non-transitory computer-readable or processor-readable storage medium. Non-transitory computer-readable or processor-readable storage media may be any storage media that may be accessed by a computer or a processor. By way of example but not limitation, such non-transitory computer-readable or processor-readable media may include RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above are also included within the scope of non-transitory computer-readable and processor-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a non-transitory processor-readable medium and/or computer-readable medium, which may be incorporated into a computer program product.
The preceding description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the claims. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and implementations without departing from the scope of the claims. Thus, the present disclosure is not intended to be limited to the embodiments and implementations described herein, but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein.
