US20170075827A1 - I/o command id collision avoidance in a memory device - Google Patents
I/o command id collision avoidance in a memory device Download PDFInfo
- Publication number
- US20170075827A1 US20170075827A1 US14/852,111 US201514852111A US2017075827A1 US 20170075827 A1 US20170075827 A1 US 20170075827A1 US 201514852111 A US201514852111 A US 201514852111A US 2017075827 A1 US2017075827 A1 US 2017075827A1
- Authority
- US
- United States
- Prior art keywords
- command
- memory
- commands
- complete
- memory device
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/14—Handling requests for interconnection or transfer
- G06F13/16—Handling requests for interconnection or transfer for access to memory bus
- G06F13/1668—Details of memory controller
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/14—Handling requests for interconnection or transfer
- G06F13/36—Handling requests for interconnection or transfer for access to common bus or bus system
- G06F13/368—Handling requests for interconnection or transfer for access to common bus or bus system with decentralised access control
Definitions
- the invention generally relates to memory devices.
- a memory device often comprises logic that manages the flow of data going to and from a memory array.
- the memory device includes a memory controller that processes Input/Output (I/O) commands to address specific memory locations in the memory array to read data from and write data to the array.
- I/O commands can implement write operations through different ways. For example, a read-modify-write I/O command directs the memory controller to read a memory location and then write a new value to that location at once, either with a completely new value or some function of the previous value.
- the memory device is accessible from multiple master components/devices through slave logic. And, those master components can assign their own identifications (IDs) with each I/O command issued to the memory device, leaving the slave logic with potential ID collisions that can prevent the I/O commands from operating on data in the memory device.
- IDs identifications
- FIG. 1 is a block diagram of an exemplary memory device operable with a plurality of master devices.
- FIG. 2 is a flowchart of an exemplary process of the memory device of FIG. 1 .
- FIG. 3 is a more detailed block diagram of the exemplary memory device of FIG.
- FIG. 4 is a flowchart exemplarily illustrating clock cycle looping for I/O command ID collision avoidance.
- FIG. 5 is an exemplary state machine operable with the memory device of FIG. 1 .
- FIG. 6 illustrates an exemplary computer system operable to execute programmed instructions to perform desired functions.
- FIG. 1 is a block diagram of an exemplary memory device 140 operable with a plurality of master devices 120 - 1 - 120 -N (where the reference number “N” merely represents an integer greater than “1” and not necessarily equal to any other “N” reference designated herein).
- the memory device 140 employs slave logic 200 to interface with the master devices 120 through a computer bus 122 .
- the slave logic 200 is operable to receive and buffer read I/O commands and various forms of write I/O commands, including I/O commands that perform read-modify-write operations. Generally, I/O commands from the master devices 120 are processed in the order that they are received. Each of the I/O commands comprises an identification (ID) assigned by its originating master device. The slave logic 200 is operable to determine the IDs of the I/O commands so as to prevent ID collisions.
- ID identification
- master devices assign IDs to each of the I/O commands issued to the memory device.
- the slave logic 200 is likely to receive I/O commands with the same ID.
- the slave logic 200 thus extracts IDs from each of the I/O commands received and determines whether any given ID exists with an I/O command presently being processed, more specifically an I/O command operable to perform a read-modify-write operation in the memory 110 . If an I/O command with the same ID is being processed, the slave logic 200 stalls the later I/O command until the “in-progress” I/O command is complete.
- the slave logic 200 is any device, system, software, or combination thereof operable to prevent ID collisions when multiple master devices issue I/O commands with the same IDs.
- a memory controller 100 processes the I/O commands to specific locations in the memory 110 .
- each I/O command may have an address of a memory bank 111 in the memory 110 to where data is to be operated on.
- the memory controller 100 is any device, system, software, or combination thereof operable to process I/O commands to access memory locations in the memory 110 for read and write operations.
- the memory controller 100 determines an address within each I/O command that directs the read/write operation to a specific location in one of the memory banks 111 - 1 - 111 -NM (where the reference number “M” merely represents an integer greater than “1” and not necessarily equal to any other “M” reference designated herein).
- the memory controller 100 is operable to determine the order in which the I/O commands are processed is operable to “load” the I/O commands in the order that they are received so as to process the various read/write operations of the commands. For example, the memory controller 100 may load a write I/O command that writes to a specific address in one of the memory banks 111 . Then, the memory controller 100 may load a read I/O command that reads from a specific address of the memory banks 111 . Once read, the data is output from the memory 110 through a read multiplexer 112 .
- Another example of an operation that may be formed via the I/O commands includes a read-modify-write operation that reads data from a location in the memory 110 . The read-modify-write operation then writes a new value at that location in one clock cycle, either with a completely new value or some function of the previous value, as mentioned.
- the slave logic 200 and the memory controller 100 are configured “on-chip” with the memory 110 .
- the slave logic 200 and the memory controller 100 are operable with various forms of data storage devices used to implement the memory 110 .
- Some examples of the memory 110 include static random access memory (SRAM) and dynamic random access memory (DRAM).
- FIG. 2 is a flowchart of an exemplary process 150 of the slave logic 200 .
- the slave logic 200 receives an I/O command, in the process element 151 , and determines an ID of the I/O command, in the process element 152 .
- the slave logic 200 determines whether the I/O command is a read-modify-write I/O command that is operable to perform a read-modify-write operation in the memory 110 , in the process element 153 . If the I/O command is a read-modify-write I/O command, then the slave logic 200 tracks the ID of the I/O command, in the process element 154 . If the I/O command is not a read-modify-write I/O command, the slave logic 200 allows processing of the I/O command (e.g., by the memory controller 100 ), in the process element 157 .
- the slave logic 200 After tracking the ID of the read-modify-write I/O command, in the process element 154 , the slave logic 200 determines whether the I/O command has the same ID of any in-progress read-modify-write I/O command, in the process element 155 . If so, the slave logic 200 stalls the other I/O command, in the process element 156 , and loops until the previous read-modify-write I/O command is complete. Once the previous read-modify-write I/O command is complete, the slave logic 200 transfers the next read-modify-write I/O command to the memory controller 100 for processing and tracks the ID of that read-modify-write I/O command until it is complete.
- FIG. 3 is a block diagram of another exemplary memory controller 100 .
- the memory controller 100 is integrated “on chip” with the memory 110 and configured with the slave logic 200 in an ARM Advanced Microcontroller Bus Architecture (AMBA).
- the slave logic 200 uses Advanced eXtensible Interface (AXI) 4, the fourth generation of the AMBA interface specification, to interface with a plurality of master I/O devices (e.g., master devices 120 of FIG. 1 ).
- the slave logic 200 comprises, among other things, a command FIFO (First In First Out) buffer 201 , a write data buffer 203 , write response logic 204 , a read data controller 205 , and a command queue 202 .
- AXI Advanced eXtensible Interface
- the command FIFO buffer 201 is operable to receive and buffer read I/O commands (via an AXI4 AR interface) and various forms of write I/O commands (via an AXI4 AW interface), including read-modify-write operations.
- Data associated with the write commands is processed through the write data buffer 203 (via an AXI4 W interface).
- the I/O commands are queued for processing in the command queue 202 .
- the write response logic 204 replies to the appropriate master device issuing the I/O command (via an AXI4 B interface).
- the data is transferred from the memory 110 (via the read multiplexer 112 ) to the appropriate master device issuing the I/O command (via an AXI4 R interface).
- the command FIFO buffer 201 receives I/O commands from the master devices 120 such that they may be processed in the order that they are received. Each of the I/O commands comprises an identification (ID) assigned by its originating master device 120 .
- the command queue 202 is operable to determine the IDs of the I/O commands so as to prevent ID collisions.
- master devices 120 assign IDs to each of the I/O commands issued to the memory device 140 .
- the command FIFO buffer 201 is likely to receive I/O commands with the same ID.
- the command queue 202 thus extracts IDs from each of the I/O commands received and determines whether any given ID exists with a read-modify-write I/O command presently being processed. If a read-modify-write I/O command with the same ID is being processed, the command queue 202 determines whether the subsequent I/O command is also a read-modify-write command. If so, the command queue 202 stalls the subsequent I/O command until the in-progress I/O command is complete. Otherwise, the command queue 202 to assess the subsequent I/O command to the memory controller 100 for processing.
- the command queue 202 is operable to receive a first read-modify-write I/O command from a first master device 120 while a second read-modify-write I/O command is presently operating on data in the memory 110 .
- the second read-modify-write I/O command is from a second different master device 120 but has the same ID as the first read-modify-write I/O command.
- the command queue 202 stalls the first read-modify-write I/O command until the second read-modify-write I/O command is complete. In the meantime, the command queue 202 tracks the ID of the second read-modify-write I/O command until the second read-modify-write I/O command is complete.
- the command queue 202 allows the third I/O command to be processed by the memory controller 100 regardless of its ID even while the first I/O command is in progress.
- FIG. 4 is a flowchart of a process 250 exemplarily illustrating ID tracking for AXI I/O commands.
- the command FIFO 201 of the slave logic 200 receives an AXI I/O command, in the process element 251 , and then determines whether the AXI I/O command is a read-modify-write I/O command, the process element 252 . If so, the command queue 202 loads the ID of the AXI I/O command into the ID tracker 253 where it is retained until the read-modify-write operation of the AXI I/O command is processed.
- the command queue 202 determines whether the ID is equal to an ID already existing in the ID tracker 253 , in the process element 254 . If the AXI I/O command is not an AXI read-modify-write I/O command, then the command queue 202 allows the AXI I/O command to be processed by the memory controller 100 , in the process element 256 .
- the command queue 202 stalls the subsequent AXI I/O command, in the process element 255 and loops until the ID of the previous AXI read-modify-write I/O command is complete. Otherwise, the command queue 202 allows the AXI read-modify-write I/O command to be processed by the memory controller 100 , in the process element 256 .
- a first master device 120 - 1 i.e., of FIG. 1
- That I/O command will have an ID associated with it as assigned by the master device 120 - 1 .
- the command FIFO 201 will intake that I/O command and transfer it to the command queue 202 on a first in first out basis.
- a second master device 120 - 2 issues an AXI read-modify-write I/O command to the memory device 140 with an ID that is the same as that issued by the first master device 120 - 1 .
- the command queue 202 will load the ID of the first I/O command into the ID tracker 253 and allow it to be processed by the memory controller 100 .
- the command queue 202 will inspect the AXI read-modify-write I/O command from the second master device 120 - 2 , load its ID into the ID tracker 253 , and determine whether another matching ID exists in the ID tracker 253 .
- the command queue 202 will stall the second AXI read-modify-write I/O command from the second master device 120 - 2 until the previous AXI read-modify-write I/O command from the first master device 120 - 1 is complete and its ID has been flushed from the ID tracker 253 . If a third AXI I/O command is received by the command FIFO 201 from another master device 120 - 3 and that I/O command is, for example, a read I/O command, then the command queue 202 allows the third AXI I/O command to be processed by the memory controller 100 regardless of its ID.
- FIG. 5 is an exemplary state machine 275 operable with the command queue 202 .
- the command queue 202 receives the AXI I/O commands from the command FIFO 201 and inspects the I/O commands via command detector logic 276 to determine whether the commands are read-modify-write I/O commands. For those AXI I/O commands that are read-modify-write I/O commands, ID extractor logic 277 extracts the ID and transfers it to the ID tracker 253 where it remains until the read-modify-write operation of the AXI I/O command is complete.
- the ID tracker 253 comprises six buffers corresponding to the number of cycles it will take for a read-modify-write operation to complete. Accordingly, for any subsequent AXI read-modify-write I/O command, the ID that is extracted from the subsequent command is compared via the comparator 278 to the ID existing in the ID tracker 253 . If no matching ID exists in the ID tracker 253 , the comparator 278 allows the subsequent AXI read-modify-write I/O command to be processed by the memory controller 100 (in the process element 279 ). Otherwise, the subsequent AXI read-modify-write I/O command is stalled until the previous AXI read-modify-write I/O command is complete.
- the ID tracker 253 can be configured with any number of buffers to accommodate the number of clock cycles it takes for any given I/O command. In some embodiments, the number of buffers in the ID tracker 253 can be configured on the fly to accommodate various I/O command processing durations.
- FIG. 6 illustrates a computing system 300 in which a computer readable medium 306 may provide instructions for performing any of the methods disclosed herein.
- the invention can take the form of a computer program product accessible from the computer readable medium 306 providing program code for use by or in connection with a computer or any instruction execution system.
- the computer readable medium 306 can be any apparatus that can tangibly store the program for use by or in connection with the instruction execution system, apparatus, or device, including the computer system 300 .
- the medium 306 can be any tangible electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device).
- Examples of a computer readable medium 306 include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk.
- Some examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.
- the computing system 300 can include one or more processors 302 coupled directly or indirectly to memory 308 through a system bus 310 .
- the memory 308 can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code is retrieved from bulk storage during execution.
- I/O devices 304 can be coupled to the system either directly or through intervening I/O controllers.
- Network adapters may also be coupled to the system to enable the computing system 300 to become coupled to other data processing systems, such as through host systems interfaces 312 , or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Memory System (AREA)
Abstract
Description
- The invention generally relates to memory devices.
- A memory device often comprises logic that manages the flow of data going to and from a memory array. Often, the memory device includes a memory controller that processes Input/Output (I/O) commands to address specific memory locations in the memory array to read data from and write data to the array. Depending on the command set of the memory controller, the I/O commands can implement write operations through different ways. For example, a read-modify-write I/O command directs the memory controller to read a memory location and then write a new value to that location at once, either with a completely new value or some function of the previous value. In some instances, the memory device is accessible from multiple master components/devices through slave logic. And, those master components can assign their own identifications (IDs) with each I/O command issued to the memory device, leaving the slave logic with potential ID collisions that can prevent the I/O commands from operating on data in the memory device.
- Some embodiments of the present invention are now described, by way of example only, and with reference to the accompanying drawings. The same reference number represents the same element or the same type of element on all drawings.
-
FIG. 1 is a block diagram of an exemplary memory device operable with a plurality of master devices. -
FIG. 2 is a flowchart of an exemplary process of the memory device ofFIG. 1 . -
FIG. 3 is a more detailed block diagram of the exemplary memory device of FIG. -
FIG. 4 is a flowchart exemplarily illustrating clock cycle looping for I/O command ID collision avoidance. -
FIG. 5 is an exemplary state machine operable with the memory device ofFIG. 1 . -
FIG. 6 illustrates an exemplary computer system operable to execute programmed instructions to perform desired functions. - The figures and the following description illustrate specific exemplary embodiments of the invention. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the invention and are included within the scope of the invention. Furthermore, any examples described herein are intended to aid in understanding the principles of the invention and are to be construed as being without limitation to such specifically recited examples and conditions. As a result, the invention is not limited to the specific embodiments or examples described below.
-
FIG. 1 is a block diagram of anexemplary memory device 140 operable with a plurality of master devices 120-1-120-N (where the reference number “N” merely represents an integer greater than “1” and not necessarily equal to any other “N” reference designated herein). In this embodiment, thememory device 140 employsslave logic 200 to interface with themaster devices 120 through a computer bus 122. - The
slave logic 200 is operable to receive and buffer read I/O commands and various forms of write I/O commands, including I/O commands that perform read-modify-write operations. Generally, I/O commands from themaster devices 120 are processed in the order that they are received. Each of the I/O commands comprises an identification (ID) assigned by its originating master device. Theslave logic 200 is operable to determine the IDs of the I/O commands so as to prevent ID collisions. - For example, master devices assign IDs to each of the I/O commands issued to the memory device. As master devices generally do not keep track of how other master devices assign IDs, the
slave logic 200 is likely to receive I/O commands with the same ID. Theslave logic 200 thus extracts IDs from each of the I/O commands received and determines whether any given ID exists with an I/O command presently being processed, more specifically an I/O command operable to perform a read-modify-write operation in thememory 110. If an I/O command with the same ID is being processed, theslave logic 200 stalls the later I/O command until the “in-progress” I/O command is complete. In this regard, theslave logic 200 is any device, system, software, or combination thereof operable to prevent ID collisions when multiple master devices issue I/O commands with the same IDs. - A
memory controller 100 processes the I/O commands to specific locations in thememory 110. For example, each I/O command may have an address of amemory bank 111 in thememory 110 to where data is to be operated on. Thememory controller 100 is any device, system, software, or combination thereof operable to process I/O commands to access memory locations in thememory 110 for read and write operations. In processing the I/O commands, thememory controller 100 determines an address within each I/O command that directs the read/write operation to a specific location in one of the memory banks 111-1-111-NM (where the reference number “M” merely represents an integer greater than “1” and not necessarily equal to any other “M” reference designated herein). - The
memory controller 100 is operable to determine the order in which the I/O commands are processed is operable to “load” the I/O commands in the order that they are received so as to process the various read/write operations of the commands. For example, thememory controller 100 may load a write I/O command that writes to a specific address in one of thememory banks 111. Then, thememory controller 100 may load a read I/O command that reads from a specific address of thememory banks 111. Once read, the data is output from thememory 110 through aread multiplexer 112. Another example of an operation that may be formed via the I/O commands includes a read-modify-write operation that reads data from a location in thememory 110. The read-modify-write operation then writes a new value at that location in one clock cycle, either with a completely new value or some function of the previous value, as mentioned. - In this embodiment, the
slave logic 200 and thememory controller 100 are configured “on-chip” with thememory 110. Generally, theslave logic 200 and thememory controller 100 are operable with various forms of data storage devices used to implement thememory 110. Some examples of thememory 110 include static random access memory (SRAM) and dynamic random access memory (DRAM). -
FIG. 2 is a flowchart of anexemplary process 150 of theslave logic 200. In this embodiment, theslave logic 200 receives an I/O command, in theprocess element 151, and determines an ID of the I/O command, in theprocess element 152. Theslave logic 200 and then determines whether the I/O command is a read-modify-write I/O command that is operable to perform a read-modify-write operation in thememory 110, in theprocess element 153. If the I/O command is a read-modify-write I/O command, then theslave logic 200 tracks the ID of the I/O command, in theprocess element 154. If the I/O command is not a read-modify-write I/O command, theslave logic 200 allows processing of the I/O command (e.g., by the memory controller 100), in theprocess element 157. - After tracking the ID of the read-modify-write I/O command, in the
process element 154, theslave logic 200 determines whether the I/O command has the same ID of any in-progress read-modify-write I/O command, in theprocess element 155. If so, theslave logic 200 stalls the other I/O command, in theprocess element 156, and loops until the previous read-modify-write I/O command is complete. Once the previous read-modify-write I/O command is complete, theslave logic 200 transfers the next read-modify-write I/O command to thememory controller 100 for processing and tracks the ID of that read-modify-write I/O command until it is complete. -
FIG. 3 is a block diagram of anotherexemplary memory controller 100. In this embodiment, thememory controller 100 is integrated “on chip” with thememory 110 and configured with theslave logic 200 in an ARM Advanced Microcontroller Bus Architecture (AMBA). Theslave logic 200 uses Advanced eXtensible Interface (AXI) 4, the fourth generation of the AMBA interface specification, to interface with a plurality of master I/O devices (e.g.,master devices 120 ofFIG. 1 ). Theslave logic 200 comprises, among other things, a command FIFO (First In First Out)buffer 201, awrite data buffer 203, writeresponse logic 204, aread data controller 205, and acommand queue 202. - The
command FIFO buffer 201 is operable to receive and buffer read I/O commands (via an AXI4 AR interface) and various forms of write I/O commands (via an AXI4 AW interface), including read-modify-write operations. Data associated with the write commands is processed through the write data buffer 203 (via an AXI4 W interface). The I/O commands are queued for processing in thecommand queue 202. Once a write I/O command is processed and the data is written to thememory 110, thewrite response logic 204 replies to the appropriate master device issuing the I/O command (via an AXI4 B interface). Similarly, when a read I/O command is processed and the data is read from thememory 110, the data is transferred from the memory 110 (via the read multiplexer 112) to the appropriate master device issuing the I/O command (via an AXI4 R interface). - The
command FIFO buffer 201 receives I/O commands from themaster devices 120 such that they may be processed in the order that they are received. Each of the I/O commands comprises an identification (ID) assigned by its originatingmaster device 120. Thecommand queue 202 is operable to determine the IDs of the I/O commands so as to prevent ID collisions. - For example,
master devices 120 assign IDs to each of the I/O commands issued to thememory device 140. Again, because master devices generally do not keep track of how other master devices assign IDs, thecommand FIFO buffer 201 is likely to receive I/O commands with the same ID. Thecommand queue 202 thus extracts IDs from each of the I/O commands received and determines whether any given ID exists with a read-modify-write I/O command presently being processed. If a read-modify-write I/O command with the same ID is being processed, thecommand queue 202 determines whether the subsequent I/O command is also a read-modify-write command. If so, thecommand queue 202 stalls the subsequent I/O command until the in-progress I/O command is complete. Otherwise, thecommand queue 202 to assess the subsequent I/O command to thememory controller 100 for processing. - In other words, the
command queue 202 is operable to receive a first read-modify-write I/O command from afirst master device 120 while a second read-modify-write I/O command is presently operating on data in thememory 110. The second read-modify-write I/O command is from a seconddifferent master device 120 but has the same ID as the first read-modify-write I/O command. Thecommand queue 202 stalls the first read-modify-write I/O command until the second read-modify-write I/O command is complete. In the meantime, thecommand queue 202 tracks the ID of the second read-modify-write I/O command until the second read-modify-write I/O command is complete. And, if a third I/O command is received by thecommand FIFO 201 and that I/O command is not a read-modify-write, thecommand queue 202 allows the third I/O command to be processed by thememory controller 100 regardless of its ID even while the first I/O command is in progress. -
FIG. 4 is a flowchart of aprocess 250 exemplarily illustrating ID tracking for AXI I/O commands. In this embodiment, thecommand FIFO 201 of the slave logic 200 (FIG. 3 ) receives an AXI I/O command, in theprocess element 251, and then determines whether the AXI I/O command is a read-modify-write I/O command, theprocess element 252. If so, thecommand queue 202 loads the ID of the AXI I/O command into theID tracker 253 where it is retained until the read-modify-write operation of the AXI I/O command is processed. Additionally, thecommand queue 202 determines whether the ID is equal to an ID already existing in theID tracker 253, in theprocess element 254. If the AXI I/O command is not an AXI read-modify-write I/O command, then thecommand queue 202 allows the AXI I/O command to be processed by thememory controller 100, in theprocess element 256. - If the AXI I/O command comprises an ID that is the same as an ID existing in the
ID tracker 253 and the I/O command is a read-modify-write command, then thecommand queue 202 stalls the subsequent AXI I/O command, in theprocess element 255 and loops until the ID of the previous AXI read-modify-write I/O command is complete. Otherwise, thecommand queue 202 allows the AXI read-modify-write I/O command to be processed by thememory controller 100, in theprocess element 256. - To illustrate, suppose a first master device 120-1 (i.e., of
FIG. 1 ) issues an AXI read-modify-write I/O command to thememory device 140. That I/O command will have an ID associated with it as assigned by the master device 120-1. Thecommand FIFO 201 will intake that I/O command and transfer it to thecommand queue 202 on a first in first out basis. Then, suppose a second master device 120-2 issues an AXI read-modify-write I/O command to thememory device 140 with an ID that is the same as that issued by the first master device 120-1. Thecommand queue 202 will load the ID of the first I/O command into theID tracker 253 and allow it to be processed by thememory controller 100. Thecommand queue 202 will inspect the AXI read-modify-write I/O command from the second master device 120-2, load its ID into theID tracker 253, and determine whether another matching ID exists in theID tracker 253. As the first AXI read-modify-write I/O command is being processed, its ID will remain in theID tracker 253 until it is complete. Thecommand queue 202 will stall the second AXI read-modify-write I/O command from the second master device 120-2 until the previous AXI read-modify-write I/O command from the first master device 120-1 is complete and its ID has been flushed from theID tracker 253. If a third AXI I/O command is received by thecommand FIFO 201 from another master device 120-3 and that I/O command is, for example, a read I/O command, then thecommand queue 202 allows the third AXI I/O command to be processed by thememory controller 100 regardless of its ID. -
FIG. 5 is anexemplary state machine 275 operable with thecommand queue 202. In this embodiment, thecommand queue 202 receives the AXI I/O commands from thecommand FIFO 201 and inspects the I/O commands viacommand detector logic 276 to determine whether the commands are read-modify-write I/O commands. For those AXI I/O commands that are read-modify-write I/O commands,ID extractor logic 277 extracts the ID and transfers it to theID tracker 253 where it remains until the read-modify-write operation of the AXI I/O command is complete. - As illustrated, the
ID tracker 253 comprises six buffers corresponding to the number of cycles it will take for a read-modify-write operation to complete. Accordingly, for any subsequent AXI read-modify-write I/O command, the ID that is extracted from the subsequent command is compared via thecomparator 278 to the ID existing in theID tracker 253. If no matching ID exists in theID tracker 253, thecomparator 278 allows the subsequent AXI read-modify-write I/O command to be processed by the memory controller 100 (in the process element 279). Otherwise, the subsequent AXI read-modify-write I/O command is stalled until the previous AXI read-modify-write I/O command is complete. - It should be noted that the invention is not intended to be limited to the number of clock cycles it takes to process an I/O command. The
ID tracker 253 can be configured with any number of buffers to accommodate the number of clock cycles it takes for any given I/O command. In some embodiments, the number of buffers in theID tracker 253 can be configured on the fly to accommodate various I/O command processing durations. - Additionally, the invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In one embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.
FIG. 6 illustrates acomputing system 300 in which a computerreadable medium 306 may provide instructions for performing any of the methods disclosed herein. - Furthermore, the invention can take the form of a computer program product accessible from the computer
readable medium 306 providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, the computerreadable medium 306 can be any apparatus that can tangibly store the program for use by or in connection with the instruction execution system, apparatus, or device, including thecomputer system 300. - The medium 306 can be any tangible electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device). Examples of a computer
readable medium 306 include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Some examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD. - The
computing system 300, suitable for storing and/or executing program code, can include one ormore processors 302 coupled directly or indirectly to memory 308 through asystem bus 310. The memory 308 can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code is retrieved from bulk storage during execution. Input/output or I/O devices 304 (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers. Network adapters may also be coupled to the system to enable thecomputing system 300 to become coupled to other data processing systems, such as through host systems interfaces 312, or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/852,111 US20170075827A1 (en) | 2015-09-11 | 2015-09-11 | I/o command id collision avoidance in a memory device |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/852,111 US20170075827A1 (en) | 2015-09-11 | 2015-09-11 | I/o command id collision avoidance in a memory device |
Publications (1)
Publication Number | Publication Date |
---|---|
US20170075827A1 true US20170075827A1 (en) | 2017-03-16 |
Family
ID=58238064
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/852,111 Abandoned US20170075827A1 (en) | 2015-09-11 | 2015-09-11 | I/o command id collision avoidance in a memory device |
Country Status (1)
Country | Link |
---|---|
US (1) | US20170075827A1 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20180074757A1 (en) * | 2016-09-09 | 2018-03-15 | Toshiba Memory Corporation | Switch and memory device |
US10031689B2 (en) * | 2016-09-15 | 2018-07-24 | Western Digital Technologies, Inc. | Stream management for storage devices |
US20190332321A1 (en) * | 2018-04-27 | 2019-10-31 | Silicon Motion Inc. | Method for controlling storage device |
CN112466351A (en) * | 2019-09-06 | 2021-03-09 | 爱思开海力士有限公司 | Semiconductor device with a plurality of transistors |
US10942879B2 (en) | 2018-12-17 | 2021-03-09 | Micron Technology, Inc. | Handling operation collisions in a non-volatile memory |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6535941B1 (en) * | 1999-11-08 | 2003-03-18 | International Business Machines Corporation | Method and apparatus for avoiding data bus grant starvation in a non-fair, prioritized arbiter for a split bus system with independent address and data bus grants |
US20050138252A1 (en) * | 2003-12-23 | 2005-06-23 | Arm Limited | Transaction request servicing mechanism |
US20050177663A1 (en) * | 2004-01-17 | 2005-08-11 | Samsung Electronics Co., Ltd. | Method of using bus and bus interface |
US20080235421A1 (en) * | 2007-03-22 | 2008-09-25 | Siva Shankar Jayaratnam | Technique and apparatus to optimize inter-port memory transaction sequencing on a multi-ported memory controller unit |
US20120042105A1 (en) * | 2010-01-19 | 2012-02-16 | Panasonic Corporation | Bus arbitration apparatus |
-
2015
- 2015-09-11 US US14/852,111 patent/US20170075827A1/en not_active Abandoned
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6535941B1 (en) * | 1999-11-08 | 2003-03-18 | International Business Machines Corporation | Method and apparatus for avoiding data bus grant starvation in a non-fair, prioritized arbiter for a split bus system with independent address and data bus grants |
US20050138252A1 (en) * | 2003-12-23 | 2005-06-23 | Arm Limited | Transaction request servicing mechanism |
US20050177663A1 (en) * | 2004-01-17 | 2005-08-11 | Samsung Electronics Co., Ltd. | Method of using bus and bus interface |
US20080235421A1 (en) * | 2007-03-22 | 2008-09-25 | Siva Shankar Jayaratnam | Technique and apparatus to optimize inter-port memory transaction sequencing on a multi-ported memory controller unit |
US20120042105A1 (en) * | 2010-01-19 | 2012-02-16 | Panasonic Corporation | Bus arbitration apparatus |
Cited By (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10445018B2 (en) * | 2016-09-09 | 2019-10-15 | Toshiba Memory Corporation | Switch and memory device |
USRE49273E1 (en) * | 2016-09-09 | 2022-11-01 | Kioxia Corporation | Switch and memory device |
US20180074757A1 (en) * | 2016-09-09 | 2018-03-15 | Toshiba Memory Corporation | Switch and memory device |
US10031689B2 (en) * | 2016-09-15 | 2018-07-24 | Western Digital Technologies, Inc. | Stream management for storage devices |
US10976958B2 (en) * | 2018-04-27 | 2021-04-13 | Silicon Motion, Inc. | Method for controlling storage device |
US20190332321A1 (en) * | 2018-04-27 | 2019-10-31 | Silicon Motion Inc. | Method for controlling storage device |
US11301175B2 (en) | 2018-04-27 | 2022-04-12 | Silicon Motion, Inc. | Method for controlling storage device |
WO2020131251A3 (en) * | 2018-12-17 | 2021-03-25 | Micron Technology, Inc. | Handling operation collisions in a non-volatile memory |
KR20210078570A (en) * | 2018-12-17 | 2021-06-28 | 마이크론 테크놀로지, 인크. | Handling Behavioral Conflicts in Non-Volatile Memory |
KR102341240B1 (en) | 2018-12-17 | 2021-12-21 | 마이크론 테크놀로지, 인크. | Handling Behavioral Conflicts in Non-Volatile Memory |
US10942879B2 (en) | 2018-12-17 | 2021-03-09 | Micron Technology, Inc. | Handling operation collisions in a non-volatile memory |
EP3899738A4 (en) * | 2018-12-17 | 2022-09-21 | Micron Technology, Inc. | Handling operation collisions in a non-volatile memory |
US11481348B2 (en) | 2018-12-17 | 2022-10-25 | Micron Technology, Inc. | Handling operation collisions in a non-volatile memory |
US11201149B2 (en) * | 2019-09-06 | 2021-12-14 | SK Hynix Inc. | Semiconductor devices |
CN112466351A (en) * | 2019-09-06 | 2021-03-09 | 爱思开海力士有限公司 | Semiconductor device with a plurality of transistors |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9870172B2 (en) | Address collision avoidance in a memory device | |
US20170075827A1 (en) | I/o command id collision avoidance in a memory device | |
JP7313381B2 (en) | Embedded scheduling of hardware resources for hardware acceleration | |
US9021228B2 (en) | Managing out-of-order memory command execution from multiple queues while maintaining data coherency | |
US20160283111A1 (en) | Read operations in memory devices | |
US9508409B2 (en) | Apparatuses and methods for implementing masked write commands | |
KR20090046609A (en) | Processor and memory control method | |
CN105095128B (en) | Interrupt processing method and interrupt controller | |
KR101891387B1 (en) | Reads and writes between contiguous data block and noncontiguous sets of logical address blocks in a persistent storage device | |
WO2016169318A1 (en) | Access method, device and system for expanding memory | |
US20080126641A1 (en) | Methods and Apparatus for Combining Commands Prior to Issuing the Commands on a Bus | |
US9607120B2 (en) | Implementing system irritator accelerator FPGA unit (AFU) residing behind a coherent attached processors interface (CAPI) unit | |
US9032162B1 (en) | Systems and methods for providing memory controllers with memory access request merging capabilities | |
US8954644B2 (en) | Apparatus and method for controlling memory | |
US8713262B2 (en) | Managing a spinlock indicative of exclusive access to a system resource | |
CN105453043B (en) | Providing queue barriers when unsupported by I/O protocols or target devices | |
US11694732B2 (en) | Active random access memory | |
US20160371082A1 (en) | Instruction context switching | |
US20190012096A1 (en) | Apparatus and method for enforcing timing requirements for a memory device | |
US20210109762A1 (en) | Multi-die and multi-core computing platform and booting method for the same | |
CN102053913B (en) | Memory device and data access method thereof | |
EP2801913A1 (en) | Memory control apparatus and method | |
US9524769B2 (en) | Smart in-module refresh for DRAM | |
US20160048463A1 (en) | Assignment control method, system, and recording medium | |
US11455261B2 (en) | First boot with one memory channel |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:WARD, ROBERT E.;LESSARD, BRIAN;REEL/FRAME:036546/0624 Effective date: 20150911 |
|
AS | Assignment |
Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH CAROLINA Free format text: PATENT SECURITY AGREEMENT;ASSIGNOR:AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD.;REEL/FRAME:037808/0001 Effective date: 20160201 Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH Free format text: PATENT SECURITY AGREEMENT;ASSIGNOR:AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD.;REEL/FRAME:037808/0001 Effective date: 20160201 |
|
AS | Assignment |
Owner name: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD., SINGAPORE Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS COLLATERAL AGENT;REEL/FRAME:041710/0001 Effective date: 20170119 Owner name: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS COLLATERAL AGENT;REEL/FRAME:041710/0001 Effective date: 20170119 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |