Emulating one tape protocol of flash memory to a different type protocol of flash memory

[0002] 1. Field of the Invention

[0003] The invention relates to flash memory cards and particularly to flash memory cards that can emulate the protocol of one type of flash memory using flash memory devices conforming to a different protocol.

[0004] 2. Background

[0005] Linear flash memory devices have enjoyed wide and growing popularity in devices such as flash memory cards, combination devices such as flash/modem PC cards, and embedded systems such as routers, hubs, switches used in networks. Flash memories are solid state chips that can store data without requiring power to retain their data. Thus, they are often used in places where one might otherwise use a hard disk of a floppy disk to store data. However, because they are solid state devices, they are more rugged and can be made into very small sizes. One example is the very popular linear flash memory PCMCIA card.

[0006] Referring to FIG. 1, the basic components of flash memory devices are a controller 110 and one or more flash memory chips 120. A host device 100 reads or writes data from/to the flash memory chip 120 via an interface 105 such as a PCMCIA interface, USB, or any other device. The accessing of the desired memory part of the memory inside the flash memory chip 120 that contains the desired data is called “addressing.” In prior art flash memory devices, the controller ordinarily simply frames and queues addressing signals so that the flash memories receive them in the correct format. Advanced flash devices can provide further functionality to the controller, for example, by keeping a record of bad memory cells and remapping addresses for those bad cells, by eliminating errors in bad cells using error correcting codes, by load leveling to spread wear over all cells of the flash memory.

[0007] There is a set of steps that must be done for a host computer to address a given part of the memory. These steps are performed by two sets of components: the controller 110 on the device, such as the flash PC card, and addressing hardware (not shown) in the flash memory chips themselves 120. To read or write data, besides the data involved (e.g., a series of bits that represents the character “A,”) the host system 100 has to generate a command, for example, a command to read from a particular memory location on the flash chip 120. Flash chips are currently made to understand two sets of commands, which the controller can generate. One set of commands is standard (called “Command-Command Interface” or “CCI”) and most manufacturers provide support for this set of commands. Another set of commands is specific to the manufacturer of the flash chips, and if a controller is designed to generate the commands for a particular manufacturer, the controller cannot be used with another manufacturer's chips. Also, sometimes device manufacturers design their systems (the “host” systems, which are the ones the flash cards are plugged into) to use the specific command set of the manufacturer to achieve extended capabilities or higher speed that are available from the manufacturer-specific command protocol. However, this has the disadvantage that it locks the card manufacturer into a particular flash manufacturer's specification so long as the card manufacturer is supplying cards to the host system manufacturer. Thus, the card manufacturer is prevented from switching to a different supplier of flash memory chips, should cost performance characteristics of that different supplier make that an attractive option.

[0008] One type of flash memory device that translates between one type of command and another type of command is an ATA-type controller. The host applies block-level commands to the flash device and an internal controller translates these to linear addresses. Thus, in such translations, the numbers of input and output address signal lines may differ on each side of the translation.

[0009] The invention provides a translator inside a flash memory controller that translates commands from a host system conforming to the protocol of one flash chip manufacturer into commands that are recognized by the flash chips of another manufacturer. The result is that host system manufacturers may design systems to use the extended capabilities of a particular flash chip manufacture's command set knowing that the chip's of another manufacturer could be substituted in the flash memory cards the host system accepts. This allows the supplier of the cards to supply cards with the highest possible cost/performance ratio.

[0010] One of the issues facing the designer of an interface is that there is that there is rarely a one-to-one correspondence of states between the state-machine of one protocol and another. Thus, translating commands from one device to emulate another can present problems. Another source of difficulty is when the host is designed to expect certain responses at a certain time. If there is a delay, the host may never believe a valid response may be forthcoming.

[0011] There are conditions that can help to get around these difficulties. First, commands from one protocol can be delivered to a controller while the controller isolates the flash memory from the host. After the commands of protocol 1 are received and validated as a recognized command, the controller can generate the commands using the second protocol. This is a robust mechanism for working around the lack of a one-to-one correspondence between states during command and argument-passing from the host to the controller and what would otherwise exist if the controller were simply addressing the flash memory directly. Second, the flash memory that is used to substitute for the one the host is programmed to expect should be faster than the latter. In this way, the time lag between host sending commands to the controller and the controller generating new commands in tandem, then waiting for the response is not very great. Where possible, if a portion of the protocol 2 command can be generated before a complete protocol 1 command is validated by the controller, one or more bus cycles can be saved. In this case, if the protocol 1 command is invalid, the controller can deliberately force a invalid command that would reset the flash memory receiving the protocol 2 command.

[0012] The invention will be described in connection with certain preferred embodiments, with reference to the following illustrative figures so that it may be more fully understood. With reference to the figures, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of the preferred embodiments of the present invention only, and are presented in the cause of providing what is believed to be the most useful and readily understood description of the principles and conceptual aspects of the invention. In this regard, no attempt is made to show structural details of the invention in more detail than is necessary for a fundamental understanding of the invention, the description taken with the drawings making apparent to those skilled in the art how the several forms of the invention may be embodied in practice.

[0013] FIG. 1 is block diagram of the functional components of a prior art flash memory device such as a PCMCIA flash card.

[0014] FIG. 2A is a block diagram of the functional components of a flash memory device, such as a PCMCIA flash card, according to an embodiment of the invention.

[0015] FIG. 2B is a block diagram of the functional components of a flash memory device, such as a PCMCIA flash card, according to another embodiment of the invention.

[0016] FIG. 3 is a state diagram illustrating the process of translation of commands of one protocol to commands of another protocol according to an embodiment of the invention.

[0017] FIG. 4 is a state diagram illustrating the process of translation of commands of one protocol to commands of another protocol according to another embodiment of the invention.

[0018] Referring to FIG. 2A, a translation controller 215 translates control signals that include data, address, and control signals from a first to a second protocol. The protocol 2 commands are thus generated and applied to the conventional controller 210. Thus, a flash memory 220 that conforms to one protocol can be used in a device that is usable with a host programmed to interface with flash memories conforming to a different protocol. Controller 210 could be an ASIC, a programmable processor, an FPGA, or any other suitable device.

[0019] Referring now to FIG. 2B, the translation and conventional control functions can be combined in a single controller device 225.

[0020] Referring now to FIG. 3, the state machine within the translation controller 215 is represented by a flow diagram that begins in a default read mode 235. Each state is separated from an upstream state by one clock cycle. During a clock cycle, a part of a command may be received and the data in that part determines which transition is followed in the state diagram. The actual state diagram shown in completely figurative and is only intended to suggest the process of parsing the protocol 1 command until a specific command has been identified.

[0021] Beginning at the top of the flow diagram, most of the time, flash memory devices are used for reading. In addition, when a read operation is performed, generally there is no problem with matching states of the memory device with the protocol used by the host. That is, the controller can simply pass signals through by merely framing and queuing the address to provide addressing in a fashion that involves no translation steps. This is indicated at 270.

[0022] If a command such as a sector erase, chip erase, program, manufacturer inquiry, etc. the command is validated according to logic that is specific to protocol 1 in step 240. That is, in step 240 a procedure is executed the result of which is to determine the specific command and argument data (e.g., an address) that must be sent to the protocol 2 flash memory to provide what the host 100 expects. If the command received is invalid, the flow is escaped and control returns to step 235. If a valid command is completely received, a corresponding command is generated under protocol 2 and applied to the signal lines of the flash memory in step 250. Then in step 260, data from the flash memory may be read, or a reply, or a time interval invoked. Alternatively at step 260 nothing (NOP) may be done, depending on the particular command and the nature of protocol 2. If a reply is required by protocol 1, that reply is then generated at step 275. Finally control returns to step 235.

[0023] Referring now to FIG. 4, to save time, which may be critical if the host is programmed to expect a response within a limited time, it may be possible to parse the command so that part of a protocol 2 command is generated while the protocol 1 command is further parsed. In the embodiment of FIG. 4, it is determined at state S5 that the protocol 1 command, not all of which has been received at state S5, corresponds to one of two protocol 1 commands (A and B), each of which has the same first part. To exploit this for time saving, after state S5, at step 300, the part of the protocol 1 command that is common to commands A and B is generated. Simultaneously, instantly thereafter (i.e., within the same clock cycle) the next part of the protocol 1 command is received in state S7 and which decides whether the next part of the protocol 2 command should be command A or command B. Control passes to step S310 or 320 depending on which.

[0024] The first part of the protocol 1 command may be good but the second part may prove the protocol 1 command as a whole invalid. Thus, one possibility at state S7 is that an invalid command will be identified in which case it is necessary to call off the first part. Since the first part of a protocol 2 command has been generated, the protocol 2 command must be “called off” and this can be accomplished in various ways, one of which is to generate an invalid protocol 2 second part “queer command” that will be rejected by the succeeding stage of the controller 210.

[0025] It will be evident to those skilled in the art that the invention is not limited to the details of the foregoing illustrative embodiments, and that the present invention may be embodied in other specific forms without departing from the spirit or essential attributes thereof. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.