High-Performance Inline ECC Architecture for DRAM Controllers

Abstract

The present invention discloses a high-performance inline ECC architecture for a DRAM controller. Specifically disclosed are techniques for reducing the time required to read and write data to a memory. When error-correcting code (ECC) bits for detecting and / or correcting data corruption are written to the memory, data reads and / or writes can be delayed. In some cases, writing ECC bits may take longer than writing data bits because ECC writes may involve read / modify / write operations rather than simply writing bits to the memory. By interleaving ECC writes with data writes, some of the latency associated with writing ECC bits can be hidden. However, if there are not enough data writes available for interleaving, hiding this latency becomes difficult. Thus, for example, various techniques are disclosed where ECC writes are postponed until a sufficient number of data writes become available for interleaving. By interleaving ECC writes, the disclosed techniques reduce the total time required to read and write data to the memory.

Description

Technical Field

[0001] Each embodiment generally relates to computer memory controller technology, and more specifically, to techniques for reducing the time to read from and write to memory. Background Art

[0002] Some conventional memory controllers write system and application data, along with corresponding error correction code (ECC) data, to memory via a command / data bus. These memory controllers can then read the system and application data, along with the corresponding ECC data, from memory via the command / data bus and use the corresponding ECC data to verify the system and application data.

[0003] Certain conventional memory controllers implement so-called "inline ECC" operations. In such an implementation, the memory controller writes system and application data, along with corresponding ECC data, to the same memory page via the command / data bus. The memory controller then reads the system and application data, along with the corresponding ECC data, from the same memory page via the command / data bus. A memory controller configured in this manner issues write transactions and corresponding ECC write transactions to memory during a time interval herein referred to as a "write turn". These memory controllers then issue read transactions and corresponding ECC read transactions to memory during a time interval herein referred to as a "read turn". Generally, write turns and read turns alternate with each other.

[0004] ECC write transactions generally experience higher latency for at least two reasons. First, a given ECC write transaction cannot occur immediately after a previous write transaction has completed because a delay is needed to prepare the memory page for the additional write data associated with the ECC write transaction. This delay may be caused by an internal read-modify-write. Second, once a given ECC write transaction has completed, activation operations are typically required to prepare the memory page for subsequent read operations. These activation operations consume additional clock cycles.

[0005] When other write transactions from other banks are interleaved with those ECC write transactions on the command / data bus, the latency associated with the ECC write transactions can be masked. However, at the end of a write turn, most write transactions have been completed, leaving few (if any) write transactions that can be interleaved with the ECC write transactions on the command / data bus. Since there are fewer write transactions available for interleaving, the latency associated with these ECC write turns generally cannot be masked, which can degrade overall performance in various ways.

[0006] First, the write round needs to be extended while the remaining ECC write transactions are completed. Extending the write round delays subsequent read rounds, thereby reducing the memory access speed. The latency typically associated with the ECC write transactions discussed above exacerbates these types of delays. In turn, the latency of critical requests such as central processing unit (CPU) reads and / or memory management unit (MMU) walks may increase, thereby reducing the overall system performance. Second, when the command / data bus is not fully utilized when the remaining ECC write transactions are completed, the "bubbles" on the command / data bus reduce the overall bus performance. These problems further reduce the system performance when multiple ECC writes are pending in the same bank.

[0007] As previously mentioned, what is needed in the art is a more efficient way to schedule ECC write transactions to memory. SUMMARY OF THE INVENTION

[0008] Various embodiments include computer-implemented methods, including: determining that there are not a sufficient number of pending write transactions available during a first time period when a write transaction is scheduled to execute to mask one or more latencies associated with a first error correction code (ECC) write transaction; in response to determining that there are not a sufficient number of pending write transactions available, preventing the first ECC write transaction from being scheduled to execute during the first time period; determining that there are a sufficient number of pending write transactions available during a second time period when a write transaction is scheduled to execute to mask one or more delays; and in response to determining that there are a sufficient number of pending write transactions available, scheduling the first ECC write transaction to execute during the second time period.

[0009] At least one technical advantage of the disclosed technology over the prior art is that by deferring those ECC write transactions to subsequent rounds, the latency associated with the ECC write transactions at the end of the round can continue to be masked. As a result, only a small number of read rounds after the write round have to be delayed, and more ECC write transaction latencies can be masked, which increases the memory access speed and overall performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Thus, the manner in which the above-described features of the various embodiments can be understood in detail can be obtained by referring to the various embodiments, some of which are illustrated in the drawings. However, it should be noted that the drawings only illustrate typical embodiments of the inventive concept and should not be considered to limit the scope in any way, and there are other equally effective embodiments.

[0011] Figure 1 A system configured to implement one or more aspects of the present embodiment is shown;

[0012] Figure 2 is a more detailed illustration of a Figure 1 parallel processing subsystem according to various embodiments;

[0013] Figure 3A is a more detailed illustration of a Figure 2 partitioning unit according to various embodiments;

[0014] Figure 3B shows an alternative system of a Figure 3A memory controller that can be implemented according to various embodiments;

[0015] Figure 4 is a more detailed illustration of a Figure 3A and Figure 3B memory controller according to various embodiments;

[0016] Figure 5 is a bus activity diagram showing how an ECC write transaction can degrade performance according to various embodiments;

[0017] Figure 6 is a bus activity diagram showing how a cache ECC write transaction can improve performance according to various embodiments; and

[0018] Figure 7 is a flowchart of method steps for caching ECC write transactions to improve performance according to various embodiments. DETAILED DESCRIPTION

[0019] In the following description, numerous specific details are set forth to provide a more thorough understanding of the various embodiments. However, it will be apparent to one of ordinary skill in the art that the inventive concept may be practiced without one or more of these specific details.

[0020] As described above, a memory controller configured to implement "inline ECC" issues a write transaction and a corresponding ECC write transaction to the same memory page during a write round. The ECC write transaction can be a "masked" write that triggers an internal read-modify-write. Subsequently, the memory controller may issue a read transaction and a corresponding ECC read transaction to the same memory page during a read round. The memory controller issues these various transactions over a command / data bus.

[0021] ECC write transactions incur various latencies, which can be masked when other write transactions are interleaved with those ECC write transactions on the command / data bus. However, at the end of the write round, there are still not enough write transactions to be interleaved with the ECC write transactions, and the latencies associated with these ECC write transactions cannot be masked. Therefore, the write round may have to be extended while the remaining ECC write transactions are completed. During this period, the command / data bus is not fully utilized, resulting in a condition known as "bubbles" in the art.

