Patent ID: 12197320

DETAILED DESCRIPTION

FIG.1is an illustration of a system for dispatching requests to a flash memory, according to examples of the present disclosure. Requests may be queued based on priority and dispatched according to an arbitration scheme. The arbitration scheme may allow various types of overrides to accommodate bursts, especially high priority requests, and transactions spanning multiple requests. The arbitration scheme may allow for execution of ultra high priority control commands to instruct a first flash target to begin adjusting voltages for a read. These control commands may be quick to dispatch but may require a significant delay before issuing a read command. The arbitration scheme may follow those control commands with a low priority burst of write commands to a different flash target previously configured to write. The arbitration scheme may dispatch the entire sequence of write commands atomically to maintain data consistency. The arbitration scheme's “pipelining” of operations may improve flash memory performance. System100couples to flash controller CPU102and flash memory target104. System100may be incorporated within a flash memory controller integrated circuit. System100comprises queues106a-106ccoupled to and receiving flash memory commands from CPU102. Each queue may be a first in first out queue storing zero or more flash command records. Queues106a-106care associated with priority levels. As illustrated, queue106ais associated with a low priority level, queue106bis associated with a high priority level, and queue106cis associated with an ultra-high priority level. In some examples, write requests are assigned to low priority queue106a, read requests are assigned to high priority queue106b, and control requests are assigned to ultra-high priority queue106c. Queues106a-106chave read ports coupled to inputs of parallel mux108. Mux108has an output coupled to flash target104or a set of addressable flash targets104. Arbiter110is coupled to empty output signals of queues106a-106cenabling it to determine when each queue is empty. Arbiter110is also coupled to some output lines of mux108. In some examples, arbiter110receives signals122passing the value of arbitration flags from a dispatched flash command record. Signals133may include flag signifying transfer begin, transfer end, write transfer, read transfer, and lock. Each flag may be set by CPU102and stored within or in conjunction with each flash command record in queues106a-106c. Arbiter110drives the queue select input on mux108to select the queue from which the next request will be passed to flash target104via command lines120.

In one mode of operation, arbiter110is configured to arbitrate between queues106a-106con a strict priority basis. At each arbitration decision arbiter110will select the highest priority queue that contains requests. For example, if all three queues contain requests, arbiter110will select from ultra priority queue106cuntil that queue is empty and will then draw from high priority queue106buntil that queue is empty and will then draw from low priority queue106a. If arbiter110is drawing from low priority queue106aand a new request arrives an ultra priority queue106c, arbiter110will draw from ultra priority queue106cat the next arbitration decision.

In some examples, CPU102may have set the lock bit on a series of requests in a particular queue to force the arbiter to draw from that queue until the lock signal has been cleared. In some examples, arbiter110may exit its locked mode when that queue is empty.

In some examples, a series of requests may be logically related. For example, a burst read operation may read 32 KB of data sequentially from a flash target. The flash target may be organized internally as 16 KB pages with a transfer size of 4 KB in a single chunk. In this example, CPU102may issue a series of ten requests to complete the overall operation. CPU102may issue a read command for the first page followed by four sequential read transfer commands. The first read transfer command of the four may include a xfer_begin flag and a rd_xfer flag and the last of the four may include a xfer_end flag and a rd_xfer flag. CPU102may then issue a second page read command and four read transfer commands to complete the overall transfer.

In another example, CPU102may issue a series of five requests to complete a write transaction of 16 KB to flash target104, e.g., four write transfer requests followed by a write request. Because write requests are low priority, a read request arriving before all five requests in the write sequence can interrupt may be scheduled by arbiter110immediately, thus interrupting the larger write transaction. In some examples, arbiter110may mark all five requests as incomplete and return them to the queue. In some examples, arbiter110may signal CPU102that the write transaction was preempted. CPU102may requeue or cancel the preempted write transaction.

In some examples, CPU102may mark a sequence of commands indicating they are part of a burst transfer. CPU102may mark the first command in a sequence as Rd_xfer, signaling the start of a burst read. CPU102may mark the second command Xfer_begin signaling the start of a series of burst transfers and the last command in the sequence Xfer_end signaling the end of a read sequence. In some examples, arbiter110may continue to schedule from high priority queue106buntil arbiter110observes the Xfer_end signal.

FIG.2a flowchart of a method for dispatching requests to a flash memory, according to certain examples of the present disclosure. Method200schedules flash memory commands. At block201, commands are received from CPU102and queued in priority queues106a-106c. Write requests are queued in low priority queue106a. Read requests are queued in high priority queue106b. Other requests are queued in ultra-high priority queue106c. In some examples, additional queues may be used to further differentiate between command types. Block201may signal CPU102when any queue106is full to prevent a queue overflow.

At block202, if ultra queue106cis empty arbiter110will proceed to block208. Otherwise, at block204, arbiter110dispatches a command from ultra-high priority queue106c, dispatches that command to flash target104, and drives one or more of signals Xfer_begin, Xfer_end, Wr_xfer, Rd_xfer, and lock with values set by fields in the dispatched command. At block206, if the lock bit is asserted, arbiter110will return to block202to dispatch another ultra high priority command and will otherwise proceed to block208.

At block208, if high priority queue106bis empty, arbiter110will proceed to block214. Otherwise, at block210, arbiter110dispatches a command from high priority queue106b, dispatches that command to flash target104, and drives one or more of signals Xfer_begin, Xfer_end, Wr_xfer, Rd_xfer, and lock with values set by fields in the dispatched command. At block212, if the lock signal is asserted, arbiter110will return to block208to dispatch another high priority command, otherwise it will return to block202.

At block214, if low priority queue106ais empty, arbiter110will proceed to block202. Otherwise, at block216arbiter110dispatches a command from low priority queue106a, dispatches that command to flash target104, and drives one or more of signals Xfer_begin, Xfer_end, Wr_xfer, Rd_xfer, and lock with values set by fields in the dispatched command. At block218, if the lock signal is asserted, arbiter110will return to block214to dispatch another low priority command, otherwise it will return to block202.

FIG.3is an illustration of a system for simulating a register transfer language description of a circuit, according to certain examples of the present disclosure. System300includes CPU302and memory304. Memory304includes electronic design automation (EDA) software306and a register transfer level (RTL) description308. CPU302may be a conventional personal computer or workstation processor and memory304may be conventional memory. EDA may be conventional software for simulating, analyzing, and verifying a circuit design. EDA may include design capabilities and may prepare mask data files for manufacturing a circuit of a specified design. RTL308may be described in a one or more hardware description language files and may define the structure and operation of system100.

Although example embodiments have been described above, other variations and embodiments may be made from this disclosure without departing from the spirit and scope of these embodiments.