[0022] To address these issues, various embodiments include a transaction arbiter that schedules memory transactions across the command / data bus. During a write round, the transaction arbiter determines whether there are enough write transactions available to be interleaved with the ECC write transactions to mask the latencies associated with those ECC write transactions. If there are not enough write transactions available, the transaction arbiter activates a cache to store the remaining ECC write transactions, thereby allowing a subsequent read round to begin. During the subsequent read round, if the transaction arbiter schedules an ECC read transaction for ECC data corresponding to the ECC write transactions cached, the ECC read transaction is serviced from the cache. During a subsequent write round, the transaction arbiter preferentially schedules the cached ECC write transactions, thereby allowing those ECC write transactions to be interleaved with other write transactions on the command / data bus.

[0023] At least one technical advantage of the disclosed technology over the prior art is that by deferring those ECC write transactions to subsequent rounds, the latencies associated with the ECC write transactions at the end of the round can continue to be masked. As a result, there are fewer read rounds that have to be delayed after a write round, and more ECC write transaction latencies can be masked, which increases memory access speed and overall performance. Another technical advantage of the disclosed technology is that the deferred ECC write transactions can be interleaved with other write transactions to increase command / data bus utilization. Therefore, the disclosed technology can be implemented to reduce the occurrence of bubbles on the command / data bus and improve the performance of the command / data bus. These technical advantages represent one or more technological advancements over prior art methods.

[0024] System Overview

[0025] Figure 1FIG. 0 is a block diagram showing a computer system 100 configured to implement one or more aspects of the present embodiment. The computer system 100 includes a central processing unit (CPU) 102 and a system memory 104 that communicate via an interconnect path that may include a memory bridge 105. The memory bridge 105 (e.g., which may be a north bridge chip) is connected to an I / O (input / output) bridge 107 via a bus or other communication path 106 (e.g., a HyperTransport link). The I / O bridge 107 (which may be, for example, a south bridge chip) receives user input from one or more user input devices 108 (e.g., a keyboard, a mouse) and forwards the input to the CPU 102 via the communication path 106 and the memory bridge 105. The parallel processing subsystem 112 is coupled to the memory bridge 105 via a bus or a second communication path 113 (e.g., a Peripheral Component Interconnect (PCI) Express, an Accelerated Graphics Port, or a HyperTransport link); in one embodiment, the parallel processing subsystem 112 is a graphics subsystem that delivers pixels to a display device 110, which may be any conventional cathode ray tube, liquid crystal display, light emitting diode display, etc. A system disk 114 is also connected to the I / O bridge 107 and may be configured to store content, applications, and data for use by the CPU 102 and the parallel processing subsystem 112. The system disk 114 provides non-volatile storage for applications and data and may include a fixed or removable hard disk drive, a flash device, and a CD-ROM (Compact Disc Read-Only Memory), a DVD-ROM (Digital Versatile Disc-ROM), a Blu-ray, an HD-DVD (High Definition DVD), or other magnetic, optical, or solid state storage devices.

[0026] A switch 116 provides a connection between the I / O bridge 107 and other components such as a network adapter 118 and various plug-in cards 120 and 121. Other components (not explicitly shown), including Universal Serial Bus (USB) or other port connections, a CD (Compact Disc) drive, a DVD (Digital Versatile Disc) drive, a film recording device, etc., may also be connected to the I / O bridge 107. Figure 1 The various communication paths shown, including the specifically named communication paths 106 and 113, may be implemented using any suitable protocol, such as PCI Express, AGP (Accelerated Graphics Port), HyperTransport, or any other bus or one or more point-to-point communication protocols, and the connections between different devices may use different protocols known in the art.

[0027] In one embodiment, the parallel processing subsystem 112 includes circuitry optimized for graphics and video processing, including, for example, video output circuitry, and constitutes a Graphics Processing Unit (GPU). In another embodiment, the parallel processing subsystem 112 includes circuitry optimized for general-purpose processing while retaining the computational architecture described in more detail herein. In yet another embodiment, the parallel processing subsystem 112 may be integrated with one or more other system elements in a single subsystem, such as joining the memory bridge 105, the CPU 102, and the I / O bridge 107 to form a System-on-Chip (SoC), also as described in more detail below in conjunction with Figure 3B is described in more detail.

[0028] It should be understood that the systems shown herein are illustrative and can be varied and modified. The connection topology can be modified as needed, including the number and arrangement of bridges, the number of CPUs 102, and the number of parallel processing subsystems 112. For example, in some embodiments, the system memory 104 is directly connected to the CPU 102 rather than through a bridge, and other devices communicate with the system memory 104 via the memory bridge 105 and the CPU 102. In other alternative topologies, the parallel processing subsystem 112 is connected to the I / O bridge 107 or directly to the CPU 102 rather than to the memory bridge 105. In other embodiments, the I / O bridge 107 and the memory bridge 105 can be integrated into a single chip rather than existing as one or more discrete devices. Large embodiments can include two or more CPUs 102 and two or more parallel processing subsystems 112. The specific components shown herein are optional; for example, any number of expansion cards or peripheral devices may be supported. In some embodiments, the switch 116 is eliminated, and the network adapter 118 and the expansion cards 120, 121 are directly connected to the I / O bridge 107.

[0029] Figure 2 A parallel processing subsystem 112 is shown in accordance with various embodiments. As shown, the parallel processing subsystem 112 includes one or more Parallel Processing Units (PPUs) 202, each Parallel Processing Unit (PPU) 202 being coupled to a local Parallel Processing (PP) memory 204. Generally, the parallel processing subsystem includes U PPUs, where U ≥ 1 (here, multiple instances of similar objects are represented by the reference numeral identifying the object and a bracketed number identifying the desired instance). The PPU 202 and the parallel processing memory 204 can be implemented using one or more integrated circuit devices, such as programmable processors, Application-Specific Integrated Circuits (ASICs), or memory devices, or any other technically feasible means.

[0030] Referring again to Figure 1 and Figure 2, in some embodiments, some or all of the PPUs 202 in the parallel processing subsystem 112 are graphics processors having a rendering pipeline that can be configured to perform various operations related to generating pixel data from graphics data, the graphics data being provided by the CPU 102 and / or the system memory 104 via the memory bridge 105 and the second communication path 113, which interacts with the local parallel processing memory 204 (which can be used as a graphics memory including, for example, a conventional frame buffer) to store and update pixel data, transfer the pixel data to the display device 110, etc. In some embodiments, the parallel processing subsystem 112 can include one or more PPUs 202 operating as graphics processors and one or more other PPUs 202 for general computing. The PPUs can be the same or different, and each PPU can have a dedicated parallel processing memory device or no dedicated parallel processing memory device. One or more of the PPUs 202 in the parallel processing subsystem 112 can output data to the display device 110, or each PPU 202 in the parallel processing subsystem 112 can output data to one or more display devices 110.

[0031] In operation, the CPU 102 is the main processor of the computer system 100, controlling and coordinating the operation of other system components. In particular, the CPU 102 issues commands that control the operation of the PPU 202. In some embodiments, the CPU 102 writes the command stream for each PPU 202 to a data structure (not explicitly shown in Figure 1 or Figure 2 ) that can be located in the system memory 104, the parallel processing memory 204, or another storage location accessible to both the CPU 102 and the PPU 202. A pointer to each data structure is written to a pushbuffer to initiate the processing of the command stream in the data structure. The PPU 202 reads the command stream from one or more pushbuffers and then executes the commands asynchronously relative to the operation of the CPU 102. The execution priority for each pushbuffer can be specified by an application via the device driver 103 to control the scheduling of different pushbuffers.

[0032] Now referring back to Figure 2 and Figure 1, each PPU 202 includes an I / O (Input / Output) unit 205 that communicates with the rest of the computer system 100 via a communication path 113 that is connected to the memory bridge 105 (alternatively, in one alternative embodiment, directly connected to the CPU 102). The connection of the PPU 202 to the rest of the computer system 100 can also be varied. In some embodiments, the parallel processing subsystem 112 is implemented as an add-in card that can be inserted into an expansion slot of the computer system 100. In other embodiments, the PPU 202 can be integrated with a bus bridge (such as the memory bridge 105 or the I / O bridge 107) on a single chip. In other embodiments, some or all of the elements of the PPU 202 can be integrated with the CPU 102 on a single chip.

[0033] In one embodiment, the communication path 113 is a PCI Express link, where dedicated lanes are allocated to each PPU 202, as is known in the art. Other communication paths can also be used. The I / O unit 205 generates packets (or other signals) for transmission on the communication path 113 and also receives all incoming packets (or other signals) from the communication path 113, directing the incoming packets to the appropriate components of the PPU 202. For example, commands related to processing tasks can be directed to the host interface 206, while commands related to memory operations (e.g., reading from or writing to the parallel processing memory 204) can be directed to the memory crossbar unit 210. The host interface 206 reads each push buffer and outputs the command stream stored in the push buffer to the front end 212.

[0034] Each PPU 202 advantageously implements a highly parallel processing architecture. As shown in detail, the PPU 202(0) includes an array of processing clusters 230 that includes a number C of general processing clusters (GPCs) 208, where C ≥ 1. Each GPC 208 is capable of concurrently executing a large number (e.g., hundreds or thousands) of threads, where each thread is an instance of a program. In various applications, different GPCs 208 can be assigned to process different types of programs or to perform different types of computations. The assignment of GPCs 208 can vary according to the workload generated by each type of program or computation.

[0035] The GPC 208 receives processing tasks to be executed from the job assignment unit within the task / job unit 207. The job assignment unit receives a pointer to the processing task, which is encoded as task metadata (TMD) and stored in the memory. The pointer to the TMD is included in a command stream, which is stored as a push buffer and received by the front-end unit 212 from the host interface 206. Processing tasks that can be encoded as TMD include an index of the data to be processed, as well as status parameters and commands that define how the data is to be processed (e.g., what program is to be executed). The task / job unit 207 receives tasks from the front-end 212 and ensures that the GPC 208 is configured to an active state before starting the processing specified by each TMD. A priority can be specified for each TMD for scheduling the execution of the processing task. Processing tasks can also be received from the processing cluster array 230. Optionally, the TMD can include a parameter that controls whether the TMD is added to the head or tail of a list of processing tasks (or a list of pointers to processing tasks), thus providing another level of control over the priority.

[0036] The memory interface 214 includes a number D of partition units 215, each partition unit 215 being directly coupled to a portion of the parallel processing memory 204, where D ≥ 1. As shown, the number of partition units 215 generally equals the number of dynamic random access memories (DRAMs) 220. In other embodiments, the number of partition units 215 may not equal the number of memory devices. Those of ordinary skill in the art will understand that the DRAMs 220 can be replaced with other suitable storage devices and can be of a generally conventional design. Thus, a detailed description is omitted. Render targets (such as frame buffers or texture maps) can be stored across the DRAMs 220, allowing the partition units 215 to write portions of each render target in parallel to effectively utilize the available bandwidth of the parallel processing memory 204.

[0037] Any one of the GPCs 208 can process data to be written to any of the DRAMs 220 within the parallel processing memory 204. The crossbar switch unit 210 is configured to route the output of each GPC 208 to the input of any partition unit 215 or to another GPC 208 for further processing. The GPC 208 communicates with the memory interface 214 through the crossbar switch unit 210 to read from or write to various external memory devices. In one embodiment, the crossbar switch unit 210 has connections to the memory interface 214 to communicate with the I / O unit 205 and to the local parallel processing memory 204, enabling processing cores within different GPCs 208 to communicate with the system memory 104 or with other memories that are not local to the PPU 202. In Figure 2In the illustrated embodiment, the crossbar switch unit 210 is directly connected to the I / O unit 205. The crossbar switch unit 210 can use virtual channels to separate traffic flows between the GPC 208 and the partition unit 215.

[0038] In addition, the GPC 208 can be programmed to perform processing tasks related to a wide variety of applications, including but not limited to linear and non-linear data transformations, filtering of video and / or audio data, modeling operations (e.g., applying physical laws to determine the position, velocity, and other attributes of an object), image rendering operations (e.g., tessellation shaders, vertex shaders, geometry shaders, and / or pixel shader programs), etc. The PPU 202 can transfer data from the system memory 104 and / or the local parallel processing memory 204 to internal (on-chip) memory, process the data, and write the resulting data back to the system memory 104 and / or the local parallel processing memory 204, where such data can be accessed by other system components, including the CPU 102 or another parallel processing subsystem 112.

[0039] The PPU 202 can have any number of local parallel processing memories 204, excluding local memory, and can use local memory and system memory in any combination. For example, the PPU 202 can be a graphics processor in a unified memory architecture (UMA) embodiment. In such an embodiment, little or no dedicated graphics (parallel processing) memory will be provided, and the PPU 202 will use system memory exclusively or almost exclusively. In a UMA embodiment, the PPU 202 can be integrated into a bridge chip or a processor chip, or provided as a discrete chip with a high-speed link (e.g., PCI Express), the high-speed link connecting the PPU 202 to the system memory via a bridge chip or other communication means.

[0040] As described above, any number of PPU 202 can be included in the parallel processing subsystem 112. For example, multiple PPU 202 can be provided on a single plug-in card, or multiple plug-in cards can be connected to the communication path 113, or, one or more PPU 202 can be integrated into a bridge chip. The PPU 202 in a multi-PPU system can be the same as or different from each other. For example, different PPU 202 can have different numbers of processing cores, different numbers of local parallel processing memories, etc. In the presence of multiple PPU 202, those PPU can operate in parallel to process data with a higher throughput than is possible with a single PPU 202. A system that includes one or more PPU 202 can be implemented in a variety of configurations and form factors, including desktop computers, laptop computers or handheld personal computers, servers, workstations, game consoles, embedded systems, etc.

[0041] Figure 3A One of the partition units 215 within a PPU 202 according to various embodiments Figure 2 is shown in the block diagram. As shown, the partition unit 215 includes an L2 cache 350, a memory controller 355, and a raster operation unit (ROP) 360. The L2 cache 350 is a read / write cache configured to perform load and store operations received from the crossbar unit 210 and the ROP 360. Read misses and urgent write-back requests are output from the L2 cache 350 to the memory controller 355 for processing. Dirty updates are also sent to the memory controller 355 for opportunistic processing. The memory controller 355 interfaces directly with the DRAM 220, outputs read and write requests, and receives data read from the DRAM 220. The memory controller 355 may also be implemented in the SoC architecture, as described in more detail below in conjunction with Figure 3B is described in more detail.

[0042] In a graphics application, the ROP 360 is a processing unit that performs raster operations (e.g., stencil test, z-test, blending, etc.) and outputs pixel data as processed graphics data to be stored in the graphics memory. In some embodiments, the ROP 360 is included within each GPC 208 instead of the partition unit 215, and pixel read and write requests are sent through the crossbar unit 210 instead of pixel fragment data.

[0043] The processed graphics data can be displayed on the display device 110 or routed for further processing by one of the processing entities within the CPU 102 or the parallel processing subsystem 112. Each partition unit 215 includes an ROP 360 to allocate the processing of raster operations. In some embodiments, the ROP 360 may be configured to compress z data or color data written to the memory, as well as decompress z data or color data read from the memory.

[0044] Figure 3B An alternative system that can implement a memory controller according to various embodiments is shown Figure 3A is shown. As shown, the system 300 includes Figure 1 a CPU 102 of Figure 2The PPU 202 and the system-on-chip (SoC) client 302. The SoC client 302 may include an encoder, a decoder, a display, a camera, and other devices. The CPU 102, the PPU 202, and the SoC client 302 are coupled to the memory controller 355, and the memory controller 355 is configured to transfer various types of memory transactions to the memory controller 355. In response, the memory controller 355 accesses the data stored in the DRAM 220. For example, the CPU 102 may send one or more write transactions to the memory controller 355. In response, the memory controller 355 may write the data to the DRAM 220. Similarly, the CPU 102 may send one or more read transactions to the memory controller 355. In response, the memory controller 355 may read the data from the DRAM 220.

[0045] Generally referring Figure 3A - Figure 3B , the memory controller 355 may be implemented in any of the configurations shown in these figures to provide access to the DRAM 220. The memory controller 355 performs various operations to coordinate the execution of memory transactions to improve memory access performance, as described in more detail below in connection with Figure 4 - Figure 7 More detailed description.

[0046] The memory controller is configured to improve memory access

[0047] Figure 4 is according to various embodiments Figure 3A - Figure 3B A more detailed illustration of the memory controller. As shown, the memory controller 355 includes a transaction queue 400, an ECC cache 410, an activation arbiter 420, a direction arbiter 430, a transaction arbiter 440, a command issue 450, and an ECC command scheduler 460. The transaction queue 400 is coupled to the activation arbiter 420, the direction arbiter 430, and the transaction arbiter 440. The activation arbiter 420 is coupled to the command issue 450. The direction arbiter 430 is coupled to the activation arbiter 420. The transaction arbiter 440 is coupled to the command issue 450 and the ECC command scheduler 460. The command issue 450 is coupled to the DRAM 220 via a command / data bus 452. The ECC command scheduler 460 is coupled to the ECC cache 410.

[0048] The transaction queue 400 is configured to queue write transactions and read transactions. Write transactions involve normal system data to be written to the DRAM 220, and read transactions involve normal system data to be read from the DRAM 220.

[0049] The transaction arbiter 440 obtains write transactions from the transaction queue 400 and causes the command issue 450 to issue those write transactions to the DRAM 220 during a write round. The ECC command scheduler 460 generates ECC write transactions corresponding to those write transactions during the write round. The ECC write transactions specify ECC data associated with the system data to be written to the DRAM 220. As referred to herein, a "write round" is an interval when write transactions and ECC write transactions are scheduled for execution.

[0050] During a given write round, the transaction arbiter 440 schedules a given write transaction for execution, and the ECC command scheduler 460 schedules the corresponding ECC write transaction for execution. In response, the DRAM 220 stores the write data associated with the given write transaction into a given memory page and stores the ECC data associated with the corresponding ECC write transaction into the same memory page. This method may be referred to in the art as "inline ECC". In one embodiment, a portion of each memory page may be allocated for ECC data and the remaining portion of each memory page may be allocated for normal system data.

[0051] The transaction arbiter 440 obtains read transactions from the transaction queue 400 and causes the command issue 450 to issue those read transactions to the DRAM 220 during a read round. The ECC command scheduler 460 generates ECC read transactions corresponding to those read transactions during the read round. The ECC read transactions specify ECC data associated with the system data to be read from the DRAM 220. As described herein, a "read round" is an interval when read transactions and ECC read transactions are scheduled for execution.

[0052] During a given read round, the ECC command scheduler 460 schedules a given ECC read transaction to read ECC data from a relevant memory page of the DRAM 220, and then the transaction arbiter 440 schedules the corresponding read transaction to read data from the same memory page of the DRAM 220. As is known in the art, the ECC data can be used to verify the read data.

[0053] The direction arbiter 430 analyzes the transaction queue 400 and determines whether a write round or a read round should occur. The direction arbiter 430 implements a round-robin policy based on the transactions stored in the transaction queue 400 to alternate between write rounds and read rounds. The round-robin policy indicates specific conditions for the end of a given round and the start of a subsequent round. The activation arbiter 420 sends an activation command to the DRAM 220 to prepare for a given write round or a given read round.

[0054] ECC write transactions are typically partial write transactions and can therefore cause significant latency. The transaction arbiter 440 and the ECC command scheduler 460 can sometimes mask this latency during a write round by interleaving write transactions and ECC write transactions. The transaction arbiter 440 and the ECC command scheduler 460 can mask the latency in this way when there are sufficient write transactions available and sufficient banks of the command / data bus 452 are open to service those write transactions. However, when the write round is nearly over, there may not be enough write transactions available to interleave with any remaining ECC write transactions, and not enough banks of the command / data bus 452 are open. Therefore, the write round must be extended until the remaining ECC write transactions are completed. During this time, the command / data bus 452 is underutilized. These issues are described in more detail below in conjunction with Figure 5 These issues are described in more detail.

[0055] To address the above issues, the transaction arbiter 440 analyzes the transaction queue 400 during a write and determines when there are not enough write transactions available to mask the latency associated with any remaining ECC write transactions. The transaction arbiter 440 then activates the ECC cache 410 and causes the ECC command scheduler 460 to cache the remaining ECC write transactions. The transaction arbiter 440 can then initiate a read round without waiting for these remaining ECC write transactions to complete. During the read round, any ECC read transactions targeted at the same memory space associated with the cached ECC write transactions are serviced from the ECC cache 410. During a subsequent write round, the cached ECC write transactions are prioritized to occur near the beginning of the write round and can therefore be interleaved with write transactions to mask the latency associated with these ECC write transactions. These issues are described in more detail below in conjunction with Figure 6 This method is described in more detail.

[0056] Exemplary bus activity diagram

[0057] Figure 5 is a bus activity diagram according to various embodiments, which shows how ECC write transactions degrade performance. As shown, the bus activity diagram 500 indicates the various operations that occur on banks B0 to B4 of the command / data bus 452 during a write round 510 and a subsequent read round 520. These operations include write transactions, ECC write transactions, activations, ECC read transactions, and read transactions.

[0058] As described above, an ECC write transaction may cause significant latency. There are two reasons for this latency. First, a given ECC write transaction cannot occur immediately after a previous write transaction has been completed. A given ECC write transaction can only begin after a minimum latency shown as D0 in the bus activity diagram 500. Second, an activation following a given ECC write transaction cannot occur immediately after the ECC write transaction has been completed. The activation can only begin after a minimum latency shown as D1 in the bus activity diagram 500.

[0059] When many banks are open and write transactions can be interleaved with a given ECC write transaction, the latency associated with the given ECC write transaction can be masked. For example, the latencies D0 and D1 associated with bank B0 are masked by write transactions occurring on banks B3 and B4.

[0060] However, at the end of write round 510, many write transactions have been completed and the corresponding banks may be closed. Therefore, write transactions may not be available to mask the latency associated with any remaining ECC write transactions. For example, ECC write transactions occurring on banks B3 and B4 cannot be masked. In this case, a bubble 520 occurs because the ECC write transactions occurring on banks B3 and B4 cause write round 510 to be extended, and during this period the command / data bus 452 is not fully utilized. Bubbles generally limit the performance of the command / data bus 452. The transaction arbiter 440 and the ECC command scheduler 460 mitigate the bubbles caused by ECC write transactions at the end of a round by the method described below Figure 6 described.

[0061] Figure 6 is a bus activity diagram according to various embodiments, which shows how cache ECC write transactions can improve performance. As shown, the bus activity diagram 600 indicates various operations occurring on banks B0 to B4 of the command / data bus 452 during write round 610, subsequent read round 620, and subsequent write round 630.

[0062] During write round 610, the transaction arbiter 440 determines that there are not enough write transactions available to mask the latency associated with the ECC write transactions on banks B3 and B4 (previously shown in Figure 5 write round 510). In response, the transaction arbiter 440 defers these ECC write transactions to occur during write round 630, as shown. In doing so, the transaction arbiter 440 activates the ECC cache 410, and the ECC command scheduler 460 sends the ECC write transactions to the ECC cache 410 instead of issuing those transactions for execution.

[0063] Using this method, it is not necessary to extend the write round 610 to accommodate the ECC write transaction at the end of the round, and thus the read round 620 can start earlier than the read round 520 of Figure 5 Once the read round 620 is completed, the transaction arbiter 440 prioritizes the ECC write transaction of the cache during the write round 630, and interleaves these transactions on banks B3 and B4 with other write transactions on banks B0 and B1. In this way, the latency associated with these ECC write transactions can be effectively masked, and bubbles on the command / data bus 452 can be reduced or avoided.

[0064] In one embodiment, the number of write transactions required to mask the latency associated with a given ECC write transaction is proportional to the number of clock cycles required to perform the ECC write transaction. For example, when a given ECC write transaction is completed in N clock cycles, then N write transactions are required to mask the latency associated with the given ECC write transaction. In one embodiment, the transaction arbiter 440 can interleave the ECC write transaction with write transactions from different bank groups.

[0065] Deferring ECC Write Transactions to Improve Performance

[0066] Figure 7 is a flowchart of method steps for caching ECC write transactions to improve performance according to various embodiments. Although the method steps are described in connection with the Figure 1 - Figure 6 system, those skilled in the art will understand that any system configured to execute the method steps in any order falls within the scope of the various embodiments.

[0067] As shown, method 700 begins at step 702, where the transaction arbiter 440 of Figure 4 schedules write transactions, and the ECC command scheduler 460 generates and schedules ECC write transactions. The transaction arbiter 440 issues write transactions, and the ECC command scheduler 460 schedules ECC write transactions during the write round. During the write round, the transaction arbiter 440 retrieves write transactions from the transaction cache 400, and in some cases, retrieves write transactions from previously cached ECC write transactions.

[0068] At step 704, the transaction arbiter 440 determines whether there are sufficient write transactions available to mask the ECC write transaction latency. The occurrence of ECC write transaction latency is because the ECC write transaction cannot be executed immediately after the previous write transaction, and subsequent activation operations cannot be executed immediately after the ECC write transaction. These latencies generally cannot be masked at the end of the write round.

[0069] If, at step 704, transaction arbiter 440 determines that there are sufficient write transactions available, method 700 returns to step 702, and transaction arbiter 440 continues to schedule write transactions, and ECC command scheduler 460 continues to schedule ECC write transactions. Transaction arbiter 440 also preferentially schedules any cached ECC write transactions. Alternatively, if, at step 704, transaction arbiter 440 determines that there are not sufficient write transactions available, method 700 proceeds to step 706.

[0070] At step 706, transaction arbiter 440 activates ECC cache 410 to store any remaining ECC write transactions until a subsequent write round. The size of ECC cache 410 is sized to accommodate the number of ECC write transactions typically remaining at the end of a write round. ECC cache 410 is configured to service ECC read requests targeted to the same memory space as any cached ECC write transactions.

[0071] At step 708, direction arbiter 430 initiates a read round. Direction arbiter 430 implements a round-robin policy based on the number and / or priority of transactions stored in transaction queue 400. In one embodiment, the round-robin policy may indicate that a transition from a write round to a read round should occur when a threshold number of read transactions reside in transaction queue 400.

[0072] At step 710, in response to direction arbiter 430, transaction arbiter 440 initiates a read round and schedules read transactions, while ECC command scheduler 460 schedules corresponding ECC read transactions. In so doing, transaction arbiter 440 issues read transactions, and ECC command scheduler 460 issues ECC read transactions on command / data bus 452. ECC read transactions targeted to ECC data are typically scheduled before read transactions targeted to corresponding read data. Then, based on the ECC data, the read data can be verified and / or corrected as needed.

[0073] In step 712, the transaction arbiter 440 determines whether any of the ECC read transactions are targeted at a memory space associated with an ECC write transaction in the cache. If the transaction arbiter 440 identifies an ECC read transaction targeted at a memory space associated with an ECC write transaction in the cache, the method proceeds to step 714. In step 714, the transaction arbiter 440 causes the ECC cache 410 to service the ECC read transaction based on the ECC write transaction in the cache. In one embodiment, the ECC write transaction in the cache may include the ECC data that needs to be provided in response to the ECC read transaction. If, in step 712, the transaction arbiter 440 does not identify any ECC read transactions targeted at a memory space associated with an ECC write transaction in the cache, the method skips step 714 and proceeds to step 716. In the case where the ECC data is not cached, the ECC data may also be read from the DRAM 220, potentially delaying the start of subsequent write rounds.

[0074] In step 716, the direction arbiter 430 initiates a write round based on the round robin policy discussed above in connection with step 708. In one embodiment, the round robin policy may indicate that a transition from a read round to a write round should occur when a threshold number of write transactions reside in the transaction queue 400. After the read round ends, the transaction arbiter 440 may stop the cache ECC write transactions.

[0075] In step 718, the transaction arbiter 440 gives priority to the ECC write transactions in the cache when issuing write transactions during the write round. Then, the ECC write transactions in the cache may be interleaved with other write transactions on different banks of the command / data bus 452, thereby masking the latency associated with these ECC write transactions. Once all the ECC write transactions in the cache have been scheduled, the transaction arbiter 440 may deactivate the ECC cache 410 and then continuously determine whether there are enough write transactions available to mask the latency associated with the ECC write transactions. In one embodiment, the number of write transactions required to mask the latency associated with a given ECC write transaction is proportional to the number of clock cycles required to execute the ECC write transaction. In another embodiment, the transaction arbiter 440 may interleave the ECC write transactions with write transactions from different bank groups.

[0076] In summary, the transaction arbiter schedules memory transactions across the command / data bus. During a write round, the transaction arbiter determines if there are sufficient write transactions available to interleave with the ECC write transactions in order to mask the latency associated with those ECC write transactions. If there are not enough write transactions available, the transaction arbiter activates the cache to store the remaining ECC write transactions, thereby allowing a subsequent read round to begin. During the subsequent read round, if the transaction arbiter schedules an ECC read transaction for the ECC data of an ECC write transaction corresponding to the cache, the ECC read transaction is serviced from the cache. During a subsequent write round, the transaction arbiter preferentially schedules the ECC write transactions of the cache, thereby allowing those ECC write transactions to be interleaved with other write transactions on the command / data bus.

[0077] One implementation of the disclosed memory controller includes a transaction arbiter that performs a series of steps. In a first step, the transaction arbiter determines that there are not enough write transactions available to mask the latency associated with an ECC write transaction. The transaction arbiter performs this step by determining that fewer than N write transactions are queued, where the ECC write transaction requires N clock cycles to complete. In a second step, the transaction arbiter prevents the ECC write transaction from being scheduled for execution. The transaction arbiter performs this step by caching the ECC write transaction instead of scheduling the ECC write transaction for execution during a first write round. In a third step, the transaction arbiter determines that there are enough write transactions available to mask the latency associated with an ECC write transaction during a second write round. The transaction arbiter performs this step by determining that at least N write transactions are queued during the second write round. In a fourth step, the transaction arbiter schedules the ECC write transaction for execution during the second write round. By performing these four steps and corresponding sub-steps, the transaction arbiter reduces the occurrence of bus bubbles caused by ECC write transactions scheduled to execute at the end of a write round, thereby allowing the memory subsystem to operate more efficiently.

[0078] At least one technical advantage of the disclosed technology over the prior art is that by deferring those ECC write transactions to a subsequent round, the latency associated with ECC write transactions at the end of a round can continue to be masked. As a result, there are fewer read rounds that must be delayed after a write round, and more ECC write transaction latency can be masked, which increases memory access speed and overall performance. Another technical advantage of the disclosed technology is that the deferred ECC write transactions can be interleaved with other write transactions to increase command / data bus utilization. Thus, the disclosed technology can be implemented to reduce the occurrence of bubbles on the command / data bus and provide command / data bus performance. These technical advantages represent one or more technological advancements over prior art methods.

[0079] 1. Some embodiments include a computer-implemented method, comprising: determining that during a first time period in which a write transaction is scheduled to execute, there are not a sufficient number of pending write transactions available to mask one or more latencies associated with a first error correction code (ECC) write transaction; in response to determining that there are not a sufficient number of pending write transactions available, preventing the first ECC write transaction from being scheduled to execute during the first time period; determining that during a second time period in which a write transaction is scheduled to execute, there are a sufficient number of pending write transactions available to mask one or more latencies; and in response to determining that there are a sufficient number of pending write transactions available, scheduling the first ECC write transaction to execute during the second time period.

[0080] 2. The computer-implemented method of clause 1, wherein preventing the first ECC write transaction from being scheduled to execute includes: caching the first ECC write transaction during the first time period and during subsequent time periods in which a read transaction is scheduled to execute.

[0081] 3. The computer-implemented method of any one of clauses 1-2, further comprising: determining that a first read transaction targets a memory page associated with the first ECC write transaction; and servicing the first read transaction using a cached version of the first ECC write transaction.

[0082] 4. The computer-implemented method of any one of clauses 1-3, wherein during the second time period, scheduling one or more write transactions to execute using a first bank associated with a command / data bus, wherein scheduling the first ECC write transaction to execute includes: during the second time period, scheduling the first ECC write transaction to execute using a second bank associated with the command / data bus.

[0083] 5. The computer-implemented method of any one of clauses 1-4, wherein the first ECC write transaction executes during N clock cycles that occur during the second time period, and the one or more write transactions include at least N write transactions, where N includes a positive integer value.

[0084] 6. The computer-implemented method of any one of clauses 1-5, wherein the first ECC write transaction is associated with write data written to a first memory page during the first time period.

[0085] 7. The computer-implemented method of any one of clauses 1-6, wherein the first ECC write transaction is executed during the second time period to write ECC data associated with the write data to the first memory page.

[0086] 8. A computer-implemented method as described in any one of clauses 1-7, wherein determining that there are a sufficient number of write transactions to be processed available includes: determining that at least a first number of write transactions to be processed associated with a first set of memory banks are scheduled for execution during the second time period, and that at least a second number of write transactions to be processed associated with a second set of memory banks are scheduled for execution during the second time period.

[0087] 9. A computer-implemented method as described in any one of clauses 1-8, wherein preventing the first ECC write transaction from being scheduled for execution during the first time period includes: preventing a bubble from being formed on the command / data bus on which the first ECC transaction has been scheduled for execution during the first time period.

[0088] 10. A computer-implemented method as described in any one of clauses 1-9, wherein preventing the first ECC write transaction from being scheduled for execution during the first time period increases the utilization of the command / data bus during the first time period and the second time period.

[0089] 11. Some embodiments include a system comprising: a memory controller that schedules write transactions for execution by performing the following steps: determining that during a first time period in which a write transaction is scheduled for execution, there are not a sufficient number of write transactions to be processed available to mask one or more latencies associated with a first error correction code (ECC) write transaction; in response to determining that there are not a sufficient number of write transactions available, preventing the first ECC write transaction from being scheduled for execution during the first time period; determining that during a second time period in which a write transaction is scheduled for execution, there are a sufficient number of write transactions to be processed available to mask one or more latencies; and in response to determining that there are a sufficient number of write transactions available, scheduling the first ECC write transaction for execution during the second time period.

[0090] 12. The system as described in clause 11, wherein the memory controller prevents the first ECC write transaction from being scheduled for execution by caching the first ECC write transaction during the first time period and during subsequent time periods in which a read transaction is scheduled for execution.

[0091] 13. The system as described in any one of clauses 11-12, wherein the memory controller performs the following additional steps: determining that a first read transaction targets a memory page associated with the first ECC write transaction; and servicing the first read transaction using the cached version of the first ECC write transaction.

[0092] 14. The system as described in any one of clauses 11 - 13, wherein the memory controller performs the following additional steps: during the second time period, schedule one or more write transactions to be executed using a first bank associated with the command / data bus, wherein scheduling the first ECC write transaction to be executed includes: during the second time period, schedule the first ECC write transaction to be executed using a second bank associated with the command / data bus.

[0093] 15. The system as described in any one of clauses 11 - 14, wherein the first ECC write transaction is executed during N clock cycles that occur during the second time period, and the one or more write transactions include at least N write transactions, where N includes a positive integer value.

[0094] 16. The system as described in any one of clauses 11 - 15, wherein the first ECC write transaction is associated with write data written to a first memory page during the first time period, and wherein the first ECC write transaction is executed during the second time period to write ECC data associated with the write data to the first memory page.

[0095] 17. The system as described in any one of clauses 11 - 16, wherein the memory controller determines that there are a sufficient number of pending write transactions available by determining that during the second time period, schedule at least a first number of pending write transactions associated with a first set of banks to be executed, and during the second time period, schedule at least a second number of pending write transactions associated with a second set of banks to be executed.

[0096] 18. The system as described in any one of clauses 11 - 17, wherein the memory controller prevents the first ECC write transaction from being scheduled to be executed during the first time period to prevent a bubble from forming on the command / data bus on which the first ECC transaction has been scheduled to be executed during the first time period.

[0097] 19. The system as described in any one of clauses 11 - 18, wherein the memory controller preventing the first ECC write transaction from being scheduled to be executed during the first time period increases the utilization of the command / data bus during the first time period and the second time period.

[0098] 20. Some embodiments include a subsystem comprising: a cache that stores memory transactions; and a transaction arbiter that performs the following steps: determining that during a first time period in which a write transaction is scheduled to execute, there are not a sufficient number of pending write transactions available to mask one or more latencies associated with a first error correction code (ECC) write transaction; in response to determining that there are not a sufficient number of pending write transactions available, storing the first ECC write transaction in the cache to prevent the first ECC write transaction from being scheduled to execute during the first time period; determining that during a second time period in which a write transaction is scheduled to execute, there are a sufficient number of pending write transactions available to mask one or more latencies; and in response to determining that there are a sufficient number of pending write transactions available, scheduling the first ECC write transaction to execute during the second time period.

[0099] Any combination of any claim element recited in any claim and / or any element described in this application, in any way, falls within the intended scope of this embodiment and the protection.

[0100] The description of the various embodiments has been presented for purposes of illustration, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments.

[0101] Aspects of the present embodiments may be embodied as a system, method, or computer program product. Accordingly, aspects of the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects (which may generally be referred to herein as a "module" or "system"). Additionally, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer-readable media having computer-readable program code embodied thereon.

[0102] Any combination of one or more computer-readable media may be utilized. A computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0103] The foregoing has described aspects of the present disclosure with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. It should be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine. When executed by the processor of the computer or other programmable data processing apparatus, the instructions enable the functions / actions specified in one or more blocks of the flowchart and / or block diagram to be implemented. These processors may be, but are not limited to, general purpose processors, special purpose processors, application specific processors, or field programmable gate arrays.

[0104] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing the specified logical function. It should also be noted that, in some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can be implemented by a system based on dedicated hardware for performing the specified functions or actions, or combinations of dedicated hardware and computer instructions.

[0105] While the foregoing is directed to embodiments of the present disclosure, other and further embodiments of the present disclosure may be devised without departing from the basic scope thereof, and the scope of the present disclosure is determined by the appended claims.

Claims

1. A computer-implemented method, comprising: Determining that during a first time period in which a write transaction is scheduled for execution, there are not a sufficient number of pending write transactions available to mask one or more latencies associated with a first error correction code (ECC) write transaction; In response to determining that there are not a sufficient number of pending write transactions available, preventing the first ECC write transaction from being scheduled for execution during the first time period; Determining that during a second time period in which a write transaction is scheduled for execution, there are a sufficient number of pending write transactions available to mask one or more latencies; And In response to determining that there are a sufficient number of pending write transactions available, scheduling the first ECC write transaction for execution during the second time period.

2. The computer-implemented method according to claim 1, wherein preventing the first ECC write transaction from being scheduled for execution comprises: Caching the first ECC write transaction during the first time period and during subsequent time periods in which a read transaction is scheduled for execution.

3. The computer-implemented method of claim 1, further comprising: Determining that a first read transaction targets a memory page associated with the first ECC write transaction; And Servicing the first read transaction using the cached version of the first ECC write transaction.

4. The computer-implemented method according to claim 1, further comprising: During the second time period, scheduling one or more write transactions to execute using a first bank associated with a command / data bus, wherein scheduling the first ECC write transaction for execution includes: during the second time period, scheduling the first ECC write transaction to execute using a second bank associated with the command / data bus.

5. The computer-implemented method of claim 4, wherein the first ECC write transaction is executed during N clock cycles that occur during the second time period, and the one or more write transactions include at least N write transactions, where N includes a positive integer value.

6. The computer-implemented method of claim 1, wherein the first ECC write transaction is associated with write data written to a first memory page during the first time period.

7. The computer-implemented method of claim 6, wherein the first ECC write transaction is executed during the second time period to write ECC data associated with the write data to the first memory page.

8. The computer-implemented method according to claim 1, wherein determining that a sufficient number of write transactions to be processed are available includes: Determining that at least a first number of pending write transactions associated with a first set of banks are scheduled for execution during the second time period, and that at least a second number of pending write transactions associated with a second set of banks are scheduled for execution during the second time period.

9. The computer-implemented method according to claim 1, wherein preventing the first ECC write transaction from being scheduled for execution during the first time period comprises: Preventing a bubble from forming on a command / data bus on which the first ECC write transaction has been scheduled for execution during the first time period.

10. The computer-implemented method of claim 1, wherein preventing the first ECC write transaction from being scheduled for execution during the first time period increases utilization of the command / data bus during the first time period and the second time period.

11. A computer system, comprising: A memory controller that schedules write transactions for execution by performing the following steps: Determine that during a first time period in which a write transaction is scheduled to execute, there are not a sufficient number of pending write transactions available to mask one or more latencies associated with a first error correction code (ECC) write transaction; In response to determining that there are not a sufficient number of pending write transactions available, prevent the first ECC write transaction from being scheduled to execute during the first time period; Determine that during a second time period in which a write transaction is scheduled to execute, there are a sufficient number of pending write transactions available to mask one or more latencies; And In response to determining that there are a sufficient number of pending write transactions available, schedule the first ECC write transaction to execute during the second time period.

12. The system of claim 11, wherein the memory controller prevents the first ECC write transaction from being scheduled to execute by caching the first ECC write transaction during the first time period and during subsequent time periods in which a read transaction is scheduled to execute.

13. The system of claim 11, wherein the memory controller performs the following additional steps: Determine that a first read transaction targets a memory page associated with the first ECC write transaction; and Service the first read transaction using a cached version of the first ECC write transaction.

14. The system of claim 11, wherein the memory controller performs the following additional steps: during the second time period, scheduling one or more write transactions to be performed using a first bank associated with the command / data bus, wherein scheduling the first ECC write transaction to be performed includes: During the second time period, schedule the first ECC write transaction to execute using a second bank associated with the command / data bus.

15. The system of claim 14, wherein the first ECC write transaction executes during N clock cycles that occur during the second time period, and the one or more write transactions include at least N write transactions, where N includes a positive integer value.

16. The system of claim 14, wherein the first ECC write transaction is associated with write data written to a first memory page during the first time period, and wherein the first ECC write transaction is executed during the second time period to write ECC data associated with the write data to the first memory page.

17. The system of claim 14, wherein the memory controller determines that there are a sufficient number of pending write transactions available by determining that at least a first number of pending write transactions associated with a first set of banks are scheduled to execute during the second time period, and that at least a second number of pending write transactions associated with a second set of banks are scheduled to execute during the second time period.

18. The system of claim 11, wherein the memory controller prevents the first ECC write transaction from being scheduled to execute during the first time period to prevent a bubble from forming on the command / data bus on which the first ECC write transaction has been scheduled to execute during the first time period.

19. The system of claim 11, wherein preventing the first ECC write transaction from being scheduled to execute during the first time period increases utilization of the command / data bus during the first time period and the second time period.

20. A computer subsystem, comprising: A cache that stores memory transactions; And A transaction arbiter that performs the following steps: Determine that during a first time period in which a write transaction is scheduled for execution, there are not a sufficient number of pending write transactions available to mask one or more latencies associated with a first error correction code (ECC) write transaction; In response to determining that there are not a sufficient number of pending write transactions available, store the first ECC write transaction in the cache to prevent the first ECC write transaction from being scheduled for execution during the first time period; Determine that during a second time period in which a write transaction is scheduled for execution, there are a sufficient number of pending write transactions available to mask one or more latencies; And In response to determining that there are a sufficient number of pending write transactions available, schedule the first ECC write transaction for execution during the second time period.

Images